Re: Intel GPU driver import
On 5/12/2012 4:39 PM, Konstantin Belousov wrote: > > My own preference is to implement second choice and put the driver > into dev/drm2. Is there a way to have an OPTION in the config file build one driver, and without the OPTION to build the other, but use the same name? If so, that might be the most elegant solution.. Chuck ___ 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: FreeBSD 10 prognostication...
On 5/16/2012 6:02 PM, Outback Dingo wrote: Guess his next claim will be that the kernel was forked from minix, and userland came from QNX... some people are just plain (biting my tongue) You guys DO realize that's a troll website, right? And you're being seriously trolled.. right? *shakes head and walks away* Chuck Burns ___ 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: Chrome crashing system (amd64-10.0-CURRENT)
On 5/17/2012 2:11 AM, John Hixson wrote: On Thu, May 17, 2012 at 01:15:54AM -0500, Conrad J. Sabatier wrote: For the last week or so, I've been unable to run chrome. Any attempt to start it up will cause the system either to freeze up or reboot. To add to this, I've had the same problem on 10-CURRENT for several months now. Are you guys building ports with clang? There's a known bug with google-perftools, when it's built with clang, chrome will crash upon launch. chrome itself can be built with any compiler, but if google-perftools is built with clang, crash! http://code.google.com/p/gperftools/issues/detail?id=394 -- Chuck Burns ___ 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: Clang as default compiler November 4th
On Fri, 14 Sep 2012 15:23:19 -0500 Brooks Davis wrote: > On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: > > On Thu, Sep 13, 2012 at 09:32:12AM -0600, Ian Lepore wrote: > > > On Wed, 2012-09-12 at 19:08 -0700, Steve Kargl wrote: > > > > In regards to my initial post in this thread, I was just trying > > > > to assess whether any benchmarks have been performed on FreeBSD > > > > for floating point generated by clang. Other than the limited > > > > testing that I've done, it appears that the answer is 'no'. > > > > > > > > > > We have src/tools/tests/testfloat and src/tools/regression/lib/msun. I > > > know nothing about the former (just noticed it for the first time). The > > > latter I think is a set of correctness tests rather than performance > > > tests. > > > > It's quite clear that the clang proponent have not tried > > to run src/tools/regression/lib/msun. > > > > % setenv CC clang > > % make |& grep warning | wc -l > > 1354 > > % make clean > > % make |& tee make.log > > % head -20 make.log > > clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp > > test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, > > ignoring pragma [-Wunknown-pragmas] > > #pragma STDC FENV_ACCESSON > > ^ > > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > > ^~~ > > test-cexp.c:98:7: note: expanded from macro 'testall' > > test(cexp, x, result, exceptmask, excepts, checksign); \ > > ^ > > test-cexp.c:87:11: note: expanded from macro 'test' > > assert(((func), fetestexcept(exceptmask) == (excepts)));\ > > ^ > > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > > ^ > > test-cexp.c:183:2: warning: expression result unused [-Wunused-value] > > testall(0.0, 1.0, ALL_STD_EXCEPT, 0, 1); > > ^~~ > > test-cexp.c:99:7: note: expanded from macro 'testall' > > > > % tail -20 make.log > > test-trig.c:69:11: note: expanded from macro 'test' > > assert(((func), fetestexcept(exceptmask) == (excepts)));\ > > ^ > > /usr/include/assert.h:54:21: note: expanded from macro 'assert' > > #define assert(e) ((e) ? (void)0 : __assert(__func__, __FILE__, \ > > ^ > > 74 warnings generated. > > clang -O2 -pipe -march=opteron -O0 -lm test-fenv.c -o test-fenv > > test-fenv.c:82:14: warning: pragma STDC FENV_ACCESS ON is not supported, > > ignoring pragma [-Wunknown-pragmas] > > #pragma STDC FENV_ACCESS ON > > ^ > > 1 warning generated. > > for p in test-cexp test-conj test-csqrt test-ctrig test-exponential > > test-fma test-fmaxmin test-ilogb test-invtrig test-logarithm test-lrint > > test-lround test-nan test-nearbyint test-next test-rem test-trig > > test-fenv; do /usr/src/tools/regression/lib/msun/$p; done > > Assertion failed: (((cexp), fetestexcept((0x04 | 0x20 | 0x01 | 0x08 | > > 0x10)) == (0))), function test_nan, file test-cexp.c, line 211. > > 1..7 > > ok 1 - cexp zero > > Abort trap (core dumped) > > *** [tests] Error code 134 > > > > Stop in /usr/src/tools/regression/lib/msun. > > Prompted by this post, I did a bit of testing and it looks like we have > two classes of failures that need to be investigated. First, some tests > are failing with a gcc compiled world and clang compiled test code. > They seem to mostly be unexpected fp exception state when testing with > NaNs. I suspect that someone more knowledgeable in this area could come > up with a reduced test case and explication of what clang is doing wrong > pretty quickly. > > The second class is tests that fail when libm is compiled using clang. > I've not investigate those at all. I'd tend to guess that we have a > wider range of issues there. > > This is clearly an area we need more focus on before a switch to clang. > To a point I would be OK with it delaying the switch to work these > issues, but as with C99 long double support we can't let the quest for > perfection delay us indefinitely. > > -- Brooks Also, you probably want to be sure you are running these tests against clang 3.2, not the clang that is in base, since -that- is the version that will be going live, right? -- Chuck Burns ___ 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: [HEADSUP] Upcoming GNU sort removal
On 10/4/2012 11:26 AM, C. P. Ghost wrote: BTW, its good to see BSD-licensed tools gradually replacing GNU tools in base. Though I'd have really preferred to see resources directed towards getting XEN/Dom0 support to FreeBSD/amd64. This really needs some love, IMHO. ;-) Gabor Thanks, -cpghost. Then give it some love yourself! No one is stopping you! :) -- Chuck Burns ___ 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: Fw: FreeBSD in Google Code-In 2012? You can help too!
On 10/24/2012 4:57 PM, Michael Vale wrote: -Original Message- From: Michael Vale Sent: Thursday, October 25, 2012 8:57 AM To: Adrian Chadd Subject: Re: FreeBSD in Google Code-In 2012? You can help too! oh i only replied to you, not the thread. I have some ideas though... -Original Message- From: Adrian Chadd Sent: Thursday, October 25, 2012 8:29 AM To: Michael Vale Subject: Re: FreeBSD in Google Code-In 2012? You can help too! :-) Cross-compiling ports is a big issue though. I'm going to smack people over the head about it at MeetBSD. That's a good idea, fix ports so that one can compile 32bit ports on FreeBSD amd64. If that's not what you meant, then ok.. but it's still a good idea for a task. :P -- Chuck Burns ___ 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: polling's future [was: Re: Dynamic Ticks/HZ]
On Tuesday, November 06, 2012 12:36:46 PM Andre Oppermann wrote: > On 06.11.2012 12:30, Luigi Rizzo wrote: > > On Tue, Nov 06, 2012 at 11:23:34AM +0100, Andre Oppermann wrote: > > ... > > > >> Hi Luigi, > >> > >> do you agree on polling having outlived its usefulness in the light > >> of interrupt moderating NIC's and SMP complications/disadvantages? > > > > yes, we should let it rest in peace. > > Thank you for this non-complicated answer. :-) > I worry about what happens for those people who would be running FreeBSD on older equipment where polling might still make sense. Do we throw them under the bus? -- Chuck Burns ___ 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: 9.1-RC3 feels okay :-)
On 11/7/2012 10:27 AM, Warren Block wrote: On Wed, 7 Nov 2012, CeDeROM wrote: Isn't this a Xorg bug then? When I have no configuration file Hal should provide the configuration, so sooner or later the mouse should start moving... but is does not.. Do I get http://www.wonkity.com/~wblock/docs/html/aei.html correct that when I am using xorg.conf there is no need for Hal and when I am using Hal there is no need for xorg.conf? Not quite, no. xorg.conf is the configuration file for xorg-server. It can do a lot more than just identify input devices. Option "AutoAddDevices" "Off" tells xorg-server: even if hal is present and running, don't use it to detect input devices. AFAIK, hal is not used by xorg-server for anything else. All other autoconfig (video card detection, monitor detection, it even has its own built-in input device detection) is done by the xorg server itself. ___ 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" And, for the record, HAL is NOT needed in recent xorg-server, even for running without an xorg.conf file. This was not the case for a while, but with recent xorg-server, hal is NOT NEEDED even for autodetection. It has been deprecated by the linux folks for a few years now. -- Chuck Burns ___ 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: Failed to switch consoles in 9.0-RC3
On 11/8/2012 7:40 AM, CeDeROM wrote: Hello :-) When switching from Xorg (installed from package by portinstall) to console I got this bad behavior and constantly beeping speaker. On the console, when it switched, I got this message 3 times: Failed to switch console (Invalid agrument) There are no more messages or debug information to better describe the problem sorry... Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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" Known issue. KMS prevents console switching, still. KMS is not quite ready for use, but works fine as long as you stay in Xorg -- Chuck Burns ___ 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: sysutils/lsof Author Question (for CLANG)....
On 11/8/2012 8:17 AM, Andriy Gapon wrote: on 08/11/2012 01:00 Greg 'groggy' Lehey said the following: On Wednesday, 7 November 2012 at 16:35:22 -0600, Larry Rosenman wrote: On 2012-11-07 15:39, Greg 'groggy' Lehey wrote: On Wednesday, 7 November 2012 at 10:32:23 -0500, Benjamin Kaduk wrote: Once again, attempting to use kernel internals outside of the supported interfaces is just asking for trouble; I do not understand why this message is not sinking in over the course of your previous mails to these lists, so I will not try to belabor it further. IIRC lsof is a special case that always needs to be built with intimate knowledge of the kernel. This is VERY true. Since some of the information lsof uses has no API/ABI/KPI/KBI to get, it grovels around in the kernel. And until those interfaces are provided, I think this is legitimate. If there's anybody out there who hasn't used lsof, you should try it. It's good. Just curious why lsof can't use interfaces that e.g. fstat/sockstat/etc use? Those base utilities do not seem to experience as much trouble as lsof. BTW, it is still beyond me why VOP_WRITE could be of any interest to userland code even for such a utility as lsof. Honestly, if you do not like the way lsof does things, I'm sure patches are welcome.. -- Chuck Burns ___ 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: 9.1-RC3 feels okay :-)
On 11/8/2012 10:58 AM, Richard Kuhns wrote: On 11/08/12 10:45, Warren Block wrote: On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version >=1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option "AllowEmptyInput" "False" is added to Section "ServerLayout" by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. Option "AutoAddDevices" "Off" is the one that means "dont' use Hal to detect input devices". Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. ___ 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" Just a comment: according to http://wiki.freebsd.org/VirtualBox, Hal is still required for VirtualBox in order to have host DVD/CD access. Doesn't mean xorg-server needs hal. Build xorg-server without hal support... install hald for virtualbox. Everything still works as it should... In the meantime, someone should probably write a devd<->udisks[12] translation daemon.. for things like gnome, kde, xfce, and virtualbox, which have the udisks linuxisms can actually continue to work in the future.. I'd do it if I had any coding skills... I left those behind when I sold my Commodore64. :P -- Chuck Burns ___ 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: 9.1-RC3 feels okay :-) - Hald and xorg?
On 11/8/2012 1:46 PM, Warren Block wrote: On Thu, 8 Nov 2012, Richard Kuhns wrote: On 11/08/12 10:45, Warren Block wrote: On Thu, 8 Nov 2012, CeDeROM wrote: I have tested additional options in xorg runtime :-) With the patched xorg mouse driver 1.7.1 (or driver version >=1.7.2) situation is following: 1. With hald and dbus no xorg.conf file is needed. However it might bo option to pass some additional featutes parameters with xorg.conf. 2. With no hald and dbus mouse and keyboard does not work in xorg unless Option "AllowEmptyInput" "False" is added to Section "ServerLayout" by hand in xorg.conf. Without this option input does not work even if xorg.conf defines it! AllowEmptyInput=False forces to detect input deviced by Xorg at startup. No. AllowEmptyInput is wrong. It was causing so many problems that it has been removed from later xorg-server releases. Option "AutoAddDevices" "Off" is the one that means "dont' use Hal to detect input devices". Thank you for this hint! This could be added to the handbook :-) AllowEmptyInput=False should be a default for Xorg IMO we can report it to the Xorg project! :-) Really, the simplest solution is to build xorg-server with the HAL option disabled. I agree that this should be the default. Just a comment: according to http://wiki.freebsd.org/VirtualBox, Hal is still required for VirtualBox in order to have host DVD/CD access. This is probably a permissions thing. VirtualBox sees the device, but can't quite mount it. So hal may not be actually required for that function in VirtualBox, but figuring out just what is needed without hal remains to be done. KDE and Gnome both still need hal, but AFAIK do not require it to be used for xorg input device detection. xfce4 works fine without hal. ___ 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" Actually, KDE does -not- need hal. KDE uses the SOLID system for automatic mounting/unmounting of removable/non-removable drives. There are two backends for SOLID. Hal, and udisks. Since FreeBSD does not support udisks, then the only viable SOLID backend, at the moment, is the hald one. The kde@ team plans to eventually write a devd SOLID backend, but they are extremely busy, so any help in that would be most welcome.. avilla@ can probably elaborate on that.. cross-posting my reply to the kde@ ML so they can chime in if need be. -- Chuck Burns ___ 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: from 5-NOV WITH_CLANG_IS_CC in /etc/src.conf is no longer needed, right?
On 11/9/2012 2:44 PM, Anton Shterenlikht wrote: From christer.solsko...@gmail.com Fri Nov 9 20:40:46 2012 > > On 2012-11-09 09:27, Anton Shterenlikht wrote: > > I'm on 242801 amd64. > > I understand from [1] that WITH_CLANG_IS_CC > > is no longer needed in /etc/src.conf. > > Yet I somehow still get cc,c++,cpp all GCC binaries, e.g. > > > > # /usr/bin/cc --version > > cc (GCC) 4.2.1 20070831 patched [FreeBSD] > > Please post your make.conf and src.conf files. You may have something > in there which overrides the new defaults. > > # cat /etc/src.conf > PORTS_MODULES=net/bwn-firmware-kmod > # cat /etc/make.conf > SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 > SENDMAIL_LDFLAGS+= -L/usr/local/lib > SENDMAIL_LDADD+=-lsasl2 > WITH_PKGNG=yes > PERL_VERSION=5.16.2 > # > Sure you are running a current enough CURRENT? sure... just forgot installworld... # cc --version FreeBSD clang version 3.2 (trunk 162107) 20120817 Target: x86_64-unknown-freebsd10.0 Thread model: posix # After 10 years of using freebsd, I fucked up again... really embarrased, sorry Anton ___ 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" Just remember, if you can't laugh at yourself for dumb misakes, there will always be someone willing to do it for you! :) Glad you figured it out.. now the obligatory "LOL!" :) -- Chuck Burns ___ 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: [head tinderbox] failure on arm/arm
On 11/9/2012 3:20 PM, Adrian Chadd wrote: On 9 November 2012 07:34, Doug Brewer wrote: No offence, but how many times did you break the build? Could you please compile your code before committing next time? Thanks a lot! I'm implementing a cut-down version of make universe on my development laptop. It unfortunately is slightly too small to run make universe at the moment; I do a lot of development on netbooks with small amounts of RAM and disk. My cut-down version is likely going to be "oh, and cross build a test MIPS kernel or two that doesn't actually set ATH_DEBUG* options by default". So I'm sorry about this; it'll get resolved soon. Adrian ___ 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" Adrian. diskspace and cpu cycles are things I can spare, drop me a line outside of the ML and we can discuss particulars. "It's just a personal box.. on a residential internet service, I have an amd64 box with 600G free on my pool.. 8G ram.. and I have a smaller i386 box... 100G or so free, 512M ram.. just drop me a line.. -- Chuck Burns ___ 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: [head tinderbox] failure on arm/arm
On 11/9/2012 4:16 PM, Brett wrote: Message: 11 Date: Fri, 9 Nov 2012 23:34:58 +0800 From: Doug Brewer To: Adrian Chadd Cc: a...@freebsd.org, FreeBSD Tinderbox , curr...@freebsd.org Subject: Re: [head tinderbox] failure on arm/arm Message-ID: Content-Type: text/plain; charset=ISO-8859-1 No offence, but how many times did you break the build? Could you please compile your code before committing next time? Thanks a lot! Just an observation: a few years ago when I got sick of Linux's "headlong rush" development model, I subscribed to various BSD mailing lists to see what else was out there. I considered FreeBSD at the time - there was a neverending avalanche of "[head tinderbox] failure" messages. This told me that I would be more likely to be running code written by people who knew what they were doing if I went with Open, Net, or DragonflyBSD. I safely run OpenBSD-current on my main computer and it always works (I think I have had 2-3 build problems in about 3 years, and they were all my fault). At the moment, I only feel confident enough with FreeBSD-current to run it on my unimportant torrent computer. This is 80% due to constant build failures, and 20% due to invasive changes being introduced with documentation/instructions scattered over many different pages and mailing lists, e.g: http://wiki.freebsd.org/FrontPage?action=fullsearch&context=180&value=xorg&titlesearch=Titles http://wiki.freebsd.org/FrontPage?action=fullsearch&context=180&value=pkgng&titlesearch=Titles Hypothetical user: "Is it WITHOUT_PKGNG= or WITHOUT_PKGNG=yes or WITH_PKGNG=no today?" I wonder how many other people that you never hear from feel the same, and if some sort of "x weeks commit freezeout" should apply to the build breakers. Cute pointy hats or whatever obviously have no effect. Rant over! ___ 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" Quite honestly, the head/current branch is going to have build failures.. It's the test bed.. Stick with the release system unless you want cutting edge.. just remember.. cutting edge cuts sometimes... -- Chuck Burns ___ 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: cvsup/csup servers stale?
On 11/15/2012 12:58 PM, Eitan Adler wrote: On 15 November 2012 13:47, Ian FREISLICH wrote: Hi Has the svn->cvs exporter died? Or have the cvsup/csup servers been retired as threatened in a previous thread (I might have missed the headsup)? The FreeBSD cluster is undergoing maintenance. In particular the main machines were recently physically moved, upgraded, and discombobulated. A number of services are down but we are working on fixing this as fast as possible! I want my money back! :) Upgrades are always fun. *throws his hands up and shouts "whee!!" as the rollercoaster goes up and down* No worries. :) -- Chuck Burns ___ 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: (bsd)patch vs ports
On Wednesday, November 27, 2013 11:21:58 AM Andriy Gapon wrote: > When building ports on head I sometimes see messages like the following > during a patch phase: > > ===> Applying FreeBSD patches for firefox-25.0_1,1 > No such line 262 in input file, ignoring > ===> Applying NSS patches > No such line 194 in input file, ignoring > No such line 658 in input file, ignoring > No such line 52 in input file, ignoring > No such line 45 in input file, ignoring > > Is this a cause for concern? > Do those messages mean that potentially important patches are not actually > applied? Well.. If it compiles, then no, those patches were probably not important. Security fixes are usually done upstream by the vendor. Honestly, it appears that someone left old patch files, and those patches may no longer be needed for firefox to compile on FreeBSD. break19 ___ 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: Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
On 11/20/2012 10:27 AM, O. Hartmann wrote: On 11/20/12 11:43, Olivier Smedts wrote: 2012/11/20 Paul Webster : I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. But a change like this is expected in a new major branch, ie. 10-CURRENT. Not so in -STABLE branches of course. I don't see the problem here. Cheers What would be the alternative? Being stuck with the old PF? As Olivier Smedts said, changes like that are expected in a complete new branch. If people need to stay compatible, they are about to use 9.X as long as they have migrated. The downside is more work. The bright side would be development/progression. oh Why not release pf2 as a port? Then those who want the new pf can use it, and those that want the old one can use it. Or, another option is a knob USE_NEWPF during buildworld will build the new pf, otherwise it'd build the old, default one. This way you can still introduce the change, but default to the old one for those of us who are too crusty to change. :) -- Chuck Burns ___ 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: Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
On 11/20/2012 10:52 AM, Aldis Berjoza wrote: 20.11.2012, 18:34, "Chuck Burns" : On 11/20/2012 10:27 AM, O. Hartmann wrote: On 11/20/12 11:43, Olivier Smedts wrote: 2012/11/20 Paul Webster : I am aware this is a much discussed subject since the upgrade of PF, I believe the final decision was that to many users are used to the old style pf and an upgrade to the new syntax would cause to much confusion. But a change like this is expected in a new major branch, ie. 10-CURRENT. Not so in -STABLE branches of course. I don't see the problem here. Cheers What would be the alternative? Being stuck with the old PF? As Olivier Smedts said, changes like that are expected in a complete new branch. If people need to stay compatible, they are about to use 9.X as long as they have migrated. The downside is more work. The bright side would be development/progression. oh Why not release pf2 as a port? Then those who want the new pf can use it, and those that want the old one can use it. Or, another option is a knob USE_NEWPF during buildworld will build the new pf, otherwise it'd build the old, default one. This way you can still introduce the change, but default to the old one for those of us who are too crusty to change. :) FreeBSD already have 3x firewalls. Having 4th m I think, isn't desired. Nonsense. More options are always preferable to fewer options. -- Chuck Burns ___ 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: Upgrading FreeBSD to use the NEW pf syntax. (Copied from freebsd-pf)
On 11/20/2012 11:51 AM, Eitan Adler wrote: On 20 November 2012 12:47, Chuck Burns wrote: Nonsense. More options are always preferable to fewer options. Even when those options must be maintained? Documented? Bug fixed? The ones who want the old pf can maintain it.. those who want the new one, can maintain *it*. I, for one, would prefer the new one eventually replace the old one, but there should definitely be a transition period, similar to how pkgng is going in. Chuck ___ 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: pkg - Shared object "libarchive.so.5" not found, required by "pkg"
On 11/24/2012 12:38 PM, Christer Solskogen wrote: On Sat, Nov 24, 2012 at 3:45 PM, Victor Balada Diaz wrote: You have pkg-static for that kind of problems. You should rebuild pkg port to get pkg working again. So I still need /usr/ports when I use pkg? No. ports-mgmt/pkg can be self-bootstrapped with no need to compile anything. -but- If you want to use -stable or -current, then you really should use ports as well... -- Chuck Burns ___ 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: 9.1-RC3 AMD64 reproducible kernel panic
On 12/7/2012 12:31 PM, CeDeROM wrote: Hello :-) After days of problem with my system storage (?) I think I have located the issue, or at least I am able to reproduce it, please take a look at attached picture (photo of a crash). At first I thought that was the Ext2 filesystem issue, but then I have replaced the filesystem to UFS2-SU+J (which increased transfer efficiency and dramatically reduced filesystem check time compared to Ext2) but the issue persisted. This problem occurs also when only / is mounted (no additional storage locations only the OS). This can mean there is a corruption on / that is marked clean. Right now I am not sure if this is storage related anymore... there is however some note on ffs double alloc. Crash occurs after I start Xorg (Kde3 WM, all packages installed from binary packages with portinstall). Please let me know if you need additional information/tests :-) Best regards :-) Tomek I could be blind, but I do not see any attachment. Best to upload it to an image-sharing site, and then post the link anyway. How have you ruled out a hardware issue? Just because it works fine under another OS doesn't necessarily mean that the hardware is fine, just that other OS may not probe/use/access it in exactly the same manner. -- Chuck Burns ___ 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: 9.1-RC3 LiveCD missing features
On 12/7/2012 3:50 PM, CeDeROM wrote: Hello :-) I have tried to chceck for badblocks on my / but I did not find badblocks program on LiveCD and there is no option to install it. This is very useful utility, please add it as part of LiveCD :-) Also there is a problem with DHCP based workstations using LiveCD - although interface gets configured it is impossible to update /etc/resolv.conf (by dhclient and by hand) and so this workstation pretty useless for IPv4 (is it more usable on IPv6?). Please update :-) Thank you :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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" dd if=/dev/zer of=/dev/ada0 ^^^ There's your "badblocks" program. Any hard drive made in the last decade have been self-remapping.. Attempting to write to a bad block will cause the hard drive to remap an unused sector into it's place, until the drive runs out of said "unused" backup sectors, and at that time, will begin simply begin just "losing" storage space... IE the number of total sectors on the drive will begin to shrink. -- Chuck Burns ___ 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: 9.1-RC3 LiveCD missing features
On 12/7/2012 9:10 PM, Warren Block wrote: On Fri, 7 Dec 2012, Chuck Burns wrote: dd if=/dev/zer of=/dev/ada0 ^^^ There's your "badblocks" program. Any hard drive made in the last decade have been self-remapping.. That should be /dev/zero. And this will be very slow, going one 512-byte block at a time. Using a 64K or 128K buffer (bs=128K) will speed it up tremendously. my 0 key gets stuck sometimes.. sue me. :P -- Chuck Burns ___ 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: pkg/ports system terribly messed up?
On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: > Hello. > > I just made the last update of the ports yesterday (I use portmaster -da > performing this task) and obviously or superficially everything went all > right. > It's portmaster actually. While it -usually- works great, I've noticed that occassionally it loops like that. kill the script, upgrade the port that is looping. That usually fixes it. -- Chuck Burns ___ 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: pkg/ports system terribly messed up?
On Wednesday, October 01, 2014 7:48:08 AM Rainer Hurling wrote: > Am 01.10.2014 um 05:44 schrieb Chuck Burns: > > On Tuesday, September 30, 2014 8:13:01 AM O. Hartmann wrote: > >> Hello. > >> > >> I just made the last update of the ports yesterday (I use portmaster -da > >> performing this task) and obviously or superficially everything went all > >> right. > > > > > > > > It's portmaster actually. While it -usually- works great, I've noticed > > that occassionally it loops like that. > > > > kill the script, upgrade the port that is looping. > > Because it seems that I have the same problem as Oliver: What script you > are talking about? > > > That usually fixes it. portmaster is just a (not-so-)simple shell script. Kill portmaster (CTRL-C a few times) then build the offending port with "make && make deinstall reinstall clean" -- Chuck ___ 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"
make installworld fails on releng9
I had some issues while running make installworld after I sync'd to the latest releng9, on my RC1 install. Now, it appears to failed, while trying to create some links, chfn chsh ypchpass ypchfn ypchsh. These are supposed to be hardlinked to /usr/bin/chpass, except that, since the other files already exist, and are immutable, make installworld was unable to do anything, so I wound up removing the immutable flag on these files and re- running make installworld. I didn't see any mention of this little.. issue, in UPDATING, or in the - current mailing list (yes, I know, 9.0 is no longer technically, current, but since it isn't released yet, I figure it's close enough) -- Chuck Burns ___ 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: make installworld fails on releng9
On Saturday, October 29, 2011 1:13:58 AM Benjamin Kaduk wrote: > > Are you running installworld in single-user mode? > What is the value of kern.securelevel? > > -Ben Kaduk Yes, I was running in single-user mode, and kern.securelevel was never modified, and is currently showing as "-1" Also, I am running zfs root, if that makes a difference -- Chuck Burns "We have the right as individuals to give away as much of our own money as we please in charity; but as members of Congress we have no right to appropriate a dollar of the public money." - Davy Crockett ___ 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: /sys/amd64/conf/DEFAULTS
On Tuesday, November 08, 2011 02:12:58 PM Niclas Zeising wrote: > From my understanding of things, the DEFAULTS kernel configuration file > is automatically included into the build by config(8). There is no need > to include it into the generic using the "include" statement. It was > first added 6 years ago, on October 27 2005. > Regards! Not sure if you already know this, or not but another thing to keep in mind, if a module is not mentioned, or is commented out, then it will still be built, just not included into the monolithic kernel. If you were already aware of this, then my apologies. Chuck ___ 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: Use of newest version number such as 10.0 instead of current
On Friday, November 11, 2011 07:29:46 AM Mehmet Erol Sanliturk wrote: -(snipped stuff)- > This is preventing testing and / or using efforts . > > > I know , it is possible to rename local link names , but > everyone is not so much knowledgeable . > > > > Thank you very much . > > Mehmet Erol Sanliturk Quite honestly, if someone isn't that knowledgeable, then they probably shouldn't be running current. In fact, the handbook even states that. I don't really see an issue here. -current is a bleeding edge development release, that must be built from source, and SHOULD always point to the latest source code. If you are using pkg_add -r to install software, on anything but release versions, you should expect breakage. If you do not wish to build from source, then you should probably stick to release versions. Chuck Burns ___ 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: Use of newest version number such as 10.0 instead of current
On Friday, November 11, 2011 08:17:52 AM you wrote: -snip- > My sentence is NOT about "Current" , but 9.0 RC1 . > Perhaps , you will NOT say , if a person is NOT knowledgeable , he should > NOT use 9.0 RC1 . > If you use a proper RC, then pkg_add will work until a new RC, and since there is no binary upgrade path for anything other than releases, you will need to reinstall, with the newly released RC. -snip- > Up to now , my most disappointed situation is that , there is NO any > tendency to > lower required expertise level to use FreeBSD . > Such an approach is confining FreeBSD to a small number of elite users > when compared to millions of Linux users let alone hundred millions of > some other operating systems which they are approaching to billions when > version users are summed in spite of paying money also . GhostBSD, PCBSD are two options for "lower expertise" and, as such, are billed as desktop versions of FreeBSD. FreeBSD itself (as well as the other BSDs) is a minimalistic OS, where you can build your own system, making it either into a server, workstation, or even into a desktop system if you so desire. If you want something with point-n-click ease of use, go use one of the two desktop-oriented versions. Both GhostBSD, and PCBSD are just a desktop environment built on top of FreeBSD. PCBSD even has a 9.0 RC out now as well, if you're into testing. PCBSD uses the kde environment, and GhostBSD uses the gnome 2.32 environment. If you want something else, feel free to create your own. There is nothing in the BSD license that prevents you from doing that. Instead of complaining that SOMEONE ELSE should do something that YOU want done, why not just do it yourself. In other words, put up, or shut up. :) Chuck Burns ___ 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"
devel/google-perftools fails to build on 10-current
I recently source-up'd to 10-current, and began the slow process of rebuilding all my installed ports, devel/google-perftools fails with an undeclared "__isthreaded" The following should be more than enough information. Thanks, Chuck Burns root@freebeast /usr/src % svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 228349 Node Kind: directory Schedule: normal Last Changed Author: rmh Last Changed Rev: 228349 Last Changed Date: 2011-12-08 06:31:47 -0600 (Thu, 08 Dec 2011) if /bin/sh ./libtool --tag=CXX --mode=compile c++ -DHAVE_CONFIG_H -I. -I. - I./src -I./src -DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE - pthread -DNDEBUG -Wall -Wwrite-strings -Woverloaded-virtual -Wno-sign- compare -fno-builtin-malloc -fno-builtin-free -fno-builtin-realloc -fno- builtin-calloc -fno-builtin-cfree -fno-builtin-memalign -fno-builtin- posix_memalign -fno-builtin-valloc -fno-builtin-pvalloc -fno-omit-frame- pointer -fno-exceptions -O2 -pipe -march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la-maybe_threads.lo -MD -MP -MF ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" -c -o libtcmalloc_minimal_internal_la-maybe_threads.lo `test -f 'src/maybe_threads.cc' || echo './'`src/maybe_threads.cc; then mv -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo" ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Plo"; else rm -f ".deps/libtcmalloc_minimal_internal_la-maybe_threads.Tpo"; exit 1; fi libtool: compile: c++ -DHAVE_CONFIG_H -I. -I. -I./src -I./src - DNO_TCMALLOC_SAMPLES -DNO_HEAP_CHECK -D_THREAD_SAFE -pthread -DNDEBUG -Wall - Wwrite-strings -Woverloaded-virtual -Wno-sign-compare -fno-builtin-malloc - fno-builtin-free -fno-builtin-realloc -fno-builtin-calloc -fno-builtin-cfree - fno-builtin-memalign -fno-builtin-posix_memalign -fno-builtin-valloc -fno- builtin-pvalloc -fno-omit-frame-pointer -fno-exceptions -O2 -pipe - march=opteron -fno-strict-aliasing -MT libtcmalloc_minimal_internal_la- maybe_threads.lo -MD -MP -MF .deps/libtcmalloc_minimal_internal_la- maybe_threads.Tpo -c src/maybe_threads.cc -fPIC -DPIC -o .libs/libtcmalloc_minimal_internal_la-maybe_threads.o src/maybe_threads.cc: In function 'int perftools_pthread_once(pthread_once_t*, void (*)())': src/maybe_threads.cc:118: error: '__isthreaded' was not declared in this scope *** Error code 1 Stop in /usr/ports/devel/google-perftools/work/google-perftools-1.8.3. *** Error code 1 Stop in /usr/ports/devel/google-perftools. The -full- build log follows. root@freebeast ~ % cd /usr/ports/devel/google-perftools root@freebeast /usr/ports/devel/google-perftools % ls Makefile distinfo files/ pkg-descr pkg-plist work/ root@freebeast /usr/ports/devel/google-perftools % make clean ===> Cleaning for google-perftools-1.8.3 root@freebeast /usr/ports/devel/google-perftools % ls Makefile distinfo files/ pkg-descr pkg-plist root@freebeast /usr/ports/devel/google-perftools % make ===> Vulnerability check disabled, database not found ===> License BSD accepted by the user ===> Extracting for google-perftools-1.8.3 => SHA256 Checksum OK for google-perftools-1.8.3.tar.gz. ===> Patching for google-perftools-1.8.3 ===> Applying FreeBSD patches for google-perftools-1.8.3 ===> Configuring for google-perftools-1.8.3 checking build system type... amd64-portbld-freebsd10.0 checking host system type... amd64-portbld-freebsd10.0 checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for gcc... cc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether cc accepts -g... yes checking for cc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of cc... gcc3 checking how to run the C preprocessor... cpp checking whether we are using the GNU C++ compiler... yes checking whether c++ accepts -g... yes checking dependency style of c++... gcc3 checking whether cc understands -c and -o together... yes checking for objcopy... objcopy checking if objcopy supports -W... yes checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for
Re: How to update /usr/src/ using SVN and "make update"?
On Saturday, December 10, 2011 3:59:41 AM O. Hartmann wrote: > Taking the instruction from manpage make.conf(5) and setting variable > SVN_UPDATE to YES, typing "make update" in /usr/srcfails due to svn > can not be found. make.conf(5) also contains a variable "SUP" containing > the path for cvsup or cvsup and I'm desperately missing a similar > variable for subversion. Since subversion is a port, it might be so that > setting a variable in make.conf(5) conflicts with the BSD policy and > logic, but then I'd appreciate a hint like "you need to set the propper > environment variable for finding svn in the search path ...blablabla". > Using "make update" ends up in "svn not found". Typing manually "svn -r > HEAD" in /usr/src as it is shown when the make update fails works well, > since the shell's environment PATH variable knows /usr/local/bin to look > for. > I also file a PR not letting this getting forgotten, please close it, if > it is obsolete. > > Regards, > O. Hartmann Here is quick, hackish patch to allow your make update to work, it appears that the Makefile.inc1 does not include the full path to svn, while it does include the full path to cvs and other tools, this makes me think that the user path is ignored (which is a good thing) -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ Index: Makefile.inc1 === --- Makefile.inc1 (revision 228349) +++ Makefile.inc1 (working copy) @@ -106,7 +106,7 @@ CVS?= cvs CVSFLAGS?= -A -P -d -I! -SVN?= svn +SVN?= /usr/local/bin/svn SVNFLAGS?= -r HEAD SUP?= /usr/bin/csup SUPFLAGS?= -g -L 2 ___ 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: How to update /usr/src/ using SVN and "make update"?
On Saturday, December 10, 2011 7:35:27 AM Chuck Burns wrote: > Here is quick, hackish patch to allow your make update to work, it appears > that the Makefile.inc1 does not include the full path to svn, while it does > include the full path to cvs and other tools, this makes me think that the > user path is ignored (which is a good thing) > Heh, I am notorious for overthinking things. My bad.. yes, just add SVN=/usr/local/bin/svn to your /etc/make.conf file -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ ___ 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: [rfc] removing/conditionalising WERROR= in Makefiles
On 12/30/2011 7:06 AM, Dimitry Andric wrote: On 2011-12-26 11:10, Alexander Best wrote: that's why i'd like to propose the following patch. i ran a full tinderbox run against r228878 and it suceeded. Did you also try this with clang? For example the xfs module alone gets a whole slew of warnings, which would be fatal if WERROR= was removed: sys/gnu/fs/xfs/xfs_dir2_block.c:1149:17: warning: array index of '1' indexes past the end of an array (that contains 1 element) [-Warray-bounds] dep->name[0] = dep->name[1] = '.'; ^ ~ sys/gnu/fs/xfs/xfs_dir2_data.h:90:2: note: array 'name' declared here __uint8_t name[1]; /* name bytes, no null */ ^ 1 warning generated. just as an aside, the XFS module didn't seem to work when I last attempted to use it, so it may be worth just removing it? -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ ___ 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: Very fresh (two days ago) 10-current becomes completely unresponsive under load
On 01/10/12 17:21, Lev Serebryakov wrote: Hello, Lev. You wrote 11 января 2012 г., 3:05:29: OH! I have top running right now, when it "hangs". 0% idle time, LA becomes 20 when it have only 35 processes at all, but there is no specific process consuming CPU. Ok, it seems, that here is a problem (CPU time : PID USERNAME PRI NICE SIZERES STATETIME WCPU COMMAND 12 root -16- 0K 8K sleep 18:35 30.18% ng_queue And after that 5 minutes without updates, than normal numbers. It seems, that root of problem is: (a) netgraph in this version of kernel OR (b) new mpd 5.6 (previous version had 5.5). P.S. Adding net@ and mav@ to CC, original posting with all data is in current@ If it were me, I would also try with the older 44BSD scheduler, just to see what happens. -- Chuck Burns The Southern Libertarian http://www.thesouthernlibertarian.com/ ___ 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: Enhancing the user experience with tcsh
On 2/10/2012 10:41 AM, Gavin Atkinson wrote: On Fri, 2012-02-10 at 11:25 -0500, Eitan Adler wrote: Picking a random email to reply to. My goal with this email is to reduce the amount of "controversial" changes. I applaud this. I've often considered doing the same but avoided it because it was easier than fighting the bikeshed :) commit 3ea4ea3a59d14cb060244618dd89d7dd0170bee1 diff --git a/etc/root/dot.cshrc b/etc/root/dot.cshrc --- a/etc/root/dot.cshrc +++ b/etc/root/dot.cshrc @@ -7,9 +7,10 @@ alias hhistory 25 alias jjobs -l -alias la ls -a +alias la ls -aF alias lf ls -FA -alias ll ls -lA +alias ll ls -lAF +alias ls ls -F Two people didn't like these changes but didn't explain why. This is incredibly helpful, especially for a new user. If you dislike the alias change please explain what bothers you about it? I don't use the first two aliases, so I don't care about them at all. I do however disagree strongly with changing the default options on such a widely used command. This change is disruptive, and it can affect use of ls(1) in scripts. For example, it even sticks the extra characters in the output of "ls -1" (the number 1), which is specifically designed to be used when piping the output elsewhere. Please do not break this. It is also distracting - If I want to see what type of file a particular entry is, why not just run "ls -l"? It's like the tendency some Linux distributions have of "alias mv mv -i", although that can at least be overridden on the command line with "-f". The "ls -F" change cannot be overridden without unaliasing. if ($?prompt) then # An interactive shell -- set some stuff up - set prompt = "`/bin/hostname -s`# " + set prompt = "[%n@%m]%c04%# " + set promptchars = "%#" Many people had alternative suggestions for the prompt. Can you please clarify why you believe your prompt should be the _default_ one? I can't comment as I didn't say my suggestion should be default - but for me the above isn't a bad choice. I would however prefer: set prompt = "%n@%m:%c04 %# " and not set prompt = "[%n@%m]%c04%# " as that then gives you user@host:path in exactly the same format as you need to use with scp, etc. I use the $HOME/bin on my machines but I am not so sure to make this a general thing. Many people expect it, and given that it is the last item in the path it won't affect all that much. It's been in there forever. I think this should stay, it would just be too disruptive otherwise. My $0.02 Instead of using -F to denote filetypes, why not use colors? -G -- it shouldnt affect scripts at all, yet still provide the same sort of feedback. (Tho, I personally use csh's built-in "ls-F" instead of "ls", and actually tend to alias it to ls as well.) Just a thought. I do, however, like most of the other changes. Here's my stamp. "Approved" :) -- Chuck Burns The Southern Libertarian (owner/editor) http://www.thesouthernlibertarian.com/ ___ 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: loader is aborted with 'out of memory'
On 2/13/2012 7:06 AM, TAKAHASHI Yoshihiro wrote: I got the following error of the current loader if I put the xxx_after line into loader.conf to wait a key after load the xxx module. --- Error: out of memory Module xxx Error executing read -p "Press Enter" Aborted! --- The loader.conf is: xxx_load="YES" xxx_after="read -p \"Press Enter\"" Does anyone know what is wrong? --- TAKAHASHI Yoshihiro ___ 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" Uhm, yea.. it's having trouble executing the command 'read -p "Press Enter"' My guess is, it can't run that command "read". Perhaps it needs a full path, or something? grasping at straws on the fix you want, but the error message is pretty clear.. and without the _after line I'm betting it would boot fine. -- Chuck Burns The Southern Libertarian (owner/editor) http://www.thesouthernlibertarian.com/ ___ 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: setting CC/CXX/CPP unconditionally in src.conf
On 2/28/2012 4:55 PM, Ade Lovett wrote:
On 2/28/2012 14:11, Alexander Best wrote:
any chance we can have a CFLAGS.gcc and CFLAGS.clang in the future?
that would
make certain things a lot easier. dealing with gcc specific options,
such as
-mpreferred-stack-boundary=2 would simply work by setting
CFLAGS.gcc=-mpreferred-stack-boundary=2 e.g.
You already can:
CFLAGS.cc= cc_cflags_here
CFLAGS.clang= clang_cflags_here
CFLAGS+= generic_cflags_here
CFLAGS+= ${CFLAGS.${CC}}
-aDe
I think was asking for adding a third...
.cc for base gcc
.clang for .. clang..
and .gcc for ports gcc4x
..
At least, thats how I read it, I could be wrong, it's happened before.
Chuck
___
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: ABI/architecture identification for packages
We should probably pad the version number, and shorten things up.. similar to: package-1.2-fbsd09.1-x86.pkg package-1.2-fbsd09.1-x64.pkg package-1.2-fbsd09.1-ppc.pkg package-1.2-fbsd09.1-ppc64.pkg package-1.2-fbsd09.1-arm.pkg For app "Package" version 1.2, on FreeBSD 9.1 drop the .1 for .0 versions. The reason for the padding is to help with sorting, at least until freebsd 100.0 comes out. :P Chuck Burns On 3/20/2012 5:40 AM, Alexander Yerenkow wrote: IMHO, 32 / 64 = easily parsable and represent integer. i386/amd64 - wellknown names, but this info about processor bits not lies in math. My point is i386 is arch, so can be kept, while 32 is processor bit count. If you'll keep 32/64 various checks in side software will be simple (if you have 32 bit processor, then this info is bundled in "32"), while if you consider using "i386" string as storage of information about "32" bit, it not so elegant. Also, linuxes has come to i386- i586- i686- mess, and many their scripts looks overbloated when they checks if system really 32 bit. Just my point of view :) ___ 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" ___ 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: Virtual Manager Vacancy
On 3/25/2012 9:35 PM, Super Bisquit wrote: I'm a retired 69 year old pregnant male looking for part-time work during my career break. I'm not a pregnant male, I just look like it ouch. :( Chuck ___ 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: Using TMPFS for /tmp and /var/run?
On 4/2/2012 10:52 AM, Chris Rees wrote: This is a known issue with ZFS. Is that your case? Chris Yes. Interesting that it happens only with ZFS. and jb, thanks, I could've sworn I'd hit "Reply to list" - thanks for forwarding it for me. Chuck ___ 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"
