Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Sun, 2021-01-03 at 19:02:24 +0100, Helge Oldach wrote: Hi all, I have deep cloned main from https://git.freebsd.org/src.git as described in the mini primer and started pulling updates. Now I'm stumbling over a bit of confusion: | hmo@p48 /usr/src $ git log -p e35a01eec6926bfb5c088ca8961079b5

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Thu, 31 Dec 2020 at 02:50, Helge Oldach wrote: > > The only sensible way out is to retire mergemaster and switch to > etcupdate. This would affect any stable/1? users building from source. stable/11 and stable/12 users can continue to update via svn and have $FreeBSD$ expanded, for the life of

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 12/23/20 11:58 AM, Warner Losh wrote: [...] mergemaster and etcupdate can cope without them. Warner [...] Until this moment, I had never heard of etcupdate, and I had mergemaster practically programmed into my fingers for system updates. So I read the man page for etcupdate, and it looks l

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Thu, Dec 31, 2020 at 01:06:17PM +0200, Christos Chatzaras wrote: > ... > But the latest doc version has no reference about "mergemaster -p". > > So "mergemaster/etcupdate -p" is not needed if we use 12.2? > I used src/UPDATING (near the end, under "COMMON ITEMS", then "To rebuild everyth

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> Or I don't need "etcupdate -p" ? In > https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/makeworld.html > I > don't see that "mergemaster -p" is needed and I don't remember where I found > this command but

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> No need to. etcupdate should merge back local changes and shout if it > can't. > So I run these commands? rm -fr /usr/src gitup release cd /usr/src make buildworld make buildkernel make installkernel etcupdate -p make installworld etcupdate Or I don't need "etcupdate -p" ? In https://ww

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> On 31 Dec 2020, at 09:50, Helge Oldach wrote: > > Mergemaster is looking for "[$]${ID_TAG}:" (note the colon) which will > break with the git "$FreeBSD$" scheme. This makes autoupdate annoyingly > explicit as local changes to /etc files will no longer be recognized as > "accepted". > > Furt

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

W dniu 31.12.2020 o 08:50, Helge Oldach pisze: Warner Losh wrote on Wed, 23 Dec 2020 17:58:10 +0100 (CET): On Wed, Dec 23, 2020 at 3:35 AM Marek Zarychta < zarychtam at plan-b.pwste.edu.pl> wrote: In file header, we have now only $FreeBSD$ since svn tags disappeared after the transition. Addin

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

> Greetings, > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. > The short version is that we're switching the version control

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Am 23.12.20 um 21:55 schrieb Ulrich Spörlein: > On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote: >> On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: >>> On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: >>> > The FreeBSD project will be moving it's source repo from

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Wed, 2020-12-23 at 12:19:47 -0800, John Kennedy wrote: On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Mon, Dec 21, 2020 at 12:47:38PM -0800, John Kennedy wrote: > On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > > The FreeBSD project will be moving it's source repo from subversion to git > > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > > repo will mo

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Renato Botelho wrote: > If you want to switch to a different already existing branch, as svn switch > does, you should look at git-checkout. > > It can be a bit expensive due to the size of src repository so if you do work > on multiple branches too often you can improve it using git-worktree.

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Warner Losh wrote: > On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm wrote: >> With svn I used: >>svn switch svn://svn.freebsd.org/base/stable/NEW /usr/src >> >> For git I found: >>git branch -m stable/OLD stable/NEW >>or >>git branch -M stable/OLD stable/NEW > >

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 12/23/2020 12:01, Warner Losh wrote: On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm wrote: Hi, Warner Losh wrote: The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. First of all I'd like to thank all those involved in this for their

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Wed, Dec 23, 2020 at 7:32 AM Michael Grimm wrote: > Hi, > > Warner Losh wrote: > > > The FreeBSD project will be moving it's source repo from subversion to > git > > starting this this weekend. > > First of all I'd like to thank all those involved in this for their > efforts. > > Following >

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Wed, Dec 23, 2020 at 3:35 AM Marek Zarychta < zarych...@plan-b.pwste.edu.pl> wrote: > W dniu 17.12.2020 o 01:46, Warner Losh pisze: > > Greetings, > > > > The FreeBSD project will be moving it's source repo from subversion to > git > > starting this this weekend. The docs repo was moved 2 weeks

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 23.12.2020 18:04, Lev Serebryakov wrote: On 23.12.2020 17:32, Michael Grimm wrote: git-branch(1):     With a -m or -M option, will    be renamed to . If ==     had a corresponding reflog, it is renamed to    match  

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On 23.12.2020 17:32, Michael Grimm wrote: git-branch(1): With a -m or -M option, will be renamed to . If == had a corresponding reflog, it is renamed to match , and a reflog entry is created to remembe

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

Hi, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. First of all I'd like to thank all those involved in this for their efforts. Following https://github.com/bsdimp/freebsd-git-docs/blob/main/mini-primer.md form yo

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

W dniu 17.12.2020 o 01:46, Warner Losh pisze: > Greetings, > > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. > > The short ver

Re: HEADS UP: FreeBSD src repo transitioning to git this weekend

On Wed, Dec 16, 2020 at 05:46:35PM -0700, Warner Losh wrote: > The FreeBSD project will be moving it's source repo from subversion to git > starting this this weekend. The docs repo was moved 2 weeks ago. The ports > repo will move at the end of March, 2021 due to timing issues. ... I filed Bug

HEADS UP: FreeBSD src repo transitioning to git this weekend

Greetings, The FreeBSD project will be moving it's source repo from subversion to git starting this this weekend. The docs repo was moved 2 weeks ago. The ports repo will move at the end of March, 2021 due to timing issues. The short version is that we're switching the version control we're using

HEADS UP: coming changes to a devd event

e for ACPI. We don't really document either (until recently), but use the ACPI one in the default devd.conf script. I'm not changing that at all since it doesn't need adjustment. This is a heads up that the other one is changing from system=kern to system=kernel to be more consistent

Heads up for LinuxKPI updates to 12-STABLE

Hi As with recent 13-CURRENT, we're pushing some updates that might break build of drm modules temporarily on 12-STABLE. One of those changes is moving lindebugfs.ko from ports to base. If you're building your kernel with MODULES_OVERRIDE, don't forget to include it since it is required by drm dri

HEADS-UP: em users

Please note the commit below, in particular the UPDATING entry. In short, if you use em ix ixv ixl iavf vmx drivers and compile them into kernel statically, you need to add device iflib to your configs. Standard in-tree configs were updated, so if you do e.g. 'include GENERIC' you do not need t

Re: HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE

On Sun, Dec 16, 2018 at 11:44 AM Kurt Jaeger wrote: > Will CUBIC be used if the system is running 12.0, or does it only happen > if one actively configures the use of the algorithm ? > > Can the use be detected somehow ? > This only happens if someone explicitly configured the use of the alterna

HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE

Hi all: Just a heads-up for those beginning to test or use FreeBSD 12.0-RELEASE or 12/STABLE, the alternate TCP congestion control algorithm CUBIC (cc_cubic) is currently broken and causes complete stalls of certain network traffic (e.g., rsync, git checkouts, etc.), as well as what appears to

Re: Heads up: OFED build by default

OFED in head lead to the following in order for ci.freebsd.org's FreeBSD-head-amd64-gcc builds to not fail/stop in all_subdir_lib/ofed : Author: jhb Date: Mon Aug 6 23:51:08 2018 New Revision: 337399 URL: https://svnweb.freebsd.org/changeset/base/337399 Log: Make the system C11 atomics heade

Heads up: OFED build by default

I am going to merge revisions r336568, r336569, and r336570 from HEAD to stable/11. They enable the build of the OFED libraries by default, and move the build of most of the utilities under the WITH_OFED_EXTRA knob. Also as a minor fix, since libpcap lives in /lib and depends on two OFED libraries,

HEADS-UP: Deprecation of legacy (v3) password database support

FreeBSD password databases (/etc/pwd.db, /etc/spwd.db) can contain records in one or both of two versions: * v3, a legacy architecture-dependent format * v4, the current architecture- and endian-independent format When v4 support was added in 2003 (r113596) pwd_mkdb emitted both v3 and v4 record

HEADS-UP: 11.2-RELEASE cycle starting in one month

[Several vendor contacts in BCC.] For those that did not notice the website update adding the 11.2-RELEASE cycle schedule, I apologize for sending this to public lists this late. I thought I had done this, but apparently not. The 11.2-RELEASE release cycle will begin April 20, 2018. The schedule

Re: [HEADS UP] - OFED/RDMA stack update

Behalf Of Navdeep Parhar > Sent: Tuesday, March 20, 2018 10:08 PM > To: Hans Petter Selasky ; Konstantin Belousov > ; 'freebsd-infinib...@freebsd.org' > ; freebsd-drivers > ; Meny Yossefi ; > 'FreeBSD-stable@FreeBSD.org' ; freebsd-arch > > Subjec

RE: [HEADS UP] - OFED/RDMA stack update

018 10:08 PM To: Hans Petter Selasky ; Konstantin Belousov ; 'freebsd-infinib...@freebsd.org' ; freebsd-drivers ; Meny Yossefi ; 'FreeBSD-stable@FreeBSD.org' ; freebsd-arch Subject: Re: [HEADS UP] - OFED/RDMA stack update On 03/17/2018 13:03, Hans Petter Selasky wrote: > O

Re: [HEADS UP] - OFED/RDMA stack update

On 03/20/18 21:07, Navdeep Parhar wrote: And what about the cxgb breakage? Is there any simple way to make an old style driver work with the new stack? T3 iw_cxgb in head was retired before the ofed overhaul. Hi, The most simple way is to pull this driver from Linux 4.9, including libcxgb f

Re: [HEADS UP] - OFED/RDMA stack update

On 03/17/2018 13:03, Hans Petter Selasky wrote: > On 03/17/18 20:52, Navdeep Parhar wrote: >> Hold your horses.  Do you have confirmation from the affected party that >> the shims are adequate for them?  I have been waiting for that before >> looking at this branch. > > Hi Navdeep, > > Mellanox h

Re: [HEADS UP] - OFED/RDMA stack update

On Sat, Mar 17, 2018 at 09:03:40PM +0100, Hans Petter Selasky wrote: > On 03/17/18 20:52, Navdeep Parhar wrote: > >Hold your horses. Do you have confirmation from the affected party that > >the shims are adequate for them? I have been waiting for that before > >looking at this branch. > > Hi Nav

Re: [HEADS UP] - OFED/RDMA stack update

On 03/17/18 20:52, Navdeep Parhar wrote: Hold your horses. Do you have confirmation from the affected party that the shims are adequate for them? I have been waiting for that before looking at this branch. Hi Navdeep, Mellanox has received an API list from at least one party, and has taken

Re: [HEADS UP] - OFED/RDMA stack update

Hold your horses. Do you have confirmation from the affected party that the shims are adequate for them? I have been waiting for that before looking at this branch. Is the iw_cxgbe breakage a simple merge conflict as previously discussed or do the shims require driver changes? If they don't the

Re: [HEADS UP] - OFED/RDMA stack update

Hi, The bsd_rdma_4_9_stable_11 projects branch is close to being merged into FreeBSD 11-stable. Mellanox plans to merge no later than 12:00 CEST TUE 20th of March 2018, unless objections are received. A compatibility header file has been created, ib_verbs_compat.h, which offers full source c

Re: [HEADS UP] - OFED/RDMA stack update

On Mon, Feb 26, 2018 at 02:21:39PM -0800, Navdeep Parhar wrote: > +freebsd-arch@ > > Hi Meny, > > Can you please post the KPI/KBI analysis that you generated to some > public location and provide a link here? A straight MFC would be a > major break of KPI/KBI in -STABLE and the options we're loo

Re: [HEADS UP] - OFED/RDMA stack update

ies > > > -Original Message- > From: Meny Yossefi > Sent: Monday, November 13, 2017 11:09 AM > To: 'freebsd-infinib...@freebsd.org' ; > 'freebsd-curr...@freebsd.org' > Cc: freebsd-drivers > Subject: [HEADS UP] - OFED/RDMA stack update

RE: [HEADS UP] - OFED/RDMA stack update

d-curr...@freebsd.org' Cc: freebsd-drivers Subject: [HEADS UP] - OFED/RDMA stack update Hi, This is to inform you that by end of this week we plan to merge the OFED/RDMA stack update from the project - 'bsd_rdma_4_9' into 12-CURRENT. The update aligns the OFED common code and

RE: [HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

No, interface names will remain as is. -Meny From: owner-freebsd-stable@freebsd.orgOn Behalf OfWilhelm Schuster Sent: Monday, February 12, 2018 6:02:11 PM (UTC+00:00) Monrovia, Reykjavik To: freebsd-stable@freebsd.org Subject: Re: [HEADS UP] Mellanox&#

Re: [HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

On 2018-02-12 12:55, Hans Petter Selasky wrote: > Hi, > > The change will happen this week. > This is part of ongoing work in FreeBSD 11-stable. > > Make sure to update your /boot/loader.conf by adding > mlx4en_load="YES" if you are using the mlxen.ko kernel modules. Does that mean, that interfa

[HEADS UP] Mellanox's mlxen.ko will be renamed into mlx4en.ko for 11-stable

Hi, The change will happen this week. This is part of ongoing work in FreeBSD 11-stable. Make sure to update your /boot/loader.conf by adding mlx4en_load="YES" if you are using the mlxen.ko kernel modules. --HPS ___ freebsd-stable@freebsd.org mailing

HEADS UP: Do not upgrade EC2 instances from 10.x to 11.x yet

[Apologies if anyone gets this twice; the first copy I sent seems to have been eaten by a mail server somewhere.] We've identified a bug in the loader(8) in 11.0-RELEASE (to be precise, FreeBSD 11 after April 6th) which results in it attempting to read past the end of the disk if the last partitio

RE: [REVISED] [HEADS-UP] 11.0-RELEASE status update

Will final 11.0-RELEASE include fixes related to broken Hyper-V compatibility? 11.0-RC2, 11.0-RC3 and non-final 11.0-RELEASE failed to install on Hyper-V 2012 R2 with all current updates. storvsc0: on vmbus0 (probe0:blkvsc0:0:0:0): storvsc scsi_status = 2 (probe0:blkvsc0:0:1:1): invalid LUN 1 ...

[REVISED] [HEADS-UP] 11.0-RELEASE status update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: [Corrected the date.] Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republish

[HEADS-UP] 11.0-RELEASE status update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear FreeBSD Community: Although the FreeBSD 11.0-RELEASE has not yet been officially announced, many have found images on the Project FTP mirrors. However, please be aware the final 11.0-RELEASE will be rebuilt and republished on the Project mirro

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

On 2016-08-08, Devin Teske wrote: > Which would you use? Ed25519. > Or perhaps RSA? (as des@ recommends) RSA if you need compatibility with servers or other clients that don't know Ed25519. That's why ssh-keygen, alas, still defaults to RSA. -- Christian "naddy" Weisgerber

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

_cryptography#cite_note-31 >> <https://en.wikipedia.org/wiki/Elliptic_curve_cryptography#cite_note-31>> >> suggesting a return to encryption based on non-elliptic-curve groups. >> "" >> Or perhaps RSA? (as des@ recommends) >> (not necessarily to Gle

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

hy#cite_note-31> suggesting a return to encryption based on non-elliptic-curve groups. "" Or perhaps RSA? (as des@ recommends) (not necessarily to Glen but anyone that wants to answer) -- Devin On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SH

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

gt; > suggesting a return to encryption based on non-elliptic-curve groups. "" > > Or perhaps RSA? (as des@ recommends) > > (not necessarily to Glen but anyone that wants to answer) > -- > Devin > > >> On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: >>

Re: [FreeBSD-Announce] HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

ly to Glen but anyone that wants to answer) -- Devin > On Aug 4, 2016, at 6:59 PM, Glen Barber wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (

Re: HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

On Fri, Aug 05, 2016 at 01:59:18AM +, Glen Barber wrote: > This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, > and will be deprecated effective 11.0-RELEASE (and preceeding RCs). > Stupid editor mistake. OpenSSH DSA keys are deprecated upstream. Sorr

HEADS-UP: OpenSSH DSA keys are deprecated in 12.0 and 11.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is a heads-up that OpenSSH keys are deprecated upstream by OpenSSH, and will be deprecated effective 11.0-RELEASE (and preceeding RCs). Please see r303716 for details on the relevant commit, but upstream no longer considers them secure

[FIXED] Re: [HEADS UP] "options ZFS" broken on stable/10; please use zfs(4) module for the time being

Hi again, I’m sending out a follow up email noting that MFCing the changes in stable/10@r293121 has fixed this issue. I apologize for the inconvenience it caused. Thank you! -NGie ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd

Re: [HEADS UP] "options ZFS" broken on stable/10; please use zfs(4) module for the time being

> On Jan 3, 2016, at 06:42, Mariusz Zaborski wrote: > > Hi, > > Did you merge the changes made in ./sys/cddl/compat/opensolaris/sys/nvpair.h > and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201356 ? Those twos > should repair the problem. > > Thanks for doing all the work around mergi

Re: [HEADS UP] "options ZFS" broken on stable/10; please use zfs(4) module for the time being

Hi, Did you merge the changes made in ./sys/cddl/compat/opensolaris/sys/nvpair.h and https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201356 ? Those twos should repair the problem. Thanks for doing all the work around merging it. Cheers, Mariusz On 3 January 2016 at 05:32, NGie Cooper wrote:

[HEADS UP] "options ZFS" broken on stable/10; please use zfs(4) module for the time being

Hi all, Marcel brought to my attention that “options ZFS” is currently broken on stable/10 as of r292973. It builds on head however. I’m trying to determine what MFCs are missing in order to fix stable/10. I’ll send out an update email once I figure it out and fix the issue. I ap

Re: HEADS-UP: PCI ID driver conflict with ahd(4) and pms(4)

On Fri, Jul 31, 2015 at 01:48:32AM +, Glen Barber wrote: > The new driver for PMC Sierra SAS/SATA HBAs does not properly validate > that both the vendor ID and device ID of some storage device drivers. > At present, we know there is a conflict with ahd(4), it is possible > there are more. > T

Re: HEADS-UP: PCI ID driver conflict with ahd(4) and pms(4)

On Fri, Jul 31, 2015 at 09:20:49AM +0200, Kurt Jaeger wrote: > Hi! > > > prior to the releng/10.2 branch), please exercise caution when upgrading > > to the latest stable/10 or releng/10.2 if your storage controller > > matches any of the following PCI device IDs: > > Which field of pciconf -lvb

Re: HEADS-UP: PCI ID driver conflict with ahd(4) and pms(4)

Hi! > prior to the releng/10.2 branch), please exercise caution when upgrading > to the latest stable/10 or releng/10.2 if your storage controller > matches any of the following PCI device IDs: Which field of pciconf -lvb or sysctl output needs to be compared ? Is it the device= field ? dev.ata

HEADS-UP: PCI ID driver conflict with ahd(4) and pms(4)

The new driver for PMC Sierra SAS/SATA HBAs does not properly validate that both the vendor ID and device ID of some storage device drivers. At present, we know there is a conflict with ahd(4), it is possible there are more. The issue was reported on the -current@ mailing list in this thread: htt

Heads-up: Change to 10.2-RELEASE schedule

At this time, re@ feels it is not necessary to have 10.2-BETA3 as part of the release cycle, so the next 10.2 builds (planned to start in just under 9 hours) will be 10.2-RC1. The 10.2-RELEASE schedule has been updated on the FreeBSD.org website to reflect this change, and is also included in this

Heads-Up: stable/10 freeze in effect

For those not subscribed to svn commit email, the code freeze for the upcoming 10.2-RELEASE is now in effect. The full schedule as it stands now is available here: https://www.FreeBSD.org/releases/10.2R/schedule.html If you are aware of an issue that affects stable/10 that does not have a co

HEADS-UP: system deadlock issues when rebooting after updating or upgrading to 10.1-RELEASE

this issue manifests as an unresponsive system after issuing a reboot(8) (or in some cases, a shutdown(8)) command, after the "All buffers synced." message is displayed, and this heads-up is addressing only those cases (or potential cases). All other filesystem related should be reported in a s

Re: [HEADS UP] change in devfs path matching logic

on 29/08/2013 16:03 Toomas Aas said the following: > Hello! > > On Thu, 29 Aug 2013 Jase Thew wrote: > >> On 29/08/2013 11:24, Andriy Gapon wrote: >>> on 29/08/2013 10:47 Andriy Gapon said the following: It looks like I should have done more investigation on the state of devfs in

Re: [HEADS UP] change in devfs path matching logic

Hello! On Thu, 29 Aug 2013 Jase Thew wrote: On 29/08/2013 11:24, Andriy Gapon wrote: on 29/08/2013 10:47 Andriy Gapon said the following: It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits

Re: [HEADS UP] change in devfs path matching logic

On 29/08/2013 11:24, Andriy Gapon wrote: on 29/08/2013 10:47 Andriy Gapon said the following: It looks like I should have done more investigation on the state of devfs in stable/8 before MFC-ing the change. There are several earlier big commits that have not been MFC-ed. So, now I can either re

Re: [HEADS UP] change in devfs path matching logic

On 29/08/2013 11:11, Andriy Gapon wrote: on 29/08/2013 12:07 Jase Thew said the following: After some fiddling about, I've obtained a crashdump of this panic : http://goo.gl/sRXjo4 If you need anything else, please let me know. Obviously, I can't do anything with the vmcore without the match

Re: [HEADS UP] change in devfs path matching logic

on 29/08/2013 10:47 Andriy Gapon said the following: > It looks like I should have done more investigation on the state of devfs in > stable/8 before MFC-ing the change. There are several earlier big commits > that > have not been MFC-ed. > So, now I can either revert the MFC and be done with it.

Re: [HEADS UP] change in devfs path matching logic

on 29/08/2013 12:07 Jase Thew said the following: > After some fiddling about, I've obtained a crashdump of this panic : > > http://goo.gl/sRXjo4 > > If you need anything else, please let me know. Obviously, I can't do anything with the vmcore without the matching kernel (and perhaps modules).

Re: [HEADS UP] change in devfs path matching logic

On 29/08/2013 08:47, Andriy Gapon wrote: on 28/08/2013 20:29 Jase Thew said the following: I'm getting a similar panic with r254986 on stable/8 when starting up jails : Thank you very much for the report. Somehow I missed Toomas'es report on the mailing list. It looks like I should have done

Re: [HEADS UP] change in devfs path matching logic

on 28/08/2013 20:29 Jase Thew said the following: > On 24/08/2013 21:03, Toomas Aas wrote: >> Hello! >> >> On Fri, 23 Aug 2013 Andriy Gapon wrote: >> >>> >>> This change is about to be MFC-ed. >>> >>> on 26/07/2013 17:39 Andriy Gapon said the following: I have just committed a significan

Re: [HEADS UP] change in devfs path matching logic

On 24/08/2013 21:03, Toomas Aas wrote: Hello! On Fri, 23 Aug 2013 Andriy Gapon wrote: This change is about to be MFC-ed. on 26/07/2013 17:39 Andriy Gapon said the following: I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/25

Re: [HEADS UP] change in devfs path matching logic

Hello! On Fri, 23 Aug 2013 Andriy Gapon wrote: This change is about to be MFC-ed. on 26/07/2013 17:39 Andriy Gapon said the following: I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 I just rebuilt my 8-STABLE i386 s

Re: [HEADS UP] change in devfs path matching logic

On Fri, 23 Aug 2013 17:06:51 +0300 Andriy Gapon wrote: > > This change is about to be MFC-ed. > > on 26/07/2013 17:39 Andriy Gapon said the following: > > > > I have just committed a significant change to devfs path matching > > logic http://svnweb.freebsd.org/changeset/base/253677 > > > > Ja

Re: [HEADS UP] change in devfs path matching logic

This change is about to be MFC-ed. on 26/07/2013 17:39 Andriy Gapon said the following: > > I have just committed a significant change to devfs path matching logic > http://svnweb.freebsd.org/changeset/base/253677 > > Jaakko Heinonen (jh@) has full credit for the code while I have full > respon

Re: [HEADS UP] change in devfs path matching logic

on 26/07/2013 17:39 Andriy Gapon said the following: > Please note that nothing changes with respect to matching simple paths like > /dev/something. I must add: and thus rules in etc/defaults/devfs.rules should not be affected except for their unintended side-effects. -- Andriy Gapon ___

[HEADS UP] change in devfs path matching logic

I have just committed a significant change to devfs path matching logic http://svnweb.freebsd.org/changeset/base/253677 Jaakko Heinonen (jh@) has full credit for the code while I have full responsibility for any consequences of the commit. Before this change the logic of matching the devfs paths

Heads-Up: Schedule for 9.2-RELEASE

It was brought to our attention that this was not announced on -stable before now. That is my fault. This is a reminder that the Code Slush (aka "Feature Freeze") for 9.2-RELEASE is in effect. The Code Slush is different from the Code Freeze in that you do not need to ask re@ permission for ever

[HEADS UP] New pkgng git location

Pkg has moved from http://github.com/pkgng/pkgng to http://github.com/freebsd/pkg Please update any links or git checkouts you have. You can update your git checkout with: > git remote set-url origin git://github.com/freebsd/pkg.git pkgng/pkgng -- Regards, Bryan Drewery signature.asc Descri

Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1

On Wed, Mar 20, 2013 at 04:20:02PM +0100, Matthias Gamsjager wrote: > > Due to the security incident, there are still no official FreeBSD > > packages. > > Do you know what the status is on that issue? I'd also like to find out what the status of this is. The packages at: ftp://ftp.freebsd.org

Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1

> Due to the security incident, there are still no official FreeBSD > packages. > Do you know what the status is on that issue? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send an

Re: [HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1

On Thu, 14 Mar 2013 06:29:21 -0500, Bryan Drewery wrote: > > If you are building your own packages and managed to get onto 1.0.9 you > can upgrade to 1.0.9_1 as follows: > > # cp /usr/local/sbin/pkgs-static . > # pkg delete -f pkg # ./pkg-static add URL-TO-YOUR-PACKAGESITE/All/ pkg-1.0.9_1.txz >

[HEADS UP] pkgng binary packages regression in 1.0.9. Fixed in 1.0.9_1

This only affects binary-packages-only users. pkg 1.0.9 had a regression with 'pkg update' that will prevent updating your repository. Please skip this version and use 1.0.9_1. This version was only in ports for 7 hours. Due to the security incident, there are still no official FreeBSD packages.

HEADS UP: FreeBSD 7.3 EoL coming soon

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Everyone, On March 31st, FreeBSD 7.3 will reach its End of Life and will no longer be supported by the FreeBSD Security Team. Users of FreeBSD 7.3 are strongly encouraged to upgrade to FreeBSD 7.4, FreeBSD 8.1, FreeBSD 8.2, or FreeBSD 9.0 befor

HEADS UP: Xen merge coming to stable/8

Hi folks, I'm planning to merge almost all of the Xen changes from FreeBSD/head into stable/8 soon. This should bring more features, stability, etc. I've attached what will be the commit message. If there are any objections, speak now. Ken -- Kenneth Merry k...@freebsd.org MFC r215818, r21640

Re: HEADS UP: ZFS v28 merged to 8-STABLE

On Jun 10, 2011, at 17:24, Bob Friesenhahn wrote: > Dedup can require a huge amount of RAM, or a dedicated L2ARC SSD, depending > on the size of your storage. You should not enable it unless you are > prepared for the consequences. Under OpenSolaris, each tracking entry for a deduped block (wh

Re: HEADS UP: ZFS v28 merged to 8-STABLE

On Jun 10, 2011, at 17:25, Volodymyr Kostyrko wrote: > Am I missing something? How about using fletcher[24] for dedup? Fletcher is fairly weak as things go, and so even though two checksums are the same, there's a decent chance that the data is actually different. At least with recent releases

Re: HEADS UP: ZFS v28 merged to 8-STABLE

06.06.2011 13:53, Martin Matuska написав(ла): Hi, I have merged ZFS version 28 to 8-STABLE (revision 222741) New major features: - data deduplication Am I missing something? How about using fletcher[24] for dedup? -- Sphinx of black quartz judge my vow. _

Re: HEADS UP: ZFS v28 merged to 8-STABLE

On Fri, 10 Jun 2011, Jeremy Chadwick wrote: We tried using dedup on one of our systems, but within 10-15 minutes turned it off. I believe the added CPU overhead of dedup was causing the system to act "bursty" in other non-ZFS-related tasks; e.g. turn on dedup, then in a SSH window hold down the

Re: HEADS UP: ZFS v28 merged to 8-STABLE

On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: > I have merged ZFS version 28 to 8-STABLE (revision 222741) Follow-up, since we're gradually upgrading our ZFS-based RELENG_8 servers to ZFSv28. Committers/those involved should see my very last paragraph. First, server upgrades:

Re: HEADS UP: ZFS v28 merged to 8-STABLE

a compatibility layer so that in the update phase >> most functionality of the new zfs binaries can be used with the old >> kernel module and old zfs binaries with the new kernel module. > > Beware that the compatibility layer is known broken on big-endian > architect

Re: HEADS UP: ZFS v28 merged to 8-STABLE

compatibility layer so that in the update phase >> >> most functionality of the new zfs binaries can be used with the old >> >> kernel module and old zfs binaries with the new kernel module. >> > >> > Beware that the compatibility layer is known broken on big-e

Re: HEADS UP: ZFS v28 merged to 8-STABLE

gt; kernel module and old zfs binaries with the new kernel module. > > > > Beware that the compatibility layer is known broken on big-endian > > architectures, i.e. powerpc64 and sparc64. > > Thanks for the heads-up! I was just about to update a couple of sparc64 > mach

Re: HEADS UP: ZFS v28 merged to 8-STABLE

On Mon, Jun 06, 2011 at 12:53:11PM +0200, Martin Matuska wrote: > Hi, > > I have merged ZFS version 28 to 8-STABLE (revision 222741) > > New major features: > > - data deduplication > - triple parity RAIDZ (RAIDZ3) > - zfs diff > - zpool split > - snapshot holds > - zpool import -F. Allows to re

Re: HEADS UP: ZFS v28 merged to 8-STABLE

Thanks. Everything works fine. 2011/6/6 Lystopad Olexandr : >  Hello, Martin Matuska! > > On Mon, Jun 06, 2011 at 12:53:11PM +0200 > m...@freebsd.org wrote about "HEADS UP: ZFS v28 merged to 8-STABLE": >> Hi, >> >> I have merged ZFS version 28 to 8-STAB

  1   2   3   4   5   6   7   8   9   10   >