RE: subversion-freebsd dependencies
Hi! On a newly installed development machine I installed subversion-freebsd from ports and ended up with a huge dependency chain. If you're just using it for FreeBSD you can un-check all the OPTIONS. If you might want to use the http:// protocol to check something out the neon option works well and is fairly painless. It doesn't help to remove tcl build dependency, as sqlite3 is unconditional dependency :( There is the sqlite-autoconf-3070800.tar.gz on the SQLite download page. This source code builds fine without tcl installed. But FreeBSD port still uses sqlite-src-XXX.zip which marked as Legacy Source Code Distribution Formats (Not Recommended) So it seems that tcl dependency may be avoided. -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: cvsup broken on amd64?
Hi!
So I've taken a look at the csup source.
The problem here is the updater thread setting the closed state
(fixups_closed()) before calling updater_batch() again to handle
fixups.
Checking for size != 0 at that point may not be valid at the list size
may actually be 0 for a short period of time.
What about this patch:
Index: updater.c
===
--- updater.c (revision 224905)
+++ updater.c (working copy)
@@ -240,9 +240,9 @@
* Make sure to close the fixups even in case of an error,
* so that the lister thread doesn't block indefinitely.
*/
- fixups_close(up-config-fixups);
if (!error)
error = updater_batch(up, 1);
+ fixups_close(up-config-fixups);
switch (error) {
case UPDATER_ERR_PROTO:
xasprintf(args-errmsg, Updater failed:
Protocol error);
I've tried this patch. Now csup hangs before handling fixups.
So there is no message Applying fixups... at all.
--
Alexander Zagrebin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: cvsup broken on amd64?
Pester the maintainer? I've thought that if an opened PR exists, then it have to be reviewed sooner or later... -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: cvsup broken on amd64?
I'm also using cvsup again, due to a problem I had with csup back in February 2011 http://www.mail-archive.com/freebsd-stable@freebsd.org/msg114 813.html . I didn't open a PR; I was under some time pressure and cvsup worked. There is a solution of the csup problem: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/154954 I've opened this PR, but nobody has paid to it attentions. :( -- Alexander Zagrebin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS v28: kernel panics while reading an extended attribute
Hi! It seems, I've found a bug in the ZFS v28 on the latest stable: if we have a snapshot with some files having an extended attributes, then attempt to read an extended attributes's value leads to a well reproducible kernel panic. The part of backtrace follows: #6 0x804bbe44 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:228 #7 0x80950ea7 in zil_commit (zilog=0x0, foid=5795917) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zil.c:1497 #8 0x80979e6b in zfs_freebsd_read (ap=Variable ap is not available.) at /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:622 #9 0x80979750 in zfs_getextattr (ap=0xff80dd5d8820) at vnode_if.h:384 #10 0x8038921b in extattr_get_vp (vp=0xff0056a01588, attrnamespace=1, attrname=0xff80dd5d89a0 DOSATTRIB, data=Variable data is not available.) at vnode_if.h:1332 It seems that ZIL isn't available for snapshots, but zfs_freebsd_read doesn't check this when calling zil_commit. The attached patch fixes this issue. Can anybody confirm this? -- Alexander Zagrebin --- sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig 2011-08-01 23:04:07.358173627 +0400 +++ sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c 2011-08-02 00:10:02.674585604 +0400 @@ -618,7 +618,8 @@ zfs_read(vnode_t *vp, uio_t *uio, int io /* * If we're in FRSYNC mode, sync out this znode before reading it. */ - if (ioflag FRSYNC || zfsvfs-z_os-os_sync == ZFS_SYNC_ALWAYS) + if (zfsvfs-z_log + (ioflag FRSYNC || zfsvfs-z_os-os_sync == ZFS_SYNC_ALWAYS)) zil_commit(zfsvfs-z_log, zp-z_id); /* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
8.1-RC2: bug in ng_ipfw (ng_ipfw doesn't return a packet back to ipfw)
After upgrading from RELENG_8_0 to RELENG_8_1 (8.1-RC2) I have noticed that ng_ipfw doesn't return a packet back to ipfw after `ipfw add ... netgraph ...` due to the bug in the sys/netgraph/ng_ipfw.c The attached patch solves the problem. -- Alexander patch-sys-netgraph-ng_ipfw.c Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS allows deletion of files in a sticky directory
I have found that directory entry may be deleted from a ZFS directory with the sticky bit, if the entry is a plain file and you have write access (this is citation from a comments in zfs_dir.c) But this behavior isn't described in the sticky(8) and isn't allowed on a UFS. The attached patch provides the UFS-like behavior of a sticky directories on a ZFS. Is this bug or feature? -- Alexander Zagrebin patch-zfs_dir.c Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
ZFS: statfs and recordsize problem
I have noticed, that statfs called for ZFS file systems, returns the value of FS's recordsize property in both f_bsize and f_iosize. It's a problem for some software. For example, squid uses block size of cache's file system to calculate the space occupied by file. So by default it considers that any small file uses 128KB of a cache (when default value of recordsize is used), though really this file may use 512B only. This miscalculation leads to unreasonable cleaning of a cache. IMHO the behavior of statfs have to be changed, as ZFS uses variable (up to recordsize) block sizes. It must return 512 as f_bsize and recordsize as f_iosize. One of possible solutions is the attached patch. Could somebody look it? -- Alexander Zagrebin patch-zfs_vfsops.c Description: Binary data ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
