fuck you pkg.conf
Hi. So. Each time pkg_add runs, it tries to connect to either PKG_PATH or to installpath from pkg.conf to fetch quirks (I assume). When you have no network anymore (moving around with your laptop or whatever), and you want to install a local package, you're basically fucked: $ time sudo pkg_add ./gmake-4.1.tgz - hangs forever - getting tired, so ^C Fatal error: Caught SIGINT at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 40. 1m57.24s real 0m0.15s user 0m0.08s system - sometimes, that keeps the pkg db locked... On my production machines, I have a regular job that removes the useless pkg.conf, but it happens often enough on my dev boxen now that I felt I should send something. The problem is that each time I update using bsd.rd, /etc/pkg.conf is re-created... and I am not even talking about the fact that the created file is wrong since I usually do not install base from the same place I get packages -- but well. Can we have a switch or whatever that would prevent pkg_add from trying to go online each time it's run please? -- Antoine
Re: fuck you pkg.conf
On 11/29/14 11:07, Antoine Jacoutot wrote: Hi. So. Each time pkg_add runs, it tries to connect to either PKG_PATH or to installpath from pkg.conf to fetch quirks (I assume). When you have no network anymore (moving around with your laptop or whatever), and you want to install a local package, you're basically fucked: $ time sudo pkg_add ./gmake-4.1.tgz - hangs forever - getting tired, so ^C Fatal error: Caught SIGINT at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 40. 1m57.24s real 0m0.15s user 0m0.08s system - sometimes, that keeps the pkg db locked... On my production machines, I have a regular job that removes the useless pkg.conf, but it happens often enough on my dev boxen now that I felt I should send something. The problem is that each time I update using bsd.rd, /etc/pkg.conf is re-created... and I am not even talking about the fact that the created file is wrong since I usually do not install base from the same place I get packages -- but well. Can we have a switch or whatever that would prevent pkg_add from trying to go online each time it's run please? Doesn't having a pkg.conf help rather than remove it I change it and use this $ cat /etc/pkg.conf installpath=/usr/ports/packages/amd64/all The location of my local packages. The only problem is fw_update run on first reboot, I just normally rm /mnt/etc/rc.firsttime before rebooting at the end of an upgrade
Re: fuck you pkg.conf
On 2014/11/29 12:07, Antoine Jacoutot wrote: Hi. So. Each time pkg_add runs, it tries to connect to either PKG_PATH or to installpath from pkg.conf to fetch quirks (I assume). When you have no network anymore (moving around with your laptop or whatever), and you want to install a local package, you're basically fucked: $ time sudo pkg_add ./gmake-4.1.tgz - hangs forever - getting tired, so ^C Fatal error: Caught SIGINT at /usr/libdata/perl5/OpenBSD/AddDelete.pm line 40. 1m57.24s real 0m0.15s user 0m0.08s system - sometimes, that keeps the pkg db locked... On my production machines, I have a regular job that removes the useless pkg.conf, but it happens often enough on my dev boxen now that I felt I should send something. The problem is that each time I update using bsd.rd, /etc/pkg.conf is re-created... and I am not even talking about the fact that the created file is wrong since I usually do not install base from the same place I get packages -- but well. Can we have a switch or whatever that would prevent pkg_add from trying to go online each time it's run please? I do see some use for being able to ignore pkg.conf from the command line. But that said, why does your pkg.conf keep returning? I don't have one on my laptop at all, I probably removed it once after installing, but it never comes back. On some other machines I have ntogo = yes but no installpath. I just control everything by setting PKG_PATH in the shell, default set in .profile (using arch -s, uname -r etc. and choosing a mirror based on the address of the default route to tell what network I'm on), and I just override with 'PKG_PATH= sudo pkg_add blah' if I need to.
Re: fuck you pkg.conf
But that said, why does your pkg.conf keep returning? I don't have one on my laptop at all, I probably removed it once after installing, but it It returns each time I upgrade using bsd.rd. -- Antoine
[patch]rcs: comment typo
Hi tech, it's NULL not NUL. fritjof Index: diff3.c === RCS file: /cvs/src/usr.bin/rcs/diff3.c,v retrieving revision 1.33 diff -u -p -r1.33 diff3.c --- diff3.c 4 Mar 2012 04:05:15 - 1.33 +++ diff3.c 29 Nov 2014 13:15:51 - @@ -450,7 +450,7 @@ ed_patch_lines(struct rcs_lines *dlines, if (lp-l_len 2) continue; - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; Index: rcs.c === RCS file: /cvs/src/usr.bin/rcs/rcs.c,v retrieving revision 1.81 diff -u -p -r1.81 rcs.c --- rcs.c 10 Oct 2014 08:15:25 - 1.81 +++ rcs.c 29 Nov 2014 13:16:40 - @@ -799,7 +799,7 @@ rcs_patch_lines(struct rcs_lines *dlines if (lp-l_len 2) errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; lineno = (int)strtol((lp-l_line + 1), ep, 10); @@ -1047,7 +1047,7 @@ rcs_delta_stats(struct rcs_delta *rdp, i errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; (void)strtol((lp-l_line + 1), ep, 10); pgppOOEBjCeyo.pgp Description: PGP signature
Re: [patch]rcs: comment typo
On Sat, Nov 29, 2014, Fritjof Bornebusch wrote:
it's NULL not NUL.
Not in this case...
NULL: is a pointer (usually 0)
NUL: is a character ('\0')
Re: 64-bit PCI bridge support: testers needed
Can this be realted to load, which is very high? Jiri 28. 11. 2014 v 16:12, sven falempin sven.falem...@gmail.com: There is no direct relation with the commit, but i will anyway report the test result on my problematic hardware. The behavior is mostly the same, but now rl0: watchdog timeout is spammed by the kernel. As you can see the system work for more than 40 hours. I really wonder what could be the cause of this, after rebooting the machine reproduce the bug quickly, maybe there is some kind of electric problem. Aug 22 18:00:07 unicorn /bsd: rl0: watchdog timeout # uptime 7:58PM up 1 day, 23:17, 1 user, load averages: 5.23, 5.50, 5.30 # date Fri Aug 22 19:58:38 EDT 2014 # rl0: watchdog timeout rl0: watchdog timeout On Wed, Nov 26, 2014 at 10:10 AM, sven falempin sven.falem...@gmail.com wrote: HEllo, So i reported a bug with a pci bridge a while ago. On an Apu with a pci to pci bridge over pci express. Dmesg below I use a recent snapshot OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014 and assume the commit was in The situation improved, as i can have the card running with bsd.mp for more than a second. But on the second boot. During the first boot i add the vr3: restarting kernel message when asking for a lease on vr3. At this moment my not reliable serial usb decide to do the classic freez. This time i was not able to get access to the machine. I am currently sending icmp trhough rl and vr and waiting for a problem. bug mail objet was : pci disconnection creates interfaces instabilities dmesg: OpenBSD 5.6-current (GENERIC.MP) #610: Tue Nov 25 06:00:07 MST 2014 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 2098520064 (2001MB) avail mem = 2038870016 (1944MB) mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7e16d820 (7 entries) bios0: vendor coreboot version 4.0 date 09/08/2014 bios0: PC Engines APU acpi0 at bios0: rev 0 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP SPCR HPET APIC HEST SSDT SSDT SSDT acpi0: wakeup devices AGPB(S4) HDMI(S4) PBR4(S4) PBR5(S4) PBR6(S4) PBR7(S4) PE20(S4) PE21(S4) PE22(S4) PE23(S4) PIBR(S4) UOH1(S3) UOH2(S3) UOH3(S3) UOH4(S3) UOH5(S3) [...] acpitimer0 at acpi0: 3579545 Hz, 32 bits acpihpet0 at acpi0: 14318180 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD G-T40E Processor, 1000.14 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu0: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu0: 8 4MB entries fully associative cpu0: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD G-T40E Processor, 1000.00 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,SSSE3,CX16,POPCNT,NXE,MMXX,FFXSR,PAGE1GB,LONG,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,IBS,SKINIT,ITSC cpu1: 32KB 64b/line 2-way I-cache, 32KB 64b/line 8-way D-cache, 512KB 64b/line 16-way L2 cache cpu1: 8 4MB entries fully associative cpu1: DTLB 40 4KB entries fully associative, 8 4MB entries fully associative cpu1: smt 0, core 1, package 0 ioapic0 at mainbus0: apid 2 pa 0xfec0, version 21, 24 pins acpiprt0 at acpi0: bus -1 (AGPB) acpiprt1 at acpi0: bus -1 (HDMI) acpiprt2 at acpi0: bus 1 (PBR4) acpiprt3 at acpi0: bus 2 (PBR5) acpiprt4 at acpi0: bus 3 (PBR6) acpiprt5 at acpi0: bus -1 (PBR7) acpiprt6 at acpi0: bus 5 (PE20) acpiprt7 at acpi0: bus -1 (PE21) acpiprt8 at acpi0: bus -1 (PE22) acpiprt9 at acpi0: bus -1 (PE23) acpiprt10 at acpi0: bus 0 (PCI0) acpiprt11 at acpi0: bus 4 (PIBR) acpicpu0 at acpi0: C2, PSS acpicpu1 at acpi0: C2, PSS acpibtn0 at acpi0: PWRB cpu0: 1000 MHz: speeds: 1000 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 AMD AMD64 14h Host rev 0x00 ppb0 at pci0 dev 4 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci1 at ppb0 bus 1 re0 at pci1 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:33:85:d8 rgephy0 at re0 phy 7: RTL8169S/8110S PHY, rev. 4 ppb1 at pci0 dev 5 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci2 at ppb1 bus 2 re1 at pci2 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00), msi, address 00:0d:b9:33:85:d9 rgephy1 at re1 phy 7: RTL8169S/8110S PHY, rev. 4 ppb2 at pci0 dev 6 function 0 AMD AMD64 14h PCIE rev 0x00: msi pci3 at ppb2 bus 3 re2 at pci3 dev 0 function 0 Realtek 8168 rev 0x06: RTL8168E/8111E (0x2c00),
Re: [patch]rcs: comment typo
On Sat, Nov 29, 2014 at 05:27:00AM -0800, Claus Assmann wrote:
On Sat, Nov 29, 2014, Fritjof Bornebusch wrote:
it's NULL not NUL.
Not in this case...
NULL: is a pointer (usually 0)
NUL: is a character ('\0')
Ahh I see, thank you.
pgpMkIwf4S_cz.pgp
Description: PGP signature
Re: fuck you pkg.conf
On Sat, Nov 29, 2014 at 14:02, Antoine Jacoutot wrote: But that said, why does your pkg.conf keep returning? I don't have one on my laptop at all, I probably removed it once after installing, but it It returns each time I upgrade using bsd.rd. This seems like a mistake. I like that the install script remembers things like timezone and mirror for installation, but it always prompts me. It's never an invisible setting. And two, it's not actually something configured on the installed system.
Re: fuck you pkg.conf
Date: Sat, 29 Nov 2014 09:27:51 -0500 From: Ted Unangst t...@tedunangst.com On Sat, Nov 29, 2014 at 14:02, Antoine Jacoutot wrote: But that said, why does your pkg.conf keep returning? I don't have one on my laptop at all, I probably removed it once after installing, but it It returns each time I upgrade using bsd.rd. This seems like a mistake. I like that the install script remembers things like timezone and mirror for installation, but it always prompts me. It's never an invisible setting. And two, it's not actually something configured on the installed system. It would be rather annoying if pkg_add would ask me where I'd want to fetch my packages from every time I run it. Changing the install script to only create /etc/pkg.conf when doing a new install would make more sense.
Re: [patch]rcs: comment typo
On Sat, Nov 29, 2014 at 02:22:25PM +0100, Fritjof Bornebusch wrote: Hi tech, it's NULL not NUL. You're touching a big controversy here. Many developers say that NUL is the right term when rferring to chars and not pointers, -Otto fritjof Index: diff3.c === RCS file: /cvs/src/usr.bin/rcs/diff3.c,v retrieving revision 1.33 diff -u -p -r1.33 diff3.c --- diff3.c 4 Mar 2012 04:05:15 - 1.33 +++ diff3.c 29 Nov 2014 13:15:51 - @@ -450,7 +450,7 @@ ed_patch_lines(struct rcs_lines *dlines, if (lp-l_len 2) continue; - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; Index: rcs.c === RCS file: /cvs/src/usr.bin/rcs/rcs.c,v retrieving revision 1.81 diff -u -p -r1.81 rcs.c --- rcs.c 10 Oct 2014 08:15:25 - 1.81 +++ rcs.c 29 Nov 2014 13:16:40 - @@ -799,7 +799,7 @@ rcs_patch_lines(struct rcs_lines *dlines if (lp-l_len 2) errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; lineno = (int)strtol((lp-l_line + 1), ep, 10); @@ -1047,7 +1047,7 @@ rcs_delta_stats(struct rcs_delta *rdp, i errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; (void)strtol((lp-l_line + 1), ep, 10);
Re: [patch]rcs: comment typo
Hi, Otto Moerbeek wrote on Sat, Nov 29, 2014 at 04:53:28PM +0100: On Sat, Nov 29, 2014 at 02:22:25PM +0100, Fritjof Bornebusch wrote: Hi tech, it's NULL not NUL. You're touching a big controversy here. Many developers say that NUL is the right term when rferring to chars and not pointers, Not only that. For the system manuals, we have basically settled on recommending .Dv NULL for the NULL pointer, (void *)0 NUL-terminated \ without any markup for talking about C strings, ... ending in '\0' Yours, Ingo
Re: [patch]rcs: comment typo
On Sat, Nov 29, 2014 at 04:53:28PM +0100, Otto Moerbeek wrote: On Sat, Nov 29, 2014 at 02:22:25PM +0100, Fritjof Bornebusch wrote: Hi tech, it's NULL not NUL. You're touching a big controversy here. Many developers say that NUL is the right term when rferring to chars and not pointers, And what is the correct term when referring to '0'? Or means '\0' and '0' the same. -Otto fritjof Index: diff3.c === RCS file: /cvs/src/usr.bin/rcs/diff3.c,v retrieving revision 1.33 diff -u -p -r1.33 diff3.c --- diff3.c 4 Mar 2012 04:05:15 - 1.33 +++ diff3.c 29 Nov 2014 13:15:51 - @@ -450,7 +450,7 @@ ed_patch_lines(struct rcs_lines *dlines, if (lp-l_len 2) continue; - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; Index: rcs.c === RCS file: /cvs/src/usr.bin/rcs/rcs.c,v retrieving revision 1.81 diff -u -p -r1.81 rcs.c --- rcs.c 10 Oct 2014 08:15:25 - 1.81 +++ rcs.c 29 Nov 2014 13:16:40 - @@ -799,7 +799,7 @@ rcs_patch_lines(struct rcs_lines *dlines if (lp-l_len 2) errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; lineno = (int)strtol((lp-l_line + 1), ep, 10); @@ -1047,7 +1047,7 @@ rcs_delta_stats(struct rcs_delta *rdp, i errx(1, line too short, RCS patch seems broken); op = *(lp-l_line); - /* NUL-terminate line buffer for strtol() safety. */ + /* NULL-terminate line buffer for strtol() safety. */ tmp = lp-l_line[lp-l_len - 1]; lp-l_line[lp-l_len - 1] = '\0'; (void)strtol((lp-l_line + 1), ep, 10); pgpxlyH4t3nOW.pgp Description: PGP signature
patch: Support long lines in Plan B
Hi,
this diff doesn't just fix the division by zero for input files with
lines longer than 1023 chars in Plan B mode, it actually removes this
line limit!
Before:
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' a a
$ dd if=/dev/zero bs=1 count=1024 | tr '\0' b b
$ diff -u a b a.diff
$ patch -x 8 a a.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- a Sat Nov 29 17:34:15 2014
|+++ b Sat Nov 29 17:34:19 2014
--
Floating point exception (core dumped)
$_
After:
$ patch -x 8 a a.diff
Hmm... Looks like a unified diff to me...
The text leading up to this was:
--
|--- a Sat Nov 29 17:34:15 2014
|+++ b Sat Nov 29 17:34:19 2014
--
Patching file a using Plan B...
Hunk #1 succeeded at 1.
done
With this diff, patch uses fgetln to read very long lines. One could argue
that this limits patch to the amount of RAM it has available -- but
that will happen anyway because at least twice as much memory as the
longest line has to be allocated. fgetln is therefore a good choice to
easily parse the file.
If you want to regress-test, you can supply -x 8 in PATCHOPTIONS to
enforce Plan B. Keep in mind that test5 will fail because this debug
option skips a check if the input file is available.
Tobias
Index: inp.c
===
RCS file: /cvs/src/usr.bin/patch/inp.c,v
retrieving revision 1.41
diff -u -p -u -p -r1.41 inp.c
--- inp.c 25 Nov 2014 10:22:08 - 1.41
+++ inp.c 29 Nov 2014 16:14:45 -
@@ -55,8 +55,9 @@ static char **i_ptr;/* pointers to line
static int tifd = -1; /* plan b virtual string array */
static char*tibuf[2]; /* plan b buffers */
static LINENUM tiline[2] = {-1, -1}; /* 1st line in each buffer */
-static LINENUM lines_per_buf; /* how many lines per buffer */
-static int tireclen; /* length of records in tmp file */
+static size_t lines_per_buf; /* how many lines per buffer */
+static size_t tibuflen; /* plan b buffer length */
+static size_t tireclen; /* length of records in tmp file */
static boolrev_in_string(const char *);
static boolreallocate_lines(size_t *);
@@ -333,8 +334,8 @@ static void
plan_b(const char *filename)
{
FILE*ifp;
- size_t i = 0, j, maxlen = 1;
- char*p;
+ size_t i = 0, j, len, maxlen = 1;
+ char*lbuf = NULL, *p;
boolfound_revision = (revision == NULL);
using_plan_a = false;
@@ -343,15 +344,28 @@ plan_b(const char *filename)
(void) unlink(TMPINNAME);
if ((tifd = open(TMPINNAME, O_EXCL | O_CREAT | O_WRONLY, 0666)) 0)
pfatal(can't open file %s, TMPINNAME);
- while (fgets(buf, sizeof buf, ifp) != NULL) {
- if (revision != NULL !found_revision rev_in_string(buf))
+ while ((p = fgetln(ifp, len)) != NULL) {
+ if (p[len - 1] == '\n')
+ p[len - 1] = '\0';
+ else {
+ /* EOF without EOL, copy and add the NUL */
+ if ((lbuf = malloc(len + 1)) == NULL)
+ fatal(out of memory\n);
+ memcpy(lbuf, p, len);
+ lbuf[len] = '\0';
+ p = lbuf;
+
+ last_line_missing_eol = true;
+ len++;
+ }
+ if (revision != NULL !found_revision rev_in_string(p))
found_revision = true;
- if ((i = strlen(buf)) maxlen)
- maxlen = i; /* find longest line */
+ if (len maxlen)
+ maxlen = len; /* find longest line */
}
- last_line_missing_eol = i 0 buf[i - 1] != '\n';
- if (last_line_missing_eol maxlen == i)
- maxlen++;
+ free(lbuf);
+ if (ferror(ifp))
+ pfatal(can't read file %s, filename);
if (revision != NULL) {
if (!found_revision) {
@@ -376,23 +390,26 @@ plan_b(const char *filename)
revision);
}
fseek(ifp, 0L, SEEK_SET); /* rewind file */
- lines_per_buf = BUFFERSIZE / maxlen;
tireclen = maxlen;
- tibuf[0] = malloc(BUFFERSIZE + 1);
+ tibuflen = maxlen BUFFERSIZE ? maxlen : BUFFERSIZE;
+ lines_per_buf = tibuflen / maxlen;
+ tibuf[0] = malloc(tibuflen + 1);
if (tibuf[0] == NULL)
fatal(out of memory\n);
- tibuf[1] = malloc(BUFFERSIZE + 1);
+ tibuf[1] = malloc(tibuflen + 1);
if (tibuf[1] == NULL)
fatal(out of memory\n);
for (i = 1;; i++) {
p = tibuf[0] + maxlen * (i % lines_per_buf);
if (i % lines_per_buf == 0) /* new block */
- if (write(tifd, tibuf[0],
/etc/rc: remove RC4 in a comment
Hi!
RC4 is no more. It's better to be more generic.
comments / oks ?
Ciao,
David
Index: rc
===
RCS file: /cvs/src/etc/rc,v
retrieving revision 1.444
diff -u -p -u -p -r1.444 rc
--- rc 17 Nov 2014 18:19:08 - 1.444
+++ rc 29 Nov 2014 18:54:54 -
@@ -359,7 +359,7 @@ if [ -f /etc/resolv.conf.save ]; then
touch /etc/resolv.conf
fi
sh /etc/netstart
-dmesg /dev/random# any write triggers an RC4 rekey
+dmesg /dev/random# any write triggers a rekey
if [ X${pf} != XNO ]; then
if [ -f ${pf_rules} ]; then
Re: fuck you pkg.conf
On Sat, Nov 29, 2014 at 04:32:20PM +0100, Mark Kettenis wrote:
Date: Sat, 29 Nov 2014 09:27:51 -0500
From: Ted Unangst t...@tedunangst.com
On Sat, Nov 29, 2014 at 14:02, Antoine Jacoutot wrote:
But that said, why does your pkg.conf keep returning? I don't have one on
my laptop at all, I probably removed it once after installing, but it
It returns each time I upgrade using bsd.rd.
This seems like a mistake. I like that the install script remembers
things like timezone and mirror for installation, but it always
prompts me. It's never an invisible setting. And two, it's not
actually something configured on the installed system.
It would be rather annoying if pkg_add would ask me where I'd want to
fetch my packages from every time I run it.
Changing the install script to only create /etc/pkg.conf when doing a
new install would make more sense.
This sound like a reasonable compromise to me.
Index: install.sub
===
RCS file: /home/cvs/src/distrib/miniroot/install.sub,v
retrieving revision 1.799
diff -p -u -r1.799 install.sub
--- install.sub 18 Nov 2014 19:00:16 - 1.799
+++ install.sub 29 Nov 2014 19:35:51 -
@@ -1952,12 +1952,9 @@ finish_up() {
done /mnt/etc/fstab
fi
- # Create or update pkg.conf with the new package path, if any
- if [[ -n $PACKAGE_PATH ]]; then
- grep -v '^[ ]*installpath[ ]*=' /mnt/etc/pkg.conf
2/dev/null /tmp/pkgconf
- print -r -- installpath = $PACKAGE_PATH /tmp/pkgconf
- cp /tmp/pkgconf /mnt/etc/pkg.conf
- fi
+ # Create an initial pkg.conf with the package path during install.
+ [[ -n $PACKAGE_PATH $MODE == install ]]
+ print -r -- installpath = $PACKAGE_PATH /mnt/etc/pkg.conf
echo -n Making all device nodes...
(cd /mnt/dev; sh MAKEDEV all
--
-=[rpe]=-
urndis(4) fix
Recent Oracle SPARC machines have a USB gadget to talk to the Service
Processor (ILOM). This gadget supports both RNDIS and CDC Ethernet.
The RNDIS bits uncovered a bug in urndis(4). When urndis_ctrl_set()
sets up the REMOTE_NDIS_SET_MSG command it sets up msg-rm_infobuflen,
it subsequently overwrites its contents. Apparently many RNDIS
devices don't care, but this hardware sends a response back that
indicates the command wasn't accepted. Diff below fixes this problem.
It matches what Linux does.
Unfortunately, this isn't enough to make the gadget work in RNDIS mode.
I'd appreciate it if people using urndis(4) could test this diff.
Index: if_urndis.c
===
RCS file: /cvs/src/sys/dev/usb/if_urndis.c,v
retrieving revision 1.49
diff -u -p -r1.49 if_urndis.c
--- if_urndis.c 13 Jul 2014 15:52:49 - 1.49
+++ if_urndis.c 29 Nov 2014 20:30:24 -
@@ -554,7 +554,7 @@ urndis_ctrl_set(struct urndis_softc *sc,
msg-rm_infobuflen = htole32(len);
if (len != 0) {
msg-rm_infobufoffset = htole32(20);
- memcpy((char*)msg + 20, buf, len);
+ memcpy((char*)msg + 28, buf, len);
} else
msg-rm_infobufoffset = 0;
msg-rm_devicevchdl = 0;
@@ -570,7 +570,7 @@ urndis_ctrl_set(struct urndis_softc *sc,
letoh32(msg-rm_infobufoffset),
letoh32(msg-rm_devicevchdl)));
- rval = urndis_ctrl_send(sc, msg, sizeof(*msg));
+ rval = urndis_ctrl_send(sc, msg, sizeof(*msg) + len);
free(msg, M_TEMP, 0);
if (rval != RNDIS_STATUS_SUCCESS) {
