Re: AMD64 packages

[ian kremlin]

On Fri, Dec 12, 2014 at 2:02 PM, Ingo Schwarze  wrote:
>
> There are dragons.
>

ingo, theo:

sorry to post toxic advice, and thanks for the knowledge. i did not realize
how shlib_version worked. i must have gotten lucky with my build but i
should go back and fix it properly now

ian

Re: AMD64 packages

[Stan Gammons]

On Dec 12, 2014 1:06 PM, "Theo de Raadt"  wrote:
>
> > ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500:
> >
> > > whenever i grab a snapshot and get library version mismatches after a
> > > `pkg_add -u`, i've found the easiest way to get those objects
> >
> > Definitely not the easiest way.  Waiting for the next snapshot is
> > definitely much easier and safer for the average user.
> >
> > > is grab a fresh source tree and compile them manually.
> > > for example, libc:
> >
> > There are dragons.
>
>
> No, Ingo, stop right there.
>
> What he is trying to do is create a frankenstein.  People who do this
> will run into problems.
>
> Then they'll submit a bug report.
>
> It ends badly.
>

I never dreamed that asking a simple question of about how long it might be
before I could fix what I screwed up would end causing all of this.
Whenever new packages are available, I'll fix what I broke and try to not
do it again.

Stan

Re: AMD64 packages

[Theo de Raadt]

> ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500:
> 
> > whenever i grab a snapshot and get library version mismatches after a
> > `pkg_add -u`, i've found the easiest way to get those objects
> 
> Definitely not the easiest way.  Waiting for the next snapshot is
> definitely much easier and safer for the average user.
> 
> > is grab a fresh source tree and compile them manually.
> > for example, libc:
> 
> There are dragons.


No, Ingo, stop right there.

What he is trying to do is create a frankenstein.  People who do this
will run into problems.

Then they'll submit a bug report.

It ends badly.

Re: AMD64 packages

[Ingo Schwarze]

Hi Ian,

ian kremlin wrote on Thu, Dec 11, 2014 at 10:04:26PM -0500:

> whenever i grab a snapshot and get library version mismatches after a
> `pkg_add -u`, i've found the easiest way to get those objects

Definitely not the easiest way.  Waiting for the next snapshot is
definitely much easier and safer for the average user.

> is grab a fresh source tree and compile them manually.
> for example, libc:

There are dragons.  Sometimes, you need to do "make includes" in
the right directory first.  Then again, that tends to reinstall
*many* headers, not just those you care about right now, so be sure
you don't install some that hurt you.  Also, "make depend" can
sometimes be necessary, and you certainly should never forget about
"make obj".  When there is a flag day, very special steps may be
required before doing anything else or somewhere in the middle.
If you screw up, chances are you can't even do a clean shutdown any
longer and are in for fsck(8) and manually reinstalling working
libraries in single user mode before you can fully boot again.

If this scares anybody, i'm not surprised; updating libraries is
not a playground for newbies.

> cd /usr/src/lib/libc
> 
> edit 'shlib_version' to have the appropriate major/minor versions
> (pkg_add(1) will tell you which ones it wants.

That, actually, is *terrible* advice and almost guarantees a fiasco.
If you edit shlib_version manually, you build a library containing
code *incompatible* with what it's supposed to contain, so the end
result will be that programs using that library will, at run time,
 * crash,
 * produce obviously wrong results,
 * and/or silently produce results that are wrong in non-obvious ways.
Some programs, by mere luck, may also work, if you are lucky,
but it's hard to predict in advance which ones will and which 
ones wont.

To update a library, update all related source code - ideally,
the whole source tree unless you know precisely what you are
doing - to one consistent state, than compile from that state
*without* manually screwing with shlib_version.  That's the whole
point of library versioning!

> make && make install

The command "make install" in lib/libc is among the more
dangerous commands you might type, and if something is wrong,
recovery is often more difficult than recovery from less
scary errors.

> the bsd.port.mk(5) build system is well thought out

No objection here...

> and allows for straightforward, helpful maneuvers like this

 ... but i really wouldn't give it that twist.  Nothing about
what you said is straightforward or helpful.  It sounds more
like somewhere between foolhardy and suicidal.

> pkg_check(8) is also an invaluable tool in helping deal with package
> issues. also, use the right $PKG_PATH!

That's good advice again, for sure.

Yours,
  Ingo

Re: AMD64 packages

[Stuart Henderson]

On 2014-12-12, ian kremlin  wrote:
> whenever i grab a snapshot and get library version mismatches after a
> `pkg_add -u`, i've found the easiest way to get those objects is grab a
> fresh source tree and compile them manually. for example, libc:
>
> cd /usr/src/lib/libc
>
> edit 'shlib_version' to have the appropriate major/minor versions

This is bad advice. There is a reason why we bump library versions!

What you could do if you can't wait for new packages and don't have the
correct version of the library, is to identify the date/time when the
library was updated and e.g. "cvs up -D 2014/12/05" (i.e. before the
update) to fetch a copy of the source code for the library at the
version you need, and build that.

Re: CPU power consumption on thinkpad x201 on openbsd current

[Stefan Sperling]

On Wed, Jun 04, 2014 at 11:08:42PM +0200, Johan Svensson wrote:
> I'm trying to migrate from Linux to Openbsd on my laptop (thinkpad x201).
> 
> The first problem that i came across was that the Cpu fanspeed was running
> constantly at 3500RPM.
> After the acpithinkpad.c patch from jcs (and i modified to make it work on
> the openbsd-current(link: http://exclude.se/patch/jcs_mod_by_js.diff)
> 
> Another thing that i noticed is that the battery lifetime is really bad.
> In Linux i get around ~5,5 hours.
> In OpenBSD i get around 2 hours.
> 
> when i ran : sysctl hw.sensors | grep -i consumption.
> the output of the cpu was 6W.
> 
> in Linux it's around 1,5W.
> 
> with: apmd -C and apmd -L it's the same.
> dmesg: http://exclude.se/openbsd/dmesg.txt
> 
> Is there anyway to fix this?
> 
> Regards
> Johan Svensson

I've done some testing on an x201i and it seems the intel_powerclamp driver
("Package Level C-state Idle Injection for Intel CPUs") is responsible for
the difference in battery life. If that Linux driver is blacklisted battery
life drops to about the same levels as on OpenBSD.

Re: OpenBSD 5.6 - amd64 on Lenovo G480

[Ville Valkonen]

On 12 December 2014 at 03:50, Leonardo Santagostini
 wrote:
> Hello @misc,
>
> This mail is regarding about issues that im facing after doing a fresh
> install of 5.6 RELEASE and snapshot on my latptop
>
> The point is that after installing sucessfully i am trying to start X but
> screen goes black. The only way i have to go to console is pressing
> CTRL+ALT+F1 after lid close, suspend and resume.
>
> Just wanting to know what is the best way i can help you regarding this.
>
> i know sending:
>
> 1) dmesg
> 2) x.org.log
>
> Is ok, but i have no idea what else could help.
>
> So, please, just let me know what else is needed, so i can do my homework.
>
> (Also i tried snapshot from 12/08 but an libc version problem appears when
> x starts)
>
> Regards,
> Leonardo Santagostini
>
> 

Hello Leonardo,

have you done fw_update -v ? Hard to say if it's needed since you
didn't include the dmesg.

--
Regards,
Ville Valkonen

Re: Xorg fails PIII agp

[Koko Wijatmoko]

On Fri, 12 Dec 2014 07:03:56 -0430
elvis fuentes  wrote:

> [demime 1.01d removed an attachment of type application/octet-stream
> which had a name of LogXorg5.6]
> 
> [demime 1.01d removed an attachment of type application/octet-stream
> which had a name of dmesg54]
> 
> [demime 1.01d removed an attachment of type application/octet-stream
> which had a name of Xorg54Log]
> 
> [demime 1.01d removed an attachment of type application/octet-stream
> which had a name of dmesg5.6]

Your attachment is removed by list manager.
Copy paste inline within your email...

Xorg fails PIII agp

[elvis fuentes]

hi guys moving from openbsd 5.4 to 5.6 with a fresh install I've found Xorg
refuse to work.

I leave a Xorg and dmesg file with 5.4 and 5.6.


In the case of 5.4 xorg just works out of the box. I really don't know what
is missing.

thnks !!

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of LogXorg5.6]

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of dmesg54]

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of Xorg54Log]

[demime 1.01d removed an attachment of type application/octet-stream which had 
a name of dmesg5.6]

Re: problems compiling i386 from source (patching)

[Remco]

li...@ggp2.com wrote:

> I applied the newest unbound patch to several amd64 machines without
> trouble, and have had issues on several of my i386 boxes.  The initial
> error was probably the same as below, but led me to believe I may have
> had some kind of kernel or system "frankenbox" behavior.  I used cvs to
> pull all the latest sources ("cvs -q up -rOPENBSD_5_6 -Pd" is what I
> ran, so it should be the latest patch branch code),
> compiled/installed/rebooted to the new kernel, then ran through the
> steps for a make build.  make build bombed out on nsd with a similar
> error.
> 
> in unbound, running make -f Makefile.bsd-wrapper obj works fine, but
> make -f Makefile.bsd-wrapper produces the error (which I believe is what
> I initially saw):
> 
> ...
> checking for ctime_r... yes
> checking if make supports $< with implicit rule in scope... yes
> configure: Stripping extension flags...
> configure: creating ./config.status
> Bad system call (core dumped)
> config.status: creating Makefile
> Bad system call (core dumped)
> config.status: error: could not create Makefile
> *** Error 1 in /usr/src/usr.sbin/unbound (Makefile.bsd-wrapper:65
> '/usr/src/usr.sbin/unbound/obj/config.status')
> 
> 

I ran into this as well, and found a similar problem on the net. 
Unfortunately I didn't preserve the link but read on for a possible 
solution.

If your machine is upgraded all the time you may have /usr/bin/nawk getting 
in the way, which should have been removed during the 5.5->5.6 upgrade. 
(section "2. Files to delete and move") It seems I did at least the nsd part 
of this section, so I just (re)ran the first set of rm-s, which includes 
/usr/bin/nawk, and the problem was gone.

Re: Music On Console (MOC)

[Richard Toohey]

On 12/12/14 19:48, Ted Unangst wrote:

On Fri, Dec 12, 2014 at 15:00, Richard Toohey wrote:


(3) can help with the POSIX questions.

The maintainer has asked the same question on a MOC forum:

http://moc.daper.net/node/1369

I have no idea what posix features they want, so it's a tough question.

Thanks for all the replies - very much appreciated.

I think I should try a different tack - I'm not a MOC user nor a 
developer and I don't understand the POSIX issues.


If anyone using OpenBSD and MOC wants to ensure that future versions 
work on OpenBSD, then now is a good time to help out.  And best to 
contact the MOC developers directly: http://moc.daper.net/node/269.


Thanks,
Richard.

Re: DNS over IPSec weirdness

[David Dahlberg]

First of all, I have no real clue. It sound weird. But maybe I can help
you at least with that one:

Am Donnerstag, den 11.12.2014, 16:13 + schrieb Zé Loff:
> However, if I try to do something like "ping -c 1 www_lan.foo.bar" (or
> e.g. ssh) I can see the packets with the DNS request pass through enc0
> on the tunnel (and on the physical interface too) but nothing traffic
> shows up on enc0 on the other endpoint (I do believe they show up on
> the
> physical interface on that end, but my tcpdump foo isn't good enough
> to
> be sure).

You can get the IPsec SA SPIs and keys with the "ipsecctl -k -sa"
command.
Feed them into tcpdump with "-E espalg:espkey" (please read the man
page, before you do so). Wireshark may also decrypt your stream via the
ESP protocol settings.

-dd


-- 
David Dahlberg 

Fraunhofer FKIE, Dept. Communication Systems (KOM) | Tel: +49-228-9435-845
Fraunhoferstr. 20, 53343 Wachtberg, Germany| Fax: +49-228-856277