Re: GNU LICENSING
Hi I was wondering how to apply to the gnu licensing and how to sign and commit to the licensing laws.. Would you mind telling me how to assign to one please?? And one other thing in the license of most gnu licensing they go on to mention the 'AS IS' commitment but I don't fully understand, as well could you give me five minutes of you busy time to explain please?? My regards MR jon ruse I do donate to the fsf donation station if that is anything meaning?? Sent from my iPhone On 12 Sep 2014, at 23:46, freebsd-current-requ...@freebsd.org freebsd-current-requ...@freebsd.org wrote: Send freebsd-current mailing list submissions to freebsd-current@freebsd.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.freebsd.org/mailman/listinfo/freebsd-current or, via email, send a message with subject or body 'help' to freebsd-current-requ...@freebsd.org You can reach the person managing the list at freebsd-current-ow...@freebsd.org When replying, please edit your Subject line so it is more specific than Re: Contents of freebsd-current digest... Today's Topics: 1. Re: CDC-WDM driver (4G modems) (PseudoCylon) 2. Re: panic: resource_list_alloc: resource entry is busy (Marcin Cieslak) 3. Re: panic: resource_list_alloc: resource entry is busy (John Baldwin) 4. Re: panic: resource_list_alloc: resource entry is busy (Marcin Cieslak) 5. shells/bash port, add a knob which symlinks to /bin/bash ? (Craig Rodrigues) 6. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Bryan Drewery) 7. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Baptiste Daroussin) 8. RE: shells/bash port, add a knob which symlinks to /bin/bash ? (Rang, Anton) 9. RE: shells/bash port, add a knob which symlinks to /bin/bash ? (Benjamin Kaduk) 10. Re: panic: resource_list_alloc: resource entry is busy (John Baldwin) 11. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Alfred Perlstein) 12. Re: panic: resource_list_alloc: resource entry is busy (Marcin Cieslak) 13. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Garrett Cooper) 14. RE: shells/bash port, add a knob which symlinks to /bin/bash ? (Daniel Eischen) 15. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Lyndon Nerenberg) 16. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Craig Rodrigues) 17. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Subbsd) 18. Re: shells/bash port, add a knob which symlinks to /bin/bash ? (Brooks Davis) mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment mime-attachment ___ 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: GNU LICENSING
Am 13.09.2014 um 09:04 schrieb jon.ruse: I was wondering how to apply to the gnu licensing and how to sign and commit to the licensing laws.. Would you mind telling me how to assign to one please?? And one other thing in the license of most gnu licensing they go on to mention the 'AS IS' commitment but I don't fully understand, as well could you give me five minutes of you busy time to explain please?? You just accept the GPL and act accordingly, there is nothing to sign. If you violate the license rules and somebody notices, you may be sued, though. But you really should ask a project that uses the GPL! The BSD projects use the much simpler BSD license for all internally developed code, which in its 2-clause form just requests that you do not remove the copyright mark from any source files and that you distribute a copy of the license with any binaries. And it excludes warranties (in the PROVIDED ... AS-IS sentence), as usual for such licenses. [...] I do donate to the fsf donation station if that is anything meaning?? No it doesn't - donations do not affect what you are allowed to do under the GPL. Regards, STefan ___ 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: GNU LICENSING
I was wondering how to apply to the gnu licensing [...] Don't feed the Troll please. PS: John Ruse -- Really ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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] Patch to improve TSO limitation formula in general
Hi Rick, I've collected all input from this discussion and committed the following patch to -current. I would like to MFC this to 10-stable before the coming 10-branchout. Sorry I'm rushing this a bit, hence there is only 2 weeks left until the branching happens. http://svnweb.freebsd.org/changeset/base/271504 Thanks for all good input! --HPS ___ 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: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 13.09.2014 8:29, Peter Wemm wrote: On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov a...@freebsd.org wrote: On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as intended. I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. Well, then commit it (if capsicum team agrees). Will do - thanks for the feedback. -Patrick Is there any possibility that this is related to the problem we've recently hit in the freebsd.org cluster with this month's refresh? After running for a while: Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: Xorg causes panics with multiple drivers (Was: panic: resource_list_alloc: resource entry is busy)
John Baldwin wrote on 09/12/2014 23:06: X loaded i915kms automatically and i915 and i915kms do not get along. i915 had already allocated the IRQ when i915kms tried to alloc the same IRQ causing the issue. Who is to blame? The user who tried to manually load an unsupported combination of modules, or the system, which should have handled things gracefully (whether by automatically unloading the first driver, or producing a soft-error upon loading the 2nd driver)? On a side-note, I also had a resource_list_alloc: resource entry is busy panic right after switching from the 10.0-supported Xorg to the new Xorg; I exited Xorg, enabled FreeBSD_new_Xorg, ran pkg upgrade, then ran startx, and got the panic. Surely this wasn't my fault! ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
Am 12.09.2014 um 23:38 schrieb Bryan Drewery: The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. Proper portability means scripting for a POSIX sh, and /bin/sh can handle those scripts. In the majority of cases replacing == by = in test or [ commands suffices. We install all packages to PREFIX=/usr/local by default. Why should a bin symlink be an exception? There's no suggestion for symlinking includes or libraries which also hit users often. We'd need something for fsck and thereabouts though... if /usr is on, for instance, an ext2 file system (which is part of the kernel after all), we need the tools early in the boot process, before /usr is there. ___ 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: panic: resource_list_alloc: resource entry is busy
On Fri, 12 Sep 2014, Kevin Oberman wrote: On Fri, Sep 12, 2014 at 1:57 PM, Marcin Cieslak sa...@saper.info wrote: Please note I originally loaded i915.ko, not i915kms.ko Unfortunately, kldunload i915kms makes my screen blank and probably crashes the system (disk activity stops after a short while and there is no response to the keyboard input). //Marcin That explains most of it. You need i915kms. It is conflicting with i915 which already has the IRQ allocated. The black screen is expected. Once KMS starts talking to the graphics system, syscons can no longer talk to the display, so you get a black screen. To have a working display, you must enable vt(4). Add kern.vty=vt to /boot/loader.conf to enable vt(4) which will keep the display alive. Yes, I do have kern.vty=vt enabled in the loader and without i915kms loaded my system boots correctly. I can load i915kms later per hand or when starting X, but it does not work with bootloader. I think it's a known problem as of September 2nd as stated on the http://wiki.freebsd.org/Newcons page. (My machine is Sony VAIO SZ5MN). //Marcin ___ 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
Teach vidcontrol(1) and vt(4) to restore default font
Hello,
I tried loading gallant.fnt which I did not
like and I was wondering how to come back to
the nice default font.
There does not seem to be the way to do this,
so please find below a simple patch to add
this functionality.
It adds a new ioctl PIO_VDFFONT to the vt(4)
driver. I hope I got the reference counting
on the vt_font_default structure right.
With this patch applied, vidcontrol -f restores
the built-in font.
//Marcin
Index: sys/dev/vt/vt_core.c
===
--- sys/dev/vt/vt_core.c(wersja 271197)
+++ sys/dev/vt/vt_core.c(kopia robocza)
@@ -1948,6 +1948,10 @@
vtfont_unref(vf);
return (error);
}
+ case PIO_VDFTFONT: {
+ error = vt_change_font(vw, vt_font_default);
+ return (error);
+ }
case GIO_SCRNMAP: {
scrmap_t *sm = (scrmap_t *)data;
Index: sys/sys/consio.h
===
--- sys/sys/consio.h(wersja 271197)
+++ sys/sys/consio.h(kopia robocza)
@@ -239,6 +239,7 @@
#define GIO_FONT8x16 _IOR('c', 69, fnt16_t)
#define PIO_VFONT _IOW('c', 70, vfnt_t)
#define GIO_VFONT _IOR('c', 71, vfnt_t)
+#define PIO_VDFTFONT _IO('c', 72)
/* get video mode information */
struct colors {
Index: usr.sbin/vidcontrol/vidcontrol.1
===
--- usr.sbin/vidcontrol/vidcontrol.1(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.1(kopia robocza)
@@ -26,9 +26,11 @@
.Op Fl c Ar appearance
.Oo
.Fl f
+.Oo
.Op Ar size
.Ar file
.Oc
+.Oc
.Op Fl g Ar geometry
.Op Fl h Ar size
.Op Fl i Cm adapter | mode
@@ -136,8 +138,10 @@
Print out current output screen map.
.It Xo
.Fl f
+.Oo
.Op Ar size
.Ar file
+.Oc
.Xc
Load font
.Ar file
@@ -158,6 +162,14 @@
.Nm
will try to guess it from the size of font file.
.Pp
+When using
+.Xr vt 4
+both
+.Ar size
+and
+.Ar font
+can be omitted, and the default font will be loaded.
+.Pp
Note that older video cards, such as MDA and CGA, do not support
software font.
See also
Index: usr.sbin/vidcontrol/vidcontrol.c
===
--- usr.sbin/vidcontrol/vidcontrol.c(wersja 271197)
+++ usr.sbin/vidcontrol/vidcontrol.c(kopia robocza)
@@ -197,7 +197,7 @@
{
if (vt4_mode)
fprintf(stderr, %s\n%s\n%s\n%s\n%s\n,
-usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [size] file],
+usage: vidcontrol [-CHPpx] [-b color] [-c appearance] [-f [[size] file]],
[-g geometry] [-h size] [-i adapter | mode],
[-M char] [-m on | off] [-r foreground background],
[-S on | off] [-s number] [-T xterm | cons25] [-t N | off],
@@ -409,6 +409,19 @@
return (t);
}
+/*
+ * Set the default vt font.
+ */
+
+static void
+load_default_vt4font(void)
+{
+ if (ioctl(0, PIO_VDFTFONT) == -1) {
+ revert();
+ errc(1, errno, loading default vt font);
+ }
+}
+
static int
load_vt4font(FILE *f)
{
@@ -1328,7 +1341,7 @@
dumpopt = DUMP_FBF;
termmode = NULL;
if (vt4_mode)
- opts = b:Cc:f:g:h:Hi:M:m:pPr:S:s:T:t:x;
+ opts = b:Cc:fg:h:Hi:M:m:pPr:S:s:T:t:x;
else
opts = b:Cc:df:g:h:Hi:l:LM:m:pPr:S:s:T:t:x;
@@ -1349,15 +1362,23 @@
print_scrnmap();
break;
case 'f':
- type = optarg;
- font = nextarg(argc, argv, optind, 'f', 0);
+ optarg = nextarg(argc, argv, optind, 'f', 0);
+ if (optarg != NULL) {
+ font = nextarg(argc, argv, optind, 'f', 0);
- if (font == NULL) {
- type = NULL;
- font = optarg;
+ if (font == NULL) {
+ type = NULL;
+ font = optarg;
+ } else
+ type = optarg;
+
+ load_font(type, font);
+ } else {
+ if (!vt4_mode)
+ usage(); /* Switch syscons to ROM? */
+
+load_default_vt4font();
}
-
- load_font(type, font);
break;
case 'g':
if (sscanf(optarg, %dx%d,
___
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: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery bdrew...@freebsd.org wrote: There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be familiar enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
On 09/13/14 11:32, Craig Rodrigues wrote: On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery bdrew...@freebsd.org wrote: There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be familiar enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig ___ 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 I'd point out that the perl ports have exactly such an option already (putting links in /usr/bin, in this case). The CUPS port does too. -Nathan ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
On Sat, Sep 13, 2014 at 8:39 PM, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 09/13/14 11:32, Craig Rodrigues wrote: On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery bdrew...@freebsd.org wrote: There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. The /bin/bash thing is relatively minor, but I brought it up, because I see it so much. I've seen it in the jobs that I've worked at. I've also seen it when dealing with Google Summer of Code students. I've seen it in blogs mentioned when Linux users evaluate FreeBSD. I've seen it when people design appliances based on FreeBSD, but want the device to be familiar enough for Linux-y devops people to interact with it. If there are minor things that we can do in FreeBSD to improve the out-of-box experience of FreeBSD to new users who may be used to Linux or MacOS X, that would be great. Telling people to change their shell scripts, or manually create symlinks to /bin/bash is doable, but why not have something in the system do this automatically, so that the average end-user does not even have to think about it? If adding an optional knob to the bash port which is OFF by default to do this is a no-go, would having an optional port like what Brooks Davis mentioned be allowed which creates the symlink and updates /etc/shells? -- Craig ___ 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 I'd point out that the perl ports have exactly such an option already (putting links in /usr/bin, in this case). The CUPS port does too. -Nathan Sorry Nathan, reply all is sometimes harder than it should be. Just for the uncomfortable stuff: How about systems where env is not in /usr/bin ? I had that fun episode on an opensolaris-system... Best regards Andreas Nilsson ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
On Fri, Sep 12, 2014 at 04:38:25PM -0500, Bryan Drewery wrote: No (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. This is (for perl) may break many 3rd party scripts. ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
As a slight distraction from the topic, is this actually possible in general? I'm thinking in particular of ports that install kernel modules. Since LOCALBASE may be (and very often is) a different file system from /, such modules cannot be accessible to loader and so can't be loaded in early boot. This is potentially a problem for wireless driver firmware modules, for example. -Nathan On 09/12/14 14:38, Bryan Drewery wrote: No (as portmgr). Ports should not be touching the base system like this. Let's NOT go backwards and add a /bin/bash. In fact the /usr/bin/perl one will be removed soon as well. If we can actually eliminate ports touching /usr and / (not including /usr/local and /var) then we gain a very large memory optimization for package building by being able to ro null-mount these to the build jails. There's no reason for bash (and perl) to be exceptions to the 24000 other ports that install to /usr/local/bin. I can think of dozens of other ports that will fall into the same arguments being made here, but it does not mean it is the right thing for FreeBSD. If you want to install the symlink on your system feel free to do it. I install a static bash to /bin/bash on mine and only because I prefer bash shell and want it in / for single-user mode. That's my personal choice though. The proper fix is to fix scripts to be portable and use #! /usr/bin/env bash rather than /bin/bash. We install all packages to PREFIX=/usr/local by default. Why should a bin symlink be an exception? There's no suggestion for symlinking includes or libraries which also hit users often. On 9/12/2014 4:12 PM, Craig Rodrigues wrote: Hi, In the last 3 jobs that I have worked at, there have been a mix of Linux machines and FreeBSD machines. When using an NIS or LDAP environment where there is a single login across multiple machines, it is useful to have a single shell setting. Since Linux and MacOS X have /bin/bash as the shell, in order to get the FreeBSD boxes to play in this environment, I have seen admins do the following on FreeBSD setups: ln -s /usr/local/bin/bash /bin/bash or ln /usr/local/bin/bash /bin/bash and then make sure that /etc/shells as: /usr/local/bin/bash /bin/bash Can we add an optional knob (turned off by default) which creates this symlink and updates /etc/shells? This would help with interoperability of FreeBSD hosts in environments mixed with Linux and MacOS X. -- Craig ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-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: shells/bash port, add a knob which symlinks to /bin/bash ?
Right, well here is another one:
The missing symlink for /etc/ssl/cert.pem
There is no reason it should not be in
${prefix}/etc/ssl/cert.pem
Except that the folder etc/ssl/ only exists in base.
Without this symlink, then SSL certs aren't found by the 'fetch'
command and many significant websites these days can't work without
SSL. For example github.com (there are others).
On Sat, Sep 13, 2014 at 7:32 PM, Craig Rodrigues rodr...@freebsd.org wrote:
On Fri, Sep 12, 2014 at 2:38 PM, Bryan Drewery bdrew...@freebsd.org wrote:
There's no reason for bash (and perl) to be exceptions to the 24000
other ports that install to /usr/local/bin. I can think of dozens of
other ports that will fall into the same arguments being made here, but
it does not mean it is the right thing for FreeBSD.
If you want to install the symlink on your system feel free to do it. I
install a static bash to /bin/bash on mine and only because I prefer
bash shell and want it in / for single-user mode. That's my personal
choice though.
The proper fix is to fix scripts to be portable and use #! /usr/bin/env
bash rather than /bin/bash.
Technically, I agree with you that people should write portable shell
scripts,
and use #!/usr/bin/env bash rather than #!/bin/bash.
Pushing that behavior upstream is not always practical these days, where
FreeBSD is in the minority, while Linux and MacOS X are in the vast
majority of where
people are doing development and learning how to write shell scripts these
days.
The /bin/bash thing is relatively minor, but I brought it up, because I see
it so much.
I've seen it in the jobs that I've worked at. I've also seen it when
dealing with Google
Summer of Code students. I've seen it in blogs mentioned when Linux users
evaluate FreeBSD.
I've seen it when people design appliances based on FreeBSD, but want the
device to be
familiar enough for Linux-y devops people to interact with it.
If there are minor things that we can do in FreeBSD to improve the
out-of-box experience
of FreeBSD to new users who may be used to Linux or MacOS X, that would be
great.
Telling people to change their shell scripts, or manually create symlinks
to /bin/bash is doable,
but why not have something in the system do this automatically, so that the
average end-user does
not even have to think about it?
If adding an optional knob to the bash port which is OFF by default to do
this is a no-go,
would having an optional port like what Brooks Davis mentioned be allowed
which creates
the symlink and updates /etc/shells?
--
Craig
___
freebsd-po...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-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: Teach vidcontrol(1) and vt(4) to restore default font
On Sat, 13 Sep 2014, Marcin Cieslak wrote: Hello, I tried loading gallant.fnt which I did not like and I was wondering how to come back to the nice default font. There does not seem to be the way to do this, so please find below a simple patch to add this functionality. It adds a new ioctl PIO_VDFFONT to the vt(4) driver. I hope I got the reference counting on the vt_font_default structure right. With this patch applied, vidcontrol -f restores the built-in font. Can you please submit this to our bug tracker so it doesn't get lost? https://bugs.freebsd.org/submit Thanks, Ben ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
On 9/14/14, 2:32 AM, Craig Rodrigues wrote: Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. I agree with Craig here. we can keep our code pure but the standard shell these days for everyone except us is /bin/bash. There is nothing wrong with FreeSBD deciding that an industry standard should be adopted.. While I don't like it when people code stuff at work in bash instead of sh, I have to admit it has a lot of advantages, and I can't really stop them.. It's getting more and more common so to some extent we should probably hide our pride a bit and look at bash (and maybe vim) and giving them better standard support. mailing the symlink is a really small thing. ___ 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: shells/bash port, add a knob which symlinks to /bin/bash ?
On 9/14/14, 11:40 AM, Julian Elischer wrote: On 9/14/14, 2:32 AM, Craig Rodrigues wrote: Technically, I agree with you that people should write portable shell scripts, and use #!/usr/bin/env bash rather than #!/bin/bash. Pushing that behavior upstream is not always practical these days, where FreeBSD is in the minority, while Linux and MacOS X are in the vast majority of where people are doing development and learning how to write shell scripts these days. I agree with Craig here. we can keep our code pure but the standard shell these days for everyone except us is /bin/bash. There is nothing wrong with FreeSBD deciding that an industry standard should be adopted.. While I don't like it when people code stuff at work in bash instead of sh, I have to admit it has a lot of advantages, and I can't really stop them.. It's getting more and more common so to some extent we should probably hide our pride a bit and look at bash (and maybe vim) and giving them better standard support. mailing the symlink is a really small thing. err.. making also I would like to RE-propose some suggestions that I've been making now for nearly 15 years. That we probably should have (at least) two classes of ports. in the current system we have base and ports I think we need more granularity than that. at a minimum we should have Base, Base ports, and extended ports. where base ports Must work, and a failure would be enough to hold up a release. base might contain extra hooks for base ports stuff. Stuff in base-ports would include sendmail, bind, Xorg, maybe appache, openldap, sasl, possibly even the compilers. Base ports get special priviledges, and responsibilities. ___ 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
