Re: Removing fdisk and bsdlabel (legacy partition tools)
add variation of this to stock image to get better rescue media. maybe installer could even be updated a bit. if that is really big issue. cons is that this requires network to be present. but where to get packages from anyway without it, perhaps dvd1. i actually find it confusing that highly technically skilled people who clearly run non-standard hw of various archs and with several oses, for work or hobby, argue how installer sucks. you can patch it. then you can use it locally or submit it to fbsd. i don't know, maybe i'll do it then? --- cut --- #!/bin/sh -Cefu set -Cefu kbdcontrol -r fast -l ee test -d /tmp/unionfs/etc || mkdir -p /tmp/unionfs/etc mount -t unionfs | fgrep -q /etc || mount_unionfs /tmp/unionfs/etc /etc test -d /tmp/unionfs/root || mkdir -p /tmp/unionfs/root mount -t unionfs | fgrep -q /root || mount_unionfs /tmp/unionfs/root /root test -f /etc/wall_cmos_clock || touch /etc/wall_cmos_clock test -f /etc/localtime || tzsetup Europe/Tallinn pgrep -q adjkerntz || service adjkerntz start ifconfig -a -G lo | grep '^[a-z0-9]' | cut -d : -f 1 | xargs -n 1 sh -c \ 'echo ; service dhclient status "$0" || service dhclient forcestart "$0"' test -f /tmp/ntpdate_run_done \ || ( echo ; ntpdate dome && touch /tmp/ntpdate_run_done ) echo service ntpd onestatus || service ntpd onestart echo test -f /tmp/ntpdate_run_done && ntpdate -q dome echo date echo test -f /boot/kernel/coretemp.ko && kldload -n coretemp test -f /boot/kernel/amdtemp.ko && kldload -n amdtemp sysctl -a | grep '[0-9]C$' | egrep -v '(_(CRT|PSV)|\.tjmax)' sysctl -a | fgrep -q battery \ && ( echo ; acpiconf -i 0 | grep -v ':[[:space:]]*$') echo --- cut --- On 26 January 2024 22:11:44 EET, Freddie Cash wrote: >Sounds like a custom mfsBSD or Frenzy CD/USB would be better suited to >these bare-metal rescue setups. Something that has the specific tools you >need already installed. I know I've kept various versions of these CD >images around for just this purpose. I always found them nicer to use than >the FreeBSD install CDs in rescue mode, as there's a fully-functional >FreeBSD install to work from, including the ability to install packages >temporarily. >
Re: Removing fdisk and bsdlabel (legacy partition tools)
call me new, i only started with 4.6, being 19 years old at that time, which is pretty good i think i've always found anything but gpart way too confusing to use. by that time i started with fbsd, chs was also gone for good. hence, no need, and when gpart came, i just switched over. and i consider myself a slow adapter to some of new things also, why would ufs users need to be immediately assumed to be only using anything but gpart? it's not like ufs is some old legacy. also i don't really believe you could really use 15 with all the features except of some disk tools. on all new hw. on old hw, you won't be using 15. because fdisk is not the only thing we removed over years. unsure if sad or happy path. nbsd seems to support everything still i see. i don't know, maybe i should have really started with actual unix where i would have gotten lifelong preference to fdisk and disklabel. high respect if those ones read this tho but yea, from all the replies, only thing i see is fdisk and disklabel is more comfortable to use, while giving no technical benefits at all. fuck knows if that's the reason to keep them then i recall myself objecting before when there was call to remove grdc and pom. can't say about pom, i've used it for fun sometimes. grdc found use when checking if times are in sync. but those really belong to ports. it not like those disappear or get banned. i could put them there myself, if it comes up again and i still miss them we have moved a lot of things to ports already, since 4.6. altho, if pkgbase comes along, some argue against it too, it would be hard to draw a line where the "base" ends. what's "officially" supported and what's not but yeah, i can confirm that a lot of changes have annoyed me. switch to pkgng. or that libxo breaks stuff. pkgng now works i think, xo is still crapshoot. despite, i admit i like being able to get json from sysutils so yeah changes kind of suck, but they still happen?
Re: Proposal: Disable compression of newsyslog by default
On 23 December 2023 09:18:23 EET, Xin Li wrote: >Hi, > >Inspired by D42961, I propose that we move forward with disabling the >compression by default in newsyslog, as implemented in >https://reviews.freebsd.org/D43169 > >Historically, newsyslog has compressed rotated log files to save disk space. >This approach was valuable in the early days where storage space was limited. it's still limited >However, the landscape has changed significantly. Modern file systems, such >as ZFS, now offer native compression capabilities. not everyone uses them >Additionally, the widespread availability of larger hard drives has diminished >the necessity for additional compression. but data sizes also have increased massively >Notably, the need to decompress log files for pattern searches poses a >significant inconvenience, further questioning the utility of this legacy >feature. should be up to each admin to cba decompression vs. plain speed/size/etc >In commit 906748d208d3, flags J, X, Y, Z can now indicate that a log file is >eligible for compression rather than directly enforcing it. It allows for a >more flexible approach, wherein the actual compression method can be set to >"none" or specified as one among bzip2, gzip, xz, or zstd. that's good approach >Therefore I would propose that we change the default compression setting to >"none" in FreeBSD 15.0. This change reflects our adaptation to the evolving >technological environment and user needs. It also aligns with the broader >initiative to modernize our systems while maintaining flexibility and >efficiency. unsure about this. generic zroot install would be fine with this i guess, and usual log sizes? other custom installs need tuning anyway >I look forward to your thoughts and feedback on this proposal. > >Cheers, indeed. we have large disks now. but we fill them all. i started with 1.2g one. was too small. needed to compress for space. now i have 12t. it's still too small. i compress for space. they make them up to 22t nowadays. this is about 2 times larger but still feels small. how did this happen? we just did this to ourselves. data sizes have kept up with storage and bandwidth. gamer might get 1gbit/s connection at home so (s)he only needs to wait for one hour to download new game. just as dialup user once did, wait for hours. or it could be photographer, graphics designer or architect who works. both cases still use compressed data as cpu and ram permits it and it saves a lot of time and space. now, it's also related to servers as those things don't disappear to or appear from just thin air. they come from machines, some of them hopefully running fbsd, where admins wonder how to deal with large log sizes. they need them for audit purposes. or statistics. hardware allows, so they compress it. "write-only-read-never" data benefits from, eg, xz a lot. as others already have told so yeah, from (only!) 25+ years of experience, i can confirm that humankind has developed AND used everything at max. internet, first for military and educational uses, now for connecting washing machines. oh and, first hdd, state of art device then, can only store *part* of *compressed* photo now now, this might not be related to default fbsd installs in common usage where default base syslog creates tiny amount of data per week but one of reasons was given how everything fits uncompressed nowdays. to our disks and pipes. which it really doesn't
(some?) armv7 time issues fixed with hw.userspace_allow_phys_counter=1
i found issue, but this needs more testing and i only have allwinner h3 here with hw.userspace_allow_phys_counter=1 time doesn't jump forward and back (!) anymore i tracked this down to this commit here: 7ad28b73ec1f - arm: Add a userspace physical timer check perhaps there are more people out there with current on 32bit arm...
time instability
there's something between (working): 47d997021fbc and (not working): 03bfee175269 that causes this to happen: # date +%s 1694821998 # date +%s 1694822034 # date +%s 1694822036 # date +%s 1694822003 it's armv7 allwinner h3 board this issue happens in. i have no clue where to look except to brute force it maybe tomorrow what was committed in past two weeks that might cause this? running ntpd and powerd were killed, it didn't help a bit was real fun too, as time machine seems to have been invented, but, wtf!
Re: Stray characters in command history
i'm experiencing kind of similar issue. unsure why or how. i have 13.2. console is sc. the other side, via serial, is running current. uart is from usb serial adapter. other side has native soc uart. when i establish connection to that thing with cu, which is embedded board btw, and log in, i get weird random chars as if i've typed them in. if i do some input right after, i don't seem to get it. it gets worse, if i let cu run in other terminal and do some testing that involves lot of reboot cycles, while doing some tasks on other terminal, sometimes weird chars get injected into my input elsewhere. eg i run editor and it's annoying for something to appear as if i've typed it in. is it related? thankfully target isn't untrusted, otherwise it would be pretty bad? or where this thing even comes from? i know that you can do funny stuff with tiocsti and co but this looks pretty bad. both the fact that something makes it and the fact that they get injected elsewhere. there is also a some recent bug around this. so i'm not sure what to think of it all? On Sunday, May 21, 2023, bob prohaska wrote: > Here is another example, perhaps a bit clearer. > > The ssh connection to the first Pi3 in the chain had dropped, so it was > re-establishing via a regular user login, then su was invoked and tip run: > . > To change this login announcement, see motd(5). > Want to go the directory you were just in? > Type "cd -" > bob@pelorus:~ % su > Password: > # tip ucom > Stale lock on cuaU0 PID=2487... overriding. > connected > osed by r31 www s This appeared spontaneously, then I hit return. > osed: Command not found. < I didn't type anything. > bob@www:/usr/src %< The shell prompt on the 2nd Pi3's serial console. > > Clearly nothing to do with sshd, might it simply be a misdirected echo of console > output generated by a (dead or broken) tip connection? The first example looked > possibly malicious, this does not > > Thanks for reading, > > bob prohaska > > > > On Sun, May 21, 2023 at 06:49:33AM -0700, bob prohaska wrote: >> Lately I've been playing with buildworld on a Pi3 running -current. The same machine >> acts as a terminal server for a second Pi3 also running -current in my "cluster". >> I ssh into the first Pi3, su to root and run tip to pick up a serial connection to >> the second Pi's console. Both machines are within a week of up-to-date. >> >> While building world on the first Pi3 the ssh connection frequently drops and must be >> re-established. If there was a shell running on the serial console of the second >> Pi3 it typically keeps running and when the tip session is restarted disgorges a >> stream of accumulated console message. >> >> This morning the same thing happened, but I noticed something odd. The stream of >> messages (all login failure announcements from ssh) ended with >> >> >> May 21 06:15:00 www sshd[33562]: error: Fssh_kex_exchange_identification: banner line contains invalid characters >> *+May 21 06:15:19 www sshd[33565]: error: Fssh_kex_exchange_identification: Connection closed by remote host >> May 21 06:15:33 www sshd[33613]: error: Protocol major versions differ: 2 vs. 1 >> >> At that point I hit carriage return and got >> *+: No match. >> >> I did not type the *+ so it looks like the characters were somehow introduced elsewhere, >> possibly from the ssh failure message. How they got into the command stream is unclear. >> >> This strikes me as undesirable at best and possibly much worse. The shell reporting >> the "no match" was a regular user shell, but if I'd been su'd to root it appears that >> the unmatched characters would be seen by the root shell as input. >> >> This more-or-less fits with the pattern seen earlier with reboots observed via serial >> console halting on un-typed keystrokes. Those halts were attributed to electrical noise >> on the serial line, but this looks like something injected via part of the network >> login process. Reboot pauses have been an ongoing phenomenon for months, this is the >> first time I've noticed the "invalid characters" message from ssh on the console. >> >> Thanks for reading, apologies if I'm being a worrywart. >> >> bob prohaska >> >> >> > >
Re: etcupdate -B, /.cshrc and /.profile
on why removing those, i for example only use /etc/csh.cshrc so i don't need others
Re: The future for support of BeagleBone Black and its variants
i wonder what's the latest point in repository that DOES work? my bbb runs current from year 2014, it does run well and off emmc. it's awfully crap compared to my h3 but i would still like to have something on it. when i started working with embedded hw again, i took that out of box too, expected to seamlessly run latest current on that still, only to found out that doesn't work... On Thursday, August 10, 2023, George Abdelmalik wrote: > Hi David, > > The problems are kernel related. If I understand correctly it's in the area of clock definitions I think but I've not properly studied the patches. > > DTC is good. > > Regards, > George. > > > On 10/8/23 14:52, David Chisnall wrote: >> >> Hi, >> >> What are the changes to the DTS files? If there are problems with DTC handling the new files, please can you raise issues here: https://github.com/davidchisnall/dtc/issues >> >> If there are problems with the kernel’s handling of the dtb, please ignore me. >> >> David >> >>> On 10 Aug 2023, at 13:24, George Abdelmalik wrote: >>> >>> Hi all, >>> >>> For a long while now CURRENT has not been working on the BBB due to incompatible upstream changes in vendor DTS files. I know there are some patches available which at least get FreeBSD running but those have yet to be incorporated into the project's repository. >>> >>> This leaves me with the feeling that BBB support in FreeBSD is on the path to being dropped. Is there someone from the FreeBSD project that could speak directly to this? >>> >>> As a user it would be helpful to know if I should be searching of an alternate SBC platform or another OS for my projects. >>> >>> If it still remains the plan to keep supporting BBB into 14.0 and beyond then I'd like to know what work is missing to make that happen. I'm willing and able to help. >>> >>> Regards, >>> George. >>> >>> >>> > >
new syctl to allow ignoring time from fs if no rtc found
unsure if anybody else needs that functionality. i was suggested to submit
it into actual code review place, but i'm unsure. it's from 2014, it still
cleanly applies. probably because noone needed to touch working code!
anyway, i used it in in arm board development, in bbb, to default system
time to "visually invalid" 1970 when no other source was found. i found
getting time from filesystem causing much confusion when files were created
before ntp sync. so i added this hack
http://ketas.si.pri.ee/bbb/src-patches/debug-no-timestamp-from-filesystem.diff
Index: sys/kern/vfs_mountroot.c
===
--- sys/kern/vfs_mountroot.c (revision 274644)
+++ sys/kern/vfs_mountroot.c (working copy)
@@ -968,14 +968,16 @@
* timestamps we encounter.
*/
timebase = 0;
- mtx_lock(&mountlist_mtx);
- mp = TAILQ_FIRST(&mountlist);
- while (mp != NULL) {
- if (mp->mnt_time > timebase)
- timebase = mp->mnt_time;
- mp = TAILQ_NEXT(mp, mnt_list);
+ if (kern_getenv("debug.no_timestamp_from_filesystem") == NULL) {
+ mtx_lock(&mountlist_mtx);
+ mp = TAILQ_FIRST(&mountlist);
+ while (mp != NULL) {
+ if (mp->mnt_time > timebase)
+ timebase = mp->mnt_time;
+ mp = TAILQ_NEXT(mp, mnt_list);
+ }
+ mtx_unlock(&mountlist_mtx);
}
- mtx_unlock(&mountlist_mtx);
inittodr(timebase);
/* Keep prison0's root in sync with the global rootvnode. */
Index: sys/kern/vfs_mountroot.c
===
--- sys/kern/vfs_mountroot.c (revision 274644)
+++ sys/kern/vfs_mountroot.c (working copy)
@@ -968,14 +968,16 @@
* timestamps we encounter.
*/
timebase = 0;
- mtx_lock(&mountlist_mtx);
- mp = TAILQ_FIRST(&mountlist);
- while (mp != NULL) {
- if (mp->mnt_time > timebase)
- timebase = mp->mnt_time;
- mp = TAILQ_NEXT(mp, mnt_list);
+ if (kern_getenv("debug.no_timestamp_from_filesystem") == NULL) {
+ mtx_lock(&mountlist_mtx);
+ mp = TAILQ_FIRST(&mountlist);
+ while (mp != NULL) {
+ if (mp->mnt_time > timebase)
+timebase = mp->mnt_time;
+ mp = TAILQ_NEXT(mp, mnt_list);
+ }
+ mtx_unlock(&mountlist_mtx);
}
- mtx_unlock(&mountlist_mtx);
inittodr(timebase);
/* Keep prison0's root in sync with the global rootvnode. */
Re: You are thirty, you proper beaute: congratulations!
i installed v4.6. that was a long time ago. the public honeypot ran it, and i got curious. i've been using it since then. in servers, desktops, laptops and in embedded systems. yes, i know that hw support is not ideal. but quality is. that's my story. 21 years of that 30 i have been (t)here. sure, i just can't be as good kernel hacker than the late damnhippi was, but i can do other things. i'm not just an user nevertheless On Tuesday, June 20, 2023, Dmitry Salychev wrote: > > Steffen Nurpmeso writes: > >> Everyday's life abrades, but to me it is always nice to come back. >> >> Thanks to everyone working on this project. > > My pleasure ^_^ > >> >> And i hope you keep on going. > > As long as I can. > >> >> --steffen >> | >> |Der Kragenbaer,The moon bear, >> |der holt sich munter he cheerfully and one by one >> |einen nach dem anderen runter wa.ks himself off >> |(By Robert Gernhardt) > > Regards, > Dmitry > > -- > https://wiki.freebsd.org/DmitrySalychev > >
Re: FreeBSD Core Team Response to Controversial Social Media Posts
the discussion somehow diverted away from original idea... as i'm not politically correct person at all, i say that single report is not enough... it doesn't matter if legit or troll... it's also quite wrong if case gets special attention just because offended person adds that (s)he's discriminated because x i actually find it weird why the problem can't be directed to specific person... why do we need to turn it into "against group" issue On Monday, May 20, 2019, wrote: > Am 2019-05-20 11:33, schrieb Igor Mozolevsky: >> >> So you think a discussion on whether it is appropriate that CoC Ctte >> restricts freedom of expression is bikeshedding? >> >> Thank you for your valuable contribution! > > > IMO, the CoC was not meant to solve, decide or even regulate discussion about decades-old, very controversial geo-political problems. > > As such, I don't think it even applies here and the complaint should be dismissed on these grounds. > > Of course, the FreeBSD project is free to boot developers from its ranks more or less at will (not sure if you can sue your way back in) - but for that a new CoC wouldn't have been needed to begin with ;-) > > > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD Core Team Response to Controversial Social Media Posts
On Friday, May 10, 2019, FreeBSD Core Team Secretary <
core-secret...@freebsd.org> wrote:
> The FreeBSD Core Team is aware of recent controversial statements made
> on social media by a FreeBSD developer. We, along with the Code of
> Conduct review committee, are investigating the matter and will decide
> what action to take. Both the Core Team and the FreeBSD Foundation
> would like to make it clear that views shared by individuals represent
> neither the Project nor the Foundation.
>
> --
> FreeBSD Core Team
>
is this a political party?! i thought it was developer team of certain
specific area server operating system?
first, i would like to know if this is a joke? because it must be! then, if
it's not, what has said and by who?
was it like "i hate women" or "i don't recommend fbsd for this purpose"?
anyway, i'm not surprised if developers act strange on *social* media, as
they often behave what would be called inappropriate at best... that's why
they write code and don't sing on eurovision song contest, become elected
as president of the united states, or play on the newest marvel action
movie as a lead actor...
i know this, as i often act bad... sometimes i tell people which kind
mental disorders i have been diagnosed with ("only" asperger's syndrome, if
you're curious) as i often have problems of not understanding certain
social rules, which can't be fixed in any way, doesn't matter if people
insult me on how i did it again and how come i can't ever learn... sorry, i
really can't! each time it's surprise to me what happened...
i've used fbsd since v4.6, and despite having written some code already, i
don't really see myself becoming something like "official developer" if it
gives me this "extra butt" i could be kicked into if needed
also, if hans reiser in one day comes and wants to do something, do we turn
him down with like "sorry, you can't write code here, you killed your
wife"? really?
i think freebsd has enough purely technical disagreements that we don't
really need anything ELSE into this mix (like, what did the dev tweet last
night)
On Friday, May 10, 2019, FreeBSD Core Team Secretary <
core-secret...@freebsd.org> wrote:
> The FreeBSD Core Team is aware of recent controversial statements made
> on social media by a FreeBSD developer. We, along with the Code of
> Conduct review committee, are investigating the matter and will decide
> what action to take. Both the Core Team and the FreeBSD Foundation
> would like to make it clear that views shared by individuals represent
> neither the Project nor the Foundation.
>
> --
> FreeBSD Core Team
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD has a politics problem
I knew this would be end result of that coc(k) being whipped out. Also, I'm sure that it's not feminism you hate, it's that some idiots hide under that blanket and imagine they can't be attacked anymore. Why did that need for a new set of weird rules come out anyway? Right now it feels like successful trolling. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Massive libxo-zation that breaks everything
How about we allow JSON input on those utils too... Then we get into full-blown hell faster. Hmm... I would like to talk with system using JSON. JSON would be in utils that are or at least function similarly to rm, mv, ls, find, mount, zpool, zfs, geom, mdconfig, tar, df, netstat, ifconfig... (or maybe even talk JSON directly to the kernel?!). How to have all that goodness, while at same time not having extra library dependency? Without that library the system wouldn't work at all (and there is no fallback mode for "manual operation"). Fragile library that requires you to have worse-than-bad-Perl-looking (funnily I write lot of Perl myself) parts everywhere in your code. And requires huge set of tests to verify correct operation. Hope that you never see things like this: > df Shared object "libxo.so.0" not found, required by "df" Or this: > netstat -nhbdWi Name Mtu Network Address Ipkts Ierrs Idrop IbytesOpkts Oerrs Obytes Coll Drop smc0 %6s 1.5K 52:54:00:12:34:56 %8s 4.4M %5s 0 %5s 0 %10s 290M %8s 3.3M %5s 0 %10s 756M %5s 0 %5s 11 smc0- fe80::5054:ff fe80::5054:ff:fe1 %8s 8.7K - - %10s 592K %8s 17K - %10s 1.0M - - smc0- 2001:ad0:91f: 2001:ad0:91f:0:50 %8s 4.4M - - %10s 225M %8s 3.3M - %10s 709M - - smc0- 10.0.0.0/24 10.0.0.48 %8s 4.0K - - %10s 504K %8s 3.2K - %10s 233K - - lo0%6s16K %8s 272 %5s 0 %5s 0 %10s24K %8s 272 %5s 0 %10s24K %5s 0 %5s 0 lo0 - ::1/128 ::1 %8s 136 - - %10s16K %8s 136 - %10s16K - - lo0 - fe80::1%lo0/6 fe80::1%lo0 %8s0 - - %10s 0 %8s7 - %10s963 - - lo0 - 127.0.0.0/8 127.0.0.1 %8s 136 - - %10s 8.6K %8s 136 - %10s 8.6K - - Or, at least you only see it (occasionally) in CURRENT. ( And, all current libxo issues seem to be fixed, for now... ) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Massive libxo-zation that breaks everything
Hello. First, I would be happy to have JSON and XML output about filesystems, users, routes... but I don't like how it makes code of df, w, netstat hard to read/maintain and often broken. I don't think it would be good to continue with this. Maybe the effort should be put to creating new layer/library and then something on top of it that actually outputs JSON and XML. Or, if that's too difficult... maybe just regular df/w/netstat could be copied to somewhere else and made code libxo-output-only. And original df/w/netstat changes reverted and left alone. Then, maybe later, df/w/netstat/... could be updated to this new layer/library. Or maybe this should be just left as it is. That would mean having two netstat's in system, which could be both good (separation) and bad (maintaining). Just some ideas... I don't know how to solve this issue fully. I'm also not likely the one who would write code for all this. Hell, those aren't even all my ideas here. I just worry that system drop-in xo-zation is bad for overall health of base. Oh and, it makes rescue larger and more complex, too? On that, there was suggestion to maybe create separate "first aid kit" and "emergency room" types of system rescue utils/methods. Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
Maybe I should add (if no-one noticed it yet) that this is cross-build for ARM. I wouldn't attempt to upgrade host itself over two major versions. I think it's totally insane how you can't build other major versions & arches. 9.x can't make 11.x (well, you can, if using gcc bootstrap), and I heard that 10.x can't make 9.x... I mean, build should start "clean", building all things that are needed to bootstrap. If needed, building some tools two times to get into right environment (host -> bootstrap -> bootstrap -> build). Of course, i realize how much work that would be... But this would make it possible to build things across all supported major versions and across arches where it's not too hard to support (for example, MIPS -> amd64 likely doesn't make sense, but i386/amd64 -> ARM/MIPS/... likely has uses). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADS UP: Upgraded clang, llvm and lldb to 3.5.0
Hello. I have this issue where it's impossible to get 9.x (9.3) into state where I can build clang 3.5.0 bootstrap of CURRENT. gcc works fine. I've already discussed this with some people in EFNet :: #bsdmips Currently I have this jail, built using: WITH_CLANG_IS_CC WITH_LIBCPLUSPLUS I get strange errors like: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/APFloat.cpp:15: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APFloat.h:20: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/APInt.h:19: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/ArrayRef.h:14: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/ADT/SmallVector.h:20: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/MathExtras.h:21:10: fatal error: 'type_traits' file not found #include ^ 1 error generated. Or: In file included from /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/lib/Support/FileOutputBuffer.cpp:14: /usr/src/lib/clang/libllvmsupport/../../../contrib/llvm/include/llvm/Support/Errc.h:33:10: fatal error: 'system_error' file not found #include ^ 1 error generated. There are files: /usr/include/c++/4.2/tr1/type_traits /usr/include/c++/v1/type_traits /usr/include/c++/v1/system_error Where files in v1/ directory seem to be indeed correct ones and part of clang. But include paths seem wrong? Or is it something else? Full log: http://ketas.si.pri.ee/bbb.build.1420677522.log I don't know... if 9.x can't be used to build 11.x / CURRENT anymore, maybe this should be put to UPDATING (that 9.x is not supported) and I just upgrade to 10.x... which would solve everything (hopefully). Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: USB locks up system -- WAS Re: shutdown or acpi problem
On 2014-11-17 08:58, Dag-Erling Smørgrav wrote: > Dag-Erling Smørgrav writes: >> Steve Kargl writes: >>> I'll try that tomorrow. But, I now know that this is related to using >>> hal from ports. If I comment out both enable_dbus and enable_hal in >>> /etc/rc.conf, the system works as I would expect (ie., usb now works >>> for unplugging devices!). I further suspect that the problems lies in >>> hal_probe_storage, but haven't got too much further. >> HAL: the gift that keeps on giving. It also has this wonderful feature >> where it prevents you from unmounting anything you've ever mounted, >> because it watches for new mountpoints in the system, opens them, and >> keeps the file descriptors open indefinitely. >> >> I know this isn't really germane, but I just couldn't pass up a chance >> to complain about HAL. > > Hold on. It *is* germane: hal_probe_storage auto-mounted your USB stick > and is holding on to it. If this also happens with mice and keyboards > etc., you're probably looking at two different issues. > > DES > I cursed at HAL a lot because it made uC inside r0ket to crap itself partially... this thing can be USB device but apparently didn't like black magic that HAL did. Maybe it tried to read from the beginning or something. It took lot of time to figure out why it doesn't work. Now I have set of ignore files to prevent grabbing for every single device in system. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 07:32, Warner Losh wrote:
>
> On May 8, 2014, at 10:12 PM, Sulev-Madis Silber (ketas)
> wrote:
>
>> On 2014-05-09 02:54, Warner Losh wrote:
>>>
>>> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>>>
>>>> Hi,
>>>>
>>>> After the bsd.opts.mk / src.opts.mk split
>>>> WITHOUT_NIS in src.conf doesn't work.
>>>
>>> It should still work… At least that’s the intention...
>>>
>>>> src.conf is included in src.opts.mk after bsd.own.mk
>>>> which includes bsd.opts.mk.
>>>
>>> Yea, that’s a problem… It should be included after.
>>>
>>>> Should bsd.opts.mk options overrides now be set in
>>>> make.conf instead of src.conf?
>>>
>>> That’s a good workaround until I get that fix tested and committed. Or you
>>> could include src.conf in make.conf at the end. Either will have the same
>>> effect.
>>>
>>> Here’s the fix I’m testing, if you’d like to test that instead...
>>>
>>> diff -r d69444b828c1 share/mk/src.opts.mk
>>> --- a/share/mk/src.opts.mk
>>> +++ b/share/mk/src.opts.mk
>>> @@ -30,17 +30,15 @@
>>> .if !target()
>>> :
>>>
>>> -# Compat -- needed still?
>>> -.include
>>> -
>>> -# Allow user to configure things, but in the future this will move
>>> -# elsehwere...
>>> -
>>> +# Allow user to configure things that only effect src tree builds.
>>> SRCCONF?= /etc/src.conf
>>> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
>>> .include "${SRCCONF}"
>>> .endif
>>>
>>> +# Must be included after src.conf
>>> +.include
>>> +
>>> #
>>> # Define MK_* variables (which are either "yes" or "no") for users
>>> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>>>
>>>
>>>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>>>
>>> Yea, sorry about missing this subtle issue in the split. There was another
>>> report of something similar that I hadn’t tracked down, but your report
>>> pointed me to where I needed to go.
>>>
>>> Warner
>>>
>>
>>
>> Sorry, that didn't exactly help. I don't fully get what went so wrong there?
>>
>> Now I got this during install:
>>
>> ---
>> ===> gnu/lib/libregex/doc (install)
>> install-info: not found
>> *** Error code 127
>> ---
>>
>> It was total WTF error but just in case I tried putting ".include
>> <../src.conf>" back, and it worked!
>> I use __MAKE_CONF, and inside that file I have SRCCONF.
>
> To be clear, you define SRCCONF in /etc/make.conf (or the file defined by
> __MAKE_CONF). The file defined by SRCCONF has WITHOUT_NIS=t defined, but
> that’s not effective, even with my change. However, if you add an include to
> the file defined by __MAKE_CONF, then it is effective… Is that what you are
> telling me?
>
>> 9.2, BTW... unsure if it matters here?
>
> I’m doing my testing on 10-stable… I’ll have to try on my 9.x system… But it
> is a lot slower than my 10.x system...
>
> Warner
>
Yes, that's exactly what I mean. It seems to partially work now. I
actually have lot of WITHOUT_*'s. That install error is really weird,
never seen it before. All I know is that before all those changes,
everything worked well. And if I .include file, old behavior (everything
works as expected) is back.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
>
> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>
>> Hi,
>>
>> After the bsd.opts.mk / src.opts.mk split
>> WITHOUT_NIS in src.conf doesn't work.
>
> It should still work… At least that’s the intention...
>
>> src.conf is included in src.opts.mk after bsd.own.mk
>> which includes bsd.opts.mk.
>
> Yea, that’s a problem… It should be included after.
>
>> Should bsd.opts.mk options overrides now be set in
>> make.conf instead of src.conf?
>
> That’s a good workaround until I get that fix tested and committed. Or you
> could include src.conf in make.conf at the end. Either will have the same
> effect.
>
> Here’s the fix I’m testing, if you’d like to test that instead...
>
> diff -r d69444b828c1 share/mk/src.opts.mk
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -30,17 +30,15 @@
> .if !target()
> :
>
> -# Compat -- needed still?
> -.include
> -
> -# Allow user to configure things, but in the future this will move
> -# elsehwere...
> -
> +# Allow user to configure things that only effect src tree builds.
> SRCCONF?=/etc/src.conf
> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
> .include "${SRCCONF}"
> .endif
>
> +# Must be included after src.conf
> +.include
> +
> #
> # Define MK_* variables (which are either "yes" or "no") for users
> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>
>
>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>
> Yea, sorry about missing this subtle issue in the split. There was another
> report of something similar that I hadn’t tracked down, but your report
> pointed me to where I needed to go.
>
> Warner
>
Sorry, that didn't exactly help. I don't fully get what went so wrong there?
Now I got this during install:
---
===> gnu/lib/libregex/doc (install)
install-info: not found
*** Error code 127
---
It was total WTF error but just in case I tried putting ".include
<../src.conf>" back, and it worked!
I use __MAKE_CONF, and inside that file I have SRCCONF.
9.2, BTW... unsure if it matters here?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: WITHOUT_NIS after bsd.opts.mk / src.opts.mk split
On 2014-05-09 02:54, Warner Losh wrote:
>
> On May 8, 2014, at 3:26 PM, Guy Yur wrote:
>
>> Hi,
>>
>> After the bsd.opts.mk / src.opts.mk split
>> WITHOUT_NIS in src.conf doesn't work.
>
> It should still work… At least that’s the intention...
>
>> src.conf is included in src.opts.mk after bsd.own.mk
>> which includes bsd.opts.mk.
>
> Yea, that’s a problem… It should be included after.
>
>> Should bsd.opts.mk options overrides now be set in
>> make.conf instead of src.conf?
>
> That’s a good workaround until I get that fix tested and committed. Or you
> could include src.conf in make.conf at the end. Either will have the same
> effect.
>
> Here’s the fix I’m testing, if you’d like to test that instead...
>
> diff -r d69444b828c1 share/mk/src.opts.mk
> --- a/share/mk/src.opts.mk
> +++ b/share/mk/src.opts.mk
> @@ -30,17 +30,15 @@
> .if !target()
> :
>
> -# Compat -- needed still?
> -.include
> -
> -# Allow user to configure things, but in the future this will move
> -# elsehwere...
> -
> +# Allow user to configure things that only effect src tree builds.
> SRCCONF?=/etc/src.conf
> .if exists(${SRCCONF}) || ${SRCCONF} != "/etc/src.conf"
> .include "${SRCCONF}"
> .endif
>
> +# Must be included after src.conf
> +.include
> +
> #
> # Define MK_* variables (which are either "yes" or "no") for users
> # to set via WITH_*/WITHOUT_* in /etc/src.conf and override in the
>
>
>> Was on r265455, updated to r265715 and rebuilt with -DNO_CLEAN.
>
> Yea, sorry about missing this subtle issue in the split. There was another
> report of something similar that I hadn’t tracked down, but your report
> pointed me to where I needed to go.
>
> Warner
>
Finally! Trying it now...
I was about to take deep look into it because that bothered me so much.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
