This release fixes missing endbr / bti.Index: Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 15 Apr 2024 22:22:05 - 1.8
+++ Makefile 20 Apr 2024 21:48:06
+# .objc_sel_* symbols are for string de-duplication and can be ignored.
+SHARED_LIBS += objfw 0.1
+SHARED_LIBS += objfwrt 0.1
SHARED_LIBS += objfwtls 0.0
CATEGORIES = devel
@@ -12,7 +13,7 @@ HOMEPAGE = https://objfw.nil.im/
MAINTAINER = Jonathan Schleifer
-# GPLv2 or GPLv3 or QPL
+# LGPLv3
Am 15.04.24 um 13:24 schrieb Jonathan Schleifer:
Am 15.04.24 um 13:10 schrieb Jeremie Courreges-Anglas:
Heh, I remember I asked pretty much the same question when handling a
previous update. Could you please write down a comment above
SHARED_LIBS that explains roughly which changes don't
Am 15.04.24 um 13:10 schrieb Jeremie Courreges-Anglas:
Heh, I remember I asked pretty much the same question when handling a
previous update. Could you please write down a comment above
SHARED_LIBS that explains roughly which changes don't require a bump?
That way you'll save precious
Am 14.04.24 um 22:32 schrieb Theo Buehler:
or are these .objc_* symbols somehow special?
Those are all .objc_sel_name*. Those are symbols that just contain the
selector name as a string. That's a selector being *used*, not exported.
They're pretty similar to local symbols, however, they're
= https://objfw.nil.im/
MAINTAINER = Jonathan Schleifer
-# GPLv2 or GPLv3 or QPL
+# LGPLv3
PERMIT_PACKAGE = Yes
# uses pledge()
Index: distinfo
===
RCS file: /cvs/ports/devel/objfw/distinfo,v
retrieving revision 1.5
diff -u -p
Index: devel/objfw/Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.7
diff -u -p -r1.7 Makefile
--- devel/objfw/Makefile 25 Feb 2024 01:13:41 - 1.7
+++ devel/objfw/Makefile 10 Mar 2024 10:50:09 -
Am 24.02.24 um 23:22 schrieb Mark Kettenis:
This is how the hardware behaves; see the documentation for
PSTATE.BTYPE in Part D of the ARM Architecture Reference Manual
(document DDI0487).
The difference is that this will allow an attacker to exploit a "BR"
type branch (jump) to jump to the
Fixed upstream:
https://objfw.nil.im/info/262baf76e7e66bc4
https://objfw.nil.im/info/d73a388ecaf73b2a
New release:
https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz
https://objfw.nil.im/downloads/objfw-1.0.10.tar.gz.sig
Am 24.02.24 um 22:17 schrieb Mark Kettenis:
Ah, right. What happens in
Am 24.02.24 um 21:30 schrieb Mark Kettenis:
Unless we explicitly mark them as not, yes, they will use IBT (but not
Shadow Stack).
Ah cool!
No. Tail call elimination will use a *direct* branch, which doesn't
need a landing pad at all.
Not necessarily - I've seen tail call elimination on
Am 24.02.24 um 20:01 schrieb Theo Buehler:
This adds missing landing pads for amd64 and arm64. Not sure if for
upstream a dance using _CET_ENDBR would be preferable. For the
port I kept it simple.
ld: warning: objc_msg_lookup: missing endbr64
ld: warning: objc_msg_lookup_stret: missing
Patch attached.
Please also import to 7.4, as this contains quite the list of bugfixes
compared to the previous 1.0.3.
--
JonathanIndex: Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.5
diff -u -p
Ping?
Also, I'd like to ask for this to be backported to 7.4, as it fixes a
nasty bug where failing to open a file causes fd 0 to be closed.
--
Jonathan
Update devel/objfw to 1.0.4
--
JonathanIndex: devel/objfw/Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.5
diff -u -p -r1.5 Makefile
--- devel/objfw/Makefile 21 Sep 2023 09:50:01 - 1.5
+++
Patch attached this time to be 100% sure my MUA doesn't screw it up.
--
JonathanIndex: devel/objfw/Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.3
diff -u -p -u -r1.3 Makefile
---
Am 11.09.23 um 13:01 schrieb Jeremie Courreges-Anglas:
This diff and the previous one were likely mangled by your MUA. There
are hints available:
https://www.kernel.org/doc/html/latest/process/email-clients.html
Or you may just send diffs as attachments (inline is still preferred).
Ah,
And here's an update to the just released 1.0.2 instead. This is 1.0.1
with some additional fixes for macOS, so not important for OpenBSD. But
when updating anyway, why not update to the latest version :).
Index: Makefile
===
RCS
Fixes an issue with TLS connections and no longer requires a patch to
disable the silent rules.
Index: devel/objfw/Makefile
===
RCS file: /cvs/ports/devel/objfw/Makefile,v
retrieving revision 1.2
diff -u -p -u -r1.2 Makefile
---
Am 05.09.23 um 12:50 schrieb Stuart Henderson:
Except it isn't robust to changes - it can just silently fail to apply,
which doesn't happen with a patch.
My worry was that a patch still applies and misses to remove an -s, then
giving you only partial output, which is worse than no output.
Am 04.09.23 um 16:30 schrieb Jeremie Courreges-Anglas:
Thanks. I have imported objfw as proposed in your last tarball, except
with a simple patch for clarity instead of your ed(1) script.
Thank you!
My reason for using the ed script over a patch was that it'll be more
robust to changes.
Am 03.09.23 um 19:55 schrieb Stuart Henderson:
yep, exactly. reasons:
- we find that some upstream projects don't understand shared library
versioning, and either increment the version number when not needed, or
don't increment when it is needed.
Upstream handling reads exactly like OpenBSD
Am 03.09.23 um 19:49 schrieb Jeremie Courreges-Anglas:
I don't know which of .SILENT or make -s or the escape characters hide
the compiler command lines used to build the object files, but let's
find a way to disable this behaviour at least in the port.
Attached is an updated port that
This would be small enough if the package still built. Moving
SHARED_LIBS to 0.0 I get:
Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfw.so.0.0 does
not exist
Error: /usr/obj/pobj/objfw-1.0/fake-amd64/usr/local/lib/libobjfwrt.so.0.0 does
not exist
Error:
Am 03.09.23 um 12:55 schrieb Jeremie Courreges-Anglas:
On Sun, Sep 03 2023, Jonathan Schleifer wrote:
Am 31.08.23 um 09:56 schrieb Jonathan Schleifer:
Am 31.08.23 um 08:26 schrieb Stuart Henderson:
SHARED_LIBS += objfw 1.0
SHARED_LIBS += objfwrt 1.0
SHARED_LIBS
Am 31.08.23 um 09:56 schrieb Jonathan Schleifer:
Am 31.08.23 um 08:26 schrieb Stuart Henderson:
SHARED_LIBS += objfw 1.0
SHARED_LIBS += objfwrt 1.0
SHARED_LIBS += objfwtls 1.0
I can't remember how strict we are with these version starting numbers
but iirc we start
Am 31.08.23 um 08:26 schrieb Stuart Henderson:
SHARED_LIBS += objfw 1.0
SHARED_LIBS += objfwrt 1.0
SHARED_LIBS += objfwtls 1.0
I can't remember how strict we are with these version starting numbers
but iirc we start with 0.1 (?) I don't really mind if this isn't
Hi!
With ObjFW 1.0 being released yesterday, I thought to package it up for
OpenBSD. Please find it attached and if it looks good, it would be great
if it could be imported.
--
Jonathan
objfw.tar.gz
Description: application/gzip
Am 16.01.2009 um 11:40 schrieb Pierre-Emmanuel André:
I tested gajim with this patch (http://trac.gajim.org/changeset/10848)
and it's better but i still have random deconnexions with my jabber
servers (Ichat server and 2 ejabberd )(less deconnexions but there
are
still here). The only thing
Too end this long discussion:
Am 12.01.2009 um 23:22 schrieb Matthias Kilian:
From my point of view (as a porter), Makefiles hiding details, or
Makefiles I have to look at before I can be sure that they don't
lie, are just additional work. And hiding details doesn't give
anyone anything IMHO.
Am 12.01.2009 um 07:33 schrieb Federico G. Schwindt:
I prefer to have the full output rather than only the ANSI'd version
of it (which is quite ugly IMHO).
Would removing the colours work for you?
If not, I recommend removing the printfs completely. But the plain
output will be ugly anyway,
Am 12.01.2009 um 16:14 schrieb Federico G. Schwindt:
I don't know others, but as developer I would never prefer colorful
output over the real one, and I don't find it very useful, neither
for me
nor for anyone who might need to report issues during building.
Well, you see the compiler and
Am 12.01.2009 um 18:23 schrieb Stuart Henderson:
imho it is a bit ugly, but if being able to see the compiler command
lines requires slightly ugly output, I'd rather have the ugly output.
(i'd prefer it even more with a proper option that hides the internal
build system logic and the lines like
Am 12.01.2009 um 21:48 schrieb Matthias Kilian:
No, it isn't. There may be errors in the Makefile. There may be
overrides in the environment and/or command line that may *not*
work as desired which you can't check by just looking at the Makefile.
Have you actually looked at the Makefile and
Hi!
I'm the developer of the build system audacious, libmcs and libmowgli
use. You shouldn't just comment out .SILENT:, as this is only for
debugging. Usually, you should be fine without commenting it :). The
other thing I see it that you disable dependency checks, but yet let
it
Am 10.01.2009 um 01:59 schrieb viq:
Any news on that? BTW, there's 0.12.1 out.
0.12.1 only fixes file transfers. I've given up fixing that timeout
bug because whatever I do, there's always someone complaining like
But then I won't notice within 5 sec that my connection is
down!
Am 10.01.2009 um 22:33 schrieb Stuart Henderson:
On 2009/01/10 15:35, Jonathan Schleifer wrote:
I did several patches, one increasing the timeouts to sane values,
That sounds like a reasonable thing to put in the port.
http://trac.gajim.org/changeset/10848
It was reverted because some
Am 19.12.2008 um 12:22 schrieb Pierre-Emmanuel André:
Thanks for your update Simon.
I will not commit this update now: after a full day of testing, i've
some regressions with this version.
I tested with 3 accounts based on 3 differents servers(ichat server,
ejabberd 1.1.2 and ejabberd 2.0.1)
Simon Kuhnle [EMAIL PROTECTED] wrote:
@@ -18,5 +10,5 @@
-helpers.exec_command('python history_manager.py ')
+helpers.exec_command('%s history_manager.py ' %
(sys.executable,))
I committed something similar to that to trunk so you don't need that
Simon Kuhnle [EMAIL PROTECTED] wrote:
Oh, nice, thank you :-)
No problem. Sometimes, you should just ask upstream instead of adding
more patches, especially if it's an alpha. :)
The only other patch patches the gajim starter shellscript to use
/bin/sh and not /bin/bash, so I don't need bash
Am 14.08.2008 um 15:32 schrieb Simon Kuhnle:
Which reminds me of the problem:
sys.executable returns /usr/local/bin/gajim here, even if I run it
from
svn (so by running launsh.sh)
This is caused by the exec -a, so I also have to commit this:
-exec -a gajim ${PYTHON_EXEC} -OO gajim.py $@
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Federico G. Schwindt [EMAIL PROTECTED] wrote:
Index: audio/audacious/patches/patch-m4_buildsys_m4
===
RCS file: audio/audacious/patches/patch-m4_buildsys_m4
diff -N
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Federico G. Schwindt [EMAIL PROTECTED] wrote:
This was done for simplicity. The target does not work and it also
includes netbsd and solaris, and that's how it was done before. This
is not mean to be submitted anyways, but if you really
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Federico G. Schwindt [EMAIL PROTECTED] wrote:
--- m4/buildsys.m4.orig Thu Mar 13 22:19:27 2008
+++ m4/buildsys.m4Mon Mar 31 16:01:43 2008
@@ -72,7 +72,7 @@ AC_DEFUN([BUILDSYS_SHARED_LIB], [
UNINSTALL_LIB='rm
Jacob Meuser [EMAIL PROTECTED] wrote:
patch below against in-tree port fixes some of them, but there is
still a problem with format conversions. I'll have a patch for that
later. also, distributing a system header is a bad idea, IMNSHO.
This is a left-over from XMMS which we also had for
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Federico G. Schwindt [EMAIL PROTECTED] wrote:
yes, same thing here. i was expected it was due to my card or
something. iirc, the previous version has oss by default, need to
look into it.
The sun plugin is unmaintained atm AFAIK, therefore
You should also build the OSS plugin. I'm an Audacious developer and
fixed the OSS plugin a while ago so that it works perfectly on OpenBSD.
Even works much better than the sun audio plugin.
--
Jonathan
Helmut Schneider [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] ~]# /usr/ports/infrastructure/build/out-of-date
Collecting installed packages
Undefined subroutine OpenBSD::ProgressMeter::enable called at
/usr/ports/infrastructure/build/out-of-date line 100.
Sounds like you use current ports on
Sergey Prysiazhnyi [EMAIL PROTECTED] wrote:
Any Subj in ports tree? Like centericq, etc? Thank you a lot for
advise,
mcabber, which isn't in ports IIRC, but should be easy to port. IMO,
it's the best console jabber client so far.
--
Jonathan
Jacob Meuser [EMAIL PROTECTED] wrote:
I'm starting to think there is something wrong with auich.
I'm also having problems with auich, not only with zsnes. They were
that bad that I switched my laptop to NetBSD where it works without
any problems. I couldn't even listen to music since all few
Jacob Meuser [EMAIL PROTECTED] wrote:
sorry your report was ignored. remember, the best way to not have
problem reports ignored is to use sendbug(1).
I did use sendbug and I even reported it more than once IIRC. I guess
it's just that nobody got an idea what it could be.
--
Jonathan
Jacob Meuser [EMAIL PROTECTED] wrote:
[…]
I currently don't have OpenBSD on my laptop anymore, but I'll reinstall
it, test it and let you know. Thanks for having a look at it. :)
--
Jonathan
signature.asc
Description: PGP signature
Mike Swanson [EMAIL PROTECTED] wrote:
I've noticed ZSNES hasn't been updated in years
Well, not for years, but not in the last time, yes. I personally think
that the new versions suck as then don't provide netplay anymore,
therefore I didn't update it since I had no interest in the new
Mike Swanson [EMAIL PROTECTED] wrote:
Ah, well there's been a reply on ports@ with the updated version,
I've seen it and CC'd him.
perhaps you should look at it. Would it be feasible to have
zsnes/1.42 and zsnes/1.51 (Java also has multiple versions like
this)? For users that want netplay,
[EMAIL PROTECTED] (Christian Weisgerber) wrote:
Which is still a development release. Any good reason we should
update now?
UTF-8 support. I don't know if it works on OpenBSD, though. AFAIR it
requires an UTF-8 locale.
--
Jonathan
signature.asc
Description: PGP signature
Peter Valchev [EMAIL PROTECTED] wrote:
It has a maintainer, did you send him a note too?
The original post with the update to 0.1.1.23 _IS_ from the maintainer
and I just replied to his post to give him an update to 0.1.1.24. So
yes, I did through the mailing list.
--
Jonathan
signature.asc
Sam Fourman Jr. [EMAIL PROTECTED] wrote:
I don't believe there is, OpenBSD needs a maintainer for the Whole
Gnome Project 2.16.1
Hm, didn't we have one? Did he quit or what happened?
are you interested in porting Gnome 2.16.1?
I could do the GTK+2 port + dependencies, but I have no
Hi!
Just wanted to know:
Is there already someone working on an update of gtk+2 to 2.10.6 and
gtk-engines2 to 2.8 + the dependencies?
--
Jonathan
signature.asc
Description: PGP signature
Jonathan Schleifer [EMAIL PROTECTED] wrote:
The ports tree is in soft-lock at the moment; it's possible/likely
that your patch won't be committed until after the lock. Hang on to
it and test ports already in the tree.
I know that, but posted it so it can already be tested.
AFAIK
Will Maier [EMAIL PROTECTED] wrote:
Did you contact the current maintainer? Did you send them this patch
already?
Indirectly, through this list. If he's still interested in maintaining
it, he'll read it here. (I don't want to mail to @gmail.com, sorry.)
The ports tree is in soft-lock at the
Karl Ferdinand Ebert [EMAIL PROTECTED] wrote:
I've succesfully tested your update on i386, receiving three messages
(two errors and one warning) in building psi-0.10. The first error
appears at entering in src, the second seems to be a repetition of
the first, but more later and more
Update from the really old 0.9.3 to 0.10. Since it seems that the
maintainer isn't interested in this port anymore (0.9.3 is really old),
I hereby request to be the new maintainer.
The following files have been removed because they're not needed
anymore:
patches/patch-iris_xmpp-core_jid_cpp
PostgreSQL bindings for the ruby language.
Please test, commit and so on.
--
Jonathan
ruby-postgres.tgz
Description: application/compressed-tar
signature.asc
Description: PGP signature
Alexey E. Suslikov [EMAIL PROTECTED] wrote:
Maybe it is a good idea to try make VMware Server work instead of old
(3.x) Workstation?
I think that would not be possible. VMware depends on a kernel module.
But that module isn't open source AFAIK. Only the part that loads the
rest of the binary
Ian Darwin [EMAIL PROTECTED] wrote:
So meanwhile I use qemu for the
odd time when I need to use another OS.
qemu has the same problem as VMware: The kernel module. It's really
slow without the acceleration module. But maybe the it could be ported
to OpenBSD? I know it's not Open Source, but it
GTK+2 Bindings for the ruby language.
I only tested it with irb, therefore it needs some more testing with
real applications.
Please test, commit, and so on. Thanks.
--
Jonathan
ruby-gtk2.tgz
Description: Unix tar archive
stan [EMAIL PROTECTED] wrote:
Is there a way that I can adjust the sensitivty of wmoused?
I'm using a USB moused on a Sun X2100, and it's way too fast, I need to
slow it down a bit.
If you use X11, you could try using xset m. See the manpage for details.
--
Jonathan
Sorry, I sent it to the wrong list. My fault.
--
Jonathan
Aleksander Piotrowski [EMAIL PROTECTED] wrote:
Here goes new version of gaim port. It's based on today's CVS
sources. Have fun.
I think we shouldn't use CVS versions for ports when the current stable
version works just fine. Besides, the CVS version is very unusable IMO.
--
Jonathan
I removed the do-install target now since zsnes' install target is ok
in 1.42. Updated patch is attached, please test and commit.
--
Jonathan
zsnes.patch
Description: Binary data
Aleksander Piotrowski [EMAIL PROTECTED] wrote:
PKGNAME with p0 is not needed as you have changed version, right?
I just kept the p0 from the old port, changed.
If automake is needed to build this port then try to use following:
CONFIGURE_STYLE= automake
automake isn't needed (no
Thorsten Glaser [EMAIL PROTECTED] wrote:
Your changed do-install target
a) does not install the docs any more at all.
Because it seems that they don't exist anymore. At least they aren't in
the same place anymore, I haven't looked if they just got moved
somewhere else.
b) is totally
Marc Matteo [EMAIL PROTECTED] wrote:
but I'm pretty sure we can get rid of that too :).
Why get rid of them? Just drop gnome1, but keep libgnome1. There are
some programs that depend on libgnome1 and sometimes there is no
alternative program. Or programs that only need it optional.
For example,
patrick ~ [EMAIL PROTECTED] wrote:
So, now I turn to the list to see if anyone can shed some
light onto my problem. Where am I going wrong?
Nowhere. Just cd into /usr/ports/packages/$ARCH/all. The extensions are
build as subpackages which you have to add manually using pkg_add.
--
Jonathan
Aleksander Piotrowski [EMAIL PROTECTED] wrote:
OK, OK but what does this gnome stuff add to GIMP? What kind of
features, etc...
Hm, I don't know. I guess it's not much and only a few guys need it. It
would be the best if you make a flavor out of it, so everyone could
decide if he/she wants
Edd Barrett [EMAIL PROTECTED] wrote:
I imagine its things like drag and drop and VFS functions etc.
Drag Drop should work without Gnome since it's already possible with
only Gtk+ 2.
--
Jonathan
I think there should be a flavor no_gnome. Gimp doesn't really need all
that gnome stuff that the port uses. I only want Gimp, not half of
Gnome. Would be nice if that flavor could be implemented.
--
Jonathan
77 matches
Mail list logo
