AMD64 packages

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

AMD64 packages

Stan Gammons-2
When will new packages be built for AMD64?   I'm getting library errors
with the latest snapshot and the current packages.

Stan

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

STeve Andre'
On 12/10/14 20:51, Stan Gammons wrote:
> When will new packages be built for AMD64?   I'm getting library errors
> with the latest snapshot and the current packages.
>
> Stan
>
>
They come out frequently, but not on a set schedule.  Since the
last set came out on the 6th, I would expect the next set in the
next several days -- unless some change caused a cascade of
non-compiles in which case the problem will be worked on before
the next release.

You might want to subscribe to the ports-changes changes list,
which will show you what's been changed.  The source-changes
list will show you all the other cvs commits.  Look at

http://www.openbsd.org/mail.html

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Stan Gammons-2
On Dec 10, 2014 10:03 PM, "STeve Andre'" <[hidden email]> wrote:

>
> On 12/10/14 20:51, Stan Gammons wrote:
>>
>> When will new packages be built for AMD64?   I'm getting library errors
>> with the latest snapshot and the current packages.
>>
>> Stan
>>
>>
> They come out frequently, but not on a set schedule.  Since the
> last set came out on the 6th, I would expect the next set in the
> next several days -- unless some change caused a cascade of
> non-compiles in which case the problem will be worked on before
> the next release.
>
> You might want to subscribe to the ports-changes changes list,
> which will show you what's been changed.  The source-changes
> list will show you all the other cvs commits.  Look at
>
> http://www.openbsd.org/mail.html

Ok.  The way I normally update is by downloading the install5x.iso, make
the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do
pkg_add -u.  After all the failures because of the library mismatch, kde4
will no longer start due to an ssl library mismatch.  Bummer...  Looks like
it's wait until new packages are built.

Stan

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Liviu Daia-3
In reply to this post by Stan Gammons-2
On 10 December 2014, Stan Gammons <[hidden email]> wrote:
> When will new packages be built for AMD64?   I'm getting library errors
> with the latest snapshot and the current packages.

    There are bigger problems with the latest snapshot:

$ ldd /usr/sbin/unbound                                                                                              
/usr/sbin/unbound:
/usr/sbin/unbound: can't load library 'libssl.so.30.0'
/usr/sbin/unbound: exit status 4

$ ls -l /usr/lib/libssl*                                                                                    
-r--r--r--  1 root  bin  1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2
-r--r--r--  1 root  bin  1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0
-r--r--r--  1 root  bin  1518550 Dec  8 07:54 /usr/lib/libssl.so.29.0

$ dmesg | head -1
OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014


    Regards,

    Liviu Daia

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Theo de Raadt
In reply to this post by Stan Gammons-2
Look, this is rather simple.

If you don't understand that snapshots get built, that libraries
crank, that there are PEOPLE building this, that the data takes time
to get to the mirrors, and that this is a non-static situation, that
small catch-up syncronization errors are made, that they get fixed by
real people, then PLEASE DON'T RUN SNAPSHOTS.

Hours later, another snapshot neaks out for each architecture, which
has managed to pick up the shared library crank.

Please learn what the snapshot processes are.  It's in the FAQ!  If
you don't learn and understand the strong tech-innovation promise but
much weaker delivery promise of snapshots, you are denegrating the
effort by chattering into people's mailboxes.

We do what we can, based on what we have.  It is very nearly an
auto-build platform with catchup corrections for these details.

AND furthermore, snapshots sometimes contain surprise eggs for
future coming test code; where it is easier to build it for all
architectures and get it dogfooded in subsets of the test community,
than wait and wait and wait for them to build it themselves.  Those
are our prorities showing through.

Alternatively we could create a [hidden email]
mailing list, which I will not participate in.

> On 10 December 2014, Stan Gammons <[hidden email]> wrote:
> > When will new packages be built for AMD64?   I'm getting library errors
> > with the latest snapshot and the current packages.
>
>     There are bigger problems with the latest snapshot:
>
> $ ldd /usr/sbin/unbound                                                                                              
> /usr/sbin/unbound:
> /usr/sbin/unbound: can't load library 'libssl.so.30.0'
> /usr/sbin/unbound: exit status 4
>
> $ ls -l /usr/lib/libssl*                                                                                    
> -r--r--r--  1 root  bin  1518902 Oct 29 03:25 /usr/lib/libssl.so.27.2
> -r--r--r--  1 root  bin  1512855 Nov 16 09:49 /usr/lib/libssl.so.28.0
> -r--r--r--  1 root  bin  1518550 Dec  8 07:54 /usr/lib/libssl.so.29.0
>
> $ dmesg | head -1
> OpenBSD 5.6-current (GENERIC.MP) #668: Wed Dec 10 12:43:55 MST 2014
>
>
>     Regards,
>
>     Liviu Daia
>

<

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Liviu Daia-3
In reply to this post by Stan Gammons-2
On 11 December 2014, Theo de Raadt <[hidden email]> wrote:

> > On 10 December 2014, Stan Gammons <[hidden email]> wrote:
> > > When will new packages be built for AMD64?   I'm getting library errors
> > > with the latest snapshot and the current packages.
> >
> >     There are bigger problems with the latest snapshot:
> >
> > $ ldd /usr/sbin/unbound                                                                                              
> > /usr/sbin/unbound:
> > /usr/sbin/unbound: can't load library 'libssl.so.30.0'
> > /usr/sbin/unbound: exit status 4
[...]
> Look, this is rather simple.
>
> If you don't understand that snapshots get built, that libraries
> crank, that there are PEOPLE building this, that the data takes time
> to get to the mirrors, and that this is a non-static situation, that
> small catch-up syncronization errors are made, that they get fixed by
> real people, then PLEASE DON'T RUN SNAPSHOTS.
[...]

    Oh, I wasn't accusing anybody, or pointing fingers, or anything like
that.  I was just saying it's currently broken, that's all.  Sorry if it
came accross any other way.

    Regards,

    Liviu Daia

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Theo de Raadt
In reply to this post by Stan Gammons-2
> > If you don't understand that snapshots get built, that libraries
> > crank, that there are PEOPLE building this, that the data takes time
> > to get to the mirrors, and that this is a non-static situation, that
> > small catch-up syncronization errors are made, that they get fixed by
> > real people, then PLEASE DON'T RUN SNAPSHOTS.
> [...]
>
>     Oh, I wasn't accusing anybody, or pointing fingers, or anything like
> that.  I was just saying it's currently broken, that's all.  Sorry if it
> came accross any other way.

It happens all the time.  The conversation is very META.

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Stuart Henderson
In reply to this post by Stan Gammons-2
On 2014-12-11, Stan Gammons <[hidden email]> wrote:
> Ok.  The way I normally update is by downloading the install5x.iso, make
> the cd and boot from it, do an upgrade, reboot, do a sysmerge, then do
> pkg_add -u.  After all the failures because of the library mismatch, kde4
> will no longer start due to an ssl library mismatch.  Bummer...  Looks like
> it's wait until new packages are built.

That method is ok, you just need to allow for library changes. I'd suggest
following source-changes so you can spot these and hold off on updating for a
couple of days.

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

FRIGN
In reply to this post by STeve Andre'
On Wed, 10 Dec 2014 21:27:46 -0500
"STeve Andre'" <[hidden email]> wrote:

> You might want to subscribe to the ports-changes changes list,
> which will show you what's been changed.  The source-changes
> list will show you all the other cvs commits.  Look at
>
> http://www.openbsd.org/mail.html

Btw, now that the topic has come up. Is there a way to view the
diffs quickly on a source- or port-change?
Just reading the titles is not very helpful and I also don't feel
like pulling the entire OpenBSD CVS-tree just to view the recent
code-changes.

I'm subscribed to numerous mailing lists, and all of them provide
diff-data in the mail itself. I'm sure more people would subscribe
to such a list if it actually encouraged to read and check the
source.

Cheers

FRIGN

--
FRIGN <[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Mihai Popescu-3
In reply to this post by Stan Gammons-2
> The conversation is very META.


What is META?

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Janne Johansson-3
That it is a discussion about a discussion, not about any topic of its own.


2014-12-11 12:37 GMT+01:00 Mihai Popescu <[hidden email]>:

> > The conversation is very META.
>
>
> What is META?
>
>


--
May the most significant bit of your life be positive.

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Oliver Peter-6
In reply to this post by FRIGN
On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote:
> Btw, now that the topic has come up. Is there a way to view the
> diffs quickly on a source- or port-change?

Not official and not instantly updated:
        http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/

--
Oliver PETER       [hidden email]       0x456D688F

[demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Björn Ketelaars
In reply to this post by FRIGN
you could try http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/

On Thu, Dec 11, 2014 at 11:59 AM, FRIGN <[hidden email]> wrote:

> On Wed, 10 Dec 2014 21:27:46 -0500
> "STeve Andre'" <[hidden email]> wrote:
>
> > You might want to subscribe to the ports-changes changes list,
> > which will show you what's been changed.  The source-changes
> > list will show you all the other cvs commits.  Look at
> >
> > http://www.openbsd.org/mail.html
>
> Btw, now that the topic has come up. Is there a way to view the
> diffs quickly on a source- or port-change?
> Just reading the titles is not very helpful and I also don't feel
> like pulling the entire OpenBSD CVS-tree just to view the recent
> code-changes.
>
> I'm subscribed to numerous mailing lists, and all of them provide
> diff-data in the mail itself. I'm sure more people would subscribe
> to such a list if it actually encouraged to read and check the
> source.
>
> Cheers
>
> FRIGN
>
> --
> FRIGN <[hidden email]>
>
>


--
Björn Ketelaars <[hidden email]>
GPG key: 0x4F0E5F21

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Stuart Henderson
In reply to this post by Oliver Peter-6
On 2014-12-11, Oliver Peter <[hidden email]> wrote:
> On Thu, Dec 11, 2014 at 11:59:55AM +0100, FRIGN wrote:
>> Btw, now that the topic has come up. Is there a way to view the
>> diffs quickly on a source- or port-change?
>
> Not official and not instantly updated:
>         http://anoncvs.estpak.ee/cgi-bin/cgit/openbsd-ports/log/

Yes, this is what I use if I'm looking for contents of diffs that have
been committed.

Personally I also try to keep the main part of my commit logs in the
first line (and where ports is concerned I include the name of the port
for simple updates rather than just 'update to xx') so that the truncated
commit message on this type of display is still usable :-)

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

STeve Andre'
In reply to this post by FRIGN
On 12/11/14 05:59, FRIGN wrote:

> On Wed, 10 Dec 2014 21:27:46 -0500
> "STeve Andre'" <[hidden email]> wrote:
>
>> You might want to subscribe to the ports-changes changes list,
>> which will show you what's been changed.  The source-changes
>> list will show you all the other cvs commits.  Look at
>>
>> http://www.openbsd.org/mail.html
> Btw, now that the topic has come up. Is there a way to view the
> diffs quickly on a source- or port-change?
> Just reading the titles is not very helpful and I also don't feel
> like pulling the entire OpenBSD CVS-tree just to view the recent
> code-changes.
>
> I'm subscribed to numerous mailing lists, and all of them provide
> diff-data in the mail itself. I'm sure more people would subscribe
> to such a list if it actually encouraged to read and check the
> source.
>
> Cheers
>
> FRIGN
>
Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ?

You can get a diff of the change of any revision, which should
help out.

--STeve Andre'

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

ian kremlin
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
(pkg_add(1) will tell you which ones it wants. a good article on how these
work here: http://www.tedunangst.com/flak/post/OpenBSD-version-numbers)

make && make install

the bsd.port.mk(5) build system is well thought out and allows for
straightforward, helpful maneuvers like this

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

On Thu, Dec 11, 2014 at 3:13 PM, STeve Andre' <[hidden email]> wrote:

> On 12/11/14 05:59, FRIGN wrote:
>
>> On Wed, 10 Dec 2014 21:27:46 -0500
>> "STeve Andre'" <[hidden email]> wrote:
>>
>>  You might want to subscribe to the ports-changes changes list,
>>> which will show you what's been changed.  The source-changes
>>> list will show you all the other cvs commits.  Look at
>>>
>>> http://www.openbsd.org/mail.html
>>>
>> Btw, now that the topic has come up. Is there a way to view the
>> diffs quickly on a source- or port-change?
>> Just reading the titles is not very helpful and I also don't feel
>> like pulling the entire OpenBSD CVS-tree just to view the recent
>> code-changes.
>>
>> I'm subscribed to numerous mailing lists, and all of them provide
>> diff-data in the mail itself. I'm sure more people would subscribe
>> to such a list if it actually encouraged to read and check the
>> source.
>>
>> Cheers
>>
>> FRIGN
>>
>>  Have you looked at http://cvsweb.openbsd.org/cgi-bin/cvsweb/ ?
>
> You can get a diff of the change of any revision, which should
> help out.
>
> --STeve Andre'

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Stuart Henderson
On 2014-12-12, ian kremlin <[hidden email]> 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.

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Ingo Schwarze
In reply to this post by ian kremlin
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

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Theo de Raadt
In reply to this post by Stan Gammons-2
> 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.

Reply | Threaded
Open this post in threaded view
|

Re: AMD64 packages

Stan Gammons-2
On Dec 12, 2014 1:06 PM, "Theo de Raadt" <[hidden email]> 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

12