offline use of the ports tree (was: Re: 7.1 ports.tar.gz slightly corrupted?)
In <https://marc.info/?l=openbsd-ports=165158363011409=1>, Sol??ne Rapenne wrote > The ports tree alone isn't helpful without Internet access so I doubt an > argument like "I can use the tarball offline" make sense. On the contrary, I would argue that the ports tree (unpacked from the tarball and/or updated with CVS) *is* useful offline. I personally often do so; my typical offline usage cases are: * 'cat pkg/DESCR' to get a brief summary of what a port is and does * 'less Makefile' to find out a port's current version & patchlevel * 'cd /usr/ports; make search key=FOO' and/or 'cd /usr/ports; find . -iname '*FOO*' and/or (if I'm really desperate) 'cd /usr/ports; find . -name DESCR | xargs egrep -i FOO' or 'cd /usr/ports; find . -name DESCR | xargs agrep -i2 FOO' to see if there are any ports that might be relevant to problem area FOO. (There's also sqlports.) If I find anything potentially interesting I can investigate it further/later (which likely requires being online), but the search result itself is often useful already. Keep safe and COVID-free, -- -- "Jonathan Thornburg [remove -color to reply]" currently on the west coast of Canada "Totalitarianism will not be satisfied to assert, in the face of contrary facts, that unemployment does not exist; it will abolish unemployment benefits as part of its propaganda," -- Hannah Arendt (1951)
7.1 ports.tar.gz slightly corrupted?
The 7.1 ports.tar.gz (I tried downloading from both https://ftp.openbsd.org/pub/OpenBSD/ https://openbsd.cs.toronto.edu/pub/OpenBSD/ and verified that they gave identical files; checksums are below) appears to have a slightly corrupted 'graphics/libraw' port: % /bin/tar xzf /tmp/ports.tar.gz % cd ports % ls -d g* games/geo/ gnome/graphics/ grapics/ I was curious about the directory name 'grapics' (which looks like a 1-letter typo from 'graphics'), so I looked around. 'grapics' contains only a single port, libraw, and that port is missing various files: % cd grapics % ls CVS/libraw/ % cd libraw % ls -R .: CVS/ patches/ pkg/ ./CVS: Entries Repository Root ./patches: CVS/ ./patches/CVS: Entries Repository Root ./pkg: CVS/ ./pkg/CVS: Entries Repository Root % cat pkg/CVS/Entries D % Note the lack of a top-level 'Makefile' or 'distinfo' file, and the empty 'pkg' subdirectory apart from the 'CVS' directory (there should be at least a 'pkg/DESCR' and a 'pkg/PLIST'). This port did not have these anomolies in a 7.0 ports tree, where it lived in 'graphics/libraw' and where there is no 'grapics' top-level directory. Here are the checksums of the offending 7.1 ports.tar.gz, which as noted above is identical on the two official Canadian https mirrors: % cksum ports.tar.gz 492031365 36593768 ports.tar.gz % sha256 ports.tar.gz SHA256 (ports.tar.gz) = e97611900b96bfbd09d3c4ccb48e07acb2942c5bf9c676f0561c152a3b0fed4e % sha512 ports.tar.gz SHA512 (ports.tar.gz) = c24ce51924c94ec2a7a12ec39f376243ce70870a6ed3cabd65a574a7f41a4edab75a97f42c33967ae88b7aac454cc6f2c06d1202ecae67b0911deece10d7312b % Keep safe and COVID-free, -- Jonathan
SOLVED: Re: how to install firefox addon (noscript) on 6.6/amd64?
In message <https://marc.info/?l=openbsd-ports=157570132320029=1>
I wrote about being unable to install a firefox addon (noscript) using
the packaged firefox-69.0.2p0 under 6.6/amd64. (Firefox would download
the addon and ask for the appropriate permissions, but after my accepting
the permission request the addon would never actually install; firefox
would just keep displaying the blue-dot-oscillating-left-and-right spinner.)
I'm pleased to report a workaround: My original problem occured while
running my usual window manager, twm. I temporarily switched to fvwm,
and then the addon installed properly (and continued to work after I
returned to twm).
twm is one of the oldest window managers around, and in the past decade
or so I've noticed that some software has minor issues with it ("monster
icons"). Given that it's part of base in OpenBSD, and it's (still)
standard with the X.org server, I'll file a bug report with firefox,
and maybe also with twm.
Thanks to George Koehler for his followup to my
original message which helped nudge my brain in the direction of "try a
more popular environment".
--
-- "Jonathan Thornburg [remove color- to reply]"
"There was of course no way of knowing whether you were being watched
at any given moment. How often, or on what system, the Thought Police
plugged in on any individual wire was guesswork. It was even conceivable
that they watched everybody all the time." -- George Orwell, "1984"
how to install firefox addon (noscript) on 6.6/amd64?
I'm trying to set up my usual firefox environment on a freshly installed
OpenBSD 6.6 system, and I'm stuck trying to install an addon (noscript).
My starting point was (is) a fresh 6.6/amd64 installation, with the
firefox-69.0.2p0 package installed and firefox otherwise working ok.
My first attempt at installing noscript was to use the builtin firefox
addon search:
click menu icon on top right menubar
--> click Add-ons
--> type 'noscript' in search box, press 'enter'
This failed with the result
> 0 results found for "noscript"
and the red alert box
> ! Invalid "platform" parameter.
Duckduckgo then told me this is a known bug,
https://github.com/mozilla/addons-frontend/issues/4610
My next attempt was to go directly to
https://addons.mozilla.org
and search for noscript there. This found it, and one more click
brought me to
https://addons.mozilla.org/en-US/firefox/addon/noscript/?src=search
I then tried to install ("add") this addon into firefox:
click the blue "+ Add to Firefox" button
--> get permissions-request popup, accept
--> the extension .xpi file is then downloaded to /tmp
(e.g., /tmp/tmp-622.xpi, size 572021 bytes, cksum 3655027406),
but the extension never installs -- firefox just keeps showing the
blue-dot-oscillating-left-and-right spinner forever :(
A bit more web searching led me to
https://support.mozilla.org/en-US/kb/unable-install-add-ons-extensions-or-themes#w_you-are-asked-to-download-the-add-on-rather-than-installing-it
which suggests that I "drag and drop the file into the Add-ons window".
But there's no concept of "drag and drop" in my window manager (twm).
So questions:
* How are other people installing firefox addons under OpenBSD 6.6?
* Is there a command-line way to install a firefox add-on if the automagic
install fails?
* If I want to report this bug, should I do so here (ports@) or over
at mozilla gibhub (or somewhere else)?
thanks, ciao,
--
-- "Jonathan Thornburg [remove -color to reply]"
"He wakes me up every morning meowing to death because he wants to go out,
and then when I open the door he stays put, undecided, and then glares
at me when I put him out"
-- Nathalie Loiseau (French minister for European Affairs,
explaining why she named her cat "Brexit")
Re: OpenMP for both clang and GCC, part II
I wrote: > > The distinction > > here is between > > (a) no OpenMP support at all, so all OpenMP code has to be stubbed out > > on OpenBSD with #ifdef NOT_DEFINED or dummy routines, vs > > (b) OpenMP works and lets me develop/debug on my OpenBSD laptop/desktop > > before I ship the code off to the (Linux) supercomputer for big runs. Stuart Henderson replied > or (c) it's enabled and detected and doesn't really work properly. I agree, that would be ungood. > I don't think it's too much to ask for more information about what we > can expect to see with it enabled before we go committing diffs in > support of it around the tree .. Agreed 100% -- I'm sorry if my wording suggested otherwise. clang/clang++/flang and gcc/g++/gfortran support is all I need, but I do appreciate the point made earlier about how various other ports will auto-detect OpenMP support and reconfigure themselves to use it (with attendent bad results if it doesn't actually work properly). Perhaps compiler OpenMP support should require an explicit --enable-openmp compiler flag, or even installing a -openmp compiler flavor? ciao, -- Jonathan
Re: OpenMP for both clang and GCC, part II
On Fri, Jun 14, 2019 at 12:27:53AM +0100, Stuart Henderson wrote: > At the moment, it's unclear to me (maybe it was mentioned in the thread > but if so I missed it) what the status of OpenMP is on OpenBSD. > Whether it's any faster *at all*, whether it works reliably, etc. As of 6.4 it doesn't work at all -- there's no "omp.h" header file for code to include, so OpenMP code can't even be compiled on OpenBSD. (Or, in my case, all the OpenMP code has to be guarded with #ifdef HAVE_OPENMP and that symbol not defined when compiling on OpenBSD.) Quickly checking a 6.5 system the status appears to be the same. -- -- "Jonathan Thornburg [remove -animal to reply]" Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA currently on the west coast of Canada "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
Re: OpenMP for both clang and GCC, part II
[[speedups from OpenMP]] In message <https://marc.info/?l=openbsd-ports=155992865732530=1>, j () bitminer ! ca wrote [[about openmp]] > For long calculations, I have seen 2 cores with OpenMP take half the time > as one core with/without. So yes, it works. But Amdahl's Law applies. > If a calculation is long, and 20% is serial, and 80% parallelizable, > then the runtimes will be 100%, 60%, 46% and 40% at 1, 2, 3 and 4 cores. > The difference between 3 and 4 cores is not much. If 100% takes 4 hours, > then the difference between 1 and 2 cores is significant. I replied: > I have a code which typically gets a speedup of ~6 using OpenMP on > 8 cores and ~12 on 16 cores. Using OpenMP the code runs for anywhere > from a few days to a few weeks, so the OpenMP speedup is very significant. > > The code is ~100K lines of C++, developed on OpenBSD, running on a > Linux supercomputer. I added OpenMP support in 2015, so it's all guarded > with an #ifdef which is disabled on OpenBSD. (Debugging the OpenMP > directly on the supercomputer was slightly painful; fortunately this > code's use of OpenMP is very simple, with only 3 parallel loops and > one per-thread data structure in the entire code.) On Thu, Jun 13, 2019 at 11:18:44PM +0100, Stuart Henderson replied: > It's really performance _on OpenBSD_ that is of interest when deciding > whether it's worth the ongoing maintenance to go down this path here :) Being able to develop/debug OpenMP code on OpenBSD would be very useful to me, even if the performance boost were modest. The distinction here is between (a) no OpenMP support at all, so all OpenMP code has to be stubbed out on OpenBSD with #ifdef NOT_DEFINED or dummy routines, vs (b) OpenMP works and lets me develop/debug on my OpenBSD laptop/desktop before I ship the code off to the (Linux) supercomputer for big runs. (a) is the current status (where I can only test/debug the OpenMP parts of my code remotely). (b) would be a significantly nicer software development environment than (a) *even if* the actual performance boost were only modest (say a factor of 2 on things that only run for a few minutes on a dual-core machine), because it would allow testing/debugging of the OpenMP parts of my code locally, in a nice OpenBSD environment fully under my control. ciao, -- -- "Jonathan Thornburg [remove -animal to reply]" Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA currently on the west coast of Canada "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
Re: OpenMP for both clang and GCC, part II
In message <https://marc.info/?l=openbsd-ports=155992865732530=1>, j () bitminer ! ca wrote [[about openmp]] > For long calculations, I have seen 2 cores with OpenMP take half the time > as one core with/without. So yes, it works. But Amdahl's Law applies. > If a calculation is long, and 20% is serial, and 80% parallelizable, > then the runtimes will be 100%, 60%, 46% and 40% at 1, 2, 3 and 4 cores. > The difference between 3 and 4 cores is not much. If 100% takes 4 hours, > then the difference between 1 and 2 cores is significant. I have a code which typically gets a speedup of ~6 using OpenMP on 8 cores and ~12 on 16 cores. Using OpenMP the code runs for anywhere from a few days to a few weeks, so the OpenMP speedup is very significant. The code is ~100K lines of C++, developed on OpenBSD, running on a Linux supercomputer. I added OpenMP support in 2015, so it's all guarded with an #ifdef which is disabled on OpenBSD. (Debugging the OpenMP directly on the supercomputer was slightly painful; fortunately this code's use of OpenMP is very simple, with only 3 parallel loops and one per-thread data structure in the entire code.) ciao, -- -- "Jonathan Thornburg [remove -animal to reply]" Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA currently on the west coast of Canada "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
arora core-dumps at startup (6.2/amd64)
Running 6.2-stable/amd64, arora (package arora-0.11.0p8) core-dumps on startup: % uname -a OpenBSD copper.astro.indiana.edu 6.2 GENERIC.MP#0 amd64 % pkg_info|grep arora arora-0.11.0p8 simple Qt4-based browser using WebKit % arora Failed to load translation: "C" Trace/BPT trap (core dumped) % env|grep LC % env|grep LANG % Has anyone else run into this problem? Is there a magic environment variable that should be set before starting arora to persuade it to try different language settings? I don't see anything relevant in 'man arora'. FWIW, using another machine that's still running 6.0/amd64 (package arora-0.11.0p7), arora gives the same startup message and then sits at 100% CPU for about 15 seconds on a 2GHz Core i7 (Lenovo Thinkpad T530)... but then works fine. Thanks, ciao, -- -- "Jonathan Thornburg [remove -animal to reply]" <jthorn4...@gmail-zebra.com> "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
Re: Chrome 40+ FIDO U2F Security Keys
Does anyone know the current status of this bug? The last update visible at https://bugs.chromium.org/p/chromium/issues/detail?id=451248 was 2016-05-16. ciao, -- -- "Jonathan Thornburg [remove -animal to reply]" <jth...@astro.indiana-zebra.edu> Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA "There was of course no way of knowing whether you were being watched at any given moment. How often, or on what system, the Thought Police plugged in on any individual wire was guesswork. It was even conceivable that they watched everybody all the time." -- George Orwell, "1984"
do/should we mark dependencies of broken packages as broken?
Hi, I'm running 5.1-stable/amd64. I'd like to install graphics/dvdrip. This depends on (among other things) x11/p5-Gtk2-Ex-FormFactory. There's a package for this, but 'pkg_add -vv p5-Gtk2-Ex-FormFactory-0.65p0.tgz' fails because it can't find a x11/p5-Gtk2 package: # setenv PKG_PATH .:http://mirrors.nycbug.org/pub/OpenBSD/5.1/packages/amd64/ # pkg_add -vv p5-Gtk2-Ex-FormFactory-0.65p0.tgz [[...]] Can't find p5-Gtk2-1.221p5 Direct dependencies for p5-Gtk2-Ex-FormFactory-0.65p0 resolve to p5-Gtk2-1.221p5 Can't install p5-Gtk2-Ex-FormFactory-0.65p0: can't resolve p5-Gtk2-1.221p5 --- p5-Gtk2-1.221p5 --- Can't install p5-Gtk2-1.221p5: not found # So, I tried building x11/p5-Gtk2, and discovered that it's marked as broken: # cd /usr/ports/x11/p5-Gtk2-Ex-FormFactory # make [[...]] === p5-Glib2-1.222p2 is marked as broken: glib2 is threaded but our perl is not so we end up with undefined symbols . *** Error code 1 Stop in /usr/ports/x11/p5-Gtk2 (line 1855 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/p5-Gtk2 (line 2197 of /usr/ports/infrastructure/mk/bsd.port.mk). # All this makes sense. My question is, since x11/p5-Gtk2 is currently broken, would it make sense to also mark the all the other x11/p5-Gtk2-* ports as broken? Or do we try to localize the broken info, and leave it up to try-to-build to propagate the dependencies? Enquiring minds etc... thanks, ciao, -- -- Jonathan Thornburg jth...@astro.indiana.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
Re: print/mpage will build, but dies in 'make install'
[[for the archive]] In http://marc.info/?l=openbsd-portsm=133756419607212w=1 I wrote I'm using 5.1-release/amd64 (just installed yesterday from the CD). I'm trying to build the print/mpage package. It builds fine, but dies during 'make install': [[...]] Problem solved -- the solution was as suggested by Landry Breuil in http://marc.info/?l=openbsd-portsm=133758725213147w=1: Something fucks up your perms on WRKOBJDIR .. is there a bkis user ? I had (have) a user bkis with uid 0 but a different shell/path/homedir than root. I had mistakenly put bkis before root when vipw-ing the password file. The fix was to put bkis after root (and add a note to my personal-list-of-postinstall-OpenBSD-configs to remind me to always do this in the future). My thanks to all who contributed to this thread! ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
print/mpage will build, but dies in 'make install'
/ports/infrastructure/mk/bsd.port.mk). # exit Script done on Sun May 20 21:21:51 2012 Any ideas on what's wrong? Is there a FM I should have read more carefully? ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
Re: print/mpage will build, but dies in 'make install'
Hi, I wrote: I'm using 5.1-release/amd64 (just installed yesterday from the CD). I'm trying to build the print/mpage package. It builds fine, but dies during 'make install': On Mon, 21 May 2012, Ian McWilliam wrote: Hmm not sure what's wrong with your boxen. Builds / Installs for me. I'll try nuking my /usr/ports tree and re-unpacking from the CD tar.gz and see if that helps any. ciao, -- -- Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy IUCSS, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
4.4-release amd64 xpdf-utils spurious? file conflict
for collisions in pdflib-4.0.3p2 Looking for collisions in gimp-2.4.6p1 Looking for collisions in glitz-0.5.6p0 Looking for collisions in apr-util-1.2.10p1 Looking for collisions in libdvd-0.3p2 Looking for collisions in xcdplayer-2.2p1 Looking for collisions in gnuchess-5.07 Looking for collisions in libdv-0.104p2 Looking for collisions in hicolor-icon-theme-0.10p1 Looking for collisions in grokking-the-gimp-1.0p0 Looking for collisions in mpeg_play-2.4p0 Looking for collisions in gdbm-1.8.3p0 Looking for collisions in libquicktime-1.0.2p1 Looking for collisions in python-2.5.2p4 Looking for collisions in glib2-2.16.4p1 Looking for collisions in tk-8.4.7p2 Looking for collisions in tiff-3.8.2p0 Looking for collisions in p5-HTML-Parser-3.56 Looking for collisions in regionset-0.1 Looking for collisions in mozilla-firefox-2.0.0.16p3 Looking for collisions in p5-Event-ExecFlow-0.63 Looking for collisions in libdvdnav-20051102p2 Looking for collisions in libwmf-0.2.8.3p4 Looking for collisions in nss-3.12 Looking for collisions in ghostscript-fonts-8.11p0 Looking for collisions in dvdbackup-0.1.1p2 Looking for collisions in jbigkit-1.6p1 Looking for collisions in g95-4.2.20070307p7 Looking for collisions in libmng-1.0.10 Looking for collisions in mjpegtools-1.9.0rc3p0-quicktime Looking for collisions in ted-2.17 Looking for collisions in subversion-1.4.4p0 Looking for collisions in rsync-3.0.3 Looking for collisions in cdparanoia-3.a9.8p0 Looking for collisions in metaauto-0.9 Looking for collisions in gv-3.5.8p4 Looking for collisions in libvorbis-1.2.0p0 Looking for collisions in sdl-1.2.13p3 Looking for collisions in lame-3.97p0 Looking for collisions in popt-1.7p0 Looking for collisions in tcl-8.4.7p6 Looking for collisions in p5-libintl-1.16p1 Looking for collisions in poppler-0.6.2p4 Looking for collisions in lsdvd-0.16 Looking for collisions in libcdio-0.80p2 Looking for collisions in libungif-4.1.4p1 Looking for collisions in desktop-file-utils-0.15 Looking for collisions in libmpcdec-1.2.6 Looking for collisions in libexif-0.6.16 Looking for collisions in antiword-0.37 Looking for collisions in freetype-doc-1.3.1 Looking for collisions in xuvmstat-20050909 Looking for collisions in t1lib-5.1.0p1 Looking for collisions in mpeg_encode-1.5b Looking for collisions in Xaw3d-1.5p1 Looking for collisions in aalib-1.4 Looking for collisions in ghostscript-8.62p2 Looking for collisions in tcsh-6.15.00 /usr/local/bin/pdffonts (different md5) /dev/sd0g: 2884083 bytes /dev/sd0e: 305 bytes /dev/sd0a: 3554 bytes /usr/sbin/pkg_add: fatal issues in installing xpdf-utils-3.02pl2p1 # pkg_info -E /usr/local/bin/pdffonts # exit Script done on Wed Dec 31 10:45:07 2008 ciao, -- -- From: Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
Re: 4.4-release amd64 xpdf-utils spurious? file conflict
Hi, On Wed, 31 Dec 2008, Stuart Henderson wrote: No idea why it happened (unless maybe there's some disk corruption, either in /usr/local or /var/db), but just removing the offending file should do the trick. Hmm, I tried that last week, and again this morning... but re-fetching the packages from the master OpenBSD site again, and retrying again with the offending file renamed out of the way, now xpdf* install ok. Thanks 1L20! I guess either the mirror I was fetching from last week was broken, or some link in the chain OpenBSD mirror site -- neighbor's house with wired internet -- neighbor's very weak wavelan signal in a snowstorm (yes, I had his permission to use it, he gave me the WPA key) -- wife's windows PC that grokked WPA encryption -- usb flash memory stick -- new OpenBSD system (which still doesn't have a working wavelan) corrupted one of my packages... Hmm, perhaps packages should have an embedded checksum to spot corruption? ciao, -- -- From: Jonathan Thornburg [remove -animal to reply] jth...@astro.indiana-zebra.edu Dept of Astronomy, Indiana University, Bloomington, Indiana, USA Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
i386 gcc4: gdb can't do stack traceback
Hi,
The i386 4.4-release gcc-4.2.20070307p7 package generates executables
for which gdb can't produce stack backtraces, either from a core dump
(e.g., as generated by assert(0)), or when the program is stopped at
a gdb breakpoint. The gcc3 in base (/usr/bin/gcc) has no problems
(i.e., it produces executables for which gdb *can* produce stack
backtraces).
gcc optimization does not seem to be an issue here: this behavior
is independent of whether I compile with '-g', '-g -O0', or '-g -O2'.
In contrast, on amd64, both the gcc3 in base (/usr/bin/gcd) *and*
the gcc-4.2.20070307p7 port have no problems. I have not tested
other architectures besides i386 and amd64.
I also see the same behavior with g++: the i386 g++4 package produces
executables for which gdb can't produce stack backtraces, while the
g++3 in base is ok, as are both the amd64 g++3 and g++4. I have seen
the same problems in past versions of OpenBSD (4.3-stable, 4.2-stable,
and earlier), though I don't have those installed any more to test.
Here's a simple test case to illustrate the problem for the i386
4.4-release gcc4:
Script started on Sun Dec 28 21:52:38 2008
% cat -n stack-bug2.c
1 #include stdio.h
2
3 /* prototypes */
4 void foo(int i);
5 void bar(int i);
6
7 int main(void)
8 {
9 foo(69);
10 return 0;
11 }
12
13 void foo(int i)
14 {
15 bar(i);
16 }
17
18 void bar(int i)
19 {
20 printf(hello, world: i=%d\n, i);
21 }
% /usr/local/bin/gcc --version
gcc (GCC) 4.2.0 20070307 (prerelease)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% /usr/local/bin/gcc -g -O0 -o stack-bug2 stack-bug2.c
% gdb stack-bug2
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-unknown-openbsd4.4...
(gdb) break stack-bug2.c:20
Breakpoint 1 at 0x1c0005d7: file stack-bug2.c, line 20.
(gdb) run
Starting program: /home/jonathan/sf/null/cctry/stack-bug2
Breakpoint 1, bar (i=69) at stack-bug2.c:20
20 printf(hello, world: i=%d\n, i);
(gdb) bt
#0 bar (i=69) at stack-bug2.c:20
#1 0x1c0005d7 in bar (i=69) at stack-bug2.c:19
#2 0x1c0005d7 in bar (i=469763433) at stack-bug2.c:19
#3 0x1c0005d7 in bar (i=1) at stack-bug2.c:19
#4 0x1c0005d7 in bar (i=0) at stack-bug2.c:19
#5 0x1c0005d7 in bar (i=Cannot access memory at address 0x9
) at stack-bug2.c:19
Previous frame inner to this frame (corrupt stack?)
(gdb) quit
The program is running. Exit anyway? (y or n) y
% exit
Script done on Sun Dec 28 21:53:25 2008
In contrast, here's this same test (identical source code) run on
amd64 4.4-release gcc4, where the stack traceback works fine:
Script started on Sun Dec 28 22:02:12 2008
% cat -n stack-bug2.c
1 #include stdio.h
2
3 /* prototypes */
4 void foo(int i);
5 void bar(int i);
6
7 int main(void)
8 {
9 foo(69);
10 return 0;
11 }
12
13 void foo(int i)
14 {
15 bar(i);
16 }
17
18 void bar(int i)
19 {
20 printf(hello, world: i=%d\n, i);
21 }
% /usr/local/bin/gcc --version
gcc (GCC) 4.2.0 20070307 (prerelease)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
% /usr/local/bin/gcc -g -O0 -o stack-bug2 stack-bug2.c
% gdb stack-bug2
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as amd64-unknown-openbsd4.4...
(gdb) break stack-bug2.c:20
Breakpoint 1 at 0x400845: file stack-bug2.c, line 20.
(gdb) run
Starting program: /home/jonathan/sf/null/cctry/stack-bug2
Breakpoint 1, bar (i=69) at stack-bug2.c:20
20 printf(hello, world: i=%d\n, i);
(gdb) bt
#0 bar (i=69) at stack-bug2.c:20
#1 0x00400838 in foo (i=69) at stack-bug2.c:15
#2 0x0040081e in main () at stack-bug2.c:9
(gdb) quit
The program is running. Exit anyway? (y or n) y
% exit
Script done on Sun Dec 28 22:02:49 2008
Is this a known problem with (hopefully) a known workaround? I've
searched the ports list, but not found any discussion of this.
--
-- From: Jonathan Thornburg [remove -animal to reply]
jth...@astro.indiana-zebra.edu
Dept of Astronomy, Indiana University
galeon-2.0.3p3 instant crash on File Print
Summary: OpenBSD4.3 i386 galeon-2.0.3p3 crashes instantly on any attempt to print a web page. Environment: OpenBSD i386 4.3-stable (CVS-updated on 27.May.2008), galeon-2.0.3p3 installed via pkg_add. Window manager is twm (also from packages); NOT using either KDE or Gnome. tcsh coredumpsize, set to 'unlimited'. Other environmental limits are quite generous (datasize 1GB, stacksize 32MB, memoryuse 'unlimited', descriptors 128). To repeat: At a shell prompt, type galeon http://www.google.com (or start galeon without a url, then type that url into the titlebar). The following error messages appear (but galeon continues running): % galeon http://www.google.com ** (galeon:25080): WARNING **: Spinner animation not found ** (galeon:25080): WARNING **: Spinner animation not found (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_connect' for stock: Icon 'stock_connect' not present in theme (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_fullscreen' for stock: Icon 'stock_fullscreen' not present in theme (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_connect' for stock: Icon 'stock_connect' not present in theme (galeon:25080): GLib-GObject-CRITICAL **: g_object_ref: assertion `G_IS_OBJECT (object)' failed (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_new-tab' for stock: Icon 'stock_new-tab' not present in theme (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_mail-send' for stock: Icon 'stock_mail-send' not present in theme (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_view-html-source' for stock: Icon 'stock_view-html-source' not present in theme (galeon:25080): Gtk-WARNING **: Error loading theme icon 'stock_new-tab' for stock: Icon 'stock_new-tab' not present in theme Then select File Print. The galeon window disappears immediately, and ps reports the galeon process is gone. The shell reports an exit status of 11. I can find no core-dump file. Interestingly printing (to a postscript file) worked fine for galeon-2.0.3p1 under 4.2-stable last month. ciao, -- -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
Re: galeon-2.0.3p3 instant crash on File Print
On Sat, 31 May 2008, I wrote: Summary: OpenBSD4.3 i386 galeon-2.0.3p3 crashes instantly on any attempt to print a web page. Environment: OpenBSD i386 4.3-stable (CVS-updated on 27.May.2008), galeon-2.0.3p3 installed via pkg_add. Window manager is twm (also from packages); NOT using either KDE or Gnome. tcsh coredumpsize, set to 'unlimited'. Other environmental limits are quite generous (datasize 1GB, stacksize 32MB, memoryuse 'unlimited', descriptors 128). [[...]] Here's my dmesg: OpenBSD 4.3 (GENERIC) #0: Tue May 27 12:06:32 BST 2008 [EMAIL PROTECTED]:/usr/src/sys/arch/i386/compile/GENERIC cpu0: Intel(R) Pentium(R) M processor 1700MHz (GenuineIntel 686-class) 1.70 GHz cpu0: FPU,V86,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,TM,SBF,EST,TM2 real mem = 1609527296 (1534MB) avail mem = 1547259904 (1475MB) mainbus0 at root bios0 at mainbus0: AT/286+ BIOS, date 04/07/04, BIOS32 rev. 0 @ 0xfd750, SMBIOS rev. 2.33 @ 0xe0010 (61 entries) bios0: vendor IBM version 1RETC2WW (3.03 ) date 04/07/2004 bios0: IBM 2373221 apm0 at bios0: Power Management spec V1.2 apm0: battery life expectancy 100% apm0: AC on, battery charge high acpi at bios0 function 0x0 not configured pcibios0 at bios0: rev 2.1 @ 0xfd6e0/0x920 pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfdea0/272 (15 entries) pcibios0: PCI Interrupt Router at 000:31:0 (Intel 82371FB ISA rev 0x00) pcibios0: PCI bus #6 is the last bus bios0: ROM list: 0xc/0x1 0xd/0x1000 0xd1000/0x1000 0xdc000/0x4000! 0xe/0x1 cpu0 at mainbus0 cpu0: Enhanced SpeedStep 1700 MHz (1484 mV): speeds: 1700, 1400, 1200, 1000, 800, 600 MHz pci0 at mainbus0 bus 0: configuration mode 1 (no bios) pchb0 at pci0 dev 0 function 0 Intel 82855PM Host rev 0x03 agp0 at pchb0: aperture at 0xd000, size 0x1000 ppb0 at pci0 dev 1 function 0 Intel 82855PM AGP rev 0x03 pci1 at ppb0 bus 1 vga1 at pci1 dev 0 function 0 ATI Radeon Mobility M10 NT rev 0x80 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) uhci0 at pci0 dev 29 function 0 Intel 82801DB USB rev 0x01: irq 11 uhci1 at pci0 dev 29 function 1 Intel 82801DB USB rev 0x01: irq 11 uhci2 at pci0 dev 29 function 2 Intel 82801DB USB rev 0x01: irq 11 ehci0 at pci0 dev 29 function 7 Intel 82801DB USB rev 0x01: irq 11 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 ppb1 at pci0 dev 30 function 0 Intel 82801BAM Hub-to-PCI rev 0x81 pci2 at ppb1 bus 2 cbb0 at pci2 dev 0 function 0 TI PCI4520 CardBus rev 0x01: irq 11 cbb1 at pci2 dev 0 function 1 TI PCI4520 CardBus rev 0x01: irq 11 em0 at pci2 dev 1 function 0 Intel PRO/1000MT (82540EP) rev 0x03: irq 11, address 00:0d:60:8e:fe:9e ipw0 at pci2 dev 2 function 0 Intel PRO/Wireless 2100 rev 0x04: irq 11, address 00:0c:f1:32:c4:4c cardslot0 at cbb0 slot 0 flags 0 cardbus0 at cardslot0: bus 3 device 0 cacheline 0x8, lattimer 0xb0 pcmcia0 at cardslot0 cardslot1 at cbb1 slot 1 flags 0 cardbus1 at cardslot1: bus 6 device 0 cacheline 0x8, lattimer 0xb0 pcmcia1 at cardslot1 ichpcib0 at pci0 dev 31 function 0 Intel 82801DBM LPC rev 0x01: 24-bit timer at 3579545Hz pciide0 at pci0 dev 31 function 1 Intel 82801DBM IDE rev 0x01: DMA, channel 0 configured to compatibility, channel 1 configured to compatibility wd0 at pciide0 channel 0 drive 0: HTS726060M9AT00 wd0: 16-sector PIO, LBA, 57231MB, 117210240 sectors wd0(pciide0:0:0): using PIO mode 4, Ultra-DMA mode 5 atapiscsi0 at pciide0 channel 1 drive 0 scsibus0 at atapiscsi0: 2 targets cd0 at scsibus0 targ 0 lun 0: TOSHIBA, DVD-ROM SD-R9012, 1121 SCSI0 5/cdrom removable cd0(pciide0:1:0): using PIO mode 4, Ultra-DMA mode 2 ichiic0 at pci0 dev 31 function 3 Intel 82801DB SMBus rev 0x01: irq 11 iic0 at ichiic0 spdmem0 at iic0 addr 0x50: 512MB DDR SDRAM non-parity PC2700CL2.5 spdmem1 at iic0 addr 0x51: 1GB DDR SDRAM non-parity PC2700CL2.5 auich0 at pci0 dev 31 function 5 Intel 82801DB AC97 rev 0x01: irq 11, ICH4 AC97 ac97: codec id 0x41445374 (Analog Devices AD1981B) ac97: codec features headphone, 20 bit DAC, No 3D Stereo audio0 at auich0 Intel 82801DB Modem rev 0x01 at pci0 dev 31 function 6 not configured usb1 at uhci0: USB revision 1.0 uhub1 at usb1 Intel UHCI root hub rev 1.00/1.00 addr 1 usb2 at uhci1: USB revision 1.0 uhub2 at usb2 Intel UHCI root hub rev 1.00/1.00 addr 1 usb3 at uhci2: USB revision 1.0 uhub3 at usb3 Intel UHCI root hub rev 1.00/1.00 addr 1 isa0 at ichpcib0 isadma0 at isa0 pckbc0 at isa0 port 0x60/5 pckbd0 at pckbc0 (kbd slot) pckbc0: using irq 1 for kbd slot wskbd0 at pckbd0: console keyboard, using wsdisplay0 pms0 at pckbc0 (aux slot) pckbc0: using irq 12 for aux slot wsmouse0 at pms0 mux 0 pcppi0 at isa0 port 0x61 midi0 at pcppi0: PC speaker spkr0 at pcppi0 lpt2 at isa0 port 0x3bc/4: polled aps0 at isa0 port 0x1600/31 npx0 at isa0 port 0xf0/16: reported by CPUID; using exception 16 fdc0 at isa0 port 0x3f0/6 irq 6 drq 2 biomask effd netmask effd ttymask
alpine-1.00 core dump in autocompleting file name for msg export
I am running a just-installed-last-week i386 4.3-release (planning to go to 4.3-stable next week), using the alpine-1.00 package as a mail client, connecting via imap to a Microsoft Exchange server at my workplace. With this setup, I can reproducibly core-dump alpine by trying to export certain messagges from my inbox or saved-mail folders to a local file, and using Tab to try to autocomplete the export pathname. The core-dump happens immediately after I enter the Tab. Typing the full export pathname manually (with no autocompletion) works fine (no core-dump). This problem did *not* occur with the prececessor pine-4.64p4 package in the same setup on 4.2-stable. A gdb stack-trace of the latest core-dump (trying to export a message to the pathname msg/misc/nanaimo.people with Tab typed after the i shows this: (gdb) bt #0 0x0c2fe28d in kill () from /usr/lib/libc.so.43.0 #1 0x0c3206d4 in __stack_smash_handler (func=0x3c020e9e pico_fncomplete, damaged=233308416) at /usr/src/lib/libc/sys/stack_protector.c:89 #2 0x1c0c9c82 in ?? () #3 0x3c020e9e in ?? () #4 0x0de80100 in ?? () #5 0x in ?? () (gdb) What further information should/could I supply to help in tracking down (fixing) the problem? ciao, -- -- Jonathan Thornburg [remove -animal to reply] [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
4.3-release tin-1.8.3 package missing shared library dependence
In message http://marc.info/?l=openbsd-portsm=120893732710669w=1, Giovanni Bechis bigionews () snb ! it wrote: Tin has a hidden dependency on libicuuc.so, I removed the test from configure. Being posted on 2008-04-23, this patch didn't make it into 4.3-release, whose tin-1.8.3 package is broken: % /usr/local/bin/tin /usr/local/bin/tin: can't load library 'libicuuc.so.0.0' % The purposes of this message is to record (for the archives) the fix: the missing library lives in the icu4c-3.6p1 package; pkg_add-ing that solved the problem (and adding a -r flag to my save-a-backup-copy-of-~/.newsrc-then-run-tin shell script brought me back to a working tin). ciao, -- -- Jonathan Thornburg [remove -animal to reply] [EMAIL PROTECTED] School of Mathematics, U of Southampton, England A sound banker, alas, is not one who foresees danger and avoids it, but one who, when he is ruined, is ruined in a conventional way along with his fellows, so that no one can really blame him. -- John Maynard Keynes
documentation bundle as part of netpbm OpenBSD package?
Hi, I've used netpbm for years, and for me it has only one flaw: no man pages. As Christian Weisgerber wrote in message http://marc.info/?l=openbsd-portsm=114904961711375w=1 (dated 31.May.2006) The upstream maintainer doesn't believe in man pages any more, so these are gone. I often work on a laptop when travelling, i.e. without a network connection, so having only documentation on the web site often means no documentation at all. So... what about providing a snapshot of the html docs (i.e. local html-docs tree) as part of the netpbm package? As it is, I (and anyone else who wants a local set of documentation) have to fumble around with each new OpenBSD version to get the right set of wget options to get a local copy of the netpbm web sit. ciao, -- -- Jonathan Thornburg (remove -animal to reply) [EMAIL PROTECTED] School of Mathematics, U of Southampton, England Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
how else to search ports other than 'make ports key=foo'?
The OpenBSD FAQ (section 15.3.4) suggests using 'make search key=foo' to search the ports tree. However, the 3.9-stable ports(7) man page describes this Makefile target as obsolescent. Are there nicer search mechanisms I should be using instead, and if so, could someone point me to the FM I should R to learn about them? (Ones I've tried include 'make print-index | less' followed by '/foo', and 'head -999 `find . -name DESCR | egrep foo`'.) thanks, ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
i386 3.8-stable xpdf-3.00p7 crash with /etc/malloc.conf - AFGJP
Hi, I have a reproducible xpdf core dump with i386 3.8-stable when /etc/malloc.conf is set to strict malloc checking. In more detail: i386 3.8-stable (cvs update 6.Apr.2006) /etc/malloc.conf - AFGJP packages: xpd-3.00p7 (= the latest version as of a couple of days ago) t1lib-5.0.0 (= ditto) The pdf file is: http://de.arxiv.org/pdf/astro-ph/0406242 Note you need to fetch it with an interactive web browser -- the site blocks access with wget et al, and they may need to regenerate the pdf when they see your request. Once you get the pdf, press the space bar twice to advance to page 3. Presto, core dump. (Note you do *not* get the core dump if you explicitly type 3 into the page-number field.) gdb reports the crash occurs in #0 0x0a951335 in T1_AADoLine () from /usr/local/lib/libt1.so.5.0 #1 0x0a951fd4 in T1_AASetChar () from /usr/local/lib/libt1.so.5.0 ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
x11/msttcorefonts won't build on 3.8-stable
Hi, I'm trying to get antialiased fonts going on an i386 laptop running 3.8-stable (/usr/src and /usr/ports cvs-updated on 26.Jan.2006). So, I read the Fine FAQ, and followed the instructions in entry 8.20: # pwd /usr/ports/x11/msttcorefonts # make === Checking files for msttcorefonts-1.2 andale32.exe doesn't seem to exist on this system. Attempting to fetch /usr/ports/distfiles/msttcorefonts-1.2/andale32.exe from http://ovh.dl.sourceforge.net/sourceforge/corefonts/. Size does not match for /usr/ports/distfiles/msttcorefonts-1.2/andale32.exe /bin/sh: test: 3: unexpected operator/operand *** Error code 2 Stop in /usr/ports/x11/msttcorefonts (line 1990 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/msttcorefonts (line 1444 of /usr/ports/infrastructure/mk/bsd.port.mk). *** Error code 1 Stop in /usr/ports/x11/msttcorefonts (line 1633 of /usr/ports/infrastructure/mk/bsd.port.mk). # I've searched the openbsd-ports list for 'msttcorefonts', but not found anything relevant. ciao, -- -- Jonathan Thornburg [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
Re: a problem with cfs cmkdir
[[discussion moved here from misc@ since cfs is a port]] In a recent msg to the openbsd-misc list, Rob wrote I've used the cryptographic file system (cfs) for years, but on 3.7 with the generic kernel, cmkdir hangs after entering the password the second time. I've never seen this behavior before. I've tried different ciphers to no avail. As cfs is kind of old software with little documentation, perhaps anyone who is successfully using it could just contact me off-list. Or if anyone else cares, on-list. In any case... I too have been using cfs (with no problems) for a long time (I've got lots of E-mail archives and personal correspondence stored under it). I don't have a 3.7 box right now, but as of 3.6-stable it seems fine... with the caveat that I don't think I've done any cmkdir-s for a while. I'll try some tests tonite for a confirmation and let you know. When you get cmkdir hanging, what does top(1) show -- is cmkdir and/or cfsd in an infinite-cpu loop, or just waiting? Are you able to cattach existing cfs filesystems and use them ok? ciao, -- -- Jonathan Thornburg -- remove -animal to reply [EMAIL PROTECTED] Max-Planck-Institut fuer Gravitationsphysik (Albert-Einstein-Institut), Golm, Germany, Old Europe http://www.aei.mpg.de/~jthorn/home.html Washing one's hands of the conflict between the powerful and the powerless means to side with the powerful, not to be neutral. -- quote by Freire / poster by Oxfam
