CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 01:28:27 Modified files: geo/gpx-viewer : Makefile distinfo geo/gpx-viewer/pkg: PLIST Removed files: geo/gpx-viewer/patches: patch-configure_ac Log message: Unbreak by updating to a snapshot of the port-to-libchamplain-0.12 bzr branch. This now uses gtk+3.. ok jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 01:29:48 Modified files: geo/emerillon : Makefile distinfo geo/emerillon/pkg: PLIST Removed files: geo/emerillon/patches: patch-bindings_vala_emerillon_deps patch-configure_ac patch-data_emerillon_pc_in patch-emerillon_Makefile_in Log message: Unbreak by updating to emerillon 0.1.90. This now uses libchamplain 0.12/gtk+3/libpeas. Remove now useless patches. ok jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/07/17 02:30:58 Modified files: net/miniupnp/miniupnpc: Makefile net/miniupnp/miniupnpc/pkg: PLIST-main Added files: net/miniupnp/miniupnpc/pkg: README-main Log message: Mention that miniupnpc wants 'multicast_host=YES' suggestions/ok ajacoutot@
%{AUTOVALS9-jdsv70
ports-changes
2012-7-17 17:45:07
[demime 1.01d removed an attachment of type APPLICATION/DEFANGED which had a
name of %{AUTOVALS9.3412DEFANGED-xls]
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 03:56:30 Modified files: devel : Makefile Log message: sync
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 03:55:59 Log message: import node-gir 0.0.2 Node-gir is node bindings to the girepository library making it possible to make automatic and dynamic calls to any library that has GI annotations installed. This will make it possible to script a GNOME desktop system entirely from Node much in the way it's done today with Seed, GJS or pygtk. ok sthen@ Status: Vendor Tag: jasper Release Tags: jasper_20121707 N ports/devel/node-gir/Makefile N ports/devel/node-gir/distinfo N ports/devel/node-gir/pkg/PLIST N ports/devel/node-gir/pkg/DESCR N ports/devel/node-gir/patches/patch-wscript N ports/devel/node-gir/patches/patch-src_types_function_cc No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2012/07/17 03:31:21 Modified files: sysutils/bacula: Makefile sysutils/bacula/pkg: README-main Log message: Fix README-main, pointed out by Jiri B on ports@. ok merdely aja
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:05:34 Modified files: graphics/fyre : Makefile graphics/fyre/pkg: PLIST Removed files: graphics/fyre/patches: patch-data-Makefile_in Log message: - disable gnet support, gnet is deprecated and ought to be removed. - install a .desktop file while here.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:05:11 Modified files: games/gcompris : Makefile Log message: disable gnet support, gnet is deprecated and ought to be removed. ok aja@ (MAINTAINER)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/07/17 04:46:04 Modified files: telephony/pjsua: Makefile distinfo telephony/pjsua/patches: patch-aconfigure_ac Log message: Maintenance update to pjsua-2.0.1
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:46:41 Modified files: net: Makefile Log message: sync
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:46:24 Removed files: net/gsnmp : Makefile distinfo net/gsnmp/patches: patch-gsnmp_m4 net/gsnmp/pkg : DESCR PFRAG.shared PLIST Log message: remove outdated, deprecated and half-working cruft ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:46:01 Removed files: net/scli : Makefile distinfo net/scli/patches: patch-doc_scli_texinfo net/scli/pkg : DESCR PLIST Log message: remove broken scli, which also lacks working non-default community strings ok sthen@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:49:13 Removed files: net/gnet : Makefile distinfo net/gnet/patches: patch-Makefile_in net/gnet/pkg : DESCR PFRAG.shared PLIST Log message: remove gnet, it's deprecated and shouldn't be used anymore since the functionality has been in glib = 2.22. ok aja@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 04:48:57 Modified files: net: Makefile Log message: unhook gnet
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/07/17 05:23:18 Modified files: graphics/feh : Makefile graphics/feh/patches: patch-man_feh_pre Log message: Fix a typo in feh(1) manual page. upstream git commit 6ee2dca03289506214e5631a1360cb33e3f4cf55
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/07/17 05:32:00 Modified files: x11/awesome: Makefile distinfo x11/awesome/patches: patch-awesomeConfig_cmake patch-client_c patch-client_h Removed files: x11/awesome/patches: patch-lib_awful_client_lua_in Log message: Bugfix update to awesome v3.4.13 (Octopus)
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: dco...@cvs.openbsd.org 2012/07/17 07:26:49 Modified files: net/mldonkey/stable: Makefile distinfo net/mldonkey/stable/patches: patch-config_Makefile_in Removed files: net/mldonkey/stable/patches: patch-config_wget_c Log message: Update to mldonkey-3.1.2 While here, fix some errors wrt non-native ocaml architectures
Le rollup Eco est maintenant à 39 euros
Le rollup Eco à 39* ht avec impression: Impression HD et housse de transport incluses Idéal pour vos actions one shot Format 85x200 Montage ultra rapide Disponible en 4 jours * Hors frais de traitement de visuel (10/visuel différent) Simple et rapide: commandez online en 5 minutes sur vedi-express GROUND BOARD DISPLAY - NOUVEAU - Display double face pour votre communication extérieure - Piquets pour ancrage en sol meuble - Elastiques fournis pour fixer la bâche - Assemblage aisé: 5 minutes à 1 personne - Housse de transport incluse - Image vendue séparément VOS BACHES SUR MESURE - Impression HD - 8 finitions au choix - 4 supports d'impression - Disponible en 3 jours STOP TROTTOIRS CHEVALETS - Formats A1, B1, A0 et A2. - Assure une communication recto verso. - Cadres v-clic en aluminium anodisé. - Installation aisée - Affiches vendues séparément. VEDI express © 2002-2012 Rollup, Pop Up, bâches, stands parapluie aux meilleurs prix et dans les meilleurs délais. Powered by VEDI ne plus recevoir nos newsletters
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 13:23:31 Log message: Import py-gevent 0.13.7 gevent is a Python networking library that uses greenlet to provide synchronous API on top of libevent event loop. * Fast event loop based on libevent. * Lightweight execution units based on greenlet. * Familiar API that re-uses concepts from the Python standard library. * Cooperative sockets with ssl support. * DNS queries performed through libevent-dns. * Ability to use standard library and 3rd party modules written for standard blocking sockets * Fast WSGI server based on libevent-http. Requirement of upcoming firefox sync port. ok rpointel@ Status: Vendor Tag: landry Release Tags: landry_20120717 N ports/devel/py-gevent/Makefile N ports/devel/py-gevent/distinfo N ports/devel/py-gevent/pkg/PLIST N ports/devel/py-gevent/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 13:24:47 Log message: Import py-greenlet 0.4.0. The greenlet package is a spin-off of Stackless, a version of CPython that supports micro-threads called tasklets. Tasklets run pseudo-concurrently (typically in a single or a few OS-level threads) and are synchronized with data exchanges on channels. Dependency of the just-imported py-gevent. ok rpointel@ Status: Vendor Tag: landry Release Tags: landry_20120717 N ports/devel/py-greenlet/Makefile N ports/devel/py-greenlet/distinfo N ports/devel/py-greenlet/pkg/PLIST N ports/devel/py-greenlet/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 13:27:34 Log message: Import py-metlog 0.9.2. metlog-py is a Python client for the Metlog system of application logging and metrics gathering developed by the Mozilla Services team. The Metlog system is meant to make life easier for application developers with regard to generating and sending logging and analytics data to various destinations. Needed by upcoming firefox sync server port. ok rpointel@ Status: Vendor Tag: landry Release Tags: landry_20120717 N ports/sysutils/py-metlog/Makefile N ports/sysutils/py-metlog/distinfo N ports/sysutils/py-metlog/pkg/PLIST N ports/sysutils/py-metlog/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 13:29:13 Log message: Import py-recaptcha-client 1.0.6. Provides a CAPTCHA for Python using the reCAPTCHA service. Does not require any imaging libraries because the CAPTCHA is served directly from reCAPTCHA. Also allows you to securely obfuscate emails with Mailhide. This functionality requires pycrypto. This library requires two types of API keys. If you'd like to use the CAPTCHA, you'll need a key from https://www.google.com/recaptcha/admin/create. For Mailhide, you'll need a key from http://www.google.com/recaptcha/mailhide/apikey. Required by upcoming firefox sync server port. ok rpointel@ Status: Vendor Tag: landry Release Tags: landry_20120717 N ports/www/py-recaptcha-client/Makefile N ports/www/py-recaptcha-client/distinfo N ports/www/py-recaptcha-client/pkg/PLIST N ports/www/py-recaptcha-client/pkg/DESCR No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 13:34:10 Modified files: devel : Makefile www: Makefile sysutils : Makefile Log message: +py-cef, py-metlog, py-repoze-who, py-recaptcha-client, py-gevent, py-greenlet
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: lan...@cvs.openbsd.org 2012/07/17 14:19:27 Modified files: infrastructure/db: user.list Log message: Reserve uid 699 for user _mozsync.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2012/07/17 14:56:22 Modified files: devel/msp430/binutils: distinfo devel/msp430/gcc: distinfo devel/msp430/gdb: distinfo devel/msp430/libc: distinfo devel/msp430/msp430mcu: distinfo Log message: missed in previous
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: rfree...@cvs.openbsd.org2012/07/17 15:29:50 Log message: Import eduke32. eduke32 is an advanced Duke Nukem 3D engine capable of playing the game, and filled to the brim with editing enhancements. Includes mapster32, a map-making program similar to the original build map editor. ok jasper@, edd@ Status: Vendor Tag: rfreeman Release Tags: rfreeman_20120717 N ports/games/eduke32/distinfo N ports/games/eduke32/Makefile N ports/games/eduke32/pkg/DESCR N ports/games/eduke32/pkg/PLIST N ports/games/eduke32/pkg/README N ports/games/eduke32/patches/patch-build_src_glbuild_c N ports/games/eduke32/patches/patch-Makefile_common N ports/games/eduke32/patches/patch-build_Makefile_shared No conflicts created by this import
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: bl...@cvs.openbsd.org 2012/07/17 16:04:37 Modified files: misc/p5-File-MMagic: Makefile distinfo Log message: update p5-File-MMagic to 1.29
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2012/07/17 20:18:35 Modified files: databases/node-sqlite3: distinfo Removed files: databases/node-sqlite3/patches: patch-package_json Log message: Update node-sqlite3 to 2.1.5 ok jeremy@, jasper@
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: abie...@cvs.openbsd.org 2012/07/17 22:28:40 Modified files: databases/node-sqlite3: Makefile Log message: Remove REVISION for 2.1.5 update.
cannot send utf8 charakters with gajim + OpenPGP encryption
Hi, I get the following stack trace: Exception in thread Thread-48: Traceback (most recent call last): File /usr/local/lib/python2.7/threading.py, line 551, in __bootstrap_inner self.run() File /usr/local/lib/python2.7/threading.py, line 504, in run self.__target(*self.__args, **self.__kwargs) File /usr/local/share/gajim/src/gui_interface.py, line 2949, in thread_function output = func(*func_args) File /usr/local/share/gajim/src/common/connection.py, line 293, in encrypt_thread return self.gpg.encrypt(msg, [keyID], always_trust) File /usr/local/share/gajim/src/common/gpg.py, line 50, in encrypt always_trust=always_trust, passphrase=self.passphrase) File /usr/local/share/gajim/src/common/gnupg.py, line 646, in encrypt data = _make_binary_stream(data, self.encoding) File /usr/local/share/gajim/src/common/gnupg.py, line 148, in _make_binary_stream s = s.encode(encoding) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128) This is on OpenBSD 5.2-beta (GENERIC) #257: Wed Jul 11 11:32:34 MDT 2012 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with Information for inst:gajim-0.15p3 The message is not send, not added to the log and not added to the local chat window. I found two workarounds: Disable OpenPGP encryption (hm, yeah, not going to happen) or start gajim with LANG set, i.e. LANG=en_US.UTF-8 gajim LANG is unset on my workstation. I know this worked in 4.9, I know it's broken in a 5.1-current snapshot at or around 25th of may, there is anecdotal evidence that it used to work on 5.1-current in the february to march timeframe. Thanks, Florian -- I'm not entirely sure you are real.
High system load with gkrellm on amd64
On two of my amd64 machines (a desktop and a laptop), I have been plagued, for several months, by seemingly random high system loads (100%). Sometimes after a few minutes, sometimes after a couple of days, of use, my CPU useage would effectively hit 100%, with top showing 2 CPU cores hitting 50% each on system. For some time, I could not work out any way of solving this, short of rebooting the machine in question. It now seems that the culprit is gkrellm: killing it reduces the system load back to down to 0-3%. Has anyone else seen this problem with gkrellm? I'm at a bit of a loss to explain why it happens so randomly. It might, perhaps, be related to the rthreads transition, but it's hard to be sure. The laptop dmesg is attached at the end. If anyone wants further details, I'm happy to provide them. Laurie -- Personal http://tratt.net/laurie/ The Converge programming language http://convergepl.org/ https://github.com/ltratt http://twitter.com/laurencetratt OpenBSD 5.2-beta (GENERIC.MP) #345: Sun Jul 8 14:48:27 MDT 2012 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 8466853888 (8074MB) avail mem = 8219103232 (7838MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.6 @ 0xdae9c000 (66 entries) bios0: vendor LENOVO version 8DET54WW (1.24 ) date 10/18/2011 bios0: LENOVO 4287CTO acpi0 at bios0: rev 2 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SLIC SSDT SSDT SSDT HPET APIC MCFG ECDT ASF! TCPA SSDT SSDT UEFI UEFI UEFI acpi0: wakeup devices LID_(S3) SLPB(S3) IGBE(S4) EXP4(S4) EXP7(S4) EHC1(S3) EHC2(S3) HDEF(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpihpet0 at acpi0: 14318179 Hz acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 2292.91 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu0: 256KB 64b/line 8-way L2 cache cpu0: apic clock running at 99MHz cpu1 at mainbus0: apid 2 (application processor) cpu1: Intel(R) Core(TM) i5-2410M CPU @ 2.30GHz, 2292.56 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,SSE3,PCLMUL,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,x2APIC,POPCNT,AES,XSAVE,AVX,NXE,LONG,LAHF cpu1: 256KB 64b/line 8-way L2 cache ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 24 pins acpimcfg0 at acpi0 addr 0xf800, bus 0-63 acpiec0 at acpi0 acpiprt0 at acpi0: bus 0 (PCI0) acpiprt1 at acpi0: bus -1 (PEG_) acpiprt2 at acpi0: bus 2 (EXP1) acpiprt3 at acpi0: bus 3 (EXP2) acpiprt4 at acpi0: bus 5 (EXP4) acpiprt5 at acpi0: bus 13 (EXP5) acpiprt6 at acpi0: bus -1 (EXP7) acpicpu0 at acpi0: C3, C2, C1, PSS acpicpu1 at acpi0: C3, C2, C1, PSS acpipwrres0 at acpi0: PUBS acpitz0 at acpi0: critical temperature is 99 degC acpibtn0 at acpi0: LID_ acpibtn1 at acpi0: SLPB acpibat0 at acpi0: BAT0 model 42T4861 serial 25468 type LION oem SANYO acpibat1 at acpi0: BAT1 not present acpiac0 at acpi0: AC unit offline acpithinkpad0 at acpi0 acpidock0 at acpi0: GDCK not docked (0) cpu0: Enhanced SpeedStep 2292 MHz: speeds: 2301, 2300, 2000, 1800, 1600, 1400, 1200, 1000, 800 MHz pci0 at mainbus0 bus 0 pchb0 at pci0 dev 0 function 0 Intel Core 2G Host rev 0x09 vga1 at pci0 dev 2 function 0 Intel HD Graphics 3000 rev 0x09 wsdisplay0 at vga1 mux 1: console (80x25, vt100 emulation) wsdisplay0: screen 1-5 added (80x25, vt100 emulation) intagp0 at vga1 agp0 at intagp0: aperture at 0xe000, size 0x1000 inteldrm0 at vga1: apic 2 int 16 drm0 at inteldrm0 Intel 6 Series MEI rev 0x04 at pci0 dev 22 function 0 not configured em0 at pci0 dev 25 function 0 Intel 82579LM rev 0x04: msi, address f0:de:f1:a7:e4:89 ehci0 at pci0 dev 26 function 0 Intel 6 Series USB rev 0x04: apic 2 int 16 usb0 at ehci0: USB revision 2.0 uhub0 at usb0 Intel EHCI root hub rev 2.00/1.00 addr 1 azalia0 at pci0 dev 27 function 0 Intel 6 Series HD Audio rev 0x04: msi azalia0: codecs: Conexant/0x506e, Intel/0x2805, using Conexant/0x506e audio0 at azalia0 ppb0 at pci0 dev 28 function 0 Intel 6 Series PCIE rev 0xb4: msi pci1 at ppb0 bus 2 ppb1 at pci0 dev 28 function 1 Intel 6 Series PCIE rev 0xb4: msi pci2 at ppb1 bus 3 iwn0 at pci2 dev 0 function 0 Intel Centrino Advanced-N 6205 rev 0x34: msi, MIMO 2T2R, MoW, address 08:11:96:cb:69:58 ppb2 at pci0 dev 28 function 3 Intel 6 Series PCIE rev 0xb4: msi pci3 at ppb2 bus 5 ppb3 at pci0 dev 28 function 4 Intel 6 Series PCIE rev 0xb4: msi pci4 at ppb3 bus 13 sdhc0 at pci4 dev 0 function 0 Ricoh 5U823 SD/MMC rev 0x04: apic 2 int 16 sdmmc0 at sdhc0 ehci1 at pci0 dev 29 function 0 Intel 6 Series USB rev 0x04: apic 2 int 23 usb1 at ehci1: USB revision 2.0 uhub1 at usb1 Intel EHCI root hub rev 2.00/1.00
Re: High system load with gkrellm on amd64
On 2012/07/17 10:23, Laurence Tratt wrote: On two of my amd64 machines (a desktop and a laptop), I have been plagued, for several months, by seemingly random high system loads (100%). Sometimes after a few minutes, sometimes after a couple of days, of use, my CPU useage would effectively hit 100%, with top showing 2 CPU cores hitting 50% each on system. For some time, I could not work out any way of solving this, short of rebooting the machine in question. It now seems that the culprit is gkrellm: killing it reduces the system load back to down to 0-3%. Has anyone else seen this problem with gkrellm? I'm at a bit of a loss to explain why it happens so randomly. It might, perhaps, be related to the rthreads transition, but it's hard to be sure. The laptop dmesg is attached at the end. If anyone wants further details, I'm happy to provide them. It's worth attaching ktrace to the process when it's having this problem. Ideally start gkrellm with LD_BIND_NOW defined to reduce some of the spam e.g. LD_BIND_NOW= gkrellm Then when it's looping, do: ktrace -d -i -p $(pgrep gkrellm); sleep 1; ktrace -C kdump somefile.txt And have a look and see what it's doing. If this doesn't give anything interesting then probably break out GDB and take a look there instead, but ktrace is likely to get something useful more easily.
Re: opencore: .git?
On 2012/07/16 19:44, Jan Stary wrote: On Jul 16 13:59:27, Stuart Henderson wrote: On 2012/07/16 13:23, Jan Stary wrote: There is a .git directory inside the audio/opencore-amr port - is it supposed to be there, or is it a cvs import mistake? If this is present in your checkout, then you're using the wrong options when you update. A normal update of a -current tree should be done with cvs -d $CVSROOT up -PdA. I used 'cvs -d anon...@mirror.osn.de:/cvs up -Pd', so I missed the -A which resets sticky tags, dates, or -k options. Was that it? -P should have done it really.. I am still puzzled why the .git directory is even present in the tree. Imported by mistake, then removed almost immediately.
Re: cannot send utf8 charakters with gajim + OpenPGP encryption
On Tue, Jul 17, 2012 at 07:39:44AM +, Florian Obser wrote: Hi, I get the following stack trace: Exception in thread Thread-48: Traceback (most recent call last): File /usr/local/lib/python2.7/threading.py, line 551, in __bootstrap_inner self.run() File /usr/local/lib/python2.7/threading.py, line 504, in run self.__target(*self.__args, **self.__kwargs) File /usr/local/share/gajim/src/gui_interface.py, line 2949, in thread_function output = func(*func_args) File /usr/local/share/gajim/src/common/connection.py, line 293, in encrypt_thread return self.gpg.encrypt(msg, [keyID], always_trust) File /usr/local/share/gajim/src/common/gpg.py, line 50, in encrypt always_trust=always_trust, passphrase=self.passphrase) File /usr/local/share/gajim/src/common/gnupg.py, line 646, in encrypt data = _make_binary_stream(data, self.encoding) File /usr/local/share/gajim/src/common/gnupg.py, line 148, in _make_binary_stream s = s.encode(encoding) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128) Seems like a perfectly sensible failure mode to me, see below. This is on OpenBSD 5.2-beta (GENERIC) #257: Wed Jul 11 11:32:34 MDT 2012 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with Information for inst:gajim-0.15p3 The message is not send, not added to the log and not added to the local chat window. I found two workarounds: Disable OpenPGP encryption (hm, yeah, not going to happen) or start gajim with LANG set, i.e. LANG=en_US.UTF-8 gajim LANG is unset on my workstation. Why don't you use the UTF-8 locale if you want to use UTF-8? I know this worked in 4.9, I know it's broken in a 5.1-current snapshot at or around 25th of may, there is anecdotal evidence that it used to work on 5.1-current in the february to march timeframe. OpenBSD's libc used to default to latin1 semantics until september 2011. Since then, it's been using ASCII by default, and you have to configure a locale if you want anything more than ASCII. See http://marc.info/?l=openbsd-cvsm=131668243124387w=2 and http://marc.info/?l=openbsd-cvsm=130186491102931w=2 This was also mentioned on current.html at the time but that entry has since been shifted out. I am not sure if python follows semantics provided by libc, though that would definitely make sense. If it doesn't then you might be obversing a behaviour change in python as well, since it was probably upgraded during the same time frame. Maybe the way python selects encoding modules has changed? However, I don't see how this behaviour is wrong. You should be configuring the correct locale for your desired character set. There is nothing wrong with doing this just for one application if you don't want every application to use UTF-8.
Re: cannot send utf8 charakters with gajim + OpenPGP encryption
On Tue, Jul 17, 2012 at 02:24:25PM +0200, Stefan Sperling wrote: On Tue, Jul 17, 2012 at 07:39:44AM +, Florian Obser wrote: Hi, I get the following stack trace: Exception in thread Thread-48: Traceback (most recent call last): File /usr/local/lib/python2.7/threading.py, line 551, in __bootstrap_inner self.run() File /usr/local/lib/python2.7/threading.py, line 504, in run self.__target(*self.__args, **self.__kwargs) File /usr/local/share/gajim/src/gui_interface.py, line 2949, in thread_function output = func(*func_args) File /usr/local/share/gajim/src/common/connection.py, line 293, in encrypt_thread return self.gpg.encrypt(msg, [keyID], always_trust) File /usr/local/share/gajim/src/common/gpg.py, line 50, in encrypt always_trust=always_trust, passphrase=self.passphrase) File /usr/local/share/gajim/src/common/gnupg.py, line 646, in encrypt data = _make_binary_stream(data, self.encoding) File /usr/local/share/gajim/src/common/gnupg.py, line 148, in _make_binary_stream s = s.encode(encoding) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128) Seems like a perfectly sensible failure mode to me, see below. yes, I'm noting a behaviour change. I'm not saying that there is anything wrong with it. This is on OpenBSD 5.2-beta (GENERIC) #257: Wed Jul 11 11:32:34 MDT 2012 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with Information for inst:gajim-0.15p3 The message is not send, not added to the log and not added to the local chat window. I found two workarounds: Disable OpenPGP encryption (hm, yeah, not going to happen) or start gajim with LANG set, i.e. LANG=en_US.UTF-8 gajim LANG is unset on my workstation. Why don't you use the UTF-8 locale if you want to use UTF-8? because I'm trying to stay away from locales as far as possible :) (And it used to work before, and it's (somewhat) unrelated to the locale change in base, see below) I know this worked in 4.9, I know it's broken in a 5.1-current snapshot at or around 25th of may, there is anecdotal evidence that it used to work on 5.1-current in the february to march timeframe. OpenBSD's libc used to default to latin1 semantics until september 2011. Since then, it's been using ASCII by default, and you have to configure a locale if you want anything more than ASCII. See http://marc.info/?l=openbsd-cvsm=131668243124387w=2 and http://marc.info/?l=openbsd-cvsm=130186491102931w=2 This was also mentioned on current.html at the time but that entry has since been shifted out. I now have confirmation that this used to work in 5.1 so something else changed later. I am not sure if python follows semantics provided by libc, though that would definitely make sense. If it doesn't then you might be obversing a behaviour change in python as well, since it was probably upgraded during the same time frame. Maybe the way python selects encoding modules has changed? However, I don't see how this behaviour is wrong. Me neither. It's interesting that it only effects gpg in gajim (as far as I know). You should be configuring the correct locale for your desired character set. There is nothing wrong with doing this just for one application if you don't want every application to use UTF-8. Sure. Ah, I see now that work around was a poor choice of words the solution is... would have been better, sorry. -- I'm not entirely sure you are real.
Re: cannot send utf8 charakters with gajim + OpenPGP encryption
Sorry, forgot to add: this was mainly for the archives, there is nothing here to fix. On Tue, Jul 17, 2012 at 12:51:22PM +, Florian Obser wrote: On Tue, Jul 17, 2012 at 02:24:25PM +0200, Stefan Sperling wrote: On Tue, Jul 17, 2012 at 07:39:44AM +, Florian Obser wrote: Hi, I get the following stack trace: Exception in thread Thread-48: Traceback (most recent call last): File /usr/local/lib/python2.7/threading.py, line 551, in __bootstrap_inner self.run() File /usr/local/lib/python2.7/threading.py, line 504, in run self.__target(*self.__args, **self.__kwargs) File /usr/local/share/gajim/src/gui_interface.py, line 2949, in thread_function output = func(*func_args) File /usr/local/share/gajim/src/common/connection.py, line 293, in encrypt_thread return self.gpg.encrypt(msg, [keyID], always_trust) File /usr/local/share/gajim/src/common/gpg.py, line 50, in encrypt always_trust=always_trust, passphrase=self.passphrase) File /usr/local/share/gajim/src/common/gnupg.py, line 646, in encrypt data = _make_binary_stream(data, self.encoding) File /usr/local/share/gajim/src/common/gnupg.py, line 148, in _make_binary_stream s = s.encode(encoding) UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 1: ordinal not in range(128) Seems like a perfectly sensible failure mode to me, see below. yes, I'm noting a behaviour change. I'm not saying that there is anything wrong with it. This is on OpenBSD 5.2-beta (GENERIC) #257: Wed Jul 11 11:32:34 MDT 2012 t...@i386.openbsd.org:/usr/src/sys/arch/i386/compile/GENERIC with Information for inst:gajim-0.15p3 The message is not send, not added to the log and not added to the local chat window. I found two workarounds: Disable OpenPGP encryption (hm, yeah, not going to happen) or start gajim with LANG set, i.e. LANG=en_US.UTF-8 gajim LANG is unset on my workstation. Why don't you use the UTF-8 locale if you want to use UTF-8? because I'm trying to stay away from locales as far as possible :) (And it used to work before, and it's (somewhat) unrelated to the locale change in base, see below) I know this worked in 4.9, I know it's broken in a 5.1-current snapshot at or around 25th of may, there is anecdotal evidence that it used to work on 5.1-current in the february to march timeframe. OpenBSD's libc used to default to latin1 semantics until september 2011. Since then, it's been using ASCII by default, and you have to configure a locale if you want anything more than ASCII. See http://marc.info/?l=openbsd-cvsm=131668243124387w=2 and http://marc.info/?l=openbsd-cvsm=130186491102931w=2 This was also mentioned on current.html at the time but that entry has since been shifted out. I now have confirmation that this used to work in 5.1 so something else changed later. I am not sure if python follows semantics provided by libc, though that would definitely make sense. If it doesn't then you might be obversing a behaviour change in python as well, since it was probably upgraded during the same time frame. Maybe the way python selects encoding modules has changed? However, I don't see how this behaviour is wrong. Me neither. It's interesting that it only effects gpg in gajim (as far as I know). You should be configuring the correct locale for your desired character set. There is nothing wrong with doing this just for one application if you don't want every application to use UTF-8. Sure. Ah, I see now that work around was a poor choice of words the solution is... would have been better, sorry. -- I'm not entirely sure you are real. -- I'm not entirely sure you are real.
Le rollup Eco est maintenant à 39 euros
Le rollup Eco à 39€* ht avec impression: Impression HD et housse de transport incluses Idéal pour vos actions one shot Format 85x200 Montage ultra rapide Disponible en 4 jours * Hors frais de traitement de visuel (10€/visuel différent) Simple et rapide: commandez online en 5 minutes sur vedi-express GROUND BOARD DISPLAY - NOUVEAU - Display double face pour votre communication extérieure - Piquets pour ancrage en sol meuble - Elastiques fournis pour fixer la bâche - Assemblage aisé: 5 minutes à 1 personne - Housse de transport incluse - Image vendue séparément VOS BACHES SUR MESURE - Impression HD - 8 finitions au choix - 4 supports d'impression - Disponible en 3 jours STOP TROTTOIRS CHEVALETS - Formats A1, B1, A0 et A2. - Assure une communication recto verso. - Cadres v-clic en aluminium anodisé. - Installation aisée - Affiches vendues séparément. VEDI express © 2002-2012 Rollup, Pop Up, bâches, stands parapluie aux meilleurs prix et dans les meilleurs délais. Powered by VEDI ne plus recevoir nos newsletters
Re: Update: hotfix for www/dokuwiki
On Sat, Jul 14, 2012 at 12:50:23AM +0200, Christopher Zimmermann wrote: Hi, here's an hotfix update for www/dokuwiki. Can someone commit this? Thanks Cristopher. Tested on 5.1 i386, upgrading: dokuwiki-2012.01.25a-dokuwiki-2012.01.25b: ok
UPDATE: devel/ocaml-pcre
Hi, here again my update for devel/ocaml-pcre. Here's what I have changed: * Convert to new style assignments in Makefine (COMMENT= - COMMENT =) * remove the custom flag from the library. (see ocamlc(1) -a option) * add the same findlib hack I used for ocaml-net. * Follow the new OCaml naming convention. * install documentation this also fixes a problem with ocaml-net when running dynamically linked programs using Netstring_pcre. Tested on i386 and amd64. ok? Christopher
UPDATE: devel/ocaml-pcre - with diff
Hi,
sorry for the double posting, I forgot to insert the diff.
here again my update for devel/ocaml-pcre. Here's what I have changed:
* Convert to new style assignments in Makefine (COMMENT= - COMMENT =)
* remove the custom flag from the library. (see ocamlc(1) -a option)
* add the same findlib hack I used for ocaml-net.
* Follow the new OCaml naming convention.
* install documentation
this also fixes a problem with ocaml-net when running dynamically
linked programs using Netstring_pcre.
Tested on i386 and amd64. ok?
Christopher
Only in devel/ocaml-pcre: CVS
diff -ru devel/ocaml-pcre/Makefile mystuff/devel/ocaml-pcre/Makefile
--- devel/ocaml-pcre/Makefile Tue May 22 13:46:40 2012
+++ mystuff/devel/ocaml-pcre/Makefile Mon Jul 9 19:38:48 2012
@@ -1,40 +1,55 @@
# $OpenBSD: Makefile,v 1.2 2012/05/22 11:46:40 jasper Exp $
-COMMENT= Objective Caml perl-compatible regexp library
-CATEGORIES=devel textproc
+COMMENT = OCaml perl-compatible regexp library
+CATEGORIES = devel textproc
-V= 6.2.5
-DISTNAME= pcre-ocaml-$V
-PKGNAME= ocaml-pcre-$V
+V =6.2.5
+DISTNAME = pcre-ocaml-${V}
+PKGNAME = ocaml-pcre-${V}
+REVISION = 1
-HOMEPAGE= http://ocaml.info/home/ocaml_sources.html
+HOMEPAGE = http://ocaml.info/home/ocaml_sources.html
# GPLv2+
-PERMIT_PACKAGE_FTP=Yes
-PERMIT_PACKAGE_CDROM= Yes
-PERMIT_DISTFILES_FTP= Yes
-PERMIT_DISTFILES_CDROM=Yes
+PERMIT_PACKAGE_FTP = Yes
+PERMIT_PACKAGE_CDROM = Yes
+PERMIT_DISTFILES_FTP = Yes
+PERMIT_DISTFILES_CDROM = Yes
-MODULES= lang/ocaml
+MODULES = lang/ocaml
-MASTER_SITES= https://bitbucket.org/mmottl/pcre-ocaml/downloads/
+MASTER_SITES = https://bitbucket.org/mmottl/pcre-ocaml/downloads/
-RUN_DEPENDS= sysutils/findlib
-BUILD_DEPENDS= ${RUN_DEPENDS}
-LIB_DEPENDS= devel/pcre
-WANTLIB= pcre
+RUN_DEPENDS = sysutils/findlib
+BUILD_DEPENDS =${RUN_DEPENDS}
+LIB_DEPENDS = devel/pcre
+WANTLIB = pcre
-NO_REGRESS=Yes
-USE_GMAKE= Yes
-MAKE_ENV+= OCAMLFIND_INSTFLAGS=-ldconf ignore
+MAKE_FLAGS = NO_CUSTOM=y
+NO_REGRESS = Yes
+USE_GMAKE =Yes
+
+ALL_TARGET = all htdoc
+
pre-install:
${INSTALL_DATA_DIR} ${PREFIX}/lib/ocaml/site-lib/pcre
+ ${INSTALL_DATA_DIR} ${PREFIX}/lib/ocaml/stublibs
+ ln -s ../stublibs ${PREFIX}/lib/ocaml/site-lib/
+post-install:
+ ${INSTALL_DATA_DIR} ${PREFIX}/share/doc/ocaml-pcre/html/
+ ${INSTALL_DATA} ${WRKSRC}/LICENSE ${PREFIX}/share/doc/ocaml-pcre/
+ ${INSTALL_DATA} ${WRKSRC}/README.txt ${PREFIX}/share/doc/ocaml-pcre/
+ ${INSTALL_DATA} \
+ ${WRKSRC}/lib/doc/pcre/html/* \
+ ${PREFIX}/share/doc/ocaml-pcre/html/
+post-install:
+
.include bsd.port.mk
.if ${MODOCAML_NATIVE:L:Mno}
-WRKSRC=${WRKDIST}/lib
-ALL_TARGET=byte-code-library
-INSTALL_TARGET=libinstall-byte-code
+WRKSRC = ${WRKDIST}/lib
+ALL_TARGET = byte-code-library htdoc
+INSTALL_TARGET = libinstall-byte-code
.endif
Only in devel/ocaml-pcre/pkg: CVS
diff -ru devel/ocaml-pcre/pkg/DESCR mystuff/devel/ocaml-pcre/pkg/DESCR
--- devel/ocaml-pcre/pkg/DESCR Thu Sep 15 17:50:23 2011
+++ mystuff/devel/ocaml-pcre/pkg/DESCR Mon Jul 9 19:35:39 2012
@@ -1,13 +1,13 @@
-This OCaml-library interfaces the PCRE (Perl-compatible regular expression)
-library which is written in C. it can be used for matching regular expressions
-which are written in the PERL style.
+This OCaml-library interfaces the PCRE (Perl-compatible regular
+expression) library which is written in C. it can be used for matching
+regular expressions which are written in the PERL style.
-It is reentrant - and thus thread safe. This is not the case with the Str
-module of OCaml, which builds on the GNU regex-library. Using reentrant
-libraries also means more convenience for programmers. They do not have to
-reason about states in which the library might be in.
+It is reentrant - and thus thread safe. This is not the case with the
+Str module of OCaml, which builds on the GNU regex-library. Using
+reentrant libraries also means more convenience for programmers. They do
+not have to reason about states in which the library might be in.
-The high-level functions for replacement and substitution, all implemented
-in OCaml, are much faster than the ones of the Str-module. In fact, when
-compiled to native code, they even seem to be significantly faster than
-those of PERL.
+The high-level functions for replacement and substitution, all
+implemented in OCaml, are much faster than the ones of the Str-module.
+In fact, when compiled to native code, they even seem to be
+significantly faster than those of PERL.
diff -ru devel/ocaml-pcre/pkg/PFRAG.shared
mystuff/devel/ocaml-pcre/pkg/PFRAG.shared
--- devel/ocaml-pcre/pkg/PFRAG.shared Thu Sep 15 17:50:23 2011
+++ mystuff/devel/ocaml-pcre/pkg/PFRAG.shared Tue Jul 17 18:56:46 2012
@@ -1,2 +1,2 @@
@comment
Envie milhares de Torpedos pelo seu computador
CHEGOU !!! O serviço SMS ROBOT destina-se à todos aqueles (empresas ou pessoas físicas) que precisam enviar grandes volumes de mensagens SMS à um custo acessível e com ferramentas que facilitam o envio de mensagens diretamente da frente do computador. Este tipo de ferramenta é ideal para quem precisa se comunicar com equipes de vendas externas, onde nem sempre se está na frente de um computador, enviar mensagens para clientes a respeito de novos produtos/serviços, enviar mensagens para clientes para lembra-los de alguma ação de marketing que você esteja promovendo, enfim, existem vários usos para o envio de mensagens SMS e a grande vantagem é que este tipo de mensagem é compatível com qualquer aparelho celular existente e não depende de qualquer recurso adicional no aparelho ou na rede celular. Aplicações possíveis do serviço SMS Empresarial Cobrança; Divulgação de promoções; Campanhas eleitorais; Lembretes; Divulgação de produtos/serviços. Através de um painel de controle totalmente funcional, você poderá enviar mensagens SMS individuais ou enviar mensagens para uma lista de contatos previamente digitada. Preços e quantidades de envios: 1 software para 1 computador / capacidade de milhares de envios por dia/ preço R$2.800,00 Só hoje por R$2.000,00 para deposito a vista. Kit SMS Marketing: Software MSM ROBOT 1.3 Modem 3g Manual de instalação Característica da Licença de Uso do sistema SMSRobot: - Licença de Uso Vitalícia, sem cobrança de taxa anual ou mensal - Suporte técnico grátis durante 6 meses *Sedex grátis COMPRE JÁ: Atendimento das 9 as 23 horas fone 43-3037-1240 LOndrina / Paraná
Re: UPDATE: devel/ocaml-pcre - with diff
On 2012/07/17 19:15, Christopher Zimmermann wrote: Hi, sorry for the double posting, I forgot to insert the diff. here again my update for devel/ocaml-pcre. Here's what I have changed: * Convert to new style assignments in Makefine (COMMENT= - COMMENT =) Please do not mix whitespace changes with other diffs, it makes both the whitespace diff and the other diff difficult to review, and makes cvs history hard to read.
