Re: Abnormal termination of greeter - cause is libX11 version
On Sun, August 1, 2010 7:34 pm, Pierre Abbat wrote: > I'm using git; there's a command "git checkout vendor" in /usr/Makefile. > Should I change that to "git checkout pkgsrc-2010Q1"? I don't know if the branches are carried through to the git repo. If it isn't, you will need to either switch to CVS to make sure you have the same version, or stick to building from source for everything. There isn't a collection of binary packages that tracks the bleeding edge of pkgsrc.
Re: Abnormal termination of greeter - cause is libX11 version
On Sunday 01 August 2010 19:10:59 Justin C. Sherrill wrote: > On Sat, July 31, 2010 11:58 pm, Pierre Abbat wrote: > > I'd also like to reinstall vlc, but it's not in pkgin, and the version in > > pkgsrc tries to install the libraries for kde4, which messes up my pkgin > > packages. How do I downgrade pkgsrc to match pkgin? > > The version of pkgsrc you have installed is shown in whatever tag it's > against - /usr/pkgsrc/CVS/Tag contains the tag. It should be > pkgsrc-2010Q1 to make sure that when you build manually, you're building > the same versions as what pkgin is downloading from avalon. If it's not, > you can manually make it match and then update with > > setenv CVSROOT anon...@anoncvs.netbsd.org:/cvsroot > setenv CVS_RSH ssh > cd /usr > cvs -q update -dP > > You can also delete /usr/pkgsrc and restore it with exactly the version > you want with: > > setenv CVSROOT anon...@anoncvs.netbsd.org:/cvsroot > setenv CVS_RSH ssh > cd /usr > cvs -q checkout -rpkgsrc-2010Q1 -P pkgsrc I'm using git; there's a command "git checkout vendor" in /usr/Makefile. Should I change that to "git checkout pkgsrc-2010Q1"? > You mentioned before that you are downloading 2.6 packages on a 2.7 > system. That can work right now, but it's better to match exactly. Look > at the path set for pkgin. Done. Pierre -- When a barnacle settles down, its brain disintegrates. Já não percebe nada, já não percebe nada.
Re: Abnormal termination of greeter - cause is libX11 version
On Sat, July 31, 2010 11:58 pm, Pierre Abbat wrote: > I'd also like to reinstall vlc, but it's not in pkgin, and the version in > pkgsrc tries to install the libraries for kde4, which messes up my pkgin > packages. How do I downgrade pkgsrc to match pkgin? The version of pkgsrc you have installed is shown in whatever tag it's against - /usr/pkgsrc/CVS/Tag contains the tag. It should be pkgsrc-2010Q1 to make sure that when you build manually, you're building the same versions as what pkgin is downloading from avalon. If it's not, you can manually make it match and then update with setenv CVSROOT anon...@anoncvs.netbsd.org:/cvsroot setenv CVS_RSH ssh cd /usr cvs -q update -dP You can also delete /usr/pkgsrc and restore it with exactly the version you want with: setenv CVSROOT anon...@anoncvs.netbsd.org:/cvsroot setenv CVS_RSH ssh cd /usr cvs -q checkout -rpkgsrc-2010Q1 -P pkgsrc (notice only the last line is different.) If there's no tag, you're building from the bleeding edge of pkgsrc, which will get you the newest versions but also the newest issues, and is very likely the cause of these version mismatches. I would advise: - Making sure you have pkgsrc-2010Q1 as your /usr/pkgsrc/ - Make sure that pkgin is pointing to the right repository of files on avalon. 2.7 should show in the path, since you are running 2.7. You should be able to build everything at that point. (Look at pkg_rolling-replace if you want something to run through every option for you.) I am working on new pkgsrc-2010Q2 binaries, but it will be at least a few days before those are available, and I'll send out an announcement when they are. When they are available, do as before: make sure your local /usr/pkgsrc is updated to that release, and I'll mention when the "/stable/" link for pkgin is updated to point at packages with that newer release. You mentioned before that you are downloading 2.6 packages on a 2.7 system. That can work right now, but it's better to match exactly. Look at the path set for pkgin.
Re: HEADS UP - massive kqueue changes now in HEAD, and also basic lvm/dm
On Mon, Jul 26, 2010 at 8:32 PM, YONETANI Tomokazu wrote: > On Mon, Jul 26, 2010 at 06:04:00PM -0600, Samuel J. Greear wrote: >> I've pushed some fixes into master, >> >> Commit 0f2e13efc9137bb21562ef4093049fd044651429 should fix the screen issue. > > I updated the kernel with the latest source (the world has been installed > from the source as of 4cc93e2d), but I'm afraid it doesn't fix the issue. > Here's how you compile GNU screen from git master, by the way: > > $ git clone git://git.sv.gnu.org/screen.git > $ cd screen.git/src > $ autoreconf && ./configure && gmake && ./screen > (and press ctrl+D or type `exit' followed by Enter key) > > An window still takes about 10-seconds before closing if it was running > a shell. The shell process itself is terminated right after pressing > ctrl+D, according to the output from ps command. Bisecting revealed that > the first commit in GNU screen which takes longer to close a shell window > on a recent DragonFly kernel is: > http://git.savannah.gnu.org/cgit/screen.git/commit/?id=33b7c9ca > > > I also noticed that issuing shutdown command from within screen triggers > a kernel panic, if it proceeds within the 10-seconds delay. I don't use a > special CFLAGS to build the kernel, and I use gcc4.1 (no CCVER specified). > > Fatal trap 12: page fault while in kernel mode > mp_lock = 0001; cpuid = 1; lapic.id = 0100 > fault virtual address = 0 > fault code = supervisor read, page not present > instruction pointer = 0x8:0x0 > stack pointer = 0x10:0xd3686a80 > frame pointer = 0x10:0xd3686aa8 > code segment = base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, def32 1, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 4436 (screen) > current thread = pri 38 (CRIT) > <- SMP: XXX > trap number = 12 > panic: page fault > mp_lock = 0001; cpuid = 1 > Trace beginning at frame 0xd3686980 > panic() at panic+0x14f > panic(c0332c96,c0345fcc,0,0,f) at panic+0x14f > trap_fatal(0,0,cfaf7310,d274b650,c) at trap_fatal+0x31d > trap_pfault(26,0,0,d3a51f28,d25363d0) at trap_pfault+0xff > trap(d3686a38) at trap+0x7a0 > calltrap() at calltrap+0xd > --- trap 0, eip = 0, esp = 0xd3686a7c, ebp = 0xd274b650 --- > (null)(0,cfaac418,0,cc476400,0) at 0 > CPU_prvspace() at CPU_prvspace+0x8054 > boot() called on cpu#1 > Uptime: 20m42s > #0 _get_mycpu (di=0xc042b2a0) at ./machine/thread.h:83 > #1 md_dumpsys (di=0xc042b2a0) > at /usr/src/sys/platform/pc32/i386/dump_machdep.c:263 > #2 0xc01a24a1 in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:839 > #3 0xc01a2a73 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:388 > #4 0xc01a2fd6 in panic (fmt=0xc0332c96 "%s") > at /usr/src/sys/kern/kern_shutdown.c:745 > #5 0xc030611d in trap_fatal (frame=0xd3686a38, eva=) > at /usr/src/sys/platform/pc32/i386/trap.c:1125 > #6 0xc030622e in trap_pfault (frame=0xd3686a38, usermode=0, eva=0) > at /usr/src/sys/platform/pc32/i386/trap.c:1026 > #7 0xc03076e8 in trap (frame=0xd3686a38) > at /usr/src/sys/platform/pc32/i386/trap.c:713 > #8 0xc02f2427 in calltrap () > at /usr/src/sys/platform/pc32/i386/exception.s:785 > #9 0x in ?? () > This 10-second-wait should be fixed with commit 847ff8c. While debugging I noticed screen calls close(2) on all descriptors except stdin/err/out every time it forks. Making it use DragonFly's closefrom(2) would be a great optimization that would reduce new window creation times, if anyone felt so inclined. Sam
