rfc: should extant TLS connections be closed when a CRL is updated?
Hi, The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated CRL (Certificate Revocation List) when a SIGHUP is posted to it. However, it does not SSL_shutdown()/close() extant TCP connections using TLS. (Those would only be closed if the daemon is restarted.) I am now thinking that, maybe, an SSL_shutdown()/close() should be done on all extant TCP connections using NFS over TLS when an updated CRL is loaded, since a connection might have used a revoked certificate for its handshake. What do others think? Thanks, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
suspend/resume versus OpenZFS on USB
This week for the first time I toyed with OpenZFS on a USB device: a mobile hard disk drive connected to the dock of an HP EliteBook 8570p. A light test, with the pool imported but not writing to the dataset at suspend time. At resume time (22:31), the device was still physically connected but the pool suffered an I/O failure (and the keyboard and trackball on USB were unusable). Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11239]: vdev state changed, pool_guid=$8076233369858608335 vdev_guid=$13893535540375859253 Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11243]: pool I/O failure, zpool=$Transcend error=$28 Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11247]: pool I/O failure, zpool=$Transcend error=$28 Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11251]: pool I/O failure, zpool=$Transcend error=$28 Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11255]: pool I/O failure, zpool=$Transcend error=$28 Sep 3 22:31:03 momh167-gjp4-8570p ZFS[11259]: catastrophic pool I/O failure, zpool=$Transcend I cleared pool errors (after which the keyboard and trackball became usable), exported the pool, physically disconnected the drive, restarted the OS, reconnected, imported and – luckily – cleared the remaining metadata errors through a scrub. Please, might something be done to improve suspend/resume reliability with storage on USB? Might I/O failures be less likely if I connect the drive to the notebook instead of its dock? TIA More from /var/log/messages at https://pastebin.com/CqRYbFZm Other relevant info below. root@momh167-gjp4-8570p:~ # date ; uptime ; uname -v Thu Sep 3 22:45:07 BST 2020 10:45PM up 6 mins, 6 users, load averages: 0.20, 0.27, 0.13 FreeBSD 13.0-CURRENT #63 r364768: Tue Aug 25 20:08:23 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # zpool status -v pool: copperbowl state: ONLINE status: Some supported features are not enabled on the pool. The pool can still be used, but some features are unavailable. action: Enable all features using 'zpool upgrade'. Once this is done, the pool may no longer be accessible by software that does not support the features. See zpool-features(5) for details. scan: scrub repaired 0B in 01:39:31 with 0 errors on Thu Sep 3 01:12:21 2020 config: NAME STATE READ WRITE CKSUM copperbowl ONLINE 0 0 0 ada0p4.eli ONLINE 0 0 0 errors: No known data errors root@momh167-gjp4-8570p:~ # zpool import Transcend && zfs load-key Transcend/VirtualBox Enter passphrase for 'Transcend/VirtualBox': root@momh167-gjp4-8570p:~ # zpool status -v Transcend pool: Transcend state: ONLINE status: One or more devices has experienced an error resulting in data corruption. Applications may be affected. action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: https://zfsonlinux.org/msg/ZFS-8000-8A scan: scrub repaired 0B in 00:15:33 with 0 errors on Wed Sep 2 22:38:56 2020 config: NAME STATE READ WRITE CKSUM Transcend ONLINE 0 0 0 da0p1 ONLINE 0 0 0 errors: Permanent errors have been detected in the following files: :<0x0> :<0x3d> root@momh167-gjp4-8570p:~ # zpool scrub Transcend root@momh167-gjp4-8570p:~ # zfs version zfs-0.8.0-1 zfs-kmod-0.8.0-1 root@momh167-gjp4-8570p:~ # zpool status -v Transcend pool: Transcend state: ONLINE scan: scrub repaired 0B in 00:17:53 with 0 errors on Thu Sep 3 23:03:57 2020 config: NAME STATE READ WRITE CKSUM Transcend ONLINE 0 0 0 da0p1 ONLINE 0 0 0 errors: No known data errors root@momh167-gjp4-8570p:~ # zfs get compression,compressratio,encryption,used,referenced,mountpoint Transcend Transcend/VirtualBox NAME PROPERTY VALUE SOURCE Transcend compression zstd local Transcend compressratio 1.70x - Transcend encryption off default Transcend used 76.4G - Transcend referenced 76.4G - Transcend mountpoint /Volumes/t500 local Transcend/VirtualBox compression zstd inherited from Transcend Transcend/VirtualBox compressratio 1.00x - Transcend/VirtualBox encryption aes-256-gcm - Transcend/VirtualBox used 200K - Transcend/VirtualBox referenced 200K - Transcend/VirtualBox mountpoint /Volumes/t500/VirtualBox inherited from Transcend root@momh167-gjp4-8570p:~ # ls -hl /Volumes/t500/VirtualBox/Windows/Windows.vdi -rw--- 1 grahamperrin grahamperrin 69G Sep 3 16:58 /Volumes/t500/VirtualBox/Windows/Windows.vdi root@momh167-gjp4-8570p:~ # du
Re: Plans for git
On Thu, Sep 3, 2020 at 1:32 PM Chris wrote: > On 2020-09-03 11:33, Kristof Provost wrote: > > On 3 Sep 2020, at 19:56, Chris wrote: > >> Why was the intention to switch NOT announced as such MUCH sooner? > >> > > There was discussion about a possible switch to git on the freebsd-git > > mailing > > list as early as February 2017: > > > https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html > > > > Ed gave a talk about FreeBSD and git back in 2018: > > https://www.youtube.com/watch?v=G8wQ88d85s4 > > > > The Git Transition Working group was mentioned in the quarterly status > > reports a > > year ago: > https://www.freebsd.org/news/status/report-2019-07-2019-09.html > > and > > https://www.freebsd.org/news/status/report-2019-04-2019-06.html > It appears to me that the references you make here all allude to > _investigation_ > of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. > IMHO a change as significant as this, which will require tossing years of > tooling > out the window, and an untold amount of _re_tooling. Should have created an > announcement at _least_ as significant as a new release gets on the mailing > lists. > Yes. We've been working on this for years. We've been working on the retooling in earnest for the last 6 months. We didn't make an announcement because we wanted to have most of the pieces in place before we did that. We've been doing the multi-year process for multiple years now. I'll also point out that only the 'git' people showed. A number of other ideas were suggested, but nothing else was stood up in a serious way (hg came the closest to setting up an exporter). Since there was really no alternatives being proposed to git, the process was less visible than if we'd had to have had a hg vs git bake off. One step has lead to the next, with much status reporting done for years. Subversion, btw, is not viable in the long run. The Apache foundation has moved all its projects from svn to git. The velocity of features with svn has diminished, and the number of CI/CT/etc tool sets that supported svn well has been dropping over time. It's also been identified as a barrier to entry for the project. Sure, some people climb the learning curve to learn and understand it, but our survey data has shown that for every one that did take the time, many others did not and simply didn't contribute. All of these issues have been discussed at length at conferences for the last 5 years at least, with increasing levels of sophistication. Had there been a BSDcan this year, I'd hoped to do a talk / BOF on this to help socialize the ideas and to get people's feedback in real time (rather than the slow and difficult process of getting it just in email). We've also talked about this in the BSD office hours and core election forums over the past year. We've been rolling out the beta git repo now for 3 months. People have found issues and we've been correcting them. We've heard from people that their automated tooling needs a bit of transition time, so we'll be exporting the stable/11 and stable/12 branches back into subversion (and the release branches) after the conversion for the life of those branches, though we don't plan on doing it for the current nor stable/13 branches (due to the inefficiencies of git-svn, we need separate trees for each, and each tree takes over a day to setup). We know we need some better docs (we have some decent preliminary ones, but there's some missing bits in them, and they are too long for more casual users). We need to spell out different commit policies, how we're going to have to shift our "MFC" terminology because that's very CVS/SVN centric (in git a merge means a more specific thing than it does in svn. A cherry-pick in git is also called a merge in svn, for example). We need to document to the developers how to make the shift (this doc is mostly complete and was posted earlier, though it could use some TLC). We'd hoped to have the documents done, the policies written and vetted and have a good test system before making an announcement. The last thing I wanted was to make a big announcement, only to fail to deliver. And since each step of the process followed naturally, there wasn't a clear A/B decision point where an announcement could have been generated. We were getting close to publishing the final schedule when this thread popped up, though, since it is finally feeling like it will be real soon. I also had hoped to refine things so that existing developers and users would have only minor disruption at the cut over because things were well documented. And once we have all the basics of phase 1 (which is just going to be 'do FreeBSD's current workflow in git, making minimal changes initially), we'll start on the refinements to the workflow that will help improve the quality of code, make it easier to integrate changes, etc. There's quite the diversity of views and opinions in the larger open source world on what best practices
Re: Plans for git
On 2020-09-03 11:33, Kristof Provost wrote: On 3 Sep 2020, at 19:56, Chris wrote: Why was the intention to switch NOT announced as such MUCH sooner? There was discussion about a possible switch to git on the freebsd-git mailing list as early as February 2017: https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html Ed gave a talk about FreeBSD and git back in 2018: https://www.youtube.com/watch?v=G8wQ88d85s4 The Git Transition Working group was mentioned in the quarterly status reports a year ago: https://www.freebsd.org/news/status/report-2019-07-2019-09.html and https://www.freebsd.org/news/status/report-2019-04-2019-06.html It appears to me that the references you make here all allude to _investigation_ of a _possibility_ as opposed to a _likelihood_, or an _inevitable_. IMHO a change as significant as this, which will require tossing years of tooling out the window, and an untold amount of _re_tooling. Should have created an announcement at _least_ as significant as a new release gets on the mailing lists. Thanks for taking the time to reply, Kristof. Regards, Kristof --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Please check the current beta git conversions
For one: thanks all, it now works! Steffen Nurpmeso wrote in <20200903151825.g_rv9%stef...@sdaoden.eu>: |Renato Botelho wrote in | : ||On 02/09/20 20:20, Steffen Nurpmeso wrote: ||> Ed Maste wrote in ||> : ||> ||> I tried simply updating my github clone by switching ||> ||>url = https://cgit-beta.freebsd.org/src.git ||>#url = https://github.com/freebsd/freebsd.git ||> ||> and whereas ls-remote worked fine fetch -v --dry-run aborted as ||> well as normal fetch, after dumping dozens of POSTs ||> ||>POST git-upload-pack (gzip 1472 to 804 bytes) ||>... ||>POST git-upload-pack (gzip 976722 to 483608 bytes) ||>POST git-upload-pack (chunked) ||>error: RPC failed; HTTP 413 curl 22 The requested URL returned \ ||>error: 413 ||>fatal: the remote end hung up unexpectedly ||> ||> Maybe clone from scratch instead, but mysterious it is? ||> Good night, and Ciao from Germany, || ||github and cgit-beta repositories are not the same. Commit hashes won't ||match so you cannot simply change the URL. | |Yes i know that, but most of the blobs are of course the same, no? Having said that, i switched to git in i think 2011 and never ever read anything about the protocol or almost anything else ever since ... Except that rev-parse changed its output order which broke a (primitive) script (git-topic-creator) of mine, but that was in 2013. So: it may well be that git does not really take care for finding local data blobs unless there are commits with shared ancestors or what (the two repositories anyway show up as "warning: no common commits"). Let's see where this ends... That reminds me of the fossil/venti storage system of Plan9, with the short-time local cache and the hash-based backing store, which just stores digested blocks. There was a graphic which showed how data consumption exploded at the beginning, but the curve went flatter and flatter, and it was explicitly noted that the masses of people in Bell Labs did a lot with multimedia, videos and such. Which i found surprising. Old github pack -r--r- 1 steffen code 1526603739 Aug 2 01:47 pack-92bcd61e50e1a09e27e8aa4a67e0878468f01f79.pack -r--r- 1 steffen code 136779336 Aug 2 01:47 pack-92bcd61e50e1a09e27e8aa4a67e0878468f01f79.idx warning: no common commits remote: Enumerating objects: 920487, done. remote: Counting objects: 100% (920487/920487), done. remote: Compressing objects: 100% (254705/254705), done. remote: Total 4909613 (delta 876272), reused 665791 (delta 665782), pack-reused 3989126 Receiving objects: 100% (4909613/4909613), 1.25 GiB | 396.00 KiB/s, done. Hm. It definetely must have downloaded masses of duplicate data. I must admit, the largest repo which had to be updated very often (despite the borked NetBSD thing on github, years ago) was ghostscript. There i looked, but find it quite different, if i recall correctly. I did not blame git for the mess there. Resolving deltas: 100% (3429285/3429285), done. From https://cgit-beta.freebsd.org/src + 606d234876ce...101374bc1b34 releng/5.5 -> origin/releng/5.5 (forced update) + 2132c100d27f...385a94b8751c releng/6.4 -> origin/releng/6.4 (forced update) + c462a28e0cae...f864cd1bca00 releng/7.4 -> origin/releng/7.4 (forced update) + 3ffe9881628f...b4323ad1fd9f releng/8.4 -> origin/releng/8.4 (forced update) + 34073209c9c9...6845fb3a0339 releng/9.3 -> origin/releng/9.3 (forced update) + 57fbb64699be...c032bc8ca5d4 releng/10.3-> origin/releng/10.4 (forced update) + da2894488950...889f726543f5 releng/11.4-> origin/releng/11.4 (forced update) + e1a11e350964...6fb517db6dea releng/12.1-> origin/releng/12.1 (forced update) + a9ff142f7dcc...6a26cffb5427 stable/12 -> origin/stable/12 (forced update) + c660a28c68a8...88fc88f77538 main -> origin/main (forced update) A masterpiece! + 16be7204f705...ef7e23176ea6 refs/notes/commits -> refs/notes/commits (forced update) * [new tag] release/10.3.0 -> release/10.3.0 * [new tag] release/11.4.0 -> release/11.4.0 * [new tag] release/12.1.0 -> release/12.1.0 * [new tag] release/5.5.0 -> release/5.5.0 * [new tag] release/6.4.0 -> release/6.4.0 * [new tag] release/7.4.0 -> release/7.4.0 * [new tag] release/8.1.0 -> release/8.1.0 - [new tag] release/8.4.0 -> release/8.4.0 - [new tag] release/9.3.0 -> release/9.3.0 -r--r- 1 steffen code 1344409784 Sep 3 20:44 pack-0f656d44c6c8301d98ee51b69c3aacd8db9255ac.pack -r--r- 1 steffen code 137470236 Sep 3 20:44 pack-0f656d44c6c8301d98ee51b69c3aacd8db9255ac.idx I then garbage collected aggressively and pruned the two into -r--r- 1 steffen
Re: Plans for git (was: Please check the current beta git conversions)
On Thu, Sep 03, 2020 at 11:40:17AM -0700, Rodney W. Grimes wrote: > To the contrary 5 years ago the project on @developers basically > ran off one of the committers over the very idea of using git > for the project. It was shortly after I returned, so I find it > very ironic that now its all "git git git and we being heading > to this for 5 years" Five years ago "all of my friends say that" was given as a fact, when it was actually an anecdote. That was why people (including myself) were opposed to it. Last year FreeBSD took a user survey. That contained data. And AFAIK that was the basis of the decision. Plus, the industry had changed in the ensuing 4 years. mcl ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git (was: Please check the current beta git conversions)
> > > > On Sep 1, 2020, at 10:59 PM, Greg 'groggy' Lehey wrote: > > > > On Tuesday, 1 September 2020 at 13:14:10 -0400, Ed Maste wrote: > >> We've been updating the svn-git converter and pushing out a new > >> converted repo every two weeks, and are now approaching the time where > >> we'd like to commit to the tree generated by the exporter, > >> ... > > > > Somehow I've missed this development. Reading between the lines, it > > seems that we're planning to move from svn to git, but I can't recall > > seeing any announcement on the subject. Can you give some background? > > It would also be nice to find a HOWTO both for the migration and for > > life with git. > > We?ve been talking about the transition for about 5 years now. So far, only > people interested in git have showed up to do any work at all. Subversion has > lost, and even Apache, the main users of it, are moving to git. We started > early in the year with the firm plans and have been working on it since then. > These conversations have happened all over the place, and we?ve been posting > to developers for months now... To the contrary 5 years ago the project on @developers basically ran off one of the committers over the very idea of using git for the project. It was shortly after I returned, so I find it very ironic that now its all "git git git and we being heading to this for 5 years" Would you expect those opposed to this idea to help with it? Really? > There?s some draft guides, but they need work which is on my plate. They are > OK, but have some issues on the more complicated bits. > > Warner -- Rod Grimes rgri...@freebsd.org ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
On 3 Sep 2020, at 19:56, Chris wrote: Why was the intention to switch NOT announced as such MUCH sooner? There was discussion about a possible switch to git on the freebsd-git mailing list as early as February 2017: https://lists.freebsd.org/pipermail/freebsd-git/2017-February/92.html Ed gave a talk about FreeBSD and git back in 2018: https://www.youtube.com/watch?v=G8wQ88d85s4 The Git Transition Working group was mentioned in the quarterly status reports a year ago: https://www.freebsd.org/news/status/report-2019-07-2019-09.html and https://www.freebsd.org/news/status/report-2019-04-2019-06.html Regards, Kristof ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
On 2020-09-03 11:03, Kurt Jaeger wrote: Hi! Why was the intention to switch NOT announced as such MUCH sooner? Because communicating complex issues which might cause conflict and flame wars etc is not easy. Everyone prefers to hack on code, and possibly procrastinates on the hard stuff 8-} And all those that do the really heavy work are very, very short on time and capacity. I commented on both of these in the original post. But you trimmed that out. :-( --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
Hi! > Why was the intention to switch NOT announced as such MUCH sooner? Because communicating complex issues which might cause conflict and flame wars etc is not easy. Everyone prefers to hack on code, and possibly procrastinates on the hard stuff 8-} And all those that do the really heavy work are very, very short on time and capacity. -- p...@opsec.eu+49 171 3101372Now what ? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Plans for git
I've been wanting to comment on the git(1) ==> svn(1) switch for some time now. I feel quite strongly about it, and rightfully so for many reasons. But _because_ I feel so strongly about it. I've refrained from doing so. So as to speak in an objective manner -- I'm not _quite_ there yet. But I want to make a statement I feel could have averted much of the strong feelings expressed regarding this (inevitable) change; Why was the intention to switch NOT announced as such MUCH sooner? I, like perhaps many others, feel blindsided by the change. IMHO having done so, could've solicited some productive input. Rather than reactive commentary. In fact, I'd go so far as to say, it would have garnered additional help for the changes required. That's all I feel I can constructively say ATM. :-) @Ian I'm 60-something. I guess that makes me a dinosaur too. :-) @wlosh Please don't put me in your ~/.ignorelist ~/.killfile ;-) --Chris ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
On Thu, Sep 03, 2020 at 05:33:54PM +0200, Emmanuel Vadot wrote: > > Hello, > > On Thu, 3 Sep 2020 15:02:45 + > Glen Barber wrote: > > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > New FreeBSD development branch installation ISOs and virtual machine > > disk images have been uploaded to the FreeBSD Project mirrors. > > > > NOTE: These are the first snapshots built from the FreeBSD Git sources. > > Also note: The armv6 and armv7 builds failed, and the cause is being > > investigated. > > There is also no embbeded aarch64 image (pine64* rpi3 etc ...), do you > have more info ? > The ports tree failed to mount within the chroot directory. I think I see why, and am testing a fix now. Glen signature.asc Description: PGP signature
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
Am 2020-09-03 17:02, schrieb Glen Barber: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FreeBSD Project mirrors. === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 13.0-CURRENT amd64 o 13.0-CURRENT i386 o 13.0-CURRENT aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD Project mirrors): https://download.freebsd.org/ftp/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Hi, what about adding net/cloud-init to the images so that they can be used out-of-the-box on OpenStack? https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238068 Best Regards Rainer ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: New FreeBSD snapshots available: main (20200903 c122cf32f2a)
c4f4 > sa-east-1 region: ami-0405529811b49b9c2 > ca-central-1 region: ami-0d2cdbbb55b331683 > ap-east-1 region: ami-062a657fbd373cc97 > ap-southeast-1 region: ami-0c4f30d508c70f510 > ap-southeast-2 region: ami-00abe4775d151fb72 > eu-central-1 region: ami-030dc94d2caf60616 > us-east-1 region: ami-0035735483d37330c > us-east-2 region: ami-01fc78890c9d8cf9d > us-west-1 region: ami-014662c19db8b8287 > us-west-2 region: ami-07f9261cecfeaf8f1 > > === Vagrant Images === > > FreeBSD/amd64 images are available on the Hashicorp Atlas site for the > VMWare Desktop and VirtualBox providers, and can be installed by > running: > > % vagrant init freebsd/FreeBSD-13.0-CURRENT > % vagrant up > > == ISO CHECKSUMS == > > o 13.0-CURRENT amd64 GENERIC: > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-bootonly.iso) = > 2361315c75a8d60fcdc57c730192badd830529a0a7384ff5d23954e2c09593633872132981c0afac8b15120b3e1c0f9df93b4e01434b74fa288e35812c322330 > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-bootonly.iso.xz) = > 53349b129ad799e955d1d90ba465280795b656452dd12d46fbb1465f5ea564583d0e5c042407d30418e5602347b119d9e08d2b1a6b688d69484359d5562820e8 > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-disc1.iso) = > 22f92520c7cd3f794e3c69a0b07fe29dd581c81306650b7ca66358e55c22a3a43a3af4f24b612cb96522ce16320b7d252380598744178ae3863f571edf2580cb > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-disc1.iso.xz) = > 26e587bc66b93e438ff9541c19436cfece0d213043a9b34f824cd618e65ab456dae430dacbda7a952a4892190d85218b9ddef298b7f076208f5ee4a23a8167bc > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-memstick.img) = > a6d7f721f204f65391f472eb3c7f79e96cdccc1d767eb0faf6edda4967b6a5fbdf07effaf78c5646ea6b18e6fd0b812f92cd53933764c1b79e84b5e9bf45ea13 > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-memstick.img.xz) = > f03adcf6039ed827876ffb1f914c2d4a145fbb82475aa5fef9f381240678523f9d45b14775f0a1d448b195dfd88e1d071fdcff1216015c7c3905506fab80fc01 > SHA512 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-mini-memstick.img) > = > fd169b9c048ce907d94e64bafe880cbbf9890531a543f3bbd060179ab1f43c3a6deaa81262ea26f83a75a35bc811ec25550cd73b219e3a32bbc44f3e3dcb2d48 > SHA512 > (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-mini-memstick.img.xz) = > 8dbc3f7fbe78667d34418771e182d190a375e10ff15993d9d70eb79141c4907c7425dbfdcdbfc4ce5f6965e3ce0a8a6f703cbddc8fd0cac92b4262dbff62de46 > > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-bootonly.iso) = > eca24527ba37e4ece01863971fb57dcb3dd62bf806f06495c98dc087e7bda6a9 > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-bootonly.iso.xz) = > 190e77a1f7dd66336eb1cc3255451b5a5c2207e9ba2a9ebc8fa9f6f12a918e6c > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-disc1.iso) = > 3d233a177304a9904069ad6b32c7207f6fa1d269b54b65c083ac8b7c65247db4 > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-disc1.iso.xz) = > 00e5ef9c2f4d7e9bdc76acb03acfcbf14b94a514dc857e0ef6dc9c53ef7860ff > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-memstick.img) = > 8b397b7f7c1e32ab49afd009aa8e51e501713b842c0f3db1e72b308a8c0a9359 > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-memstick.img.xz) = > b1301e2a84daea494a17f2d5a0c7674d11ca5b57f0dfa711224730a74436d246 > SHA256 (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-mini-memstick.img) > = 9b9150d382b9f5b4a4cc6b9b04afc880d83c8fdc598cdb5a3282994d8c2dd9ea > SHA256 > (FreeBSD-13.0-CURRENT-amd64-20200903-c122cf32f2a-mini-memstick.img.xz) = > cca83937cb58e392b8f27e763aa373703aadfaed25c7a95cca2f6d916ea122d0 > > > o 13.0-CURRENT i386 GENERIC: > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-bootonly.iso) = > edfe8d146a23f47816fa5339309729f0612dcd783b2d0a58eb272e4403e3404638646b7843757fc8c44fb094f0cc766241485c57f27155541bc1cc75ad5c0ca0 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-bootonly.iso.xz) = > 95b81382e0928f0ae0e29024b748c0884599310ba021dca384994f10eb9ac5cfa90d1ee00adfe33c30982e51b9efe5e24ab8a7bdc459a51cd93baaf8ef9b7151 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-disc1.iso) = > 162859db7b263916f855f9a5dc22d43a9c42898798e11d5cc699170935d282c95426c12354a149d1aa50e66fdf8bb72caf6c65848e0c311fef76908486a388b7 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-disc1.iso.xz) = > 6dca51e88133d652dfe6c5ac45c163676a1eb336f9221c2269f4f364c305578cb53e22775bcdecc1a97bc46663f052492f7ad6543bddc83fedc16a46bc4d7c16 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-memstick.img) = > 96330a17807fe44bf4e51c644ed082bc3f5e771abb3cdf77e59bcb8a37e70f7c97964dba5c6ec1798217f2ec16181745be92a39715c721575a1c2be6daa13435 > SHA512 (FreeBSD-13.0-CURRENT-i386-20200903-c122cf32f2a-memstick.i
Re: Please check the current beta git conversions
Renato Botelho wrote in : |On 02/09/20 20:20, Steffen Nurpmeso wrote: |> Ed Maste wrote in |> : |> |> I tried simply updating my github clone by switching |> |>url = https://cgit-beta.freebsd.org/src.git |>#url = https://github.com/freebsd/freebsd.git |> |> and whereas ls-remote worked fine fetch -v --dry-run aborted as |> well as normal fetch, after dumping dozens of POSTs |> |>POST git-upload-pack (gzip 1472 to 804 bytes) |>... |>POST git-upload-pack (gzip 976722 to 483608 bytes) |>POST git-upload-pack (chunked) |>error: RPC failed; HTTP 413 curl 22 The requested URL returned \ |>error: 413 |>fatal: the remote end hung up unexpectedly |> |> Maybe clone from scratch instead, but mysterious it is? |> Good night, and Ciao from Germany, | |github and cgit-beta repositories are not the same. Commit hashes won't |match so you cannot simply change the URL. Yes i know that, but most of the blobs are of course the same, no? The same files. All that is new are likely the notes and commit objects, even the directory tree objects could often be the same, but i do not know, also because i do not have the new data yet. (But it is 100% that i will not actually inspect this deeply.) Maybe they should split in cgit. and scm. (or .git) and use the git-http-backend for clones on scm. (or .git) and then redirect some requests, this works fine for years: url.redirect = ( "^.*/([^/]+\.git/objects/.*)" => "https://???/scm/$1;, "^.*/([^/]+\.git/info/refs\?service.*)" => "https:///scm/$1; ) I mean i really like saving some download that would go over thousands of kilometres for absolutely nothing. And i think it would be cool if all the many people which clone the github repo just update to the finally landed freebsd.org instance. --steffen | |Der Kragenbaer,The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
New FreeBSD snapshots available: main (20200903 c122cf32f2a)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 New FreeBSD development branch installation ISOs and virtual machine disk images have been uploaded to the FreeBSD Project mirrors. NOTE: These are the first snapshots built from the FreeBSD Git sources. Also note: The armv6 and armv7 builds failed, and the cause is being investigated. As with any development branch, the installation snapshots are not intended for use on production systems. We do, however, encourage testing on non-production systems as much as possible. Please also consider installing the sysutils/panicmail port, which can help in providing FreeBSD developers the necessary information regarding system crashes. Checksums for the installation ISOs and the VM disk images follow at the end of this email. === Installation ISOs === Installation images are available for: o 13.0-CURRENT amd64 GENERIC o 13.0-CURRENT i386 GENERIC o 13.0-CURRENT powerpc GENERIC o 13.0-CURRENT powerpc64 GENERIC64 o 13.0-CURRENT powerpcspe MPC85XXSPE o 13.0-CURRENT aarch64 GENERIC Snapshots may be downloaded from the corresponding architecture directory from: https://download.freebsd.org/ftp/snapshots/ISO-IMAGES/ Please be patient if your local mirror has not yet caught up with the changes. Problems, bug reports, or regression reports should be reported through the Bugzilla PR system or the appropriate mailing list such as -current@ or -stable@ . === Virtual Machine Disk Images === VM disk images are available for the following architectures: o 13.0-CURRENT amd64 o 13.0-CURRENT i386 o 13.0-CURRENT aarch64 Disk images may be downloaded from the following URL (or any of the FreeBSD Project mirrors): https://download.freebsd.org/ftp/snapshots/VM-IMAGES/ Images are available in the following disk image formats: ~ RAW ~ QCOW2 (qemu) ~ VMDK (qemu, VirtualBox, VMWare) ~ VHD (qemu, xen) The partition layout is: ~ 512k - freebsd-boot GPT partition type (bootfs GPT label) ~ 1GB - freebsd-swap GPT partition type (swapfs GPT label) ~ 24GB - freebsd-ufs GPT partition type (rootfs GPT label) Note regarding arm64/aarch64 virtual machine images: a modified QEMU EFI loader file is needed for qemu-system-aarch64 to be able to boot the virtual machine images. See this page for more information: https://wiki.freebsd.org/arm64/QEMU To boot the VM image, run: % qemu-system-aarch64 -m 4096M -cpu cortex-a57 -M virt \ -bios QEMU_EFI.fd -serial telnet::,server -nographic \ -drive if=none,file=VMDISK,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -device virtio-net-device,netdev=net0 \ -netdev user,id=net0 Be sure to replace "VMDISK" with the path to the virtual machine image. === Amazon EC2 AMI Images === FreeBSD/amd64 EC2 AMIs are available in the following regions: af-south-1 region: ami-08c85df99f131c41e eu-north-1 region: ami-092fee473b57ce293 ap-south-1 region: ami-0f164c2f77d17c733 eu-west-3 region: ami-0c76f6b53f6785c66 eu-west-2 region: ami-029e99eecce2dccd7 eu-south-1 region: ami-0631457525932e458 eu-west-1 region: ami-052c5e4b4db76c3fb ap-northeast-2 region: ami-03ca41a3cd4d23104 me-south-1 region: ami-05cb623a383daf32f ap-northeast-1 region: ami-06542baa9c54e8f57 sa-east-1 region: ami-0b23146320070808d ca-central-1 region: ami-0775c8ea1d4c51202 ap-east-1 region: ami-0936d677fddabc97a ap-southeast-1 region: ami-05e8f51cac90600cb ap-southeast-2 region: ami-0f7682c07043d35b2 eu-central-1 region: ami-0c18f8b05b7cf56ff us-east-1 region: ami-0a95c17e40e205461 us-east-2 region: ami-0df13af87e013a831 us-west-1 region: ami-05a2ad30864e0a1f7 us-west-2 region: ami-086dac6ecc576e960 FreeBSD/aarch64 EC2 AMIs are available in the following regions: af-south-1 region: ami-073a95521080cd18a eu-north-1 region: ami-0c3fd8908dbb8d2d5 ap-south-1 region: ami-05594776938632a06 eu-west-3 region: ami-09f042df7c4285573 eu-west-2 region: ami-05940e5f4a220a528 eu-south-1 region: ami-02963fa721e775744 eu-west-1 region: ami-0f70514fd820b09cd ap-northeast-2 region: ami-03211c36231fe7bae me-south-1 region: ami-0d9711b19def01556 ap-northeast-1 region: ami-08c8af0923a2ec4f4 sa-east-1 region: ami-0405529811b49b9c2 ca-central-1 region: ami-0d2cdbbb55b331683 ap-east-1 region: ami-062a657fbd373cc97 ap-southeast-1 region: ami-0c4f30d508c70f510 ap-southeast-2 region: ami-00abe4775d151fb72 eu-central-1 region: ami-030dc94d2caf60616 us-east-1 region: ami-0035735483d37330c us-east-2 region: ami-01fc78890c9d8cf9d us-west-1 region: ami-014662c19db8b8287 us-west-2 region: ami-07f9261cecfeaf8f1 === Vagrant Images === FreeBSD/amd64 images are available on the Hashicorp Atlas site for the VMWare Desktop and VirtualBox providers, and can be installed by running: % vagrant init freebsd/FreeBSD-13.0-CURRENT % vagrant up == ISO CHECKSUMS == o 13.0-CURRENT amd64 GENERIC: SHA512 (FreeBSD-13.0-CURRENT-amd6
Re: Please check the current beta git conversions
On 2020-09-03 10:05, Steve Wills wrote: > Hi, > > On 9/1/20 1:14 PM, Ed Maste wrote: >> We've been updating the svn-git converter and pushing out a new >> converted repo every two weeks, and are now approaching the time where >> we'd like to commit to the tree generated by the exporter, and >> guarantee that hashes will remain consistent from this point. At this >> point the Git Working Group believes the conversion represents a >> high-fidelity translation of the Subversion history, but would >> appreciate additional review in case we've missed anything. >> >> I'd ask folks with an interest in the FreeBSD repository to clone the >> beta conversion and review the converted history in the specific areas >> they are interested in - e.g., specific contrib/ software, device >> drivers, etc. This will also present our final opportunity to change >> the author map file, if necessary. >> >> The beta src tree can be cloned via: >> % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta >> >> Please follow up this week if you notice any discrepancies or author >> entries that require updates. > > One issue that's been seen is adding this remote to an existing repo: > > $ git remote add cgit-beta https://cgit-beta.freebsd.org/ports.git > $ git fetch cgit-beta > error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 > fatal: the remote end hung up unexpectedly > > 413 is Payload too large > > This is because when you fetch, you're telling the other end what hashes > you have and it's figuring out what to send you, and that list is too > large, over 10m, I guess: > > https://stackoverflow.com/questions/7489813/github-push-error-rpc-failed-result-22-http-code-413#15021750 > > > It's unclear if there's a way to tell the client to skip that and just > fetch everything or if it's required to change the upload limit on the > web server and if so how large would be appropriate/required. > > Note fresh clone works fine. > > Steve > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I have raised the client_max_body_size setting on the web server that serves the git repo, and people report it is working now. You might still hit this error if you have a lot of unrelated histories in your checkout, but, this should solve the issue for most people. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: Please check the current beta git conversions
Hi, On 9/1/20 1:14 PM, Ed Maste wrote: We've been updating the svn-git converter and pushing out a new converted repo every two weeks, and are now approaching the time where we'd like to commit to the tree generated by the exporter, and guarantee that hashes will remain consistent from this point. At this point the Git Working Group believes the conversion represents a high-fidelity translation of the Subversion history, but would appreciate additional review in case we've missed anything. I'd ask folks with an interest in the FreeBSD repository to clone the beta conversion and review the converted history in the specific areas they are interested in - e.g., specific contrib/ software, device drivers, etc. This will also present our final opportunity to change the author map file, if necessary. The beta src tree can be cloned via: % git clone https://cgit-beta.freebsd.org/src.git freebsd-cgit-beta Please follow up this week if you notice any discrepancies or author entries that require updates. One issue that's been seen is adding this remote to an existing repo: $ git remote add cgit-beta https://cgit-beta.freebsd.org/ports.git $ git fetch cgit-beta error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 fatal: the remote end hung up unexpectedly 413 is Payload too large This is because when you fetch, you're telling the other end what hashes you have and it's figuring out what to send you, and that list is too large, over 10m, I guess: https://stackoverflow.com/questions/7489813/github-push-error-rpc-failed-result-22-http-code-413#15021750 It's unclear if there's a way to tell the client to skip that and just fetch everything or if it's required to change the upload limit on the web server and if so how large would be appropriate/required. Note fresh clone works fine. Steve ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD CI Weekly Report 2020-08-30
On Thu, Sep 3, 2020 at 4:06 AM Li-Wen Hsu wrote: > (Please send the followup to freebsd-testing@ and note Reply-To is set.) > > FreeBSD CI Weekly Report 2020-08-30 > === > > Here is a summary of the FreeBSD Continuous Integration results for the > period > from 2020-08-24 to 2020-08-30. > > During this period, we have: > > * 2429 builds (88.3% (+0.4) passed, 11.7% (-0.4) failed) of buildworld and > buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, > armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, > sparc64 architectures for head, stable/12, stable/11 branches. > * 274 test runs (45.3% (-8.1) passed, 27.7% (-8.0) unstable, 27.0% (+16.1) > exception) were executed on amd64, i386, riscv64 architectures for head, > stable/12, stable/11 branches. > * 24 doc and www builds (100% (0) passed) > > Test case status (on 2020-08-30 23:59): > | Branch/Architecture | Total | Pass | Fail | Skipped | > | --- | - | -- | - | | > | head/amd64 | 7876 (+1) | 7785 (+1) | 1 (0) | 90 (0) | > | head/i386 | 7873 (0) | 7773 (-3) | 0 (0) | 100 (+3) | > | 12-STABLE/amd64 | 7626 (0) | 7569 (0) | 0 (0) | 57 (0) | > | 12-STABLE/i386 | 7624 (0) | 7559 (+3) | 0 (0) | 65 (-3) | > | 11-STABLE/amd64 | 6912 (0) | 6861 (-30) | 0 (0) | 51 (+30) | > | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | > > (The statistics from experimental jobs are omitted) > > If any of the issues found by CI are in your area of interest or expertise > please investigate the PRs listed below. > > The latest web version of this report is available at > https://hackmd.io/@FreeBSD-CI/report-20200830 and archive is available at > https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. > > ## News > > * Numbers of FreeBSD-head-amd64-test_zfs are changed after OpenZFS > importing, > we encouage everyone check and fix the failing and skipped test cases. > > ## Failing jobs > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ > There are still mutiple errors when building with gcc6, error log > available at > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console > See also: > > https://lists.freebsd.org/pipermail/svn-src-all/2020-September/202307.html > > ## Failing test cases > > * sys.kern.kern_copyin.kern_copyin > Fails after somewhere in (r364509, r364542] > https://bugs.freebsd.org/248933 > > * lib.libbe.be_create.* and sbin.bectl.bectl_test.* > https://bugs.freebsd.org/249055 > > ## Regressions > > * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on > amd64 after r360915 > https://bugs.freebsd.org/246537 > > * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import > https://bugs.freebsd.org/244732 > Needs to check if llvm11 import fixes this. > > * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on > i386 > https://bugs.freebsd.org/244163 > Discovered by newly endabled sys.net.* tests. ([r357857]( > https://svnweb.freebsd.org/changeset/base/357857)) > > * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel > https://bugs.freebsd.org/244168 > Discovered by newly endabled sys.net.* tests. ([r357857]( > https://svnweb.freebsd.org/changeset/base/357857)) > Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , > needs more verification. > > * sys.kern.kern_copyin.kern_copyin > https://bugs.freebsd.org/248933 > > ## Failing and Flaky tests (from experimental jobs) > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ > * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d > * https://bugs.freebsd.org/237641 > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ > * Total 681 tests, 525 success, 46 failures, 110 skipped, see > > https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ > for more details > That's 35 more failures than we used to have. What changed? Was this using the openzfs kmod? It looks like test run 7392 was when the change happened. https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/7392/changes > > * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ > * Total 3749 tests, 2292 success, 644 failures, 813 skipped > > ## Disabled Tests > > * sys.fs.tmpfs.mount_test.large > https://bugs.freebsd.org/212862 > * sys.fs.tmpfs.link_test.kqueue > https://bugs.freebsd.org/213662 > * sys.kqueue.libkqueue.kqueue_test.main > https://bugs.freebsd.org/233586 > * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop > https://bugs.freebsd.org/220841 > * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) > https://bugs.freebsd.org/237450 > * sys.netinet.socket_afinet.socket_afinet_bind_zero > https://bugs.freebsd.org/238781 > * sys.netpfil.pf.names.names > * sys.netpfil.pf.synproxy.synproxy >
Re: Please check the current beta git conversions
On Thu, Sep 03, 2020 at 08:48:59AM -0300, Renato Botelho wrote: > On 02/09/20 20:20, Steffen Nurpmeso wrote: > > Ed Maste wrote in > > : > > > > I tried simply updating my github clone by switching > > > >url = https://cgit-beta.freebsd.org/src.git > >#url = https://github.com/freebsd/freebsd.git > > > > and whereas ls-remote worked fine fetch -v --dry-run aborted as > > well as normal fetch, after dumping dozens of POSTs > > > >POST git-upload-pack (gzip 1472 to 804 bytes) > >... > >POST git-upload-pack (gzip 976722 to 483608 bytes) > >POST git-upload-pack (chunked) > >error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 > >fatal: the remote end hung up unexpectedly > > > > Maybe clone from scratch instead, but mysterious it is? > > Good night, and Ciao from Germany, > > github and cgit-beta repositories are not the same. Commit hashes won't > match so you cannot simply change the URL. Right now, it is true, they differ, in the near future, when we switch, the Github repository will be overwritten and they will be identical. -- Mathieu Arnold signature.asc Description: PGP signature
Re: Please check the current beta git conversions
On 02/09/20 20:20, Steffen Nurpmeso wrote: Ed Maste wrote in : I tried simply updating my github clone by switching url = https://cgit-beta.freebsd.org/src.git #url = https://github.com/freebsd/freebsd.git and whereas ls-remote worked fine fetch -v --dry-run aborted as well as normal fetch, after dumping dozens of POSTs POST git-upload-pack (gzip 1472 to 804 bytes) ... POST git-upload-pack (gzip 976722 to 483608 bytes) POST git-upload-pack (chunked) error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 fatal: the remote end hung up unexpectedly Maybe clone from scratch instead, but mysterious it is? Good night, and Ciao from Germany, github and cgit-beta repositories are not the same. Commit hashes won't match so you cannot simply change the URL. Look at this example. Same commit with different hash: https://github.com/freebsd/freebsd/commit/33ad4343e75940eae87391cc2198ddb617246ea3 https://cgit-beta.freebsd.org/src/commit/?id=f04d830d76bdba3c5d2f3a184a72f64413dafe44 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /sys/modules/ nfscl & nfsd
"Julian H. Stacey" wrote: > Rick Macklem wrote: > > Julian H. Stacey wrote: > > >Hi curr...@freebsd.org, > > > > > >/sys/modules/ nfscl & nfsd > > >With .ctm_status src-cur 14656 .svn_revision 364986 > > > > > >/usr/src/sys/fs/nfsclient/nfs_clkrpc.c:40:10: fatal error: > > >'opt_kern_tls.h' file not found > > ># #include "opt_kern_tls.h" > > > > > ># /usr/src/sys/modules/nfsd > > ># /usr/src/sys/fs/nfsserver/nfs_nfsdkrpc.c:41:10: fatal error: > > >'opt_kern_tls.h' file not found > > > > > >Avoided for now by manualy patching out modules/Makefile > > Should be fixed by r365262. > > > > Thanks for reporting it, rick > > Thanks Rick. > The CTM src-cur system hasnt delivered that yet, it's up to > src-cur 365248 from ctm Sep 2 16:44 src-cur.14659.gz (TZ=+01:00) > So i'll wait on that. My src/ now at .svn_revision 365287 & I confirm compiles OK, Thanks! Cheers, Julian -- Julian Stacey, Consultant Sys. Engineer, BSD Linux http://berklix.com/jhs/ Crash Brexit Dec. 2020 paid by speculators. http://berklix.uk/brexit/#money Probe Russian Brexit Referendum https://petition.parliament.uk/petitions/332293 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD CI Weekly Report 2020-08-30
(Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-08-30 === Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-08-24 to 2020-08-30. During this period, we have: * 2429 builds (88.3% (+0.4) passed, 11.7% (-0.4) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 274 test runs (45.3% (-8.1) passed, 27.7% (-8.0) unstable, 27.0% (+16.1) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 24 doc and www builds (100% (0) passed) Test case status (on 2020-08-30 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | --- | - | -- | - | | | head/amd64 | 7876 (+1) | 7785 (+1) | 1 (0) | 90 (0) | | head/i386 | 7873 (0) | 7773 (-3) | 0 (0) | 100 (+3) | | 12-STABLE/amd64 | 7626 (0) | 7569 (0) | 0 (0) | 57 (0) | | 12-STABLE/i386 | 7624 (0) | 7559 (+3) | 0 (0) | 65 (-3) | | 11-STABLE/amd64 | 6912 (0) | 6861 (-30) | 0 (0) | 51 (+30) | | 11-STABLE/i386 | 6910 (0) | 6854 (-3) | 0 (0) | 56 (+3) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200830 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcomed. ## News * Numbers of FreeBSD-head-amd64-test_zfs are changed after OpenZFS importing, we encouage everyone check and fix the failing and skipped test cases. ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ There are still mutiple errors when building with gcc6, error log available at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/lastCompletedBuild/console See also: https://lists.freebsd.org/pipermail/svn-src-all/2020-September/202307.html ## Failing test cases * sys.kern.kern_copyin.kern_copyin Fails after somewhere in (r364509, r364542] https://bugs.freebsd.org/248933 * lib.libbe.be_create.* and sbin.bectl.bectl_test.* https://bugs.freebsd.org/249055 ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * lib.msun.ctrig_test.test_inf_inputs starts failing after llvm10 import https://bugs.freebsd.org/244732 Needs to check if llvm11 import fixes this. * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix committed as https://svnweb.freebsd.org/changeset/base/364220 , needs more verification. * sys.kern.kern_copyin.kern_copyin https://bugs.freebsd.org/248933 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * Total 681 tests, 525 success, 46 failures, 110 skipped, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2292 success, 644 failures, 813 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 *
Re: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
On 03/09/2020 10:01, Dave Cottlehuber wrote: > On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote: >> On 03/09/2020 00:01, Navdeep Parhar wrote: >>> Load cryptodev manually from the loader to boot and then add >>> cryptodev_load="YES" to your loader.conf. >> >> I think that this shouldn't be needed *if* zfs module has a dependency on >> cryptodev module (MODULE_DEPEND in the code). >> The loader knows how to load dependencies. > > emaste mentioned that this dependency walking doesn't work on aarch64 yet, > until after loader stage is complete. Sorry for the noise then! I didn't know about that bug. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
On Thu, 3 Sep 2020, at 06:48, Andriy Gapon wrote: > On 03/09/2020 00:01, Navdeep Parhar wrote: > > Load cryptodev manually from the loader to boot and then add > > cryptodev_load="YES" to your loader.conf. > > I think that this shouldn't be needed *if* zfs module has a dependency on > cryptodev module (MODULE_DEPEND in the code). > The loader knows how to load dependencies. emaste mentioned that this dependency walking doesn't work on aarch64 yet, until after loader stage is complete. A+ Dave — O for a muse of fire, that would ascend the brightest heaven of invention! ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [openzfs] r365058 arm64 uefi boot fails with "unknown filesystem" after launching kernel
On 03/09/2020 00:01, Navdeep Parhar wrote: > Load cryptodev manually from the loader to boot and then add > cryptodev_load="YES" to your loader.conf. I think that this shouldn't be needed *if* zfs module has a dependency on cryptodev module (MODULE_DEPEND in the code). The loader knows how to load dependencies. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
