Re: freebsd-current Digest, Vol 711, Issue 2

I was able to sort this out by installing rust from pkg. The pkg and ports
version was the same when I did it a lil while ago.

Try that, then running the Firefox build again.

Best,
Owen

On Tue, Jun 6, 2017, 20:18 Brandon Kastning <brandon.kastning_at_protonmail.com>
wrote:

> FreeBSD 12-Current Community and Developers,
>
> Regarding Issue #8; I too am having issues. I removed Firefox because it
> was randomly closing. And upon reinstall, I was receiving the python rust
> build error.
>
> What is the proper syntax for a build with the "--format=ustar" ?
>
> I apologize if I am participating incorrectly. As I am new to the
> community and unix.
>
> Best Regards,
>
> Brandon Kastning
> AKA. StreetDancer (IRC & Forums)
>
> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>
> -------- Original Message --------
> Subject: freebsd-current Digest, Vol 711, Issue 2
> Local Time: June 6, 2017 5:00 AM
> UTC Time: June 6, 2017 12:00 PM
> From: freebsd-current-request_at_freebsd.org
> To: freebsd-current_at_freebsd.org
>
> Send freebsd-current mailing list submissions to
> freebsd-current_at_freebsd.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> or, via email, send a message with subject or body 'help' to
> freebsd-current-request_at_freebsd.org
>
> You can reach the person managing the list at
> freebsd-current-owner_at_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: old syslog (jail) and new kernel = 100% CPU (Bryan Drewery)
> 2. Re: old syslog (jail) and new kernel = 100% CPU
> (Ngie Cooper (yaneurabeya))
> 3. Re: Time to increase MAXPHYS? (Kenneth D. Merry)
> 4. Boot CURRENT without efi (Andy Neustadter)
> 5. Re: Boot CURRENT without efi (Allan Jude)
> 6. Re: Time to increase MAXPHYS? (Edward Tomasz Napiera?a)
> 7. Re: Boot CURRENT without efi (Toomas Soome)
> 8. Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
> (Jean-S?bastien P?dron)
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 5 Jun 2017 08:20:47 -0700
> From: Bryan Drewery <bdrewery_at_FreeBSD.org>
> To: Alexander Leidinger <Alexander_at_leidinger.net>
> Cc: current_at_freebsd.org
> Subject: Re: old syslog (jail) and new kernel = 100% CPU
> Message-ID: <b0be1be3-4aa7-a768-6102-3c776f0537f6_at_FreeBSD.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
> >
> > Quoting Bryan Drewery <bryan_at_shatow.net> (from Sun, 4 Jun 2017 14:38:07
> > -0700):
> >
> >> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
> >>> Hi,
> >>>
> >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK.
> >>>
> >>
> >> What branch and revision is the syslogd? From my understanding the bug
> >> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
> >> not released. If it was MFC'd we need to fix it before the 11.1 release.
> >
> > This was a syslogd from head for sure.
> >
> > So the issue was that for an intermediate period of time a bug was in
> > syslogd in head which was causing this, and if I would have upgraded a
> > system were the jail would have been head from before the or after the
> > bug, then I wouldn't have noticed it?
> >
>
> Yes, that's my understanding. So it's ultimately a non-issue for
> releases since it is just a temporary issue on head.
>
> --
> Regards,
> Bryan Drewery
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 473 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/6435eaef/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 2
> Date: Mon, 5 Jun 2017 08:53:50 -0700
> From: "Ngie Cooper (yaneurabeya)" <yaneurabeya_at_gmail.com>
> To: Bryan Drewery <bdrewery_at_FreeBSD.org>
> Cc: Alexander Leidinger <Alexander_at_leidinger.net>, current_at_freebsd.org
> Subject: Re: old syslog (jail) and new kernel = 100% CPU
> Message-ID: <55114361-9212-49AE-A3FF-7691CADB2367_at_gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> > On Jun 5, 2017, at 08:20, Bryan Drewery <bdrewery_at_FreeBSD.org> wrote:
> >
> > On 6/5/2017 2:34 AM, Alexander Leidinger wrote:
> >>
> >> Quoting Bryan Drewery <bryan_at_shatow.net> (from Sun, 4 Jun 2017 14:38:07
> >> -0700):
> >>
> >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote:
> >>>> Hi,
> >>>>
> >>>> new kernel (surely r318877 and later) and old syslog in a jail = NOK.
> >>>>
> >>>
> >>> What branch and revision is the syslogd? From my understanding the bug
> >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but
> >>> not released. If it was MFC'd we need to fix it before the 11.1
> release.
> >>
> >> This was a syslogd from head for sure.
> >>
> >> So the issue was that for an intermediate period of time a bug was in
> >> syslogd in head which was causing this, and if I would have upgraded a
> >> system were the jail would have been head from before the or after the
> >> bug, then I wouldn't have noticed it?
> >>
> >
> > Yes, that's my understanding. So it's ultimately a non-issue for
> > releases since it is just a temporary issue on head.
>
> Yes. syslogd was refactored on ^/head. Some of the refactoring caused the
> issue Alexander brought up. The changes were never backported though, so
> the concern you had in the previous message isn?t something to be worried
> about, since the code hasn?t seen the changes the ^/head copy has.
> Cheers!
> -Ngie
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 842 bytes
> Desc: Message signed with OpenPGP using GPGMail
> URL: <
> http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/2630dac2/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 3
> Date: Mon, 5 Jun 2017 12:02:53 -0400
> From: "Kenneth D. Merry" <ken_at_FreeBSD.ORG>
> To: Hans Petter Selasky <hps_at_selasky.org>
> Cc: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>,
> freebsd-current_at_freebsd.org
> Subject: Re: Time to increase MAXPHYS?
> Message-ID: <20170605160253.GA17376_at_mithlond.kdm.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sun, Jun 04, 2017 at 09:52:36 +0200, Hans Petter Selasky wrote:
> > On 06/04/17 09:39, Tomoaki AOKI wrote:
> > > Hi
> > >
> > > One possibility would be to make it MD build-time OTIONS,
> > > defaulting 1M on regular systems and 128k on smaller systems.
> > >
> > > Of course I guess making it a tunable (or sysctl) would be best,
> > > though.
> > >
> >
> > Hi,
> >
> > A tunable sysctl would be fine, but beware that commonly used firmware
> > out there produced in the millions might hang in a non-recoverable way
> > if you exceed their "internal limits". Conditionally lowering this
> > definition is fine, but increasing it needs to be carefully verified.
> >
> > For example many USB devices are only tested with OS'es like Windows and
> > MacOS and if these have any kind of limitation on the SCSI transfer
> > sizes, it is very likely many devices out there do not support any
> > larger transfer sizes either.
>
> I agree that I'd like to see a tunable. We've been using a MAXPHYS value
> slightly larger than 1MB at Spectra for years with no problems, but then
> again, we're only running on newer hardware.
>
> If we keep DFLTPHYS the same (64K) or come up with another constant that is
> defined to 64K, the way the da(4) and sa(4) handle things will keep most
> older controllers working properly. Here is what da(4) does:
>
> if (cpi.maxio == 0)
> softc->maxio = DFLTPHYS; /* traditional default */
> else if (cpi.maxio > MAXPHYS)
> softc->maxio = MAXPHYS; /* for safety */
> else
> softc->maxio = cpi.maxio;
> softc->disk->d_maxsize = softc->maxio;
>
> cpi is the XPT_PATH_INQ CCB. The maxio field was added later, so older,
> unmodified drivers that haven't set the maxio field default to a 64K I/O
> size.
>
> Drivers for some of the more common SAS and FC hardware set maxio to a
> value that is correct for the hardware. (e.g. mpt(4), mps(4), mpr(4),
> and isp(4) all set it correctly.)
>
> As Warner pointed out, the way ahci(4) works is that it sets its maximum
> I/O size to MAXPHYS. The question is, does all AHCI hardware support
> arbitrary transfer sizes? Is there a way to figure out what the hardware
> supports, and if not, we should probably default it to 128K instead of
> MAXPHYS.
>
> Tape drives are another related issue. Tape block sizes up to 1MB are
> pretty common. LTFS allows for blocksizes up to 1MB. You can't currently
> read a tape with a 1MB blocksize on FreeBSD without bumping MAXPHYS and
> having a controller and tape drive that can handle the larger blocksize.
>
> The sa(4) driver has the same logic as the da(4) driver for limiting
> transfer sizes to the smaller of MAXPHYS and cpi.maxio.
>
> The sa(4) driver gives the user some tools for figuring things out:
>
> {sm4u-1-mgmt:/root:!:1} mt status -v
> Drive: sa0: <IBM ULTRIUM-HH5 G9N1> Serial Number: 101500520A
> ---------------------------------
> Mode Density Blocksize bpi Compression
> Current: 0x58:LTO-5 variable 384607 enabled (0x1)
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> Partition: 0 Calc File Number: 0 Calc Record Number: 0
> Residual: 0 Reported File Number: 0 Reported Record Number: 0
> Flags: BOP
> ---------------------------------
> Tape I/O parameters:
> Maximum I/O size allowed by driver and controller (maxio): 1048576 bytes
> Maximum I/O size reported by controller (cpi_maxio): 5197824 bytes
> Maximum block size supported by tape drive and media (max_blk): 8388608
> bytes
> Minimum block size supported by tape drive and media (min_blk): 1 bytes
> Block granularity supported by tape drive and media (blk_gran): 0 bytes
> Maximum possible I/O size (max_effective_iosize): 1048576 bytes
>
> On this particular FreeBSD/head machine, I have MAXPHYS set to 1MB. The
> controller (isp(4)) supports ~5MB I/O sizes and the drive (IBM LTO-5)
> supports ~8MB I/O, but MAXPHYS is set to 1MB, so that is the limit.
>
> I have considered changing the sa(4) driver to not use physio(9), and
> instead use a custom allocator to allow reading and writing tapes with
> blocksizes up to what the hardware (combination of tape drive and
> controller) allows. I haven't gotten around to it yet, because bumping
> MAXPHYS works well enough in most cases. It also has a nice side effect of
> allowing unmapped I/O.
>
> The pass(4) driver limits I/O sizes in the same way as the da(4) and sa(4)
> drivers for CCBs sent via the blocking (CAMIOCOMMAND) ioctl, but for CCBs
> sent via the asynchronous API, the only limit is the controller (cpi.maxio)
> limit. The latter is because the buffers for the asynchronous interface
> are malloced. If it were possible to send arbitrary sized, unmapped S/G
> lists, then we could convert the asynchronous pass(4) interface to do
> unmapped I/O.
>
> Ken
> --
> Kenneth Merry
> ken_at_FreeBSD.ORG
>
> ------------------------------
>
> Message: 4
> Date: Mon, 5 Jun 2017 13:31:10 -0400
> From: Andy Neustadter <a.n.us_at_ieee.org>
> To: freebsd-current_at_freebsd.org
> Subject: Boot CURRENT without efi
> Message-ID:
> <CA+2zecwbqWawbR0Nf75Aqw04q8JzYimxrxqevMbhTAjCJXsmYg_at_mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> Hi:
>
> I have an older HP desktop that does not support USB boot or UEFI. Is
> it possible to use this machine with 12-current using GPT? Any help
> or pointers to info would be greatly appreciated. Thanks in advance.
>
> ------------------------------
>
> Message: 5
> Date: Mon, 5 Jun 2017 13:53:20 -0400
> From: Allan Jude <allanjude_at_freebsd.org>
> To: freebsd-current_at_freebsd.org
> Subject: Re: Boot CURRENT without efi
> Message-ID: <5040e292-aedd-2fe3-67e7-9b0e440fc662_at_freebsd.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 2017-06-05 13:31, Andy Neustadter wrote:
> > Hi:
> >
> > I have an older HP desktop that does not support USB boot or UEFI. Is
> > it possible to use this machine with 12-current using GPT? Any help
> > or pointers to info would be greatly appreciated. Thanks in advance.
> > _______________________________________________
> > freebsd-current_at_freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "
> freebsd-current-unsubscribe_at_freebsd.org"
> >
>
> If your BIOS does not actively interfere, then yes, you can boot from a
> GPT partitioned disk in legacy mode, without UEFI.
>
> If it doesn't work, the installer still supports MBR.
>
> --
> Allan Jude
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 834 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/ab5d2bf6/attachment-0001.sig
> >
>
> ------------------------------
>
> Message: 6
> Date: Mon, 5 Jun 2017 18:49:30 +0100
> From: Edward Tomasz Napiera?a <trasz_at_FreeBSD.org>
> To: Hans Petter Selasky <hps_at_selasky.org>
> Cc: Tomoaki AOKI <junchoon_at_dec.sakura.ne.jp>,
> freebsd-current_at_freebsd.org
> Subject: Re: Time to increase MAXPHYS?
> Message-ID: <20170605174930.GA6259_at_brick>
> Content-Type: text/plain; charset=us-ascii
>
> On 0604T0952, Hans Petter Selasky wrote:
> > On 06/04/17 09:39, Tomoaki AOKI wrote:
> > > Hi
> > >
> > > One possibility would be to make it MD build-time OTIONS,
> > > defaulting 1M on regular systems and 128k on smaller systems.
> > >
> > > Of course I guess making it a tunable (or sysctl) would be best,
> > > though.
> > >
> >
> > Hi,
> >
> > A tunable sysctl would be fine, but beware that commonly used firmware
> > out there produced in the millions might hang in a non-recoverable way
> > if you exceed their "internal limits". Conditionally lowering this
> > definition is fine, but increasing it needs to be carefully verified.
> >
> > For example many USB devices are only tested with OS'es like Windows and
> > MacOS and if these have any kind of limitation on the SCSI transfer
> > sizes, it is very likely many devices out there do not support any
> > larger transfer sizes either.
>
> FWIW, when testing cfiscsi(4) with Windows and OSX I've noticed
> that both issue 1MB requests. I wouldn't be surprised if they avoided
> doing that for older devices, depending on eg the SCSI version reported
> by device.
>
> ------------------------------
>
> Message: 7
> Date: Mon, 05 Jun 2017 20:34:33 +0300
> From: Toomas Soome <tsoome_at_me.com>
> To: Andy Neustadter <a.n.us_at_ieee.org>
> Cc: freebsd-current_at_freebsd.org
> Subject: Re: Boot CURRENT without efi
> Message-ID: <A71EB96E-A404-442D-952C-DF6774CDC5C2_at_me.com>
> Content-Type: text/plain; charset=us-ascii
>
> > On 5. juuni 2017, at 20:31, Andy Neustadter <a.n.us_at_ieee.org> wrote:
> >
> > Hi:
> >
> > I have an older HP desktop that does not support USB boot or UEFI. Is
> > it possible to use this machine with 12-current using GPT? Any help
> > or pointers to info would be greatly appreciated. Thanks in advance.
>
> GPT does not require UEFI, BIOS boot will read the pmbr and should behave
> just as with MBR partitioning.
>
> rgds,
> toomas
>
> ------------------------------
>
> Message: 8
> Date: Mon, 5 Jun 2017 23:31:22 +0200
> From: Jean-S?bastien P?dron <dumbbell_at_FreeBSD.org>
> To: Tim Kientzle <tim_at_kientzle.com>
> Cc: FreeBSD current <freebsd-current_at_freebsd.org>
> Subject: Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
> Message-ID: <e449e1f8-19b0-04a8-f9a7-3eab1fe3657b_at_FreeBSD.org>
> Content-Type: text/plain; charset="utf-8"
>
> On 03.06.2017 08:26, Tim Kientzle wrote:
> > You could add --format=ustar to the existing command line; that
> > would force bsdtar to use the older "ustar" format (without any
> > extensions that might confuse Python's tar file module).
>
> Even better! Thank you :)
>
> >> This will use GNU tar instead of BSD tar to recreate the bootstrap and
> >> GNU tar doesn't seem to produce sparse file entries in the archive.
> >
> > How ironic; using GNU tar in order to avoid having GNU sparse file
> entries. ;-)
>
> Yes :)
>
> --
> Jean-S?bastien P?dron
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 963 bytes
> Desc: OpenPGP digital signature
> URL: <
> http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/88c1d566/attachment-0001.sig
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
> ------------------------------
>
> End of freebsd-current Digest, Vol 711, Issue 2
> ***********************************************
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>