On 2016-02-09, Jonathan Gray wrote:
> /usr/xenocara/lib/mesa/src/mesa/main/format_pack.c:6890: internal compiler
> error: in extract_insn, at recog.c:2077
Our usual workaround for these types of errors is to compile the
affected source file (and only that file, and only on that arch)
without an
No such error on amd64.p. The build log looks different.
>>> Building on amd64-1 under textproc/xlsx2csv
BDEPENDS = [textproc/go-xlsx;lang/go]
DIST = [textproc/xlsx2csv:xlsx2csv-20150225.tar.gz]
FULLPKGNAME = xlsx2csv-20150225p1
(Junk lock obtained for amd64-1 at 145508
On 2016-02-11, "Christoph R. Murauer" wrote:
> I have a diff to update net/curl to version 7.47.1.
Thanks for pointing out the release, but this .1 update only addresses
a security problem specific to Cygwin. Since we are preparing for
the release, I won't update the port now.
> Master site UR
On 2016-02-14, Jonathan Gray wrote:
>> In addition to the non-existent sync operation, I had to force 2 files
>> to build with -O0.
>
> Any idea which of the -O1 options triggers it?
-O1 is very broken on alpha and triggers ICEs a lot (always?).
--
Christian "naddy" Weisgerber
On 2016-02-14, Michael McConville wrote:
> However, the build fails for me because it can't find the module
> MenhirLib.IncrementalEngine.
>
> Has anyone else run into this?
There is no such problem in the amd64 package builds.
--
Christian "naddy" Weisgerber na...@mip
On 2016-02-14, Matthieu Herrb wrote:
> I've taken the list of individual optimisation from gcc(1) for both -O1
> and -O2 and replaced -O2 by this in CFLAGS.
gcc-local(1) is also worth a look...
> +O2= ${O1} -fthread-jumps -fcrossjumping \
> + -foptimize-sibling-calls -fcse-follow-jumps -fcs
On 2016-02-15, Tobias Ulmer wrote:
> +padding for 32bit strict alignment archs
> +
> +--- tools/build/src/engine/hash.c.orig Mon Feb 15 20:11:07 2016
> tools/build/src/engine/hash.cMon Feb 15 20:22:03 2016
> +@@ -33,6 +33,7 @@ typedef struct item ITEM;
> + struct item
> + {
> +
Does emulators/fedora suffer from the glibc DNS bug (CVE-2015-7547)?
--
Christian "naddy" Weisgerber na...@mips.inka.de
Josh Grosse:
>The segfault has been traced to a truncated pointer returning from
>gdk_pixbuf_new_from_inline, a library function of graphics/gdk-pixbuf.
>The call is from gtk/actions.c. The problem occurs on amd64, but
>not on i386 (of course).
>
>The top 32-bits of the retur
On 2016-02-20, Tobias Ulmer wrote:
> I'm having an argument whether to bump REVISION or not.
If that version didn't build before, and the change doesn't affect
other architectures, there's no reason to bump.
> Moving pre-configure to post-extract makes it possible to apply patches
> to libatomi
The ports tree is now locked for the release.
We may still trickle in a few important diffs, but talk to sthen@
and me first. No unapproved commits!
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2016-02-29, Josh Grosse wrote:
> This diff updates the application to version 2.90.
> Tested on amd64. (Some light testing on i386 was also performed.)
Shuffling the icon directories, which are only used in the gtk
flavor, from PLIST-gtk to PLIST-main doesn't make any sense.
update-plist is
Similar to x11/nx/nxcomp, comms/hylafax also fails to build after
the latest FD_* changes:
Dispatcher.c++: In member function 'virtual bool Dispatcher::anyReady() const':
Dispatcher.c++:510: error: invalid conversion from 'const fd_set*' to 'fd_set*'
Dispatcher.c++:510: error: initializing argum
On 2016-02-27, Landry Breuil wrote:
> 5.9 will ship with 44.0, but 45 is around the corner anyway. Make sure
> to test this one, since that will be the new ESR. Gtk3 has been disabled
> by default again, that's becoming a running gag. Gstreamer has been
> deprecated too, ffmpeg should be used at
On 2016-03-01, Josh Grosse wrote:
>> You still depend on gtk-update-icon-cache in the -main package.
>
> Corrected.
>
>> And you still have the PLIST goos.
>
> Thanks, fixed!
Minor issue: WANTLIB-qt should be synced.
Major issue: The difference between FLAVOR="" and FLAVOR="no_qt"
should be tha
On 2016-03-07, Josh Grosse wrote:
> Attached is a new update, from 2.90 -> 2.92.
Sorry, I still don't think this is right.
> -ONLY_FOR_ARCHS-qt=${GCC4_ARCHS}
> +ONLY_FOR_ARCHS= ${GCC4_ARCHS}
> +.if ${BUILD_PACKAGES:M-qt}
> +MODULES+=x11/qt5
> +MODQMAKE_PROJECTS= qt/qtr.pro
>
http://build-failures.rhaalovely.net/alpha/
shows pretty clearly that GCC 4.6 is not equivalent to 4.9. Ports
that use MODULES=gcc4 and that build fine elsewhere with 4.9 are
broken on alpha with 4.6 because the compiler is too old.
If somebody wants to go through the list of MODULES=gcc4 ports a
On 2016-03-08, Josh Grosse wrote:
> Thank you, naddy, for your kind patience with my port update. This one in
> particular has been a learning experience, and I appreciate the guidance.
That port is awfully complex. I keep wavering between wanting to
split off the Qt client into a separate por
On 2016-03-08, Timo Myyrä wrote:
> Here is an update for latest version of ECL.
> Seems that the Copyright file got renamed to LICENSE but Makefiles didn't get
> updated for the release so this adds backports few patches to fix it.
Wouldn't it be easier to just create a link before the build?
-
There is currently some talk of dropping the vax architecture. I'm
cautiously optimistic that it will happen. This would allow us to
remove all sorts of cruft from the ports tree.
First, there is vax itself. Removing support from infrastructure/ is
straightforward. Then Makefiles and patches n
The graphics/gegl03.log port picks up gexiv2 if it happens to be
installed, but doesn't have a proper dependency on it.
I don't know if gexiv2 should be disabled in gegl03 or the dependency
added.
Log attached.
--
Christian "naddy" Weisgerber na...@mips.inka.de
gegl03.
I propose to delete audio/rplay.
I went in there to fix errno and... urgh. The source dates from
the 1999 and it relies on an included regular expression library
that is not 64-bit clean. I think the effort to salvage this would
be disproportional.
OK?
DESCR:
rplay is a flexible network audio
Let's remove comms/xcept.
I went in there to fix errno and... urgh.
DESCR:
XCept provides a decoder for the CEPT protocol as it is in use for
example by the Btx service of the Deutsche Telekom. [...]
The Btx service was switched off in 2001.
https://en.wikipedia.org/wiki/Bildschirmtext
--
On 2016-03-08, Christian Weisgerber wrote:
> First, there is vax itself.
I think we have now scrubbed everything relating to vax itself from
the ports tree. The non-shared stuff is still everywhere.
> The vax is the last static architecture and there will never be
> another one. T
For any committers who want to pitch in or just wonder how their ports
are affected, here's what's up:
PFRAG.shared can be folded into PLIST without restrictions. Remember
the REVISION bump.
NO_SHARED_ARCHS isn't set any longer and PROPERTIES:Mno_shared will
never match. Instances of these can
Patrik Lundin:
> > SHARED_ONLY: DO NOT REMOVE from Perl ports.
>
> Does removing SHARED_ONLY from non-perl ports count as a noop or does it
> require a revision bump?
SHARED_ONLY also shows up in some other *.mk modules. I haven't
examined this further yet. Do not delete blindly.
> Is ports@
Well, put a bandaid on it.
Currently update-plist will still spit out PFRAG.shared files when
it finds .so modules. This is no longer useful. The proper fix
would be to rip out all the PFRAG.shared handling from make-plist,
but I don't feel like going in there (for now at least).
Let's just cal
On 2016-03-09, Christian Weisgerber wrote:
> I propose to delete audio/rplay.
sthen@ pointed out that x11/fvwm95 depends on this. That is optional,
the FvwmAudio module can be built without.
Still, I wonder, do we want to keep fvwm95? It's from 1996 (last
home page update in 2001).
Stuart Henderson:
> +.if ${MACHINE_ARCH} == "amd64" || ${MACHINE_ARCH} == "i386"
> +CONFIGURE_ARGS +=-no-ssse3 -no-sse4.1 -no-sse4.2 -no-avx -no-avx2
> +.endif
> +
> +.if ${MACHINE_ARCH} == "i386"
> +CONFIGURE_ARGS +=-no-sse2 -no-sse3
> +.endif
amd64 also needs -no-sse3
--
Christian "na
On 2016-03-16, Christian Weisgerber wrote:
> The SHARED_ONLY variable is a bit of a tangle. I'll start pulling
> a few threads soon.
In case anybody's wondering how things are progressing on that
front:
Basically, we're looking at a kind of network graph. We have
A quick update:
The variables and all references to CONFIGURE_SHARED, NO_SHARED_ARCHS,
and NO_SHARED_LIBS have been eliminated, as well as "no_shared" in
PROPERTIES.
There are about a hundred PFRAG.shared files left. Committers are
invited to clean up the ports they maintain.
The SHARED_ONLY va
The good news is that the end of the SHARED_ONLY removal is in
sight.
The not so great news is that the final step will involve touching
about 1600 perl ports. Most of these will gain a PKG_ARCH=* setting.
Any particular wishes where in the port Makefile PKG_ARCH should
go, after which other vari
Okan Demirmen:
> An argument to remove textproc/p5-Text-Restructured, plus all its
> (in)direct dependencies, is that most of the dependencies no longer pass
> regress, nor work completely with modern perl. Most of upstream
> abandoned the modules anywhere from 6 years to +11 years ago.
-snip-
It
Stuart Henderson:
> SHARED_ONLY in Perl-land is tied to PKG_ARCH=*. As one of the few people
> who used PKG_ARCH=* to help speed up release builds in the past, I wouldn't
> mind losing it, I don't think it's useful enough to be worth the complexity
> (and it was only ever any good for release buil
SHARED_ONLY is going away, drop it from the variables available in
the database. Did I miss anything? OK?
Index: Makefile
===
RCS file: /cvs/ports/databases/sqlports/Makefile,v
retrieving revision 1.60
diff -u -p -r1.60 Makefile
---
There are a number of ports that aren't linked to the build.
I can't quite tell for which this is intentional and where it was
simply forgotten:
devel/rcs-fast-import
games/quake2
lang/compcert
lang/php/7.0
net/py-pcs
sysutils/autossh
www/mozilla-sync/*
x11/kde4/kalzium
Also a number of firefox a
So, this is pretty much done.
There are some PFRAG.shared files left (86 at the lastest count)
and a few man pages need to be updated.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2016-03-21, Sevan Janiyan wrote:
> it'll probably bring a revision bump for a plethora of packages
> as they pull in pcre as well.
Presumably they use the shared library?
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2016-03-20, Adam Wolk wrote:
> Tested with your updated audio/libmikmod running between2.mod
> on a march 18th amd64 snapsot
Also works on sparc64. As does xmms's mikmod module.
--
Christian "naddy" Weisgerber na...@mips.inka.de
The scaffolding to support architectures without shared libraries
has been removed from the ports infrastructure. This updates the
ports tree man pages accordingly.
bsd.port.arch.mk.5
bsd.port.mk.5
port-modules.5
ruby-module.5
Gone are or will be shortly:
* the variables CONFIGURE_SHARED
On 2016-03-22, Sevan / Venture37 wrote:
>> Presumably they use the shared library?
>
> Correct.
Then they don't need a revision bump.
--
Christian "naddy" Weisgerber na...@mips.inka.de
On 2016-03-19, Jeremie Courreges-Anglas wrote:
> It would be sad if addition of pledge(2) to ports resulted tons of
> #ifdef __OpenBSD__. From the patches in the ports tree I can only spot
> archivers/xz and devel/cscope following that pattern.
Well, pledge(2) *is* specific to OpenBSD. That's w
On 2016-03-23, Matthias Kilian wrote:
> running dpb -uR with the e2fsprogs patch didn't show any problems.
> So at least ports dependeing on e2fsprogs should be fine.
>
> Any opinions?
Yes, I think the EXT2_IOC_* defines should be removed from
ext2fs/ext2_fs.h. Looks like that whole file was c
Apparently (Web)Glimpse, which covers our textproc/glimpse and
textproc/agrep ports, has been relicensed under an ISC license
in 2014:
http://webglimpse.net/
This means the restriction PERMIT_PACKAGE_CDROM="no fee" can be
removed.
However, there haven't been any new source releases. I don't know
TL;DR: We can and should kill the gettext and libiconv MODULES and
replace them with ordinary LIB_DEPENDS.
If you look at the libiconv module, it specifies both a lib and a
run dependency on libconv. That's because the iconv library also
needs some data file. On static archs, lib depen
Marc Espie:
> > If you look at the libiconv module, it specifies both a lib and a
> > run dependency on libconv. That's because the iconv library also
> > needs some data file. On static archs, lib depends turned into
> > pure build depends, so we needed an extra run depends to make sure
> > tha
On 2016-03-28, Landry Breuil wrote:
> https://cgit.rhaalovely.net/mozilla-firefox/?h=beta
> git clone -b beta https://rhaalovely.net/git/mozilla-firefox
>
> If you want to build it you probably need the attached mozilla.port.mk
> diff.
Fails for me:
gmake[3]: Entering directory
'/usr/obj/firef
Vadim Zhukov:
> So new rules for gettext dependency would be:
>
> 1. If PLIST contains ${PREFIX}/share/locale/*/*/*.mo files, the
> package should have, either directly or indirectly, a run-time
> dependency (LDEP/RDEP) on devel/gettext,-main.
^^^
On 2016-03-28, Christian Weisgerber wrote:
> One issue I thought of: The handful of ports that are linked
> statically (CGI bins and the like) will need special attention.
Or not.
For one thing, I doubt that the people who put static binaries into
chroots remember to copy charset.ali
Recently I picked up a simple USB joystick...
uhidev0 at uhub0 port 1 configuration 1 interface 0
uhidev0: MOSIC USB 2A4K GamePad, rev 1.10/1.00, addr 2, iclass 3/0
uhid0 at uhidev0: input=3, output=0, feature=0
...to check out the joystick support situation in our game ports.
I've tried a bunch
Michael Knudsen <[EMAIL PROTECTED]> wrote:
> games/heroes seems to support joystick control.
It says "No joystick found", despite successfully opening /dev/uhid0.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
Jonathan Gray <[EMAIL PROTECTED]> wrote:
> There are quite a few SDL based ports that use a joystick via SDL.
Please name specific ports.
E.g., sdlroids claims to support "-l" for listing joysticks, but
that option appears to be completely ignored.
> ScummVM has hacky joystick support I did qui
Jonathan Gray <[EMAIL PROTECTED]> wrote:
> I think SDL currently only uses just joy (4/i386) for joysticks and ignores
> USB based joysticks.
joy(4) hardware is dead. When I looked for a matching joystick
several years back, it was already a bizarre fossil.
--
Christian "naddy" Weisgerber
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> In fact, are there _any_ game ports that handle a joystick?
Is there anybody who uses a joystick with a game from ports *now*?
Not years ago, or "it should work", or other such speculation.
--
Christian
Michael Knudsen <[EMAIL PROTECTED]> wrote:
> I don't really know anything about joysticks, but could this be an
> joystick-vs-joypad issue? (Analog vs. digital.)
I know preciously little about modern joysticks, but the USB one I
got didn't even include an MS Windows driver disk, so I assume there
This is a rough update for net/BitTorrent to 4.1.3. This might fix
some problems. In my very limited testing so far, it didn't fall
into some infinite loop as 4.1.1 sometimes does (but then this
happens very irregularly for me), and kashmir didn't throw up any
background errors. It also fixes th
Edd Barrett <[EMAIL PROTECTED]> wrote:
> You were right, 1.0.6 has been released and the API bug has apparently
> been fixed. Is anyone interested in porting this to stable?
How about getting it into -current first?
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
Lately, people have started adding sprintf() -> snprintf() and
str*() -> strl*() "clean-ups" to their ports.
There is value to this, but unless you can convince the upstream
maintainer to incorporate the changes it turns into a Sisyphean
task. We don't have the manpower to maintain our own patchs
Bernd Ahlers <[EMAIL PROTECTED]> wrote:
> Works for me on i386 with an ural(4) wifi card.
My ral(4) doesn't see any networks other than the one it was already
associated with. It's the same for ifconfig -M, though. Is this
a known driver limitation?
iwi(4) is fine.
--
Christian "naddy" Weisg
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> iwi(4) is fine.
Actually, there is the strange effect that kismet _sometimes_ marks
one of my two APs as using WEP, which is very much not the case.
I have no idea whether that is a bug in kismet or related to iwi(4).
--
Christi
steven mestdagh <[EMAIL PROTECTED]> wrote:
> Also, if anyone knows a nicer fix than the post-install part to have
> pstoedit use the libp2edrvstd.so.0.0 library, I would like to hear it.
Don't add -module to the libtool flags for building that library.
However, it looks like this actually _is_ a
Marc Espie <[EMAIL PROTECTED]> wrote:
> FETCH_CMD='ftp -4' pkg_add ought then to work.
>
> Good enough ? Objections ?
Er, "-4" is not the same as "epsv4 off". In fact, there is no command
line switch for the latter.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> > Also, if anyone knows a nicer fix than the post-install part to have
> > pstoedit use the libp2edrvstd.so.0.0 library, I would like to hear it.
>
> Don't add -module to the libtool flags for building that libr
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> Oh, I misread, it's the reverse problem, .so.0.0 is actually built
> but we want plain .so. "-module" or at most "-module -avoid_version"
> should take care of this... but it doesn't.
... due to an u
steven mestdagh <[EMAIL PROTECTED]> wrote:
> - removed autoconf and created a configure patch, setting CPPFLAGS="-Dunix".
> (is this necessary?)
I don't see a reason for -Dunix. Our compiler defines __unix__ by
default, which I see is also checked in the source.
> What else is wrong with CP
The modularization raises some questions.
On static archs, a module like libp2edrvstd.so can't be loaded (or
even built). What effect has this on the functionality of pstoedit?
BTW, the static versions of the modules, like libp2edrvstd.a, are
entirely useless, no point in packaging them. The sa
Oops, Jolan pointed out that I accidentally fmt(1)ed the diff.
Here we go again.
Index: Makefile
===
RCS file: /cvs/ports/net/BitTorrent/Makefile,v
retrieving revision 1.11
diff -u -r1.11 Makefile
--- Makefile20 Jun 2005 21:19:18
steven mestdagh <[EMAIL PROTECTED]> wrote:
> > BTW, the static versions of the modules, like libp2edrvstd.a, are
> > entirely useless, no point in packaging them. The same for the .la
> > files corresponding to modules (unless ltdl is involved, but I don't
> > see it).
>
> What's the preferred w
steven mestdagh <[EMAIL PROTECTED]> wrote:
> Well, this module seems to work. The annoying part is that it insists on
> ImageMagick opening two blank X11 windows.
Ugh.
> Now I'm wondering if there are any advantages in using pstoedit with the
> Magick++ module instead of just using ImageMagick's
Mike Pechkin <[EMAIL PROTECTED]> wrote:
> Just for fun:
> 1. I don't understand LICENCE of the book
The summary makes it look like a two-clause BSD license. The actual
text has a lot of verbiage... the most offensive thing I see is
that you may not distribute the book under some copy-protected/D
Robert Nagy <[EMAIL PROTECTED]> wrote:
> Add the arm to NOT_FOR_ARCHS because mpg123 is quiet unusable
> without an FPU. People should use mpg321 instead, or mplayer with the
> mad flavor.
Or madplay. From the people who wrote libmad in the first place.
Not that it has any particular advantage,
Wolfgang S. Rupprecht <[EMAIL PROTECTED]> wrote:
> Getting perl to shut up about the LANG variable was probably all I
> really needed from perl. (And that was a simple "export
> PERL_BADLANG=0").
Why set LC_CTYPE to an unsupported value in the first place?
--
Christian "naddy" Weisgerber
Wolfgang S. Rupprecht <[EMAIL PROTECTED]> wrote:
> > > Getting perl to shut up about the LANG variable was probably all I
> > > really needed from perl. (And that was a simple "export
> > > PERL_BADLANG=0").
> >
> > Why set LC_CTYPE to an unsupported value in the first place?
>
> Because the ch
Kurt Miller <[EMAIL PROTECTED]> wrote:
> I had forgotton about it here's the status: I would prefer not
> to make a flavor out of gtk2, instead just cut over to it when it is ready.
> firefox is big enough that mantaining two versions takes too much
> time.
>
> If people want this in it needs
I did a test build on amd64 and here's the current breakage:
devel/gstreamer unsupported arch
devel/mico asm?
lang/erlang ?
lang/unicon ?
mail/py-milter libmilter.a
math/coq?
math/
comms/tkhylafax has been marked
BROKEN="required dependencies not available"
for several years, possibly because comms/hylafax was marked BROKEN
at the time. I don't see why it should be fundamentally broken and
a slightly newer release seems to be available, too. Does somebody
J. Lievisse Adriaanse <[EMAIL PROTECTED]> wrote:
> When trying to build lang/clisp on both of my laptops (running
> -current), the build fails in "make build" because it can't map the
> memory correctly, it says something like: [...]
> Does anybody else has this problems too?
Known problem, eve
Jonathan Martin <[EMAIL PROTECTED]> wrote:
> >> I never even heard of madplay until I just read these emails. Let me say,
> >> it is nice!!! I was using mp3blaster but it has some strange bug going on
> >> where one cannot adjust the volume down, only up. Maybe it's just me,
> >> hehe.
> >
> > th
Christian Weisgerber <[EMAIL PROTECTED]> wrote:
> The problem is that our mixers don't provide a smooth range 0..255
> (scaled to 0..100 by the OSS emulation) but will ratchet up to the
> next supported value. The details may vary with the sound hardware,
> on my laptops
Theo de Raadt <[EMAIL PROTECTED]> wrote:
> > > The problem is that our mixers don't provide a smooth range 0..255
> > > (scaled to 0..100 by the OSS emulation) but will ratchet up to the
> > > next supported value.
>
> How about a kernel solution.
>
> Instead of always rounding up, we can make t
Theo de Raadt <[EMAIL PROTECTED]> wrote:
> How about a kernel solution.
>
> Instead of always rounding up, we can make the code round to farthest
> thing.
There is no single rounding function in the kernel, it's in the
hands of the individual drivers. Most modern hardware goes through
dev/ic/ac
Peter Valchev <[EMAIL PROTECTED]> wrote:
> Now that mozilla has been switched to gtk+2 a lot of people will get
> bitten by the fact that for some bizarre reason the emacs mode is no
> longer default in the gtk+2 settings as someone pointed out on this
> list a few weeks ago. This means that the
Paul de Weerd <[EMAIL PROTECTED]> wrote:
> I just noticed that my OpenBSD system's figlet(6), as installed from
> /usr/ports/misc/figlet/, dumps core with a Segmentation fault :
>
> $ figlet hoi
> Segmentation fault (core dumped)
>
> I think this is caused by some change in OpenBSD. I have, howe
Marc Espie <[EMAIL PROTECTED]> wrote:
> It's all documented in package(7) and package-specs(7).
... and ImageMagick-6.0.0-2p3 was an invalid name.
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
gpdf 2.8.1 is based on xpdf 3.00pl1. I've added the pl2 and pl3
security patches, as well as a fix for the CAN-2005-2097 DoS issue
I pulled out of the Mandrake SRPM.
It is important to realize that the xpdf code base is duplicated
several times in the tree: xpdf itself, gpdf, kpdf, and cups. Any
http://www.securitytracker.com/alerts/2005/Aug/1014744.html
"A remote or local user may be able to supply a specially crafted regular
expression to trigger a heap integer overflow in PCRE."
The devel/pcre port is way outdated, but the fix introduced between
6.1 and 6.2 is applicable to our 4.5 p
Bernd Schoeller <[EMAIL PROTECTED]> wrote:
> Ok, I found out the hard way. Still, if anybody has managed to compile
> pm3 with some manual intervention, I would appreciate any helpful
> hints. How big are the chances that it will ever work again (how big
> was the stat () API change) ?
lang/ezm3/
Marc Espie suggested this.
When rsync runs over ssh, mark the underlying ssh stream as
non-interactive. It's a bulk transfer. Disabling pseudo-tty
allocation in ssh will do this.
People who run a lot of rsync over ssh should try this.
Index: Makefile
===
frantisek holop <[EMAIL PROTECTED]> wrote:
> and sometimes the downloaded files are corrupt. obvious text files
> contain binary garbage. as bt uses hash checks i would guess the
> data coming on the wire is correct and it gets 'corrupted' when
> saved to the disk. but this is just a theory.
I
I accidentally noticed that text input fields in Firefox accept
rather more compose key (Multi_key) sequences than the expected
Latin 1 set. For example, I can input all the characters with
diacritics required for Czech, Slovak, and Serbo-Croation.
Where do those compose sequences come from?
X11,
Stephan Tesch <[EMAIL PROTECTED]> wrote:
> > attached is a patch to update multimedia/transcode to the 1.0.1 release.
>
> Patching the -current source tree worked ok. But I'm having these problems
> while building the port on i386:
> ===> Building package for transcode-1.0.1
> Switching to /us
This is based on what Rui Reis submitted here earlier this month.
I'm currently running a full package build with this on i386.
Overriding the GNU m4 check and substituting our m4 will cause the
regression tests to blow up. I haven't looked further into this.
Index: Makefile
Peter Stromberg <[EMAIL PROTECTED]> wrote:
> After patching, remove any zero sized files
Today's public service message: patch -E
--
Christian "naddy" Weisgerber [EMAIL PROTECTED]
Marcos Latas <[EMAIL PROTECTED]> wrote:
> One gets a segmentation fault running splitvt on OpenBSD/amd64
> 3.7-stable.
What a surprise, with all these
warning: cast to pointer from integer of different size
flying by during the build. Fixing these... fixes the crash.
--
Christian "naddy" W
This is the type of tool I personally haven't had any use for yet,
but that sounds potentially incredibly useful to _somebody_ out
there.
Xnee is a suite of programs that can record, replay and distribute
user actions under the X11 environment. Xnee can be used to:
* Automate tests
This is a MAJOR update of devel/gettext from our historical version
to the latest 0.14.5. Due to extensive changes, I've attached the
new port as tarball rather than a diff.
This update affects a large number of dependent ports and thus needs
extra careful checking.
Build and regressions tests s
Aleksander Piotrowski <[EMAIL PROTECTED]> wrote:
> > > on i386, make regress gives me: 9 of 63 tests failed.
> >
> > Good! 1.0.0 had 15/59 failures
>
> Yeah, six tests fixed and now please fix the rest.
Including the five that are expected to fail? Tall order. Come on
guys, don't discourage c
Rui Reis <[EMAIL PROTECTED]> wrote:
> I've already updated the port and it's still available here:
> http://www.openbsd-pt.com/ports/port-tn5250-0.17.3.tar.gz
CONFIGURE_STYLE=autoconf is only used when you change one of the
files used to create the configure script from, e.g. configure.in,
and ne
Rui Reis <[EMAIL PROTECTED]> wrote:
> I've already updated the port and it's still available here:
> http://www.openbsd-pt.com/ports/port-tn5250-0.17.3.tar.gz
Further comments on some basic issues:
* This port builds dynamic and static versions of a library.
Add CONFIGURE_ARGS=${CONFIGURE_SHAR
Peter Strömberg <[EMAIL PROTECTED]> wrote:
> rc2 require no other change than updating VER
I updated to GTK 2.8 and Firefox 1.5rc2 (from 1.0.7) in one swoop
here. i386, remote X11 display.
* It picked up perfectly my existing configuration, bookmarks,
cookies, history, etc.
* Browsing works
901 - 1000 of 1999 matches
Mail list logo
