Re: -current amd64 packages not updated? Impatient or broken?
just following up on myself for anyone who might make the same mistake... turns out i had not read-recently or forgotten how to "follow -current" correctly... https://www.openbsd.org/faq/current.html in particular, i had downloaded a snapshot and dd'ed onto a usb-stick but chosen (I)nstall when booting from the stick - which apparently is totally wrong... always do an (U)pgrade to a currently running system - doh... i had wiped my hdd completely beforehand - oops... i went back, read the FAQ completely, followed the simpler solution which is to use the release-image on USB, (I)nstall to the hdd, syspatch up to -stable (maybe not necessary?), and then just did a "sysupgrade -s" and voia - everything just worked fine... sorry for the noise - thank you for the clear man-pages/faqs and im back to a happy camper ! sincerely, harold. On Tue, Jan 12, 2021 at 3:46 AM harold felton wrote: > symptom: did a "pkg_add wget" on a recent-snapshot fails with bad-major > c++ errors... am i being impatient also ? > > i remember reading (07-08 jan) that the pkg_add compiles were taking > awhile to grind thru... it is also quite-possible that i have hit a gap > between the snapshot i downloaded and the matching build - for my amd64 > machine... > > either way, i finally got my fairly new apu4d4 to stop its reboot-loop by > unplugging the installer usb-key i used... i think there might have been > something about the bios setting up the numbering for sd0/sd1 wrong - but > regardless... until a few days ago - i had been running a successful > 6.7-stable, and then 6.8-stable (i think it was sysupgrade, but maybe i > re-installed) on this hw... i will attach my dmesg, but i doubt it is > important to this question... > > i tried to do a simple "pkg_add wget" after the snapshot had been running > for a few hours safely - and received the complaint about c++ libraries > having a bad-major (which i thought i remembered from earlier messages)... > i have NOT tried any of the unique ideas that were mentioned (and > discouraged) on the list... > > [snip] >
Re: -current amd64 packages not updated? Impatient or broken?
symptom: did a "pkg_add wget" on a recent-snapshot fails with bad-major c++ errors... am i being impatient also ? i remember reading (07-08 jan) that the pkg_add compiles were taking awhile to grind thru... it is also quite-possible that i have hit a gap between the snapshot i downloaded and the matching build - for my amd64 machine... either way, i finally got my fairly new apu4d4 to stop its reboot-loop by unplugging the installer usb-key i used... i think there might have been something about the bios setting up the numbering for sd0/sd1 wrong - but regardless... until a few days ago - i had been running a successful 6.7-stable, and then 6.8-stable (i think it was sysupgrade, but maybe i re-installed) on this hw... i will attach my dmesg, but i doubt it is important to this question... i tried to do a simple "pkg_add wget" after the snapshot had been running for a few hours safely - and received the complaint about c++ libraries having a bad-major (which i thought i remembered from earlier messages)... i have NOT tried any of the unique ideas that were mentioned (and discouraged) on the list... anyways - if i am one of the "just wait a bit" people, then i apologize - i will drop back to 6.8 and syspatch up thru -stable again... otoh - if i should try-again with another snapshot and then "pkg_add wget" again - please let me know... (ie - maybe the c++ library changes will only impact some pkgs more than others ?) details-below. -- fw$ uname -a OpenBSD fw.hfelton.net 6.8 GENERIC.MP#270 amd64 fw$ --- fw$ wget ksh: wget: not found fw$ doas pkg_add wget quirks-3.508 signed on 2021-01-11T18:41:16Z quirks-3.508: ok wget-1.20.3p3:libiconv-1.16p0: ok Can't install gettext-runtime-0.21p0 because of libraries |library c++.6.0 not found | /usr/lib/libc++.so.7.0 (system): bad major |library c++abi.4.0 not found | /usr/lib/libc++abi.so.5.0 (system): bad major Direct dependencies for gettext-runtime-0.21p0 resolve to libiconv-1.16p0 Full dependency tree is libiconv-1.16p0 wget-1.20.3p3:libunistring-0.9.7: ok wget-1.20.3p3:libidn2-2.3.0p0: ok wget-1.20.3p3:bzip2-1.0.8p0: ok wget-1.20.3p3:pcre2-10.35: ok Can't install gettext-runtime-0.21p0 because of libraries Direct dependencies for gettext-runtime-0.21p0 resolve to libiconv-1.16p0 Full dependency tree is libiconv-1.16p0 Can't install libpsl-0.20.2p1: can't resolve gettext-runtime-0.21p0 Can't install wget-1.20.3p3: can't resolve libpsl-0.20.2p1,gettext-runtime-0.21p0 Couldn't install gettext-runtime-0.21p0 libpsl-0.20.2p1 wget-1.20.3p3 fw$ doas pkg_add -D snap wget quirks-3.508 signed on 2021-01-11T18:41:16Z Can't install gettext-runtime-0.21p0 because of libraries |library c++.6.0 not found | /usr/lib/libc++.so.7.0 (system): bad major |library c++abi.4.0 not found | /usr/lib/libc++abi.so.5.0 (system): bad major Direct dependencies for gettext-runtime-0.21p0 resolve to libiconv-1.16p0 Full dependency tree is libiconv-1.16p0 Can't install libpsl-0.20.2p1: can't resolve gettext-runtime-0.21p0 Can't install wget-1.20.3p3: can't resolve gettext-runtime-0.21p0,libpsl-0.20.2p1 Couldn't install gettext-runtime-0.21p0 libpsl-0.20.2p1 wget-1.20.3p3 fw$ --- fw$ dmesg OpenBSD 6.8-current (GENERIC.MP) #270: Mon Jan 11 15:06:57 MST 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 4259876864 (4062MB) avail mem = 4115456000 (3924MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 3.0 @ 0xcfe8a040 (13 entries) bios0: vendor coreboot version "v4.12.0.6" date 10/29/2020 bios0: PC Engines apu4 acpi0 at bios0: ACPI 6.0 acpi0: sleep states S0 S1 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TPM2 APIC HEST SSDT SSDT DRTM HPET acpi0: wakeup devices PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PBR8(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) UOH6(S3) XHC0(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf800, bus 0-64 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD GX-412TC SOC, 998.26 MHz, 16-30-01 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,PCLMUL,MWAIT,SSSE3,CX16,SSE4.1,SSE4.2,MOVBE,POPCNT,AES,XSAVE,AVX,F16C,NXE,MMXX,FFXSR,PAGE1GB,RDTSCP,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,TOPEXT,DBKP,PERFTSC,PCTRL3,ITSC,BMI1,XSAVEOPT cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 2MB 64b/line 16-way L2 cache cpu0: ITLB 32 4KB entries fully associative, 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 99MHz cpu0: mwait min=64, max=64, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD GX-412TC SOC, 998.13 MHz, 16-30-01 cpu1: FPU,VME,DE,PSE,T
Re: -current amd64 packages not updated? Impatient or broken?
> While at it, link /bin/ls to /bin/rm An Apple fanboy trying to look 1337 in a linux style on an OpenBSD mailing list. Impressive not.
Re: -current amd64 packages not updated? Impatient or broken?
On Jan 07 21:30, Christian Weisgerber wrote: > A new build is running now and will take another 24h to complete > if all goes well. Thanks for the ETA. You build ports faster than I can. I appreciate your service.
Re: -current amd64 packages not updated? Impatient or broken?
On Jan 07 16:40:37, ch...@nmedia.net wrote: > For those trying to use the latest snap and the latest ports, try link > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > for now. Frankenstein, indeed. You'll feel dirty just doing it. While at it, link /bin/ls to /bin/rm
Re: -current amd64 packages not updated? Impatient or broken?
On Thu, Jan 07, 2021 at 09:30:13PM +0100, Christian Weisgerber wrote: | Steve Williams: | | > I hesitate to send this because perhaps I'm just too impatient, but then | > again, perhaps not. This is not critical/time sensitive. | > | > I just thought I'd check if there a problem with the current packages folder | > from the mirrors? | | No, the amd64 package builds have been slightly delayed. A good reminder that you are building these package snaps very often, thanks to you (and all the other pkg builders and Theo and other base snap builders) for providing us with with these very regular updates. Cheers, Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: -current amd64 packages not updated? Impatient or broken?
On 2021-01-07, Patrick Wildt wrote: > Maybe I should have asked ports to run with the build first, so that > base and packages would be aligned. We (package builders) don't really do that - and in the majority of cases it's not much of a problem anyway, it normally only affects people that have freshly installed from snapshot and usually clears itself in a few days.
Re: -current amd64 packages not updated? Impatient or broken?
On Thu, Jan 07, 2021 at 05:44:05PM -0700, Theo de Raadt wrote: > Chris Cappuccio wrote: > > > Mihai Popescu [mih...@gmail.com] wrote: > > > I was in the same situation, impatient to have a 2021 snapshot. > > > > > > Warning: I am not sure you will not finish with a Frankenstein system. I > > > am > > > not so good with compiler-linker stuff. > > > > For those trying to use the latest snap and the latest ports, try link > > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > > for now. Frankenstein, indeed. You'll feel dirty just doing it. > > DO NOT DO THAT. > > We do not want reports from people about weird troubles, after they do > such things. > ... and this is the sort of thing that may work now and then bite you weeks later. -ml
Re: -current amd64 packages not updated? Impatient or broken?
Chris Cappuccio wrote: > Mihai Popescu [mih...@gmail.com] wrote: > > I was in the same situation, impatient to have a 2021 snapshot. > > > > Warning: I am not sure you will not finish with a Frankenstein system. I am > > not so good with compiler-linker stuff. > > For those trying to use the latest snap and the latest ports, try link > libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 > for now. Frankenstein, indeed. You'll feel dirty just doing it. DO NOT DO THAT. We do not want reports from people about weird troubles, after they do such things.
Re: -current amd64 packages not updated? Impatient or broken?
Mihai Popescu [mih...@gmail.com] wrote: > I was in the same situation, impatient to have a 2021 snapshot. > > Warning: I am not sure you will not finish with a Frankenstein system. I am > not so good with compiler-linker stuff. For those trying to use the latest snap and the latest ports, try link libc++.so.4.0 to libc++.so.5.0 and libc++abi.so.2.1 to libc++abi.so.3.0 for now. Frankenstein, indeed. You'll feel dirty just doing it.
Re: -current amd64 packages not updated? Impatient or broken?
I was in the same situation, impatient to have a 2021 snapshot. Dirty hint: the .hk mirror still has the base part from 2020! But try it as a last option, the folks there are not so bandwidth fortunate. After installing the base, please switch /etc/installurl to something more suitable as distance and bandwidth. Warning: I am not sure you will not finish with a Frankenstein system. I am not so good with compiler-linker stuff.
Re: -current amd64 packages not updated? Impatient or broken?
On 07/01/2021 1:30 p.m., Christian Weisgerber wrote: Steve Williams: I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? No, the amd64 package builds have been slightly delayed. First by a problem in lang/rust, which semarie@ fixed in admirably short time. Then the package build was cut short because the machine running dpb(1) panicked with filesystem corruption. A new build is running now and will take another 24h to complete if all goes well. Hi, Thanks for the update! Ah, the joys of big builds! I remember being in CPSC in University in the early 1980's and doing ray tracing. We did a 20 second movie @ 24 frames per second (16 mm film!!!). Each frame took at least 5 minutes to render on "leading edge" (at the time) SGI hardware. We would start it Friday night and it would complete before classes on Monday AM. We had to hold our breath that nothing would go wrong over the weekend or that someone wouldn't start playing flight simulator on the network with the other 2 workstations! lol Good luck with everything! It's an amazing job you are doing keeping all the balls in the air at once (juggling). Cheers, Steve W.
Re: -current amd64 packages not updated? Impatient or broken?
Steve Williams: > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages folder > from the mirrors? No, the amd64 package builds have been slightly delayed. First by a problem in lang/rust, which semarie@ fixed in admirably short time. Then the package build was cut short because the machine running dpb(1) panicked with filesystem corruption. A new build is running now and will take another 24h to complete if all goes well. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: -current amd64 packages not updated? Impatient or broken?
Thanks for the correction! amit On Thu, Jan 7, 2021 at 11:59 AM Patrick Wildt wrote: > > No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been > committed. This issue is because of libunwind 11. With libc++ 11 we > have made a separate ports build first, to check the fallout. Once the > fallout is mostly fixed, we'll do the switch to libc++ 11. Until then > snapshots are not harmed in anyway, apart from the libunwind update. > > Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > > Like naddy@ mentioned on ports@ they are trying to figure out the > > fallout from the switch to LLVM 11 as system compiler. This is why the > > packages are being delayed. Please wait a while till it is sorted out. > > > > thanks > > > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > > wrote: > > > > > > Hi, > > > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > > again, perhaps not. This is not critical/time sensitive. > > > > > > I just thought I'd check if there a problem with the current packages > > > folder from the mirrors? > > > > > > I am trying to update my development system (to resume work on a port). > > > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > > update because of missing library versions. I was told this is just a > > > discrepancy between the OS and the packages and to "wait a few days" for > > > everything to synchronize. > > > "Unfortunate timing as key system libraries have had version bumps > > > recently. Wait for a new package build (usually a few days on the faster > > > cpu architectures) and try again." > > > > > > I am watching the packages folder on various mirrors and they are all > > > from January 3, 2020, which is when my kernel is from. > > > pulseaudio-14.0.tgz03-Jan-2021 > > > > > > I am currently on: > > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > > > This morning, I still can't add/update select packages. > > > > > > desktop# sysupgrade -s > > > Fetching from > > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > > SHA256.sig 100% > > > |***| > > > 2144 00:00 > > > Signature Verified > > > Already on latest snapshot. > > > desktop# pkg_add pulseaudio > > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > > Can't install spidermonkey78-78.5.0v1 because of libraries > > > |library c++.5.0 not found > > > | /usr/lib/libc++.so.4.0 (system): bad major > > > | /usr/lib/libc++.so.6.0 (system): bad major > > > |library c++abi.3.0 not found > > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > > nspr-4.29 icu4c-68.2v0 > > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > > spidermonkey78-78.5.0v1 > > > desktop# > > > > > > Am I being too impatient? > > > > > > Thanks, > > > Steve Williams > > > > > > > > > > >
Re: -current amd64 packages not updated? Impatient or broken?
Impatient it is :D Thanks for the update! Cheers, Steve W. On 07/01/2021 10:56 a.m., Patrick Wildt wrote: I committed an update to libunwind which made a major bump necessary. Maybe I should have asked ports to run with the build first, so that base and packages would be aligned. Too late for that now. Time will fix it though. Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams: Hi, I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? I am trying to update my development system (to resume work on a port). I did the initial upgrade on January 4, 2020 and my packages wouldn't update because of missing library versions. I was told this is just a discrepancy between the OS and the packages and to "wait a few days" for everything to synchronize. "Unfortunate timing as key system libraries have had version bumps recently. Wait for a new package build (usually a few days on the faster cpu architectures) and try again." I am watching the packages folder on various mirrors and they are all from January 3, 2020, which is when my kernel is from. pulseaudio-14.0.tgz 03-Jan-2021 I am currently on: OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 This morning, I still can't add/update select packages. desktop# sysupgrade -s Fetching from https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ SHA256.sig 100% |***| 2144 00:00 Signature Verified Already on latest snapshot. desktop# pkg_add pulseaudio quirks-3.506 signed on 2021-01-03T15:41:44Z Can't install spidermonkey78-78.5.0v1 because of libraries |library c++.5.0 not found | /usr/lib/libc++.so.4.0 (system): bad major | /usr/lib/libc++.so.6.0 (system): bad major |library c++abi.3.0 not found | /usr/lib/libc++abi.so.2.1 (system): bad major | /usr/lib/libc++abi.so.4.0 (system): bad major Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 nspr-4.29 icu4c-68.2v0 Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 Can't install consolekit2-1.2.2: can't resolve polkit-0.118 Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 spidermonkey78-78.5.0v1 desktop# Am I being too impatient? Thanks, Steve Williams
Re: -current amd64 packages not updated? Impatient or broken?
Oh, and another correction: it's libc++ 10.0.1, we're not going 11 yet. Am Thu, Jan 07, 2021 at 06:59:52PM +0100 schrieb Patrick Wildt: > No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been > committed. This issue is because of libunwind 11. With libc++ 11 we > have made a separate ports build first, to check the fallout. Once the > fallout is mostly fixed, we'll do the switch to libc++ 11. Until then > snapshots are not harmed in anyway, apart from the libunwind update. > > Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > > Like naddy@ mentioned on ports@ they are trying to figure out the > > fallout from the switch to LLVM 11 as system compiler. This is why the > > packages are being delayed. Please wait a while till it is sorted out. > > > > thanks > > > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > > wrote: > > > > > > Hi, > > > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > > again, perhaps not. This is not critical/time sensitive. > > > > > > I just thought I'd check if there a problem with the current packages > > > folder from the mirrors? > > > > > > I am trying to update my development system (to resume work on a port). > > > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > > update because of missing library versions. I was told this is just a > > > discrepancy between the OS and the packages and to "wait a few days" for > > > everything to synchronize. > > > "Unfortunate timing as key system libraries have had version bumps > > > recently. Wait for a new package build (usually a few days on the faster > > > cpu architectures) and try again." > > > > > > I am watching the packages folder on various mirrors and they are all > > > from January 3, 2020, which is when my kernel is from. > > > pulseaudio-14.0.tgz03-Jan-2021 > > > > > > I am currently on: > > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > > > This morning, I still can't add/update select packages. > > > > > > desktop# sysupgrade -s > > > Fetching from > > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > > SHA256.sig 100% > > > |***| > > > 2144 00:00 > > > Signature Verified > > > Already on latest snapshot. > > > desktop# pkg_add pulseaudio > > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > > Can't install spidermonkey78-78.5.0v1 because of libraries > > > |library c++.5.0 not found > > > | /usr/lib/libc++.so.4.0 (system): bad major > > > | /usr/lib/libc++.so.6.0 (system): bad major > > > |library c++abi.3.0 not found > > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > > nspr-4.29 icu4c-68.2v0 > > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > > spidermonkey78-78.5.0v1 > > > desktop# > > > > > > Am I being too impatient? > > > > > > Thanks, > > > Steve Williams > > > > > > > > > > > >
Re: -current amd64 packages not updated? Impatient or broken?
No, that's not correct. The libc++ 11 (*not* LLVM 11) has not yet been committed. This issue is because of libunwind 11. With libc++ 11 we have made a separate ports build first, to check the fallout. Once the fallout is mostly fixed, we'll do the switch to libc++ 11. Until then snapshots are not harmed in anyway, apart from the libunwind update. Am Thu, Jan 07, 2021 at 11:56:07AM -0600 schrieb Amit Kulkarni: > Like naddy@ mentioned on ports@ they are trying to figure out the > fallout from the switch to LLVM 11 as system compiler. This is why the > packages are being delayed. Please wait a while till it is sorted out. > > thanks > > On Thu, Jan 7, 2021 at 10:56 AM Steve Williams > wrote: > > > > Hi, > > > > I hesitate to send this because perhaps I'm just too impatient, but then > > again, perhaps not. This is not critical/time sensitive. > > > > I just thought I'd check if there a problem with the current packages > > folder from the mirrors? > > > > I am trying to update my development system (to resume work on a port). > > > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > > update because of missing library versions. I was told this is just a > > discrepancy between the OS and the packages and to "wait a few days" for > > everything to synchronize. > > "Unfortunate timing as key system libraries have had version bumps > > recently. Wait for a new package build (usually a few days on the faster > > cpu architectures) and try again." > > > > I am watching the packages folder on various mirrors and they are all > > from January 3, 2020, which is when my kernel is from. > > pulseaudio-14.0.tgz03-Jan-2021 > > > > I am currently on: > > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > > > This morning, I still can't add/update select packages. > > > > desktop# sysupgrade -s > > Fetching from > > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > > SHA256.sig 100% > > |***| > > 2144 00:00 > > Signature Verified > > Already on latest snapshot. > > desktop# pkg_add pulseaudio > > quirks-3.506 signed on 2021-01-03T15:41:44Z > > Can't install spidermonkey78-78.5.0v1 because of libraries > > |library c++.5.0 not found > > | /usr/lib/libc++.so.4.0 (system): bad major > > | /usr/lib/libc++.so.6.0 (system): bad major > > |library c++abi.3.0 not found > > | /usr/lib/libc++abi.so.2.1 (system): bad major > > | /usr/lib/libc++abi.so.4.0 (system): bad major > > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > > nspr-4.29 icu4c-68.2v0 > > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > > spidermonkey78-78.5.0v1 > > desktop# > > > > Am I being too impatient? > > > > Thanks, > > Steve Williams > > > > > > >
Re: -current amd64 packages not updated? Impatient or broken?
Like naddy@ mentioned on ports@ they are trying to figure out the fallout from the switch to LLVM 11 as system compiler. This is why the packages are being delayed. Please wait a while till it is sorted out. thanks On Thu, Jan 7, 2021 at 10:56 AM Steve Williams wrote: > > Hi, > > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages > folder from the mirrors? > > I am trying to update my development system (to resume work on a port). > > I did the initial upgrade on January 4, 2020 and my packages wouldn't > update because of missing library versions. I was told this is just a > discrepancy between the OS and the packages and to "wait a few days" for > everything to synchronize. > "Unfortunate timing as key system libraries have had version bumps > recently. Wait for a new package build (usually a few days on the faster > cpu architectures) and try again." > > I am watching the packages folder on various mirrors and they are all > from January 3, 2020, which is when my kernel is from. > pulseaudio-14.0.tgz03-Jan-2021 > > I am currently on: > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > This morning, I still can't add/update select packages. > > desktop# sysupgrade -s > Fetching from > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > SHA256.sig 100% > |***| > 2144 00:00 > Signature Verified > Already on latest snapshot. > desktop# pkg_add pulseaudio > quirks-3.506 signed on 2021-01-03T15:41:44Z > Can't install spidermonkey78-78.5.0v1 because of libraries > |library c++.5.0 not found > | /usr/lib/libc++.so.4.0 (system): bad major > | /usr/lib/libc++.so.6.0 (system): bad major > |library c++abi.3.0 not found > | /usr/lib/libc++abi.so.2.1 (system): bad major > | /usr/lib/libc++abi.so.4.0 (system): bad major > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > nspr-4.29 icu4c-68.2v0 > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > spidermonkey78-78.5.0v1 > desktop# > > Am I being too impatient? > > Thanks, > Steve Williams > > >
Re: -current amd64 packages not updated? Impatient or broken?
I committed an update to libunwind which made a major bump necessary. Maybe I should have asked ports to run with the build first, so that base and packages would be aligned. Too late for that now. Time will fix it though. Am Thu, Jan 07, 2021 at 09:54:39AM -0700 schrieb Steve Williams: > Hi, > > I hesitate to send this because perhaps I'm just too impatient, but then > again, perhaps not. This is not critical/time sensitive. > > I just thought I'd check if there a problem with the current packages folder > from the mirrors? > > I am trying to update my development system (to resume work on a port). > > I did the initial upgrade on January 4, 2020 and my packages wouldn't update > because of missing library versions. I was told this is just a discrepancy > between the OS and the packages and to "wait a few days" for everything to > synchronize. > "Unfortunate timing as key system libraries have had version bumps > recently. Wait for a new package build (usually a few days on the faster cpu > architectures) and try again." > > I am watching the packages folder on various mirrors and they are all from > January 3, 2020, which is when my kernel is from. > pulseaudio-14.0.tgz 03-Jan-2021 > > I am currently on: > OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 > > This morning, I still can't add/update select packages. > > desktop# sysupgrade -s > Fetching from > https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ > SHA256.sig 100% > |***| > 2144 00:00 > Signature Verified > Already on latest snapshot. > desktop# pkg_add pulseaudio > quirks-3.506 signed on 2021-01-03T15:41:44Z > Can't install spidermonkey78-78.5.0v1 because of libraries > |library c++.5.0 not found > | /usr/lib/libc++.so.4.0 (system): bad major > | /usr/lib/libc++.so.6.0 (system): bad major > |library c++abi.3.0 not found > | /usr/lib/libc++abi.so.2.1 (system): bad major > | /usr/lib/libc++abi.so.4.0 (system): bad major > Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 > nspr-4.29 icu4c-68.2v0 > Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 > Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 > Can't install consolekit2-1.2.2: can't resolve polkit-0.118 > Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 > Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 > spidermonkey78-78.5.0v1 > desktop# > > Am I being too impatient? > > Thanks, > Steve Williams > > >
-current amd64 packages not updated? Impatient or broken?
Hi, I hesitate to send this because perhaps I'm just too impatient, but then again, perhaps not. This is not critical/time sensitive. I just thought I'd check if there a problem with the current packages folder from the mirrors? I am trying to update my development system (to resume work on a port). I did the initial upgrade on January 4, 2020 and my packages wouldn't update because of missing library versions. I was told this is just a discrepancy between the OS and the packages and to "wait a few days" for everything to synchronize. "Unfortunate timing as key system libraries have had version bumps recently. Wait for a new package build (usually a few days on the faster cpu architectures) and try again." I am watching the packages folder on various mirrors and they are all from January 3, 2020, which is when my kernel is from. pulseaudio-14.0.tgz 03-Jan-2021 I am currently on: OpenBSD 6.8-current (GENERIC.MP) #259: Sun Jan 3 15:25:58 MST 2021 This morning, I still can't add/update select packages. desktop# sysupgrade -s Fetching from https://cloudflare.cdn.openbsd.org/pub/OpenBSD//snapshots/amd64/ SHA256.sig 100% |***| 2144 00:00 Signature Verified Already on latest snapshot. desktop# pkg_add pulseaudio quirks-3.506 signed on 2021-01-03T15:41:44Z Can't install spidermonkey78-78.5.0v1 because of libraries |library c++.5.0 not found | /usr/lib/libc++.so.4.0 (system): bad major | /usr/lib/libc++.so.6.0 (system): bad major |library c++abi.3.0 not found | /usr/lib/libc++abi.so.2.1 (system): bad major | /usr/lib/libc++abi.so.4.0 (system): bad major Direct dependencies for spidermonkey78-78.5.0v1 resolve to libffi-3.3 nspr-4.29 icu4c-68.2v0 Full dependency tree is libffi-3.3 nspr-4.29 icu4c-68.2v0 Can't install polkit-0.118: can't resolve spidermonkey78-78.5.0v1 Can't install consolekit2-1.2.2: can't resolve polkit-0.118 Can't install pulseaudio-14.0: can't resolve consolekit2-1.2.2 Couldn't install consolekit2-1.2.2 polkit-0.118 pulseaudio-14.0 spidermonkey78-78.5.0v1 desktop# Am I being too impatient? Thanks, Steve Williams
Re: AMD64 packages - Reflecting dynamic linking
On 15-01-01 07:44 PM, Joel Rees wrote: At the risk of having Theo tell me to shut up and get back to work on things that matter, ... and I suppose it's inevitible that someone will want to control the world, but I really wish you and your friends would quit lying to yourselves about power. I disagree - to me, this smells like just another instance of jwz's CADT (http://www.jwz.org/doc/cadt.html) cycle repeating itself. To me, this means that the day approaches where systemd will have its very own invasive CADT movement to deal with - this thought gives me a rare example to use the word "schadenfreude" in regular conversation :). -- -Adam Thompson athom...@athompso.net
Re: AMD64 packages - Reflecting dynamic linking
At the risk of having Theo tell me to shut up and get back to work on things that matter, ... On Fri, Jan 2, 2015 at 1:33 AM, FRIGN wrote: > On Fri, 12 Dec 2014 20:02:33 +0100 > Ingo Schwarze wrote: > >> There are dragons. > >> If this scares anybody, i'm not surprised; updating libraries is >> not a playground for newbies. > >> That, actually, is *terrible* advice and almost guarantees a fiasco. >> If you edit shlib_version manually, you build a library containing >> code *incompatible* with what it's supposed to contain, so the end >> result will be that programs using that library will, at run time, >> * crash, >> * produce obviously wrong results, >> * and/or silently produce results that are wrong in non-obvious ways. >> Some programs, by mere luck, may also work, if you are lucky, >> but it's hard to predict in advance which ones will and which >> ones wont. > >> To update a library, update all related source code - ideally, >> the whole source tree unless you know precisely what you are >> doing - to one consistent state, than compile from that state >> *without* manually screwing with shlib_version. That's the whole >> point of library versioning! > > I may get a little off-topic here and object for this very important > topic to be discussed in a separate thread some day, but come to > think of it, the overhead induced with dynamic linking, symbol > versioning and crazy workarounds to make the dynamic linker remotely > safe nowadays completely destroy the once good reasons for dynamic > libraries. Do I hear echos of the /usr argument? Speed and large drives "solve" this one problem, so we can throw sense and reason out the window? > Static linking eliminates all the issues involved with symbol versions, If only we had perfect libraries to start with. > wrecking your system with a library update and I'd even go as far > as saying that static binaries are more or less independent from > distributions. As long as you ignore the inherent implicit linkages of the context OSses and the tools being used at a certain point in time, sure, theoretically, distribution independence can happen. Probably in the same universe where openbsd is a Linux distribution. (But, then you must remember to never argue that Linux Is Not UniX!) > Memory usage is also not a point any more, because we > have shared tables nowadays and in many cases, statically linked > programs need less RAM than dynamically linked ones. Even if your arguments were not random, would they be meaningful? You not only fail to prove your assertions, you fail to explain their relevance. Why? > So, what are the remaining arguments against static linking? What is your underlying argument? Static vs. dynamic is a null argument, so you must be using it as noise cover to sell something really noxious. > I agree there are programs which do not run well if statically linked > (the X-server for instance), but that's more or less a matter of design > and can be worked around in most cases. ??? > One specific point often raised is the argument, that if you have > an update for a specific library (a security update for instance), > you just need to recompile the library and all programs depending > on the library will behave correctly. > With static libraries on the other hand, you would have to recompile > all binaries and superset-libraries depending on this library for > the security fix to be effective. > This point is increasingly losing significance due to the following > reasons: Riding your noise waves, to look for clues, let's see: > 1) hot-swapping a library for a security-fix implies that the ABI > doesn't change, i.e. that the binaries on your system using this > library can access the functions the way they have been told > where they can find them. So, you are saying that there are so many bugs in the APIs that it is useless to fix non-API bugs? Cool. We can all go home now. > In many cases nowadays, bugs are fixed concurrently with version > bumps (major & minor) which means that all binaries have to be > manually updated and recompiled anyway. What do you mean by manually, anyway? > 2) compiling is not expensive any more (in most cases). > On my Gentoo-based system, it just takes 2 hours to recompile the > entire operating system including all user-space applications. Gee, I wish I had a 512 core 14GHz Intel Core 10 with 16 Terabytes of RAM ... ... and the requisite nuclear reactor to power it. > Moore's law will decrease this time over the years significantly. Intel's going to start shrinking silicon atoms now? > Imagine if it just took 5 minutes, as opposed to 5 seconds? Why not? We're in the imaginary world anyway. > would there still be a reason to > have a hand-crafted Hand crafted, now? What does that mean? > dynamic linker to carefully dissect libraries > and binaries, imposing a run-time loss and lots of > security-considerations? Oh, I'm the boogie-woogie man! (The Nightmare before Christmas is ac
Re: AMD64 packages - Reflecting dynamic linking
Quoting FRIGN : It may be a little far-fetched, but I'm sure it would be possible to have one package-manager for all distributions if there would just be the motivation to distribute statically linked binaries and not fuck things up with distribution-specific folder-structures. I'm not a hacker so I have no means to ponder your other arguments, but as a user you lost me with this. I'm running away from systemd so the concept of one package manager to rule them all does not appeal to me. http://0pointer.net/blog/revisiting-how-we-put-together-linux-systems.html -- Best regards, Jorge Lopez. This message was sent using IMP, the Internet Messaging Program.
Re: AMD64 packages - Reflecting dynamic linking
On Thu, 01 Jan 2015 10:04:26 -0700 Theo de Raadt wrote: > Ah, another arrogance -- you came here to advertise. Nope, if you read my first mail again, you'd see that I did not mention our project once and only presented it to challenge your assumption that I'm just some warrior presenting crude ideas. > You will gain little security or safety by rewriting everything for a > small and obscure userbase, without attacking the hard problems of > coding and enabling all possible mitigations. These words are very true. Even with arc4random() and given how long it has been around (and given how _obvious_ its benefits are), people still use PRNG's attempting to generate truly random data. > Static binaries are not a valid mitigation. > It sounds like you have no real word experience, because your userbase is > nonexistant. Maybe you are right. I must confess that I am an optimist and idealist when it comes to software development and looking at most software, mostly what I've seen in the last few years, you can't learn enough that there are many ugly spots in this area. You don't need a large userbase to see the issues even with a long-term switch to static binaries (so I definitely know what you're talking about) and that it is not a trivial thing. However, as a long-term perspective, one might hope that software development will actually take hardware-advancements in regard not by crufting software with more complexity, but by actually optimizing the foundation. You don't need to rewrite a lot to achieve that, same as you didn't have to rewrite a lot to make srand() truly random in builds that were non-deterministic. But I see that this discussion is getting nowhere for good reasons on both sides. So let's get back to coding. Happy hacking! Cheers FRIGN -- FRIGN
Re: AMD64 packages - Reflecting dynamic linking
> > And who are you, and what you have you done to test and then prove > > your thesis? > > Absolutely nothing, I must assume. > > Your assumption is wrong. I am working with my colleagues from 2f30 on > the "morpheus"-project[0] (including package-manager) and we have a set > of static binary-packages[1] already ready for use. Ah, another arrogance -- you came here to advertise. You will gain little security or safety by rewriting everything for a small and obscure userbase, without attacking the hard problems of coding and enabling all possible mitigations. Static binaries are not a valid mitigation. It sounds like you have no real word experience, because your userbase is nonexistant.
Re: AMD64 packages - Reflecting dynamic linking
On Thu, 01 Jan 2015 09:37:24 -0700 Theo de Raadt wrote: > And who are you, and what you have you done to test and then prove > your thesis? > Absolutely nothing, I must assume. Your assumption is wrong. I am working with my colleagues from 2f30 on the "morpheus"-project[0] (including package-manager) and we have a set of static binary-packages[1] already ready for use. > (BTW, your argument is weak and would be stronger if you tied it into > the faked moonlandings). I know you as a rude person and like your humour, but your response contains no argument against the points I have given. I'm not saying that in an arrogant way (maybe I'm getting this whole deal completely wrong) and wanted to give some food for thought for the future. The OpenBSD-security-focus paid off. It wasn't the fastest system 10 years ago and isn't today, but when it made a difference in the past, security is more important today than speed, given how rapidly hardware is developing. I see the same issue here: How long do we really want to waste our time on this cruft and develop libraries with the wrong concept in our heads when dynamic linking is apparently becoming more and more irrelevant? Cheers FRIGN [0]: http://morpheus.2f30.org/ [1]: http://morpheus.2f30.org/0.0/packages/x86_64/ -- FRIGN
Re: AMD64 packages - Reflecting dynamic linking
And who are you, and what you have you done to test and then prove your thesis? Absolutely nothing, I must assume. (BTW, your argument is weak and would be stronger if you tied it into the faked moonlandings). > I may get a little off-topic here and object for this very important > topic to be discussed in a separate thread some day, but come to > think of it, the overhead induced with dynamic linking, symbol > versioning and crazy workarounds to make the dynamic linker remotely > safe nowadays completely destroy the once good reasons for dynamic > libraries. > Static linking eliminates all the issues involved with symbol versions, > wrecking your system with a library update and I'd even go as far > as saying that static binaries are more or less independent from > distributions. Memory usage is also not a point any more, because we > have shared tables nowadays and in many cases, statically linked > programs need less RAM than dynamically linked ones. > > So, what are the remaining arguments against static linking? > I agree there are programs which do not run well if statically linked > (the X-server for instance), but that's more or less a matter of design > and can be worked around in most cases. > > One specific point often raised is the argument, that if you have > an update for a specific library (a security update for instance), > you just need to recompile the library and all programs depending > on the library will behave correctly. > With static libraries on the other hand, you would have to recompile > all binaries and superset-libraries depending on this library for > the security fix to be effective. > This point is increasingly losing significance due to the following > reasons: > > 1) hot-swapping a library for a security-fix implies that the ABI > doesn't change, i.e. that the binaries on your system using this > library can access the functions the way they have been told > where they can find them. > In many cases nowadays, bugs are fixed concurrently with version > bumps (major & minor) which means that all binaries have to be > manually updated and recompiled anyway. > > 2) compiling is not expensive any more (in most cases). > On my Gentoo-based system, it just takes 2 hours to recompile the > entire operating system including all user-space applications. > Moore's law will decrease this time over the years significantly. > Imagine if it just took 5 minutes, would there still be a reason to > have a hand-crafted dynamic linker to carefully dissect libraries > and binaries, imposing a run-time loss and lots of > security-considerations? > I'm not talking about beasts like libreoffice, chromium and others. > There are better alternatives around and if not, there will be in the > future. For huge packages, it should be simple enough to design the > package-manager in a way serving static binaries, and in case there is > a library-fix, tell all clients to redownload the current version > again. So the only real worry here is to have a clean build- > environment on the build-servers (designed by experts) and not wasting > hundreds of man-hours designing systems to cope with the dll-hell > almost all Un*xes have become on the client-side. > > Why is Linux/BSD not popular on the desktop? Because of fragmentation. > And one reason for fragmentation is that you can't use Debian packages > in Ubuntu, mostly because there are library incompatibilities. > Other reasons are lack of good software, but that's just a matter of > time. And if we can get more developers to work on useful stuff instead > of having to worry about library-versioning, this goal could be reached > in shorter time. > > It may be a little far-fetched, but I'm sure it would be possible > to have one package-manager for all distributions if there would just > be the motivation to distribute statically linked binaries and not fuck > things up with distribution-specific folder-structures. > > 3) security > Well, the issues with dynamic linking have been stated often enough[0] > [1][2][3][4]. > As far as I understand, the initial motivation of the OpenBSD-project > was to favor security over speed. It just puzzles me that issues like > dynamic linking have not yet been discussed broadly or dealt with in > the last few years given these obvious negative implications. > > Please let me know what you think. > > Cheers > > FRIGN > > [0]: http://www.catonmat.net/blog/ldd-arbitrary-code-execution/ > [1]: http://benpfaff.org/papers/asrandom.pdf > [2]: > http://web.archive.org/web/20120509105723/http://teddziuba.com/2008/09/a-web-os-are-you-dense.html > [3]: https://www.nth-dimension.org.uk/pub/BTL.pdf > [4]: http://harmful.cat-v.org/software/dynamic-linking/versioned-symbols > > -- > FRIGN
Re: AMD64 packages - Reflecting dynamic linking
On Fri, 12 Dec 2014 20:02:33 +0100 Ingo Schwarze wrote: > There are dragons. > If this scares anybody, i'm not surprised; updating libraries is > not a playground for newbies. > That, actually, is *terrible* advice and almost guarantees a fiasco. > If you edit shlib_version manually, you build a library containing > code *incompatible* with what it's supposed to contain, so the end > result will be that programs using that library will, at run time, > * crash, > * produce obviously wrong results, > * and/or silently produce results that are wrong in non-obvious ways. > Some programs, by mere luck, may also work, if you are lucky, > but it's hard to predict in advance which ones will and which > ones wont. > To update a library, update all related source code - ideally, > the whole source tree unless you know precisely what you are > doing - to one consistent state, than compile from that state > *without* manually screwing with shlib_version. That's the whole > point of library versioning! I may get a little off-topic here and object for this very important topic to be discussed in a separate thread some day, but come to think of it, the overhead induced with dynamic linking, symbol versioning and crazy workarounds to make the dynamic linker remotely safe nowadays completely destroy the once good reasons for dynamic libraries. Static linking eliminates all the issues involved with symbol versions, wrecking your system with a library update and I'd even go as far as saying that static binaries are more or less independent from distributions. Memory usage is also not a point any more, because we have shared tables nowadays and in many cases, statically linked programs need less RAM than dynamically linked ones. So, what are the remaining arguments against static linking? I agree there are programs which do not run well if statically linked (the X-server for instance), but that's more or less a matter of design and can be worked around in most cases. One specific point often raised is the argument, that if you have an update for a specific library (a security update for instance), you just need to recompile the library and all programs depending on the library will behave correctly. With static libraries on the other hand, you would have to recompile all binaries and superset-libraries depending on this library for the security fix to be effective. This point is increasingly losing significance due to the following reasons: 1) hot-swapping a library for a security-fix implies that the ABI doesn't change, i.e. that the binaries on your system using this library can access the functions the way they have been told where they can find them. In many cases nowadays, bugs are fixed concurrently with version bumps (major & minor) which means that all binaries have to be manually updated and recompiled anyway. 2) compiling is not expensive any more (in most cases). On my Gentoo-based system, it just takes 2 hours to recompile the entire operating system including all user-space applications. Moore's law will decrease this time over the years significantly. Imagine if it just took 5 minutes, would there still be a reason to have a hand-crafted dynamic linker to carefully dissect libraries and binaries, imposing a run-time loss and lots of security-considerations? I'm not talking about beasts like libreoffice, chromium and others. There are better alternatives around and if not, there will be in the future. For huge packages, it should be simple enough to design the package-manager in a way serving static binaries, and in case there is a library-fix, tell all clients to redownload the current version again. So the only real worry here is to have a clean build- environment on the build-servers (designed by experts) and not wasting hundreds of man-hours designing systems to cope with the dll-hell almost all Un*xes have become on the client-side. Why is Linux/BSD not popular on the desktop? Because of fragmentation. And one reason for fragmentation is that you can't use Debian packages in Ubuntu, mostly because there are library incompatibilities. Other reasons are lack of good software, but that's just a matter of time. And if we can get more developers to work on useful stuff instead of having to worry about library-versioning, this goal could be reached in shorter time. It may be a little far-fetched, but I'm sure it would be possible to have one package-manager for all distributions if there would just be the motivation to distribute statically linked binaries and not fuck things up with distribution-specific folder-structures. 3) security Well, the issues with dynamic linking have been stated often enough[0] [1][2][3][4]. As far as I understand, the initial motivation of the OpenBSD-project was to favor security over speed. It just puzzles me that issues like dynamic linking have not yet been discussed broadly or dealt with in the last few years given these obvious negative implications. Please let
Re: AMD64 packages
On Fri, Dec 12, 2014 at 2:02 PM, Ingo Schwarze wrote: > > There are dragons. > ingo, theo: sorry to post toxic advice, and thanks for the knowledge. i did not realize how shlib_version worked. i must have gotten lucky with my build but i should go back and fix it properly now ian
Re: AMD64 packages
On Dec 12, 2014 1:06 PM, "Theo de Raadt" wrote: > > > ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: > > > > > whenever i grab a snapshot and get library version mismatches after a > > > `pkg_add -u`, i've found the easiest way to get those objects > > > > Definitely not the easiest way. Waiting for the next snapshot is > > definitely much easier and safer for the average user. > > > > > is grab a fresh source tree and compile them manually. > > > for example, libc: > > > > There are dragons. > > > No, Ingo, stop right there. > > What he is trying to do is create a frankenstein. People who do this > will run into problems. > > Then they'll submit a bug report. > > It ends badly. > I never dreamed that asking a simple question of about how long it might be before I could fix what I screwed up would end causing all of this. Whenever new packages are available, I'll fix what I broke and try to not do it again. Stan
Re: AMD64 packages
> ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: > > > whenever i grab a snapshot and get library version mismatches after a > > `pkg_add -u`, i've found the easiest way to get those objects > > Definitely not the easiest way. Waiting for the next snapshot is > definitely much easier and safer for the average user. > > > is grab a fresh source tree and compile them manually. > > for example, libc: > > There are dragons. No, Ingo, stop right there. What he is trying to do is create a frankenstein. People who do this will run into problems. Then they'll submit a bug report. It ends badly.
Re: AMD64 packages
Hi Ian, ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500: > whenever i grab a snapshot and get library version mismatches after a > `pkg_add -u`, i've found the easiest way to get those objects Definitely not the easiest way. Waiting for the next snapshot is definitely much easier and safer for the average user. > is grab a fresh source tree and compile them manually. > for example, libc: There are dragons. Sometimes, you need to do "make includes" in the right directory first. Then again, that tends to reinstall *many* headers, not just those you care about right now, so be sure you don't install some that hurt you. Also, "make depend" can sometimes be necessary, and you certainly should never forget about "make obj". When there is a flag day, very special steps may be required before doing anything else or somewhere in the middle. If you screw up, chances are you can't even do a clean shutdown any longer and are in for fsck(8) and manually reinstalling working libraries in single user mode before you can fully boot again. If this scares anybody, i'm not surprised; updating libraries is not a playground for newbies. > cd /usr/src/lib/libc > > edit 'shlib_version' to have the appropriate major/minor versions > (pkg_add(1) will tell you which ones it wants. That, actually, is *terrible* advice and almost guarantees a fiasco. If you edit shlib_version manually, you build a library containing code *incompatible* with what it's supposed to contain, so the end result will be that programs using that library will, at run time, * crash, * produce obviously wrong results, * and/or silently produce results that are wrong in non-obvious ways. Some programs, by mere luck, may also work, if you are lucky, but it's hard to predict in advance which ones will and which ones wont. To update a library, update all related source code - ideally, the whole source tree unless you know precisely what you are doing - to one consistent state, than compile from that state *without* manually screwing with shlib_version. That's the whole point of library versioning! > make && make install The command "make install" in lib/libc is among the more dangerous commands you might type, and if something is wrong, recovery is often more difficult than recovery from less scary errors. > the bsd.port.mk(5) build system is well thought out No objection here... > and allows for straightforward, helpful maneuvers like this ... but i really wouldn't give it that twist. Nothing about what you said is straightforward or helpful. It sounds more like somewhere between foolhardy and suicidal. > pkg_check(8) is also an invaluable tool in helping deal with package > issues. also, use the right $PKG_PATH! That's good advice again, for sure. Yours, Ingo
Re: AMD64 packages
On 2014-12-12, ian kremlin wrote: > whenever i grab a snapshot and get library version mismatches after a > `pkg_add -u`, i've found the easiest way to get those objects is grab a > fresh source tree and compile them manually. for example, libc: > > cd /usr/src/lib/libc > > edit 'shlib_version' to have the appropriate major/minor versions This is bad advice. There is a reason why we bump library versions! What you could do if you can't wait for new packages and don't have the correct version of the library, is to identify the date/time when the library was updated and e.g. "cvs up -D 2014/12/05" (i.e. before the update) to fetch a copy of the source code for the library at the version you need, and build that.
Re: AMD64 packages
whenever i grab a snapshot and get library version mismatches after a `pkg_add -u`, i've found the easiest way to get those objects is grab a fresh source tree and compile them manually. for example, libc: cd /usr/src/lib/libc edit 'shlib_version' to have the appropriate major/minor versions (pkg_add(1) will tell you which ones it wants. a good article on how these work here: http://www.tedunangst.com/flak/post/OpenBSD-version-numbers) make && make install the bsd.port.mk(5) build system is well thought out and allows for straightforward, helpful maneuvers like this pkg_check(8) is also an invaluable tool in helping deal with package issues. also, use the right $PKG_PATH! On Thu, Dec 11, 2014 at 3:13 PM, STeve Andre' wrote: > On 12/11/14 05:59, FRIGN wrote: > >> On Wed, 10 Dec 2014 21:27:46 -0500 >> "STeve Andre'" wrote: >> >> You might want to subscribe to the ports-changes changes list, >>> which will show you what's been changed. The source-changes >>> list will show you all the other cvs commits. Look at >>> >>> http://www.openbsd.org/mail.html >>> >> Btw, now that the topic has come up. Is there a way to view the >> diffs quickly on a source- or port-change? >> Just reading the titles is not very helpful and I also don't feel >> like pulling the entire OpenBSD CVS-tree just to view the recent >> code-changes. >> >> I'm subscribed to numerous mailing lists, and all of them provide >> diff-data in the mail itself. I'm sure more people would subscribe >> to such a list if it actually encouraged to read and check the >> source. >> >> Cheers >> >> FRIGN >> >> Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ? > > You can get a diff of the change of any revision, which should > help out. > > --STeve Andre'
Re: AMD64 packages
On 12/11/14 05:59, FRIGN wrote: On Wed, 10 Dec 2014 21:27:46 -0500 "STeve Andre'" wrote: You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ? You can get a diff of the change of any revision, which should help out. --STeve Andre'
Re: AMD64 packages
On 2014-12-11, Oliver Peter wrote: > On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote: >> Btw, now that the topic has come up. Is there a way to view the >> diffs quickly on a source- or port-change? > > Not official and not instantly updated: > http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ Yes, this is what I use if I'm looking for contents of diffs that have been committed. Personally I also try to keep the main part of my commit logs in the first line (and where ports is concerned I include the name of the port for simple updates rather than just 'update to xx') so that the truncated commit message on this type of display is still usable :-)
Re: AMD64 packages
you could try http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ On Thu, Dec 11, 2014 at 11:59 AM, FRIGN wrote: > On Wed, 10 Dec 2014 21:27:46 -0500 > "STeve Andre'" wrote: > > > You might want to subscribe to the ports-changes changes list, > > which will show you what's been changed. The source-changes > > list will show you all the other cvs commits. Look at > > > > http://www.openbsd.org/mail.html > > Btw, now that the topic has come up. Is there a way to view the > diffs quickly on a source- or port-change? > Just reading the titles is not very helpful and I also don't feel > like pulling the entire OpenBSD CVS-tree just to view the recent > code-changes. > > I'm subscribed to numerous mailing lists, and all of them provide > diff-data in the mail itself. I'm sure more people would subscribe > to such a list if it actually encouraged to read and check the > source. > > Cheers > > FRIGN > > -- > FRIGN > > -- Björn Ketelaars GPG key: 0x4F0E5F21
Re: AMD64 packages
On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote: > Btw, now that the topic has come up. Is there a way to view the > diffs quickly on a source- or port-change? Not official and not instantly updated: http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/ -- Oliver PETER oli...@gfuzz.de 0x456D688F [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]
Re: AMD64 packages
On Wed, 10 Dec 2014 21:27:46 -0500 "STeve Andre'" wrote: > You might want to subscribe to the ports-changes changes list, > which will show you what's been changed. The source-changes > list will show you all the other cvs commits. Look at > > http://www.openbsd.org/mail.html Btw, now that the topic has come up. Is there a way to view the diffs quickly on a source- or port-change? Just reading the titles is not very helpful and I also don't feel like pulling the entire OpenBSD CVS-tree just to view the recent code-changes. I'm subscribed to numerous mailing lists, and all of them provide diff-data in the mail itself. I'm sure more people would subscribe to such a list if it actually encouraged to read and check the source. Cheers FRIGN -- FRIGN
Re: AMD64 packages
That it is a discussion about a discussion, not about any topic of its own. 2014-12-11 12:37 GMT+01:00 Mihai Popescu : > > The conversation is very META. > > > What is META? > > -- May the most significant bit of your life be positive.
Re: AMD64 packages
> The conversation is very META. What is META?
Re: AMD64 packages
On 2014-12-11, Stan Gammons wrote: > Ok. The way I normally update is by downloading the install5x.iso, make > the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do > pkg_add -u. After all the failures because of the library mismatch, kde4 > will no longer start due to an ssl library mismatch. Bummer... Looks like > it's wait until new packages are built. That method is ok, you just need to allow for library changes. I'd suggest following source-changes so you can spot these and hold off on updating for a couple of days.
Re: AMD64 packages
> > If you don't understand that snapshots get built, that libraries > > crank, that there are PEOPLE building this, that the data takes time > > to get to the mirrors, and that this is a non-static situation, that > > small catch-up syncronization errors are made, that they get fixed by > > real people, then PLEASE DON'T RUN SNAPSHOTS. > [...] > > Oh, I wasn't accusing anybody, or pointing fingers, or anything like > that. I was just saying it's currently broken, that's all. Sorry if it > came accross any other way. It happens all the time. The conversation is very META.
Re: AMD64 packages
On 11 December 2014, Theo de Raadt wrote: > > On 10 December 2014, Stan Gammons wrote: > > > When will new packages be built for AMD64? I'm getting library errors > > > with the latest snapshot and the current packages. > > > > There are bigger problems with the latest snapshot: > > > > $ ldd /usr/sbin/unbound > > > > /usr/sbin/unbound: > > /usr/sbin/unbound: can't load library 'libssl.so.30.0' > > /usr/sbin/unbound: exit status 4 [...] > Look, this is rather simple. > > If you don't understand that snapshots get built, that libraries > crank, that there are PEOPLE building this, that the data takes time > to get to the mirrors, and that this is a non-static situation, that > small catch-up syncronization errors are made, that they get fixed by > real people, then PLEASE DON'T RUN SNAPSHOTS. [...] Oh, I wasn't accusing anybody, or pointing fingers, or anything like that. I was just saying it's currently broken, that's all. Sorry if it came accross any other way. Regards, Liviu Daia
Re: AMD64 packages
Look, this is rather simple. If you don't understand that snapshots get built, that libraries crank, that there are PEOPLE building this, that the data takes time to get to the mirrors, and that this is a non-static situation, that small catch-up syncronization errors are made, that they get fixed by real people, then PLEASE DON'T RUN SNAPSHOTS. Hours later, another snapshot neaks out for each architecture, which has managed to pick up the shared library crank. Please learn what the snapshot processes are. It's in the FAQ! If you don't learn and understand the strong tech-innovation promise but much weaker delivery promise of snapshots, you are denegrating the effort by chattering into people's mailboxes. We do what we can, based on what we have. It is very nearly an auto-build platform with catchup corrections for these details. AND furthermore, snapshots sometimes contain surprise eggs for future coming test code; where it is easier to build it for all architectures and get it dogfooded in subsets of the test community, than wait and wait and wait for them to build it themselves. Those are our prorities showing through. Alternatively we could create a snapshots-failed-minute-...@openbsd.org mailing list, which I will not participate in. > On 10 December 2014, Stan Gammons wrote: > > When will new packages be built for AMD64? I'm getting library errors > > with the latest snapshot and the current packages. > > There are bigger problems with the latest snapshot: > > $ ldd /usr/sbin/unbound > > /usr/sbin/unbound: > /usr/sbin/unbound: can't load library 'libssl.so.30.0' > /usr/sbin/unbound: exit status 4 > > $ ls -l /usr/lib/libssl* > > -r--r--r-- 1 root bin 1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2 > -r--r--r-- 1 root bin 1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0 > -r--r--r-- 1 root bin 1518550 Dec 8 07:54 /usr/lib/libssl.so.29.0 > > $ dmesg | head -1 > OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014 > > > Regards, > > Liviu Daia > <
Re: AMD64 packages
On 10 December 2014, Stan Gammons wrote: > When will new packages be built for AMD64? I'm getting library errors > with the latest snapshot and the current packages. There are bigger problems with the latest snapshot: $ ldd /usr/sbin/unbound /usr/sbin/unbound: /usr/sbin/unbound: can't load library 'libssl.so.30.0' /usr/sbin/unbound: exit status 4 $ ls -l /usr/lib/libssl* -r--r--r-- 1 root bin 1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2 -r--r--r-- 1 root bin 1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0 -r--r--r-- 1 root bin 1518550 Dec 8 07:54 /usr/lib/libssl.so.29.0 $ dmesg | head -1 OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014 Regards, Liviu Daia
Re: AMD64 packages
On Dec 10, 2014 10:03 PM, "STeve Andre'" wrote: > > On 12/10/14 20:51, Stan Gammons wrote: >> >> When will new packages be built for AMD64? I'm getting library errors >> with the latest snapshot and the current packages. >> >> Stan >> >> > They come out frequently, but not on a set schedule. Since the > last set came out on the 6th, I would expect the next set in the > next several days -- unless some change caused a cascade of > non-compiles in which case the problem will be worked on before > the next release. > > You might want to subscribe to the ports-changes changes list, > which will show you what's been changed. The source-changes > list will show you all the other cvs commits. Look at > > http://www.openbsd.org/mail.html Ok. The way I normally update is by downloading the install5x.iso, make the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do pkg_add -u. After all the failures because of the library mismatch, kde4 will no longer start due to an ssl library mismatch. Bummer... Looks like it's wait until new packages are built. Stan
Re: AMD64 packages
On 12/10/14 20:51, Stan Gammons wrote: When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. Stan They come out frequently, but not on a set schedule. Since the last set came out on the 6th, I would expect the next set in the next several days -- unless some change caused a cascade of non-compiles in which case the problem will be worked on before the next release. You might want to subscribe to the ports-changes changes list, which will show you what's been changed. The source-changes list will show you all the other cvs commits. Look at http://www.openbsd.org/mail.html
AMD64 packages
When will new packages be built for AMD64? I'm getting library errors with the latest snapshot and the current packages. Stan
