battery 100% full
current/amd64 on a Thinkpad T400 (dmesg below). The battery gets used, as batteries do. With AC connected: $ sysctl hw.sensors.acpibat0 hw.sensors.acpibat0.volt0=11.10 VDC (voltage) hw.sensors.acpibat0.volt1=12.37 VDC (current voltage) hw.sensors.acpibat0.power0=0.00 W (rate) hw.sensors.acpibat0.watthour0=14.75 Wh (last full capacity) hw.sensors.acpibat0.watthour1=0.74 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=14.75 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=48.84 Wh (design capacity) hw.sensors.acpibat0.raw0=0 (battery full), OK With AC disconnected: $ sysctl hw.sensors.acpibat0 hw.sensors.acpibat0.volt0=11.10 VDC (voltage) hw.sensors.acpibat0.volt1=11.90 VDC (current voltage) hw.sensors.acpibat0.power0=17.89 W (rate) hw.sensors.acpibat0.watthour0=14.75 Wh (last full capacity) hw.sensors.acpibat0.watthour1=0.74 Wh (warning capacity) hw.sensors.acpibat0.watthour2=0.20 Wh (low capacity) hw.sensors.acpibat0.watthour3=14.20 Wh (remaining capacity), OK hw.sensors.acpibat0.watthour4=48.84 Wh (design capacity) hw.sensors.acpibat0.raw0=1 (battery discharging), OK It only charges now to 14.75 Wh out of the original 48.84 Wh. Up to the last reboot, 'apm -l' used to tell that percentage. After the last reboot, it says 100%, because 14.75 is indeed 100% of the "last full capacity". My question is: what exactly makes 14.75 the last "full" capacity? How is that determined? Does the code for hw.sensors somehow observe the AC is connected, but it's not getting charged for the last $N minutes, so this must be the full capacity or is this just what the battery tells us via apcibat(4)? Possibly via "hw.sensors.acpibat0.raw0=full"? Perhaps this is intended; does it mean that once the battery gets to a capacity of 1Wh, then having it charged to 1Wh will be a "full" battery? Would it be better if apm -l said the battery is (14.75 / 48.84) full now? Jan
Re: battery 100% full
> My question is: what exactly makes 14.75 the last "full" capacity? > How is that determined? Does the code for hw.sensors somehow observe > the AC is connected, but it's not getting charged > for the last $N minutes, so this must be the full capacity > or is this just what the battery tells us via apcibat(4)? > Possibly via "hw.sensors.acpibat0.raw0=full"? It is all embedded code inside chip on the board. OpenBSD reads it and nothing more, I think. This was done by IBM/Lenovo to support your battery in time and to be able to alert user for a battery replacement operation. I remember back there it was an utility for T40 model which let you "recondition" the battery. It was Windows only, basicaly it was changing your battery and drain it again, at least what the user was able to see. I think a capacity calibration was done also, but no option to "reset" the capacity to the factory one. Sorry.
Re: battery 100% full
On 2015-02-12, Jan Stary wrote: > Would it be better if apm -l said the battery is > (14.75 / 48.84) full now? No, because then you wouldn't know when it had finished charging.
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-11, Hugo Osvaldo Barrera wrote: > Can > someone else confirm postgres9.4 work fine on the latest -snapshot? (the > confirmation would be helpful to reafirm that it's not an issue with some > dependency or library). Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64.
Isakmpd NAT-T interoperability
Hello,
As asked by Stuart, here are our exchanges regarding a problem I encountered
with isakmpd.
After applying the patch, I'm here to report my progress. I applied the patch
by hand on a stable 5.6 tree and didn't encountered any issue merging it.
In my first try, the VPN didnt went up. I was advertising
UDP_ENCAP_TUNNEL_DRAFT and that was not working. I updated the patch to
transmit UDP_ENCAP_TUNNEL instead (the same string the ASA was emmiting), then
the 3 SAs went up right away.
Here is the final patch I'm using :
Common subdirectories: src/sbin/isakmpd/CVS and src2/sbin/isakmpd/CVS
diff -uN src/sbin/isakmpd/attribute.c src2/sbin/isakmpd/attribute.c
--- src/sbin/isakmpd/attribute.cSat Apr 9 00:32:09 2005
+++ src2/sbin/isakmpd/attribute.c Tue Feb 3 12:29:04 2015
@@ -37,6 +37,9 @@
#include "log.h"
#include "isakmp.h"
#include "util.h"
+#if 1 /* XXX hshoexer */
+#include "sa.h"
+#endif
u_int8_t *
attribute_set_basic(u_int8_t *buf, u_int16_t type, u_int16_t value)
@@ -108,3 +111,30 @@
*attr = attribute_set_basic(*attr, attr_class, value);
return 0;
}
+
+#if 1 /* XXX hshoexer */
+int
+attribute_set_encap(char *section, char *tag, struct constant_map *map,
+ int attr_class, u_int8_t **attr, u_int32_t flags)
+{
+ char *name;
+ int value;
+
+ name = conf_get_str(section, tag);
+ if (!name) {
+ LOG_DBG((LOG_MISC, 70,
+ "attribute_set_constant: no %s in the %s section", tag,
+ section));
+ return -1;
+ }
+ if (flags & SA_FLAG_NAT_T_ENABLE) {
+ if (strcmp(name, "TUNNEL") == 0)
+ name = "UDP_ENCAP_TUNNEL";
+ else if (strcmp(name, "TRANSPORT") == 0)
+ name = "UDP_ENCAP_TRANSPORT";
+ }
+ value = constant_value(map, name);
+ *attr = attribute_set_basic(*attr, attr_class, value);
+ return 0;
+}
+#endif
diff -uN src/sbin/isakmpd/attribute.h src2/sbin/isakmpd/attribute.h
--- src/sbin/isakmpd/attribute.hFri May 14 10:42:56 2004
+++ src2/sbin/isakmpd/attribute.h Tue Feb 3 12:30:36 2015
@@ -41,6 +41,10 @@
extern u_int8_t*attribute_set_basic(u_int8_t *, u_int16_t, u_int16_t);
extern int attribute_set_constant(char *, char *, struct constant_map *,
int, u_int8_t **);
+#if 1 /* XXX hshoexer */
+extern int attribute_set_encap(char *, char *, struct constant_map *,
+ int, u_int8_t **, u_int32_t);
+#endif
extern u_int8_t*attribute_set_var(u_int8_t *, u_int16_t, u_int8_t *,
u_int16_t);
diff -uN src/sbin/isakmpd/ike_quick_mode.c src2/sbin/isakmpd/ike_quick_mode.c
--- src/sbin/isakmpd/ike_quick_mode.c Mon Dec 12 08:35:29 2011
+++ src2/sbin/isakmpd/ike_quick_mode.c Tue Feb 3 12:33:27 2015
@@ -621,9 +621,16 @@
}
conf_free_list(life_conf);
}
+ #if 1 /* XXX hshoexer */
+ attribute_set_encap(xf->field,
+ "ENCAPSULATION_MODE", ipsec_encap_cst,
+ IPSEC_ATTR_ENCAPSULATION_MODE, &attr,
+ msg->isakmp_sa->flags);
+ #else
attribute_set_constant(xf->field,
"ENCAPSULATION_MODE", ipsec_encap_cst,
IPSEC_ATTR_ENCAPSULATION_MODE, &attr);
+ #endif
if (proto_id != IPSEC_PROTO_IPCOMP) {
attribute_set_constant(xf->field,
Common subdirectories: src/sbin/isakmpd/obj and src2/sbin/isakmpd/obj
Common subdirectories: src/sbin/isakmpd/sysdep and src2/sbin/isakmpd/sysdep
- Forwarded message from Stuart Henderson -
From: Stuart Henderson
To: Claer
Subject: Re: Isakmpd NAT-T interoperability
Date: Mon, 9 Feb 2015 09:42:51 +
User-Agent: Mutt/1.5.23 (2014-03-12)
Thanks - would you mind posting results on the mailing list thread too, please?
It would be nice to draw more attention to this problem and it's more likely to
generate interest when multiple people are running into it ;-)
On 2015/02/09 10:40, Claer wrote:
> Hello,
>
> No problem, I built a stable release with the patch and will test it in the
> following days. I already got the acknowledge from the other IPSec endpoint.
>
> I'll keep you informed of the results.
> Thanks for the quick answer! (quicker than mine ;))
>
> Regards,
>
> Claer
>
> On Fri, Jan 30 2015 at 17:18, Stuart Henderson wrote:
>
> > Sorry no time to look at this now. Personally I'd just try the diff and
> > see if it applies, if it doesn't, look at the .rej file and hand apply those
> > bits. isakmpd hasn't changed much recently.
> >
> > On 2015/01/30 17:32, Claer wrote:
> > > Hello,
> > >
man -m: Bad argument
I have some man pages installed in $HOME/man so I ugment my manpath like this in my ~/.shrc test -d $HOME/man && alias man="man -m $HOME/man" Now man(1) complains saying $ man ls man: -m/home/hans/man: Bad argument Using "$HOME/man/" or "$HOME/man:" results in the same. Am I missing something obvious? Jan
Re: Best filesystem & options for large drive
Hello Nick, Wednesday, February 11, 2015, 1:05:20 PM, you wrote: NH> On 02/11/15 11:58, Jan Stary wrote: >> On Feb 10 17:48:22, na...@mips.inka.de wrote: >>> On 2015-02-10, yary wrote: >>> I know FFS2 can handle that size easily, but I'm worried about fsck taking forever. This machine will have 1.5GB RAM, from what I've read that's not enough memory to fsck a 4TB volume without painful swapping. >>> >>> It vastly depends on the number of files you have on there. >>> Here's an almost full 4TB drive... >> >> FAQ4 still says >> >>If you make very large partitions, keep in mind that performing >>filesystem checks using fsck(8) requires about 1M of RAM per gigabyte of >>filesystem size >>^^^ >> >> Does that still apply? >> >> Jan >> NH> It is probably far less than that currently, but lacking a more precise NH> number, I don't think this is a bad rule of thumb, and if you wish to NH> disregard it, I suspect you either read and really understand the code NH> or do some real world testing on YOUR hardware and file systems. The NH> penalties for too much RAM are minimal; the penalties for too little are NH> ... substantial. NH> Note that you don't have to leave file systems mounted RW all the time, NH> especially a backup server. Mount it RW when you need it, dismount or NH> RO it when you don't...tripping over the power power cords won't NH> (shouldn't?) corrupt a file system that is mounted RO. You don't get to NH> ignore the issues, but you can reduce their occurrence. I was entertaining the idea of making a 100 TB OpenBSD based archive storage, even asked the list. The only answer pointed to that FAQ page, and it stopped me from pursuing that idea. Servers with 128 GB of RAM aren't uncommon, but expensive (comparing to 64/32 GB ones). -- Best regards, Borismailto:bo...@twopoint.com
Re: man -m: Bad argument
On Thu, 12 Feb 2015, Jan Stary wrote: > I have some man pages installed in $HOME/man > so I ugment my manpath like this in my ~/.shrc > > test -d $HOME/man && alias man="man -m $HOME/man" > > Now man(1) complains saying > > $ man ls > man: -m/home/hans/man: Bad argument > > Using "$HOME/man/" or "$HOME/man:" results in the same. > > Am I missing something obvious? > > Jan > What does it show when you run the alias command with no arguments to display your current aliases? I noticed that in the error message there is no space between -m and the path. That seems a bit odd. Your `test -d $HOME/man && alias man="man -m $HOME/man"` works fine for me in ksh when I put it in a .profile on 5.6 -stable. -- John Merriam
Re: Best filesystem & options for large drive
On 02/12/15 10:10, Boris Goldberg wrote: > Hello Nick, ... > I was entertaining the idea of making a 100 TB OpenBSD based archive > storage, even asked the list. The only answer pointed to that FAQ page, and > it stopped me from pursuing that idea. Servers with 128 GB of RAM aren't > uncommon, but expensive (comparing to 64/32 GB ones). I don't care what OS you are using, 100TB single volume "archive" is doing it wrong. Chunk your data, you will thank me; when it comes time to upgrade and migrate your hardware, you will be kissing my feet. The numbers have changed a bit (for the bigger) but the idea is as valid today as it was eight years ago: http://archives.neohapsis.com/archives/openbsd/2007-04/1572.html Nick.
Re: man -m: Bad argument
On Feb 12 11:12:46, j...@johnmerriam.net wrote: > On 2015-02-12 10:50, Jan Stary wrote: > >On Feb 12 10:15:08, j...@johnmerriam.net wrote: > >>What does it show when you run the alias command with no arguments to > >>display your current aliases? > >> > >>I noticed that in the error message there is no space between -m and the > >>path. That seems a bit odd. > > > >$ alias > >autoload='typeset -fu' > >diff='diff -Nup' > >functions='typeset -f' > >hash='alias -t' > >history='fc -l' > >integer='typeset -i' > >ll='ls -lAp' > >local=typeset > >login='exec login' > >ls='ls -p' > >man='man -m /home/hans/man' > >nohup='nohup ' > >pdftops='pdftops -paper A4' > >r='fc -e -' > >stop='kill -STOP' > >type='whence -v' > > > > > >In particular, the space is there, as specified in the alias command. > >But the problem is probably not in the aliases: > > > >$ unalias man > >$ man -m ~/man ls > >man: -m/home/hans/man: Bad argument > > > > Jan > > I would assume it would cause you more problems than just man if it were the > case, but, if you do a `vis /etc/passwd`, are there any funny characters in > the home directory for your username? Just a thought since that space > between -m and the path seems to disappear in the error. No. > If you leave out -m /path and just run `man ls`, does that work? With man unaliased, it works just fine. With 'man -m ~/man', or with man aliased to that, 'man ls' gave me the error above. > Also, which version of OpenBSD are you running on this machine? > 5.6 or -current? current/amd64 Jan
Re: man -m: Bad argument
Do you have another man installed somewhere? $ man -V mandoc 1.13.2
Re: man -m: Bad argument
On Feb 12 11:29:18, tro...@gmail.com wrote: > Do you have another man installed somewhere? No. > $ man -V > mandoc 1.13.2 Yes.
Re: man -m: Bad argument
On Thu, 12 Feb 2015, Jan Stary wrote: > On Feb 12 11:12:46, j...@johnmerriam.net wrote: > > On 2015-02-12 10:50, Jan Stary wrote: > > >On Feb 12 10:15:08, j...@johnmerriam.net wrote: > > >>What does it show when you run the alias command with no arguments to > > >>display your current aliases? > > >> > > >>I noticed that in the error message there is no space between -m and the > > >>path. That seems a bit odd. > > > > > >$ alias > > >autoload='typeset -fu' > > >diff='diff -Nup' > > >functions='typeset -f' > > >hash='alias -t' > > >history='fc -l' > > >integer='typeset -i' > > >ll='ls -lAp' > > >local=typeset > > >login='exec login' > > >ls='ls -p' > > >man='man -m /home/hans/man' > > >nohup='nohup ' > > >pdftops='pdftops -paper A4' > > >r='fc -e -' > > >stop='kill -STOP' > > >type='whence -v' > > > > > > > > >In particular, the space is there, as specified in the alias command. > > >But the problem is probably not in the aliases: > > > > > >$ unalias man > > >$ man -m ~/man ls > > >man: -m/home/hans/man: Bad argument > > > > > > Jan > > > > I would assume it would cause you more problems than just man if it were the > > case, but, if you do a `vis /etc/passwd`, are there any funny characters in > > the home directory for your username? Just a thought since that space > > between -m and the path seems to disappear in the error. > > No. > > > If you leave out -m /path and just run `man ls`, does that work? > > With man unaliased, it works just fine. > With 'man -m ~/man', or with man aliased to that, > 'man ls' gave me the error above. > > > Also, which version of OpenBSD are you running on this machine? > > 5.6 or -current? > > current/amd64 > > Jan > > Hmmm. There was one small change to man.c on January 16th but it doesn't look like that should be the problem I wouldn't think. Previous change was back in 2013. It is also possible it is something funny with shell expansion or something. Which shell are you using? I just blew away my -current machine the other day. I don't have -current running any more so I can't try to duplicate it for you. If no one else answers the thread on misc I would recommend sumitting a bug with sendbug. -- John Merriam
Re: man -m: Bad argument
On 2/12/15, John Merriam wrote: > On Thu, 12 Feb 2015, Jan Stary wrote: >> On Feb 12 11:12:46, j...@johnmerriam.net wrote: >> > On 2015-02-12 10:50, Jan Stary wrote: >> > >On Feb 12 10:15:08, j...@johnmerriam.net wrote: >> > >>What does it show when you run the alias command with no arguments to >> > >>display your current aliases? >> > >> >> > >>I noticed that in the error message there is no space between -m and >> > >> the >> > >>path. That seems a bit odd. >> > > >> > >$ alias >> > >autoload='typeset -fu' >> > >diff='diff -Nup' >> > >functions='typeset -f' >> > >hash='alias -t' >> > >history='fc -l' >> > >integer='typeset -i' >> > >ll='ls -lAp' >> > >local=typeset >> > >login='exec login' >> > >ls='ls -p' >> > >man='man -m /home/hans/man' >> > >nohup='nohup ' >> > >pdftops='pdftops -paper A4' >> > >r='fc -e -' >> > >stop='kill -STOP' >> > >type='whence -v' >> > > >> > > >> > >In particular, the space is there, as specified in the alias command. >> > >But the problem is probably not in the aliases: >> > > >> > >$ unalias man >> > >$ man -m ~/man ls >> > >man: -m/home/hans/man: Bad argument >> > > >> > > Jan >> > >> > I would assume it would cause you more problems than just man if it were >> > the >> > case, but, if you do a `vis /etc/passwd`, are there any funny characters >> > in >> > the home directory for your username? Just a thought since that space >> > between -m and the path seems to disappear in the error. >> >> No. >> >> > If you leave out -m /path and just run `man ls`, does that work? >> >> With man unaliased, it works just fine. >> With 'man -m ~/man', or with man aliased to that, >> 'man ls' gave me the error above. >> >> > Also, which version of OpenBSD are you running on this machine? >> > 5.6 or -current? >> >> current/amd64 >> >> Jan >> >> > > Hmmm. There was one small change to man.c on January 16th but it doesn't > look like that should be the problem I wouldn't think. Previous change > was back in 2013. > > It is also possible it is something funny with shell expansion or > something. Which shell are you using? > > I just blew away my -current machine the other day. I don't have > -current running any more so I can't try to duplicate it for you. > It's working fine here. Space, no space, aliased, unaliased. What's in your home man directory? Try it with a different, non-man directory. Complains it can't find mandoc.db but it still works. Tim.
Re: man -m: Bad argument
Ok, I don't know how this is controled, but the problem is, you are actually running mandoc for which, -m means something different. I am running actual man, I guess. I just updated -current this morning (snapshot from 2/10) so I don't know what the difference is.
Re: battery 100% full
Hi, Jan Stary wrote: Perhaps this is intended; does it mean that once the battery gets to a capacity of 1Wh, then having it charged to 1Wh will be a "full" battery? Would it be better if apm -l said the battery is (14.75 / 48.84) full now? Exctly that. At each cycle, every battery, but especially LiIon, loose a bit of its capacity. So at every cycle your 100% will be less real capacity. Suppose that everytime you use gas in your car's tank, some residue remains, filling it up. But when it is full it is full, so that's 100%, even if the total gallons are less. So your total mileage drops, but you still need to know when it is empty (= you need to seek a gas station). The difficult part is that you can't measure how full it is, the circuitry tries to estimate that, so the comparison is valid only to a certain extent. A Li-Ion battery never has to be totally depleted and shall not be overcharged, so this is somehow tricky. If the drop is well estimated, everything is fine. The problem I discovered is that since your battery is made of many elements, if some ruin before others then the estimate is usually wrong, e.g. overestimated. In any case all this data is in the battery controller. OpenBSD just reads those values, you are free to interpret them. A full cycle, up to when the computer goes to shut/down, helps to recalibrate, but doesn't make miracles and with modern batteries works not so well. Riccardo
Re: man -m: Bad argument
Hi Jan, Jan Stary wrote on Thu, Feb 12, 2015 at 02:52:33PM +0100: > I have some man pages installed in $HOME/man > so I augment my manpath like this in my ~/.shrc > > test -d $HOME/man && alias man="man -m $HOME/man" > > Now man(1) complains saying > > $ man ls > man: -m/home/hans/man: Bad argument I fail to reproduce on -current, it works for me. Jan Stary wrote on Thu, Feb 12, 2015 at 05:17:52PM +0100: > With man unaliased, it works just fine. > With 'man -m ~/man', or with man aliased to that, > 'man ls' gave me the error above. [...] > current/amd64 How old is that -current, exactly? As a rough indication, please show the output of "dmesg | head -n2". If you snapshot is older than http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/main.c#rev1.115 (December 21, 2014), you are falling prey to a bug reported almost two months ago by Alessandro de Laurenzis (and fixed back then). John Merriam wrote on Thu, Feb 12, 2015 at 10:15:08AM -0500: > I noticed that in the error message there is no space between -m > and the path. That seems a bit odd. It is odd. It is a remnant from the pre-POSIX past. Traditional roff programs did not use spaces between their options and option arguments, and that tradition is still somewhat alive. For example, most people would probably consider groff -mdoc -Tascii -P-c /usr/share/man/man1/ls.1 more natural than groff -m doc -T ascii -P -c /usr/share/man/man1/ls.1 even though both work exactly the same way. The mandoc(1) utility handles both forms, too. In the documentation, i use the modern form at some places (for example, see the man(1) manual in -current) but the traditional form in other places (for example, see the mandoc(1) manual in -current). I should probably clean that up to use the modern form everywhere. The error messages all used the traditional form in the past, but used the modern form now (changed in the same commit main.c rev. 1.115 mentioned above). > Your `test -d $HOME/man && alias man="man -m $HOME/man"` works fine > for me in ksh when I put it in a .profile on 5.6 -stable. Oh, -stable is a completely different beast. While -current is using the mandoc implementation of man(1), -stable is using the traditional BSD implementation. trondd wrote on Thu, Feb 12, 2015 at 11:29:18AM -0500: > $ man -V > mandoc 1.13.2 That means very little on OpenBSD, mandoc(1) and man(1) are moving targets on OpenBSD and i only crank the version number rarely, when doing portable releases. The version number is mostly for the benefit of non-OpenBSD systems, in particular NetBSD, FreeBSD, DragonFly, illumos and the Linux distributions using it, that is, currently Void, Alpine, Arch and Crux Linux. John Merriam wrote on Thu, Feb 12, 2015 at 11:45:21AM -0500: > Hmmm. There was one small change to man.c on January 16th > but it doesn't look like that should be the problem I wouldn't > think. Previous change was back in 2013. Oh, you mean Theo's commit http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/man/man.c#rev1.49 That's actually changing dead code that is no longer compiled, and on top of that, it's changing the code in an incorrect way such that it won't compile even if you try to build it manually: $ cd /usr/src/usr.bin/man $ make man.o [...] /usr/src/usr.bin/man/man.c:228: error: 'MACHINE' undeclared [...] I didn't complain because, well, people can break dead code as much as they like. After unlock, i'm planning to delete that file from CVS anyway. The code we are talking about is in /usr/src/usr.bin/mandoc/main.c, not in /usr/src/usr.bin/man/man.c. > If no one else answers the thread on misc I would recommend > sumitting a bug with sendbug. Correct in general, but not really needed for issues with mandoc(1) and man(1). I do read misc@. trondd wrote on Thu, Feb 12, 2015 at 12:05:40PM -0500: > Ok, I don't know how this is controled, but the problem is, you are > actually running mandoc for which, -m means something different. Which implementation of man(1) you are using depends on which version of OpenBSD you are running... ;-) Indeed, "mandoc -m" means "select macro language" while "man -m" means "prepend to man path". But the mandoc implementation of man(1) and mandoc(1) is supposed to know the difference and handle both correctly. Yours, Ingo
Re: man -m: Bad argument
On Feb 12 19:20:05, schwa...@usta.de wrote: > Jan Stary wrote on Thu, Feb 12, 2015 at 02:52:33PM +0100: > > > I have some man pages installed in $HOME/man > > so I augment my manpath like this in my ~/.shrc > > > > test -d $HOME/man && alias man="man -m $HOME/man" > > > > Now man(1) complains saying > > > > $ man ls > > man: -m/home/hans/man: Bad argument > > I fail to reproduce on -current, it works for me. Hm, I just upgraded to current and it disappeared. > Jan Stary wrote on Thu, Feb 12, 2015 at 05:17:52PM +0100: > > > With man unaliased, it works just fine. > > With 'man -m ~/man', or with man aliased to that, > > 'man ls' gave me the error above. > [...] > > current/amd64 > > How old is that -current, exactly? > As a rough indication, please show the output of "dmesg | head -n2". OpenBSD 5.6-current (GENERIC.MP) #623: Tue Dec 16 00:32:49 MST 2014 dera...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC.MP > If you snapshot is older than > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/mandoc/main.c#rev1.115 > (December 21, 2014), you are falling prey to a bug reported almost > two months ago by Alessandro de Laurenzis (and fixed back then). Ha, that was probably it then. > John Merriam wrote on Thu, Feb 12, 2015 at 10:15:08AM -0500: > > > I noticed that in the error message there is no space between -m > > and the path. That seems a bit odd. > > It is odd. It is a remnant from the pre-POSIX past. > Traditional roff programs did not use spaces between their > options and option arguments, and that tradition is still > somewhat alive. For example, most people would probably > consider > > groff -mdoc -Tascii -P-c /usr/share/man/man1/ls.1 > > more natural than > > groff -m doc -T ascii -P -c /usr/share/man/man1/ls.1 > > even though both work exactly the same way. The mandoc(1) utility > handles both forms, too. In the documentation, i use the modern > form at some places (for example, see the man(1) manual in -current) > but the traditional form in other places (for example, see the > mandoc(1) manual in -current). I should probably clean that up to > use the modern form everywhere. The error messages all used the > traditional form in the past, but used the modern form now (changed > in the same commit main.c rev. 1.115 mentioned above). > > > Your `test -d $HOME/man && alias man="man -m $HOME/man"` works fine > > for me in ksh when I put it in a .profile on 5.6 -stable. > > Oh, -stable is a completely different beast. While -current is > using the mandoc implementation of man(1), -stable is using the > traditional BSD implementation. I was confused trying to spot my problem in current man.c, thanks for the insight. Jan
Re: postgresql-server exiting abnormally after upgrade to -snapshot
On 2015-02-12 10:18, Stuart Henderson wrote: > On 2015-02-11, Hugo Osvaldo Barrera wrote: > > Can > > someone else confirm postgres9.4 work fine on the latest -snapshot? (the > > confirmation would be helpful to reafirm that it's not an issue with some > > dependency or library). > > Works fine on my bacula box, running 9.4.1 (and previously 9.4.0) on amd64. > Ok, so now I know that the issue is on my end. Which leaves me even more confused. You're running the latest snapshots too, right? (eg: the ones from feb 10th?). Aside from a clean install, do you have any more changes? Perhaps login.conf? Thanks, -- Hugo Osvaldo Barrera A: Because we read from top to bottom, left to right. Q: Why should I start my reply below the quoted text? [demime 1.01d removed an attachment of type application/pgp-signature]
Re: Hannover BSD meetup
Hi, just a reminder - we'll have our "Hannover BSD meetup" next week. And due to the positive feedback, I would appreciate if you'd optionally drop me a private note if you're intending to attend. We'll have some users and OpenBSD developers joining us. The people at the bar got concerned when we told them "we don't know how many people - we announced it publically in the Internet" ;) Ok, time to pack my stuff and to leave #s2k15 and Australia... Reyk On Thu, Jan 22, 2015 at 03:02:30PM +0100, Reyk Floeter wrote: > Hi, > > we figured out that there are more BSD people in the Hannover area, > Germany, which seems to be a good reason to meet and get beer. > > We're not quite a user group, but let's give it a try. We're a few > developers and users, mostly from OpenBSD but the other ones are > welcome. > > We don't have a mailing list; just contact me directly or poke me on > twitter (@reykfloeter). > > Save the date: Thursday, February 19th, 19:30 at "GiG Linden". > > Thanks, > Reyk --
Mutt Sidebar not working properly
Hello all: I installed the binary mutt last week with the compressed, sasl, and sidebar flavors. I also used my standard .muttrc from other systems. Everything worked fine except the sidebar. While all folders are present, and I can scroll to any folder, no folder will open. The folders do seem to be in sync, though. As an exercise, I deleted the package and compiled the port with the gpgme, sasl, and sidebar flavors; there was no difference as to the sidebar issue. My current system is OpenBSD 5.7 GENERIC.MP#834 amd64 -current to Feb. 2. I am using IMAP. Any hints as to where the issue may lie are appreciated. If my .muttrc, dmesg or anything else is needed, please let me know. Thanks.
Re: pax: directory traversal (from CVE request)
On Tue, Jan 13, 2015 at 4:58 AM, Daniel Cegiełka wrote: > http://www.openwall.com/lists/oss-security/2015/01/07/5 > > Does someone can confirm this vulnerability? It's probably the problem > of "OpenBSD-derived (?) pax". Thanks for bringing this to our attention! After much thrashing around, I believe I've got the tar issues addressed in -current. We probably won't add an option for cpio to match tar's -P option (we aren't big fans of --long-options and what masochist uses cpio for anything but a historical application?), but adding a -o suboption to pax to match tar's -P is probably in order. Let me know if you find I've missed anything. Errata for 5.5/5.6 will occur when travel interruptions permit. Philip Guenther
Re: Audio probles like, slow response in applications that use audio and a little noise in the background
Hi, Just an update. I continue with the lag. So I decided to try other players, and I discovered that ffplay from ffmpeg don't lag, this is the only one I found that works, with both audio and video. But the problem isn't solved yet since I like cmus and mplayer and I wanna use them. This is really strange, why this could happen? Audio lag in html5, mplayer and cmus, but workin on ffplay? I need help On Wed, Feb 11, 2015 at 04:54:54PM -0200, Henrique Lengler wrote: > First thanks for helping! > > On Wed, Feb 11, 2015 at 09:29:04AM +0100, Alexandre Ratchov wrote: > > the noise might be caused by a noisy microphone amp (even if > > there's no microphone plugged). By mutting the microphoe, the noise > > may disappear. Could you post the output of "mixerctl -a" ? > > Thanks, first problem solved, I did $ mixerctl inputs.mic=0,0 and the noise > stoped. > > /* mixerctl -a */ > > inputs.dac-0:1=108,108 > inputs.dac-2:3=126,126 > inputs.dac-4:5=126,126 > inputs.dac-6:7=108,108 > record.adc-0:1_mute=off > record.adc-0:1=125,125 > record.adc-2:3_mute=off > record.adc-2:3=125,125 > inputs.mix_source=mic,mic2,line-in,hp,line > inputs.mix_mic=120,120 > inputs.mix_mic2=120,120 > inputs.mix_line-in=120,120 > inputs.mix_hp=120,120 > inputs.mix_line=120,120 > inputs.mix2_source=dac-0:1,mix > inputs.mix3_source=dac-2:3,mix > inputs.mix4_source=dac-4:5,mix > inputs.mix5_source=dac-6:7,mix > outputs.SPDIF_source=dig-dac-0:1 > outputs.line_source=mix2 > outputs.line_mute=off > outputs.line_dir=output > outputs.line_boost=off > outputs.line_eapd=on > outputs.mic_source=mix3 > outputs.mic_mute=on > inputs.mic=0,0 > outputs.mic_dir=input-vr80 > outputs.mic2_source=mix8 > outputs.mic2_mute=off > inputs.mic2=85,85 > outputs.mic2_dir=input-vr80 > outputs.mic2_boost=off > outputs.line-in_source=mix4 > outputs.line-in_mute=off > inputs.line-in=85,85 > outputs.line-in_dir=input > outputs.hp_source=mix5 > outputs.hp_mute=off > inputs.hp=85,85 > outputs.hp_dir=output > outputs.hp_boost=off > outputs.hp_eapd=on > record.adc-2:3_source=mic,mic2,line-in,hp,line,mix > record.adc-0:1_source=mic,mic2,line-in,hp,line,mix > inputs.dac-8:9=126,126 > inputs.mix8_source=dac-8:9,mix > outputs.line_sense=plugged > outputs.mic_sense=unplugged > outputs.mic2_sense=unplugged > outputs.line-in_sense=unplugged > outputs.hp_sense=unplugged > outputs.master=110,110 > outputs.master.mute=off > outputs.master.slaves=dac-0:1,dac-6:7,line,hp > record.volume=125,125 > record.volume.mute=off > record.volume.slaves=adc-0:1,adc-2:3 > outputs.mode=analog > > > > I installed cmus, copied some musics to my disk and started to listen. > > > It plays normally, but when I click the arrows to advance in the music, I > > > noticed it have a delay, and it lags if I click like 3 times to advance. > > > And if click to close the application, the application close in the same > > > time, > > > but the audio stay playing for a while. > > > > > > The next thing is mplayer, It lag to advance the video (as cmus), but > > > it don't stay playing when I click close. > > > > How long is the lag? > > It's about 1.5 - 2 seconds. This really sucks I need to advance the music and > click more than once. > > > By default the buffer size is large which causes around 0.2 second > > of extra lag but makes audio stable (this is to allow audio to > > kinda work on busy or on MP systems). You could try to use smaller > > buffers, for instance add: > > > > sndiod_flags="-z 480" > > > > to /etc/rc.conf.local and restart sndiod with: > > > > /etc/rc.d/sndiod restart > > This didn't solved, maybe the audio is a little faster, but continue more > than 1 sec of delay. > > -- > Regards > > Henrique Lengler > -- Regards Henrique Lengler
Re: Mutt Sidebar not working properly
Hi, I'd say its way easier to help you and debug it with your .muttrc-file. I'm using sidebar with mutt and have no issues with it. Send both mutt -v output and .muttrc Cheers, Alexander On 2015-02-12 20:19:05, Dutch Ingraham wrote: > Hello all: > > I installed the binary mutt last week with the compressed, sasl, and sidebar > flavors. I also used my standard .muttrc from other systems. Everything > worked fine except the sidebar. While all folders are present, and I can > scroll to any folder, no folder will open. The folders do seem to be in sync, > though. > > As an exercise, I deleted the package and compiled the port with the gpgme, > sasl, and sidebar flavors; there was no difference as to the sidebar issue. > > My current system is OpenBSD 5.7 GENERIC.MP#834 amd64 -current to Feb. 2. I > am using IMAP. > > Any hints as to where the issue may lie are appreciated. If my .muttrc, dmesg > or anything else is needed, please let me know. Thanks.
Re: Mutt Sidebar not working properly
On February 13, 2015 2:19:05 AM CET, Dutch Ingraham wrote: >Hello all: > >I installed the binary mutt last week with the compressed, sasl, and >sidebar >flavors. I also used my standard .muttrc from other systems. >Everything >worked fine except the sidebar. While all folders are present, and I >can >scroll to any folder, no folder will open. The folders do seem to be >in sync, >though. > >As an exercise, I deleted the package and compiled the port with the >gpgme, >sasl, and sidebar flavors; there was no difference as to the sidebar >issue. > >My current system is OpenBSD 5.7 GENERIC.MP#834 amd64 -current to Feb. >2. I >am using IMAP. > >Any hints as to where the issue may lie are appreciated. If my >.muttrc, dmesg >or anything else is needed, please let me know. Thanks. Please note that selecting a folder does not immediately open it. Opening it is a command of its own. I can't remember which right now, though. /Alexander
