[Analyzed] Re: Problem with xorg
The problem is caused by Unicode code points in keymap files, which were made possible (and have to be used) for many locales after the introduction of Unicode support with vt(4). Am 28.08.2014 um 19:43 schrieb Stefan Esser: Am 28.08.2014 um 17:03 schrieb Filippo Moretti via freebsd-stable: I have problem with xorg with my custom kernel both with and without VT supports. I can still reboot with generic and have xorg work.My system:FreeBSD sting 10.0-STABLE FreeBSD 10.0-STABLE #0 r269789: Mon Aug 11 02:47:02 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 With my kernel-vt I get a sementation fault,while with SC I got a complete crash [...] [ 3434.354] (**) Option Protocol standard [ 3434.354] (WW) Option Device requires an string value [ 3434.354] (**) Option XkbRules base [ 3434.354] (**) Option XkbModel pc105 [ 3434.354] (**) Option XkbLayout us [ 3434.354] (**) Option config_info hal:/org/freedesktop/Hal/devices/usb_device_46d_c517_noserial_if0 [ 3434.354] (II) XINPUT: Adding extended input device USB Receiver (type: KEYBOARD, id 7) [ 3434.354] Segmentation fault at address 0x2a3da760 [ 3434.354] Fatal server error: [ 3434.354] Caught signal 11 (Segmentation fault). Server aborting [ 3434.354] [ 3434.355] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 3434.355] Please also check the log file at /var/log/Xorg.0.log for additional information. Just a me-to, but on -CURRENT: [ 357.752] (**) Keyboard0: always reports core events [ 357.752] (**) Option Protocol standard [ 357.752] (**) Option XkbRules xorg [ 357.752] (**) Option XkbModel pc105 [ 357.752] (**) Option XkbLayout de [ 357.752] (**) Option XkbVariant nodeadkeys [ 357.752] (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD, id 7) [ 357.752] Segmentation fault at address 0x80500ae80 [ 357.752] Fatal server error: [ 357.752] Caught signal 11 (Segmentation fault). Server aborting Further information: I used ktrace to identify the failing operation. It is in x11-drivers/xf86-input-keyboard line 1265 of bsd_KeyMap.c: #define KD_GET_ENTRY(i,n) \ eascii_to_x[((keymap.key[i].spcl (n+1)) 0x100) + keymap.key[i].map[n]] [...] void KbdGetMapping (InputInfoPtr pInfo, KeySymsPtr pKeySyms, CARD8 *pModMap) { KbdDevPtr pKbd = (KbdDevPtr) pInfo-private; KeySym*k; int i; #ifndef __bsdi__ switch (pKbd-consType) { /* * XXX wscons has no GIO_KEYMAP */ #if (defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)) defined(GIO_KEYMAP) case SYSCONS: case PCVT: { keymap_t keymap; if (ioctl(pInfo-fd, GIO_KEYMAP, keymap) != -1) { for (i = 0; i keymap.n_keys i NUM_KEYCODES; i++) if (remap[i]) { k = map + (remap[i] 2); k[0] = KD_GET_ENTRY(i,0); /* non-shifed */ k[1] = KD_GET_ENTRY(i,1); /* shifted */ k[2] = KD_GET_ENTRY(i,4); /* alt */ k[3] = KD_GET_ENTRY(i,5); /* alt - shifted */ if (k[3] == k[2]) k[3] = NoSymbol; if (k[2] == k[1]) k[2] = NoSymbol; if (k[1] == k[0]) k[1] = NoSymbol; if (k[0] == k[2] k[1] == k[3]) k[2] = k[3] = NoSymbol; } } } break; #endif /* SYSCONS || PCVT */ The keymap returned by ioctl(GIO_KEYMAP) used to contain characters in the selected locale, which meant it was limited to 8 bit values, effectively. Now with Unicode support, larger values (=0x100) can be found in keymap files. In my case, the Euro symbol (0x20ac) was the cause of an out-of-bounds access to the keymap array in line 1265 of bsd_KbdMap.c (assignment to k[2] for Alt E). I did not have time to investigate, how this problem can be resolved, though. But I'll create a ports PR with this information, since it must be resolved before 10.1, or users of keyboard layouts that generate characters beyond u+ff will reliably crash the X server ... Regards, STefan PS: PR ports/193192 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Analyzed] Re: Problem with xorg
Ok, so what can we do right now to not have unicode characters in say, the US keymap file? (Just a local change, not committed anywhere - I agree it needs to be fixed in the xorg code.) -a ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to submit a port update?
Hi! The update is mostly some small changes to the code to eliminate clang++ and recent g++ warnings along with Eric's typo, which has been languishing for a while. I know it's a small thing, but seeing those warnings when I compile the port makes me sad. Obviously you guys can reject if you don't feel it's worth it. Well, it's always nice to check process and procedures while it's not time-critical 8-} And you are right, the porters handbook still mentions send-pr. There is one thing which is very nice to have for an incoming PR: poudriere test logs that prove that the updated port builds cleanly. If you never used poudriere, have a look at this short starter guide: https://fossil.etoilebsd.net/poudriere/doc/trunk/doc/using_testport.wiki That changes the port diff, of course. The new one is attached, or I can update bugzilla. Always update bugzilla (says the guy who preferres mail...) Sorry to bug you if it's too trivial a change. No, it's fine. I guess I would only release new versions if runtime bugs or runtime functionality changes. You also updated the autotools environment, maybe that fixes other stuff as well. You re-rolled the distfile without a version change, this is not purrrfect, but well, what else is 8-) -- p...@opsec.eu+49 171 3101372 6 years to go ! ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Analyzed] Re: Problem with xorg
Am 31.08.2014 um 09:45 schrieb Adrian Chadd: Ok, so what can we do right now to not have unicode characters in say, the US keymap file? The normal US keyboard (/usr/share/vt/keymaps/us.kbd) does not contain characters = 0x100. There is no problem even with ISO8859-1 characters used in many European countries, since they all are in the range 0x00 to 0xff. A problem is European keyboards with teh Euro sign (0x20ac) or e.g. Cyrillic or Greek keyboards, where many characters are = 0x100. (Just a local change, not committed anywhere - I agree it needs to be fixed in the xorg code.) I'm wondering whether it might make sense to have the work-around committed to the xf86-input-keyboard port. People will waste time trying to understand, why their X server stops working when they select a keyboard layout with problematic characters for use with vt. This was not possible until a few weeks ago, since there were no such keymaps committed to vt/keymaps. If you had a keymap defined in rc.conf, then the name that used to work with syscons did not work with vt, but was just ignored (and the compiled in default US keyboard layout was used). I plan to commit a change to rc.d/syscons, soon, which will allow vt to be used with syscons keymap names (which are then internally converted to vt keymap names). With that change to rc.d/syscons, people will have their localized keyboard layout under vt, but will not be able to a local X11 server, anymore ... So I'm considering to commit the work-around patch, since a single missing key (under plain X11 - e.g. KDE works with all keys) will be just a minor violation of POLA, compared to no X11 at all. Regards, STefan ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [Analyzed] Re: Problem with xorg
On 08/31/2014 08:53, Stefan Esser wrote: The problem is caused by Unicode code points in keymap files, which were made possible (and have to be used) for many locales after the introduction of Unicode support with vt(4). Am 28.08.2014 um 19:43 schrieb Stefan Esser: Am 28.08.2014 um 17:03 schrieb Filippo Moretti via freebsd-stable: I have problem with xorg with my custom kernel both with and without VT supports. I can still reboot with generic and have xorg work.My system:FreeBSD sting 10.0-STABLE FreeBSD 10.0-STABLE #0 r269789: Mon Aug 11 02:47:02 UTC 2014 r...@grind.freebsd.org:/usr/obj/usr/src/sys/GENERIC i386 With my kernel-vt I get a sementation fault,while with SC I got a complete crash [...] [ 3434.354] (**) Option Protocol standard [ 3434.354] (WW) Option Device requires an string value [ 3434.354] (**) Option XkbRules base [ 3434.354] (**) Option XkbModel pc105 [ 3434.354] (**) Option XkbLayout us [ 3434.354] (**) Option config_info hal:/org/freedesktop/Hal/devices/usb_device_46d_c517_noserial_if0 [ 3434.354] (II) XINPUT: Adding extended input device USB Receiver (type: KEYBOARD, id 7) [ 3434.354] Segmentation fault at address 0x2a3da760 [ 3434.354] Fatal server error: [ 3434.354] Caught signal 11 (Segmentation fault). Server aborting [ 3434.354] [ 3434.355] Please consult the The X.Org Foundation support at http://wiki.x.org for help. [ 3434.355] Please also check the log file at /var/log/Xorg.0.log for additional information. Just a me-to, but on -CURRENT: [ 357.752] (**) Keyboard0: always reports core events [ 357.752] (**) Option Protocol standard [ 357.752] (**) Option XkbRules xorg [ 357.752] (**) Option XkbModel pc105 [ 357.752] (**) Option XkbLayout de [ 357.752] (**) Option XkbVariant nodeadkeys [ 357.752] (II) XINPUT: Adding extended input device Keyboard0 (type: KEYBOARD, id 7) [ 357.752] Segmentation fault at address 0x80500ae80 [ 357.752] Fatal server error: [ 357.752] Caught signal 11 (Segmentation fault). Server aborting Further information: I used ktrace to identify the failing operation. It is in x11-drivers/xf86-input-keyboard line 1265 of bsd_KeyMap.c: #define KD_GET_ENTRY(i,n) \ eascii_to_x[((keymap.key[i].spcl (n+1)) 0x100) + keymap.key[i].map[n]] [...] void KbdGetMapping (InputInfoPtr pInfo, KeySymsPtr pKeySyms, CARD8 *pModMap) { KbdDevPtr pKbd = (KbdDevPtr) pInfo-private; KeySym*k; int i; #ifndef __bsdi__ switch (pKbd-consType) { /* * XXX wscons has no GIO_KEYMAP */ #if (defined (SYSCONS_SUPPORT) || defined (PCVT_SUPPORT)) defined(GIO_KEYMAP) case SYSCONS: case PCVT: { keymap_t keymap; if (ioctl(pInfo-fd, GIO_KEYMAP, keymap) != -1) { for (i = 0; i keymap.n_keys i NUM_KEYCODES; i++) if (remap[i]) { k = map + (remap[i] 2); k[0] = KD_GET_ENTRY(i,0); /* non-shifed */ k[1] = KD_GET_ENTRY(i,1); /* shifted */ k[2] = KD_GET_ENTRY(i,4); /* alt */ k[3] = KD_GET_ENTRY(i,5); /* alt - shifted */ if (k[3] == k[2]) k[3] = NoSymbol; if (k[2] == k[1]) k[2] = NoSymbol; if (k[1] == k[0]) k[1] = NoSymbol; if (k[0] == k[2] k[1] == k[3]) k[2] = k[3] = NoSymbol; } } } break; #endif /* SYSCONS || PCVT */ The keymap returned by ioctl(GIO_KEYMAP) used to contain characters in the selected locale, which meant it was limited to 8 bit values, effectively. Now with Unicode support, larger values (=0x100) can be found in keymap files. In my case, the Euro symbol (0x20ac) was the cause of an out-of-bounds access to the keymap array in line 1265 of bsd_KbdMap.c (assignment to k[2] for Alt E). I did not have time to investigate, how this problem can be resolved, though. But I'll create a ports PR with this information, since it must be resolved before 10.1, or users of keyboard layouts that generate characters beyond u+ff will reliably crash the X server ... Regards, STefan PS: PR ports/193192 I have already done PR/191459, with a patch to be added to x11-drivers/xf86-input-keyboard (thanks Thierry Thomas to restoring it). The last contribution by ray@ is totally irrelevant - in fact the same problem appears with syscons + TEKEN_UTF8 Claude Buisson ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Patch with issues for amanda-server/amanda-client
I've filed a patch to amanda-server (and slave port amanda-client) to add staging support and set me as maintainer: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193196 This is my first staging patch; I followed all the steps in the wiki guide at https://wiki.freebsd.org/ports/StageDir but have a few unresolved issues because the way the port is built: 1) Amanda (upstream code) builds its own install-hook target which it uses to set setuid bits amongst other things, This isn't ideal and prevents packages being built as non-root. I have tried to fix this but haven't had the time yet to figure it out so I have set NEEDS_ROOT in the Makefile for now. 2) Many reported orphans were added to the plist after several iterations of the patch, and I am not sure if I have set everything correctly so that files which will only be present given certain OPTIONS are set correctly in the plist and vice versa. Some of the reported orphans seem to be false positives (see (3)) 3) The way the whole Amanda port is split into a master -server and a slave -client seems to be causing a lot of the complications In particular, the master -server port actually depends on the slave -client port being built. The -server port contains all the code for building the client including a seperate plist and a big chunk of the Makefile. It might solve some of the complication if the seperation between the two was ripped out with one port for both with a CLIENT_ONLY option (as the server requires the client files installed anyway). Please let me know if you have any advice/criticism/suggestions/hints/ opinions/there is anything missing. Thanks, Dylan -- Dylan Leigh // VU# s4081906 // www.dylanleigh.net ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD ports you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ lang/rakudo | 2013.10 | 2014.08 +-+ mail/dcc-dccd | 1.3.141 | 1.3.155 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt Thanks. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: [CFT] SSP Package Repository available
On 20/08/2014 18:34, Bryan Drewery wrote: On 9/21/2013 5:49 AM, Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Support may be added for earlier i386 releases once all ports properly respect LDFLAGS. To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports. The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all may optionally be set instead. Please help test this on your system. We would like to eventually enable this by default, but need to identify any major ports that have run-time issues due to it. [1] https://en.wikipedia.org/wiki/Buffer_overflow_protection We have not had any feedback on this yet and want to get it enabled by default for ports and packages. We now have a repository that you can use rather than the default to help test. We need your help to identify any issues before switching the default. Another data point: I've been using WITH_SSP_PORTS=yes for building from ports since late 2013. No issues noticed on 9.2 and 9.3 amd64 systems. I have also been building a selection of packages locally with poudriere using the same make.conf setting for about two months and have seen no issues there either. I have just updated my pkg configuration to use the new repository and have reinstalled all official packages. Regards, Simon Wright. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
lang/tlc86: missing standard modules?
Hey, since the update to tcl86-8.6.2, I’m getting this error trace: can't find package msgcat 1.4 while executing package require msgcat 1.4 (uplevel body line 2) invoked from within uplevel \#0 { package require msgcat 1.4 if { $::tcl_platform(platform) eq {windows} } { if { [catch { package require registry 1.1 }] } { ... (file /usr/local/lib/tcl8.6/clock.tcl line 21) invoked from within source -encoding utf-8 [file join $TclLibDir clock.tcl] (procedure ::tcl::clock::format line 3) invoked from within clock format [clock seconds] -gmt 1 -format \updated %Y%m%d %H%M%S\ (procedure update_zone line 27) invoked from within update_zone $host $ip“ As far as I can tell, msgcat should be included with Tcl. Botched install, or is the port broken? I’m going to try a downgrade next. Cheers, Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: lang/tlc86: missing standard modules?
Am 31.08.2014 um 17:32 schrieb Stefan Bethke s...@lassitu.de: Hey, since the update to tcl86-8.6.2, I’m getting this error trace: can't find package msgcat 1.4 while executing package require msgcat 1.4 (uplevel body line 2) invoked from within uplevel \#0 { package require msgcat 1.4 if { $::tcl_platform(platform) eq {windows} } { if { [catch { package require registry 1.1 }] } { ... (file /usr/local/lib/tcl8.6/clock.tcl line 21) invoked from within source -encoding utf-8 [file join $TclLibDir clock.tcl] (procedure ::tcl::clock::format line 3) invoked from within clock format [clock seconds] -gmt 1 -format \updated %Y%m%d %H%M%S\ (procedure update_zone line 27) invoked from within update_zone $host $ip“ As far as I can tell, msgcat should be included with Tcl. Botched install, or is the port broken? I’m going to try a downgrade next. Downgrading the port to r366509 / 8.6.1 unbreaks my Tcl script. I was at r366676 before. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [Analyzed] Re: Problem with xorg
I discovered that: * if I don't load kbdmap at boot-time as a module, the probe order works in a way that xorg works; * if I load kbdmap by hand after boot, or I don't load it at all, then even the US keyboard map causes xorg to choke. If I load kbdmap at boot-time then kbdcontrol reports inappropriate ioctl for device. -a ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: lang/tlc86: missing standard modules?
Am 31.08.2014 um 17:40 schrieb Stefan Bethke s...@lassitu.de: Am 31.08.2014 um 17:32 schrieb Stefan Bethke s...@lassitu.de: Hey, since the update to tcl86-8.6.2, I’m getting this error trace: can't find package msgcat 1.4 while executing package require msgcat 1.4 (uplevel body line 2) invoked from within uplevel \#0 { package require msgcat 1.4 if { $::tcl_platform(platform) eq {windows} } { if { [catch { package require registry 1.1 }] } { ... (file /usr/local/lib/tcl8.6/clock.tcl line 21) invoked from within source -encoding utf-8 [file join $TclLibDir clock.tcl] (procedure ::tcl::clock::format line 3) invoked from within clock format [clock seconds] -gmt 1 -format \updated %Y%m%d %H%M%S\ (procedure update_zone line 27) invoked from within update_zone $host $ip“ As far as I can tell, msgcat should be included with Tcl. Botched install, or is the port broken? I’m going to try a downgrade next. Downgrading the port to r366509 / 8.6.1 unbreaks my Tcl script. I was at r366676 before. I’ve filed https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193207, which includes a simple test case. Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: I want to upgrade an old (8.3-RC2) FReeBSD installation, but can't install subversion
On Thu, Aug 28, 2014 at 8:26 AM, Erich Dollansky erichsfreebsdl...@alogt.com wrote: Hi, I did not got through the full thread to see if you found a solution. Yes, I did. In fact, freebsd-update provided the solution; I used it to upgrade to FreeBSD 8.4-release: root@kg-vm2# uname -a FreeBSD kg-vm2 8.4-RELEASE-p14 FreeBSD 8.4-RELEASE-p14 #0: Tue Jul 8 12:41:46 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 and since the machine now is on a supported version, the ports tree works again, and I installed subversion and used that to get the latest FreeBSD 8-stable source on the machine, and used that to update the machine to FreeBSD 8.4-stable. HTH -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: How to submit a port update?
On Sun, Aug 31, 2014 at 12:50 AM, Kurt Jaeger li...@opsec.eu wrote: Hi! The update is mostly some small changes to the code to eliminate clang++ and recent g++ warnings along with Eric's typo, which has been languishing for a while. I know it's a small thing, but seeing those warnings when I compile the port makes me sad. Obviously you guys can reject if you don't feel it's worth it. Well, it's always nice to check process and procedures while it's not time-critical 8-} And you are right, the porters handbook still mentions send-pr. There is one thing which is very nice to have for an incoming PR: poudriere test logs that prove that the updated port builds cleanly. Or redports. Not everyone has a running poudriere setup and anyone can use redports. Now that I have my new server on-line, I may finally get around to building poudriere, myself, but until then, redports is all I have available. -- R. Kevin Oberman, Network Engineer, Retired E-mail: rkober...@gmail.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: I want to upgrade an old (8.3-RC2) FReeBSD installation, but can't install subversion
On 2014-08-31 19:43, Torfinn Ingolfsen wrote: On Thu, Aug 28, 2014 at 8:26 AM, Erich Dollansky erichsfreebsdl...@alogt.com wrote: Hi, I did not got through the full thread to see if you found a solution. Yes, I did. In fact, freebsd-update provided the solution; I used it to upgrade to FreeBSD 8.4-release: root@kg-vm2# uname -a FreeBSD kg-vm2 8.4-RELEASE-p14 FreeBSD 8.4-RELEASE-p14 #0: Tue Jul 8 12:41:46 UTC 2014 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 and since the machine now is on a supported version, the ports tree works again, and I installed subversion and used that to get the latest FreeBSD 8-stable source on the machine, and used that to update the machine to FreeBSD 8.4-stable. Hm, do you mean update with subversion to 8.4-stable or 8.4-current? Unless you have a non default kernel there is no need to rebuild to get 8.4-stable, just run `freebsd-update fetch install' without '-r ...' and you are done. Rebuilding the system from source can break freebsd-update specially if build with custom optimizations (-O...) Anyway good to hear you managed to get your system to a supported release. -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
cannot build pecl-pdflib
10-PRERELEASE fresh portstree # make === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Refetch for 1 more times files: PECL/pdflib-3.0.4.tgz === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found = pdflib-3.0.4.tgz doesn't seem to exist in /usr/ports/distfiles/PECL. = Attempting to fetch http://pecl.php.net/get/pdflib-3.0.4.tgz fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size unknown fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size of remote file is not known pdflib-3.0.4.tgz 3582 B 30 kBps 00m01s = Fetched file size mismatch (expected 27043, actual 3582) = Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 417 kBps 00m00s === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Giving up on fetching files: PECL/pdflib-3.0.4.tgz Make sure the Makefile and distinfo file (/usr/ports/print/pecl-pdflib/distinfo) are up to date. If you are absolutely sure you want to override this check, type make NO_CHECKSUM=yes [other args]. *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/pecl-pdflib Well, tried: # make NO_CHECKSUM=yes === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 tar: Error opening archive: Unrecognized archive format *** Error code 1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot build pecl-pdflib
On 08/31/14 21:16, Per olof Ljungmark wrote: 10-PRERELEASE fresh portstree # make === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Refetch for 1 more times files: PECL/pdflib-3.0.4.tgz === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found = pdflib-3.0.4.tgz doesn't seem to exist in /usr/ports/distfiles/PECL. = Attempting to fetch http://pecl.php.net/get/pdflib-3.0.4.tgz fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size unknown fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size of remote file is not known pdflib-3.0.4.tgz 3582 B 30 kBps 00m01s = Fetched file size mismatch (expected 27043, actual 3582) = Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 417 kBps 00m00s === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Giving up on fetching files: PECL/pdflib-3.0.4.tgz Make sure the Makefile and distinfo file (/usr/ports/print/pecl-pdflib/distinfo) are up to date. If you are absolutely sure you want to override this check, type make NO_CHECKSUM=yes [other args]. *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/pecl-pdflib Well, tried: # make NO_CHECKSUM=yes === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 tar: Error opening archive: Unrecognized archive format *** Error code 1 works if file is fetched from elsewhere, for instance: http://ftp.leg.uct.ac.za/pub/packages/macports/distfiles/php5-pdflib/pdflib-3.0.4.tgz ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot build pecl-pdflib
Hi, root@bolton:/usr/ports/distfiles/PECL # fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 6627 kBps 00m00s root@bolton:/usr/ports/distfiles/PECL # cd /usr/ports/print/pecl-pdflib root@bolton:/usr/ports/print/pecl-pdflib # make checksum === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum OK for PECL/pdflib-3.0.4.tgz. It's working fine here (from both pecl.php.net and distcache.FreeBSD.org) It looks like you have something that's altering your downloaded data causing it to fail the checksum (perhaps a firewall or proxy appliance) Thanks, Dan. On 31/08/2014 20:16, Per olof Ljungmark wrote: 10-PRERELEASE fresh portstree # make === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Refetch for 1 more times files: PECL/pdflib-3.0.4.tgz === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found = pdflib-3.0.4.tgz doesn't seem to exist in /usr/ports/distfiles/PECL. = Attempting to fetch http://pecl.php.net/get/pdflib-3.0.4.tgz fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size unknown fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size of remote file is not known pdflib-3.0.4.tgz 3582 B 30 kBps 00m01s = Fetched file size mismatch (expected 27043, actual 3582) = Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 417 kBps 00m00s === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Giving up on fetching files: PECL/pdflib-3.0.4.tgz Make sure the Makefile and distinfo file (/usr/ports/print/pecl-pdflib/distinfo) are up to date. If you are absolutely sure you want to override this check, type make NO_CHECKSUM=yes [other args]. *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/pecl-pdflib Well, tried: # make NO_CHECKSUM=yes === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 tar: Error opening archive: Unrecognized archive format *** Error code 1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: cannot build pecl-pdflib
On 08/31/14 21:44, Daniel Austin via freebsd-ports wrote: Hi, root@bolton:/usr/ports/distfiles/PECL # fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 6627 kBps 00m00s root@bolton:/usr/ports/distfiles/PECL # cd /usr/ports/print/pecl-pdflib root@bolton:/usr/ports/print/pecl-pdflib # make checksum === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum OK for PECL/pdflib-3.0.4.tgz. It's working fine here (from both pecl.php.net and distcache.FreeBSD.org) It looks like you have something that's altering your downloaded data causing it to fail the checksum (perhaps a firewall or proxy appliance) Not sure, http://pecl.php.net/package/pdflib was down (database error) at the very moment I was building the port and the package from distcache.FreeBSD.org did not work. Now that pecl.php.net is up again it builds fine. Perhaps the distfile at freebsd.org needs to be checked. On 31/08/2014 20:16, Per olof Ljungmark wrote: 10-PRERELEASE fresh portstree # make === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Refetch for 1 more times files: PECL/pdflib-3.0.4.tgz === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found = pdflib-3.0.4.tgz doesn't seem to exist in /usr/ports/distfiles/PECL. = Attempting to fetch http://pecl.php.net/get/pdflib-3.0.4.tgz fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size unknown fetch: http://pecl.php.net/get/pdflib-3.0.4.tgz: size of remote file is not known pdflib-3.0.4.tgz 3582 B 30 kBps 00m01s = Fetched file size mismatch (expected 27043, actual 3582) = Attempting to fetch http://distcache.FreeBSD.org/ports-distfiles/PECL/pdflib-3.0.4.tgz pdflib-3.0.4.tgz 100% of 26 kB 417 kBps 00m00s === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building = SHA256 Checksum mismatch for PECL/pdflib-3.0.4.tgz. === Giving up on fetching files: PECL/pdflib-3.0.4.tgz Make sure the Makefile and distinfo file (/usr/ports/print/pecl-pdflib/distinfo) are up to date. If you are absolutely sure you want to override this check, type make NO_CHECKSUM=yes [other args]. *** Error code 1 Stop. make[1]: stopped in /usr/ports/print/pecl-pdflib Well, tried: # make NO_CHECKSUM=yes === License PHP30 accepted by the user === pecl-pdflib-3.0.4 depends on file: /usr/local/sbin/pkg - found === Fetching all distfiles required by pecl-pdflib-3.0.4 for building === Extracting for pecl-pdflib-3.0.4 tar: Error opening archive: Unrecognized archive format *** Error code 1 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org -- Intersonic AB Registered in Solna, Sweden SE556539368201 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: I want to upgrade an old (8.3-RC2) FReeBSD installation, but can't install subversion
On Sun, Aug 31, 2014 at 8:37 PM, olli hauer oha...@gmx.de wrote: Hm, do you mean update with subversion to 8.4-stable or 8.4-current? Yes, and 8.4-stable. There is no 8.4-current. Unless you have a non default kernel there is no need to rebuild to get 8.4-stable, just run `freebsd-update fetch install' without '-r ...' and you are done. Ok. Old habits came into play; I've always updated my FreeBSD systems via source. It is that freebsd-update which is new to me... Rebuilding the system from source can break freebsd-update specially if build with custom optimizations (-O...) Noted. In my case, using freebsd-update was only to get out of the ports tree suddenly not supported situation I got into. Anyway good to hear you managed to get your system to a supported release. Yes. :) -- Regards, Torfinn Ingolfsen ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: I want to upgrade an old (8.3-RC2) FReeBSD installation, but can't install subversion
On 2014-08-31 22:38, Torfinn Ingolfsen wrote: On Sun, Aug 31, 2014 at 8:37 PM, olli hauer oha...@gmx.de wrote: Hm, do you mean update with subversion to 8.4-stable or 8.4-current? Yes, and 8.4-stable. There is no 8.4-current. Unless you have a non default kernel there is no need to rebuild to get 8.4-stable, just run `freebsd-update fetch install' without '-r ...' and you are done. Ok. Old habits came into play; I've always updated my FreeBSD systems via source. It is that freebsd-update which is new to me... Rebuilding the system from source can break freebsd-update specially if build with custom optimizations (-O...) Noted. In my case, using freebsd-update was only to get out of the ports tree suddenly not supported situation I got into. Anyway good to hear you managed to get your system to a supported release. Yes. :) If you have the time / resources setup a small test jail/vm with an older release to play with freebsd-update try it out. In case there is a security update or other fix for stable freebsd-update will lift your system with one or two commands to the new stable version. freebsd-update updates not only the OS but also /usr/src Once you've done that you will love it. PS: After using freebsd-update the directory /var/db/freebsd-update and your system is running stable you can cleanup everything inside /var/db/freebsd-update to save some space. -- olli ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org