Re: [Bug 194477] 10.1-RC1 tar(1) spurious directory permission error message
bugzilla-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=194477 --- Comment #1 from John Marshall john.marsh...@riverwillow.com.au --- Confirmed independently on -stable@ https://lists.freebsd.org/pipermail/freebsd-stable/2014-October/080685.html The scenario of traversal-only access to the parent directory is common in a situation where the directory contains per-user subdirectories, and each user has no business knowing about any subdirectory but his own. The archive generated is fine, the user has full permission to the directory being archived, but tar(1) exits with an error status. I regard this regression as a bug. i'll bite very interesting is the error on tar or utar ? i assume you mean on tar -c but be specific is this new or do older version NOT do this? if so please state the right and wrong tar versions. also i need a firm permission basis. just because you are in same group may not be the same as owning (w/respect to utar, not tar) and if your using any kernel extended permissions (tar obviously uses only unix file security / bits. it stores file perms also user # in tar header) i don't see any follow-ups just the initial comlaint, did this complain expire ? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
who controls freebsd now?
i know dumb question to throw out is it the people listed? how'd they get in control? is it all on up and up? or are some suspicious? i hope some day to use it but the water looks cold ... in debian the KEY HOLDERS (maintainers) control it and there is some heat on whether they have who's interest in mind. maintainers say hog wash users must like systemd, ssh, hard installs, etc :) i know the reagents of CA used to control BSD, apple has a branch of that i see allot of foreigners hacking it (nervously) and wonder who actaully, if anyone, checks to see if these hacks are not engineered attempts to cause usa / ca / bsd to fail (implode due to tech failures / unhappy users) maybe an annoying discussion thanks for reading the question / having the post up ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: [Bug 133286] dd can fill system memory
bugzilla-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=133286 yaneurab...@gmail.com changed: What|Removed |Added CC||yaneurab...@gmail.com --- Comment #5 from yaneurab...@gmail.com --- (Just a drive-by comment) It might be a good idea to do add iflags/oflags for Linux compatibility; they have an iflags=direct/oflags=direct option, as well as other interesting options for tweaking O_APPEND, O_NONBLOCK, and other O_* flags: https://www.gnu.org/software/coreutils/manual/html_node/dd-invocation.html so will break software and scripts (or printed books) using dd(1) ? if such a binary is on a rescue disk that may float around, what will the hangups be of not being able to use dd(1) due to versional tweeks ? ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: [Bug 191086] New: grep and bsdgrep do not recognize [[::]] and [[::]]
bz-nore...@freebsd.org wrote: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191086 Bug ID: 191086 Summary: grep and bsdgrep do not recognize [[::]] and [[::]] Product: Base System Version: 9.2-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: we...@iastate.edu grep and bsdgrep do not recognize the '[[::]]' or '[[::]]' bracket expressions described in re_format(7), though sed does: $ printf 'foobar\nfoo bar\nbaz' | grep 'foo[[::]]' grep: Invalid character class name $ printf 'foobar\nfoo bar\nbaz' | grep '[[::]]bar' grep: Invalid character class name $ printf 'foobar\nfoo bar\nbaz' | bsdgrep 'foo[[::]]' bsdgrep: Invalid character class name $ printf 'foobar\nfoo bar\nbaz' | bsdgrep '[[::]]bar' bsdgrep: Invalid character class name $ printf 'foobar\nfoo bar\nbaz' | sed -n '/foo[[::]]/p' foo bar $ printf 'foobar\nfoo bar\nbaz' | sed -n '/[[::]]bar/p' foo bar i've never heard it should support [::] i've heard \ is a gnu option not all support what is your citation showing any standard defines this and that you should be allowed to make changes (which maybe will cause other problems if you are incorrect) ? please, thank you ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: ports/188190: mail/mutt 1.5.23 needs to support POP, IMAP, SMTP over SSL
lini...@freebsd.org wrote: Old Synopsis: Mutt 1.5.23 needs to support POP, IMAP, SMTP over SSL New Synopsis: mail/mutt 1.5.23 needs to support POP, IMAP, SMTP over SSL Responsible-Changed-From-To: freebsd-bugs-freebsd-ports-bugs Responsible-Changed-By: linimon Responsible-Changed-When: Wed Apr 2 09:47:38 UTC 2014 Responsible-Changed-Why: ports PR. http://www.freebsd.org/cgi/query-pr.cgi?pr=188190 ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org is nice if it doesn't break the old way of using mutt for people who use it should be an add on or supp. pkg is nice if security isn't integrated in a way it becomes incompatible with normal security. for example: if i don't use pam the security should still work , and i shouldn't be forced to use or run kind of security hack, like ssh it's definitely a wish not need is that right ? sounds nice, good luck, of course the support is already in other apps ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/187912: Getting Stack Traces of Xorg with DTrace Causes Hang
The following reply was made to PR kern/187912; it has been noted by GNATS.
From: John D. Hendrickson and Sara Darnell johnandsa...@cox.net
To: Nick Zivkovic zivkovic.n...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: kern/187912: Getting Stack Traces of Xorg with DTrace Causes
Hang
Date: Tue, 25 Mar 2014 17:44:34 -0400
Nick Zivkovic wrote:
Number: 187912
Category: kern
Synopsis: Getting Stack Traces of Xorg with DTrace Causes Hang
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Mon Mar 24 23:50:00 UTC 2014
Closed-Date:
Last-Modified:
Originator: Nick Zivkovic
Release:10.0 (r260789)
Organization:
N/A
Environment:
FreeBSD Stalingrad 10.0-RELEASE FreeBSD 10.0-RELEASE #0 r260789: Thu Jan 16
22:34:59 UTC 2014 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
Description:
When executing the following DTrace script:
sudo dtrace -n 'syscall:::entry /execname == Xorg/ {@[ustack()] =
count();}'
and pressing ^C, the Xserver freezes. The machine (a laptop) is unresponsive.
So I ssh'd into the laptop (from a different laptop), and did:
pgrep dtrace
Sure enough the dtrace exec was still alive, but not doing anything (that I
can tell).
Firefox still did IO and stuff, but Xorg didn't have _any_ activity
(according to top).
So I did a `kill -9 $(my-dtrace-pid)`
This caused Xorg to restart.
Bottom line: running that simple (and common) DTrace script froze Xorg. I
don't mean to be inflammatory but, this should _never_ happen, especially
not in production --- which means that the FreeBSD DTrace implementation is
violating DTrace's original design constraints. This is a critical error,
and shows that FreeBSD's DTrace may not be suitable for production use, yet.
So far I've only been able to replicate this on Xorg.
It may be of importance that I did `make buildworld` and `make installworld`
with the following options:
CFLAGS+=-fno-omit-frame-pointer
STRIP=
WITH_CTF=1
In other words I made all of my installed packages dtrace-friendly.
How-To-Repeat:
When running Xorg (not stripped, no frame-pointer optimization, and with
CTF) run:
sudo dtrace -n 'syscall:::entry /execname == Xorg/ {@[ustack] = count();}'
resize windows, click around, etc.
go back to terminal and hit ^C.
Fix:
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
now that's a can of worms !
i'm poor at BSD, not a maintainer i use other mostly, but let me make
some suggestions:
DTrace, also known as Dynamic Tracing, was developed by Sun™ as a tool
for locating performance bottlenecks in production and pre-production
systems. It is not, in any way, a debugging tool, but a tool for real
time system analysis to locate performance and other issues.
#0 this tells me it is meant for regression testing / engineering not
normal users
#1 if it's for Sun they used a nice BUS, not same - maybe on their bus
there was no bus error
#2 did you try running X.org using frame buffer driver ?
#3 i'm sure you know signaling buses and interrupts can be touchy
#4 keeping video card in right mode / failing to be in right state can
be touchy
i'm thinking DTrace uses debug abilities of hardware, not just kernel
commands, to peek. that's important because if one emulated it would
one do so in parallel or in spinlock ?
what was #2? well if X runs as root for access to video card. if
there are permission problems or any problem or if video card doesn't
respond it takes system down. like breaking a vacuum tube you might
say, which runnign as normal user protects against. but ah there
are ways to fool X to do the wrong thing after it logs in as user
because !due to crap quality video cards! it still must be root in
some cases
next we have to drag the cat in and ask which hw your running :)
good luck , John
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/182139: lock order reversal
i don't get that message using linux. however i had to solve a bad IDE drive problem once caused by microsoft software the IDE company installed on it. what is your question? #1) wrong lock order is very serious: it's the whole damn disk hw and driver is built for that: if that fails you have dick. lock order is all that is between your data and being trashed by old data before getting on disk (if it gets on disk, with wrong locks) #2) if mount throws messages it could be a hw error, driver problem, fat table mutation, etc. it really depends you have to find out. i'm saying: do you know where and when the problem is thrown? because most locking is in driver code or memory caching code. for example, maybe a wrong fat table entry causes a glitch which causes the kernel to panic while sorting lock order - and you don't see or haven't read the source code to know that's what's going on. i haven't tried bsd yet because it seems so many messages point out serious problems recently developing (caused after bsd stable public release by hackers making improvements to bsd). i was only going to try it becuase it used to be rock solid and fully compiled. bsd channel scares me as to how many problems and why: from any gov agent or company all over the world hacks into drivers? ughh. is there any management or overview of who is hacking into what parts of bsd these days? or why? i mean, does the univ. of cal. have professors that have keys? or do foreigners have keys and are calling it bsd when it isn't? i know in my area as soon as gov workers invested in microsoft stock all unix classes closed and classes started requiring ms use (the area had few compared to CA to begin with). ms moved into area and got gov contracts. recently i think a few unix classes have arrived back. but nothing with funding or bite, ie, for e-commerce and e-gov. though apple does (some) of that. apple makes progress there. but most classes still require ms boxes. all a damn scam if you ask me. well good luck. hope some release for bsd is called stable and i get to try it. J B wrote: The following reply was made to PR kern/182139; it has been noted by GNATS. From: J B jb.1234a...@gmail.com To: bug-follo...@freebsd.org, jb.1234a...@gmail.com Cc: Subject: Re: kern/182139: lock order reversal Date: Mon, 16 Sep 2013 06:50:08 +0200 --f46d0438eb6d4a888e04e678f0c5 Content-Type: text/plain; charset=ISO-8859-1 I got similar errors, I assume after umount. # mount -t ext2fs /dev/ada0s6 /mnt/ # umount /mnt # cat /var/log/messages ... Sep 16 06:35:41 localhost kernel: lock order reversal: Sep 16 06:35:41 localhost kernel: 1st 0xc8077d84 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1237 Sep 16 06:35:41 localhost kernel: 2nd 0xc8077a30 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2210 Sep 16 06:35:41 localhost kernel: KDB: stack backtrace: Sep 16 06:35:41 localhost kernel: ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/172862: sed improperly deals with escape chars
The following reply was made to PR bin/172862; it has been noted by GNATS.
From: John D. Hendrickson and Sara Darnell johnandsa...@cox.net
To: Garrett Cooper yaneg...@gmail.com
Cc: freebsd-gnats-sub...@freebsd.org
Subject: Re: bin/172862: sed improperly deals with escape chars
Date: Sat, 20 Oct 2012 20:37:25 -0400
Hi. This should be files as a Question not a Bug. You need to investigate
things before claiming
bug.
$ echo foot | sed -e 's/[\\t ]*$//' | hexdump -C
What I see is your using [] wrong. '\t' doesn't go inside it for many WELL
documented reasons.
Furthermore sed mathes '\t' without [] so why bother filing a bug against [] ?
'\t' has been around more years than your were born and probably sed too...
anyhow. ediquitte is you ask questions to users and file bugs about only if
your very as
professor sure and also know how to fix it (pref. wtih code patch filed which
absolutely CANNOT
cause past software to stop working).
p.s.
So, when you see a majorly relied upon unix tool doing something stupid
it's very likely you have more learning and asking to do.
1) you don't want people hacking sed to make it work your way it would break
past software
2) you don't want BSD-SED to have false bugs filed it will make BSD look worse
than it is
3) since early stable versions of free bsd, bsd has accumulated
way too many bugs and fixes and hardware compat changes - about
a suspicious ammount - and still isn't as stable as it had been )
Garrett Cooper wrote:
Number: 172862
Category: bin
Synopsis: sed improperly deals with escape chars
Confidential: no
Severity: non-critical
Priority: low
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Thu Oct 18 21:10:00 UTC 2012
Closed-Date:
Last-Modified:
Originator: Garrett Cooper
Release:9.1-STABLE
Organization:
EMC Isilon
Environment:
FreeBSD bayonetta.local 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0 r240836M:
Sat Sep 22 12:30:11 PDT 2012
gcooper@bayonetta.local:/usr/obj/store/freebsd/stable/9/sys/BAYONETTA amd64
Description:
sed doesn't appear to be doing the right thing with escape chars (in this
case '\t'); it's not properly reinterpreting '\t' as \011, but is instead
interpreting it was 't':
$ echo foot | sed -e 's/[\\t ]*$//' | hexdump -C
66 6f 6f 0a |foo.|
0004
$ echo foot | sed -E -e 's/[\\t ]*$//' | hexdump -C
66 6f 6f 0a |foo.|
0004
GNU sed does do the right thing with escape chars (verified on Fedora 17):
# cat /etc/redhat-release
Fedora release 17 (Beefy Miracle)
# echo foot | sed -e 's/[\t ]*$//' | hexdump -C
66 6f 6f 74 0a|foot.|
0005
# echo foot | sed -e 's/[\t ]*$//' | hexdump -C
66 6f 6f 74 0a|foot.|
0005
How-To-Repeat:
echo foot | sed -e 's/[\t ]*$//'
Fix:
Release-Note:
Audit-Trail:
Unformatted:
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: misc/167222: FreeBSD 8.3 corrupting MBR partition table after installation
maybe. it's also possible what changed is your disk geometry. Answer is probably: you have the old partition data so just re-enter it (apparently your just emulating and i'm unsure your emulator simulates drive detection or has the same mbr) (also, make sure you don't have easy drive in your mbr) if this is the first time your machine is getting the upgrade sata expect some flak do you have a backup ? did you boot the old system to see if it reads it ? other possibilities: you booted microsoft and microsoft deleted it (i know at least older versions did that) Have Fun! John Andrey V. Elsukov wrote: The following reply was made to PR misc/167222; it has been noted by GNATS. From: Andrey V. Elsukov a...@freebsd.org To: Faltu faltuema...@gmail.com Cc: freebsd-gnats-sub...@freebsd.org Subject: Re: misc/167222: FreeBSD 8.3 corrupting MBR partition table after installation Date: Mon, 23 Apr 2012 13:08:55 +0400 On 23.04.2012 11:18, Faltu wrote: The whole partition table has been messed up by FreeBSD installer as shown in the following screenshots : Before installation screenshot from ubuntu live CD http://i.imgur.com/YIlpA.png After installation screenshot from ubuntu live CD http://i.imgur.com/AJm8B.png As i see there are two identical MBR and FreeBSD did nothing bad. Probably you have changed disk geometry in the installer and after that you got what you see. -- WBR, Andrey V. Elsukov ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3
a revision that breaks not only software but hardware... is CERTAINLY not a subrevision (ie, 8.3) but a major revision (ie, 9.x) I've used advanced TTY and myself see 0 no null ZERO improvement. I'd rather have the drivers fixed before they implement. You know some drivers not compiling aren't the ONLY thing altered tty effects. It seems somewhere around 8.2 stable become free for all break whatever you please. Eugene wrote: The following reply was made to PR kern/166866; it has been noted by GNATS. From: Eugene eugene...@mail.ru To: bug-follo...@freebsd.org, eugene...@mail.ru Cc: Subject: Re: kern/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3 Date: Fri, 13 Apr 2012 12:42:13 +0400 In fact, this problem is described in UPDATING: 20080820: The TTY subsystem of the kernel has been replaced by a new implementation, which provides better scalability and an improved driver model. Most common drivers have been migrated to the new TTY subsystem, while others have not. The following drivers have not yet been ported to the new TTY layer: PCI/ISA: cy, digi, rc, rp, sio USB: ubser, ucycom Line disciplines: ng_h4, ng_tty, ppp, sl, snp Adding these drivers to your kernel configuration file shall cause compilation to fail. But Hardware Notes has all this devices listed as supported. Probably, this devices (except for ng_tty, which was updated in 20081225) must be marked as temporary unsupported until their drivers were fixed. Eugene mailto:eugene...@mail.ru ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: kern/166866: [build] [cy] cy(4) driver breaks kernel build in 8.3
excuse my manners. thank you very much for the report. Eugene wrote: The following reply was made to PR kern/166866; it has been noted by GNATS. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
Re: bin/166842: bsdgrep(1) inconsistently handles ^ in non-anchoring positions
Your problem is incorrect so there is no sol'n. printf 'abc def' | grep -o '^[a-z]' is only supposed to match against abc. see grep(1) about pattern matching - there is plenty of online writeups, esp posix ieee std. see also ant / antlr for more about patterns and matching. Jim Pryor wrote: The following reply was made to PR bin/166842; it has been noted by GNATS. From: Jim Pryor dubious...@gmail.com $ printf 'abc def' | grep -o '^[a-z]' will match against each of the letters in 'abc', but not against any of the letters in 'def'. dubious...@gmail.com ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
dep-trace v. tsort (mac ports depends support)
Hi, BSD and Apple needs tsort(1) for portage still I believe. Topological sorting isn't quite right packaging. Please see: http://sourceforge.net/projects/dep-trace It is a drop-in replacement (operates like a /bin/tsort) but is right for pkg depends (ie, for portage: you need to dl source, order of compile may be required, sometimes gets missing message or loop in depends message when attempting to compile and install pkg) I'm a debian user but i wish I had a bsd machine :) So i do not know allot of BSD maintainer / mailing list specifics. Please give me a handicap there ! Thanks and thanks again, John p.s. (dep-trace itself has no depends (a /bin), has improvements, and is more hackable than tsort as to coding new ordering rules against lists - which in tsort loop detected attempting to recover is not as easy i feel. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to freebsd-bugs-unsubscr...@freebsd.org
