Re: textproc/libxslt: xsltproc segfault
On 2016/02/05 22:07, Christian Weisgerber wrote: > If you build the net/libaccounts-glib port frequently (or in a > loop), sooner or later you'll see this: > > ... > cd html && gtkdoc-mkhtml $mkhtml_options libaccounts-glib > ../libaccounts-glib-docs.xml > Computing chunks... > Writing index.sgml for book(index) > Writing libaccounts-glib.devhelp2 for book(index) > Segmentation fault (core dumped) > > The segfault is xsltproc's. Anybody feel like debugging this? > > #0 0x1fafefe4b84b in xmlXPathFreeNodeSet () >from /usr/local/lib/libxml2.so.15.1 > #1 0x1fafefe285bf in xmlHashFree () from /usr/local/lib/libxml2.so.15.1 > #2 0x1faff3911a90 in xsltFreeKeyTable (keyt=0x1faf5b0d2060) at keys.c:162 > #3 0x1faff3911adf in xsltFreeKeyTableList (keyt=0x1fb008b8b7c0) > at keys.c:181 > #4 0x1faff3913151 in xsltFreeDocumentKeys (idoc=0x1fb01dcef900) > at keys.c:932 > #5 0x1faff391e5ea in xsltFreeDocuments (ctxt=0x1fafbf185200) > at documents.c:258 > #6 0x1faff39235b2 in xsltFreeTransformContext (ctxt=0x1fafbf185200) > at transform.c:652 > #7 0x1fad33402ade in xsltProcess (doc=0x1faf6e5fda00, > cur=0x1fafbb6b0400, > filename=0x7f7ce04f "../libaccounts-glib-docs.xml") at xsltproc.c:418 > #8 0x1fad334045a0 in main (argc=19, argv=0x7f7cdc68) at > xsltproc.c:892 Not much more information, but I see the same backtrace with a checkout of git HEAD. I've got a backtrace with line numbers for *some* of the frames from 1.1.28 which looks like the same crash: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x17514110852b in xmlXPathFreeNodeSet (obj=0x175093ce3180) at xpath.c:4190 4190if ((obj->nodeTab[i] != NULL) && (gdb) p *obj $1 = {nodeNr = 1, nodeMax = 10, nodeTab = 0x175171c4e580} (gdb) p *obj->nodeTab $2 = (xmlNodePtr) 0x1750ae806180 (gdb) p **obj->nodeTab Cannot access memory at address 0x1750ae806180 (gdb) bt #0 0x17514110852b in xmlXPathFreeNodeSet (obj=0x175093ce3180) at xpath.c:4190 #1 0x1751410cd7a1 in xmlHashFree (table=0x1750cd498e00, f=0x1751411084c5 ) at hash.c:339 #2 0x1750938adf99 in xsltFreeDocumentKeys () from /usr/local/lib/libxslt.so.3.8 #3 0x1750938b7ada in xsltFreeDocuments () from /usr/local/lib/libxslt.so.3.8 #4 0x1750938c148a in xsltFreeTransformContext () from /usr/local/lib/libxslt.so.3.8 #5 0x174e80602a32 in ?? () #6 0x174e80603430 in ?? () #7 0x174e80602021 in ?? () #8 0x in ?? () (gdb) list 4185if (obj->nodeTab != NULL) { 4186int i; 4187 4188/* @@ with_ns to check whether namespace nodes should be looked at @@ */ 4189for (i = 0;i < obj->nodeNr;i++) 4190if ((obj->nodeTab[i] != NULL) && 4191(obj->nodeTab[i]->type == XML_NAMESPACE_DECL)) 4192xmlXPathNodeSetFreeNs((xmlNsPtr) obj->nodeTab[i]); 4193xmlFree(obj->nodeTab); 4194} and similar from git HEAD Program terminated with signal SIGSEGV, Segmentation fault. #0 0x041802a2952b in xmlXPathFreeNodeSet (obj=0x4183e134b20) at xpath.c:4190 4190if ((obj->nodeTab[i] != NULL) && (gdb) bt #0 0x041802a2952b in xmlXPathFreeNodeSet (obj=0x4183e134b20) at xpath.c:4190 #1 0x0418029ee7a1 in xmlHashFree (table=0x41870c785e0, f=0x41802a294c5 ) at hash.c:339 #2 0x0417ff7fca50 in xsltFreeKeyTable (keyt=0x41816c12c00) at keys.c:162 #3 0x0417ff7fca9f in xsltFreeKeyTableList (keyt=0x4182878a4a0) at keys.c:181 #4 0x0417ff7fe123 in xsltFreeDocumentKeys (idoc=0x417dd5e3540) at keys.c:933 #5 0x0417ff80954a in xsltFreeDocuments (ctxt=0x41860f08a00) at documents.c:258 #6 0x0417ff80e6d2 in xsltFreeTransformContext (ctxt=0x41860f08a00) at transform.c:750 #7 0x041591102b82 in xsltProcess (doc=0x4188958d200, cur=0x417fe3c9600, filename=0x7f7e1963 "../libaccounts-glib-docs.xml") at xsltproc.c:421 #8 0x0415911047ae in main (argc=19, argv=0x7f7e1608) at xsltproc.c:920
Re: NEW: audio/moc
On Fri, Feb 05, 2016 at 12:55:49PM +0100, Dmitrij D. Czarkoff wrote: > Vadim Zhukov said: > > 2016-02-05 2:03 GMT+03:00 Dmitrij D. Czarkoff : > > > Michael Seyfert said: > > >> I'm trying to get this into the ports tree yet again. > > >> > > >> MOC is a console audio player with simple ncurses interface. It > > >> supports OGG, WAV, MP3 and other formats. Just run mocp, go to some > > >> directory using the menu and press enter to start playing the file. > > >> The program will automatically play the rest of the files in the > > >> directory. > > > > > > I added a patch to use file(1) instead of libmagic and marked this port > > > as SHARED_ONLY. > > > > > > Comments? OKs? > > > > Why not just use fork+exec, without need to care about escaping anymore? > > This version uses fork+execl. FWIW I am getting convinced that just > disabling this functionality is the best approach: it is basically used > for detecting music files with wrong filename suffixes. Very few > legitimate use cases for this are better handled through renaming files. > > P.S.: As is pretty obvious from previous messages in this thread, I > have little experience with exec and friends in C. I'd appreciate > feedback. > > -- > Dmitrij D. Czarkoff The option UseMimeMagic is false by default so that code is not used unless the user specifies it. libmagic / file is not needed. -- Michael Seyfert
Re: NEW: audio/moc
On Fri, Feb 05, 2016 at 12:55:49PM +0100, Dmitrij D. Czarkoff wrote: > Vadim Zhukov said: > > 2016-02-05 2:03 GMT+03:00 Dmitrij D. Czarkoff : > > > Michael Seyfert said: > > >> I'm trying to get this into the ports tree yet again. > > >> > > >> MOC is a console audio player with simple ncurses interface. It > > >> supports OGG, WAV, MP3 and other formats. Just run mocp, go to some > > >> directory using the menu and press enter to start playing the file. > > >> The program will automatically play the rest of the files in the > > >> directory. > > > > > > I added a patch to use file(1) instead of libmagic and marked this port > > > as SHARED_ONLY. > > > > > > Comments? OKs? > > > > Why not just use fork+exec, without need to care about escaping anymore? > > This version uses fork+execl. FWIW I am getting convinced that just > disabling this functionality is the best approach: it is basically used > for detecting music files with wrong filename suffixes. Very few > legitimate use cases for this are better handled through renaming files. > > P.S.: As is pretty obvious from previous messages in this thread, I > have little experience with exec and friends in C. I'd appreciate > feedback. > > -- > Dmitrij D. Czarkoff You can compile with configure option --without-magic. If this is a common source of exploits then it should be removed. -- Michael Seyfert
textproc/libxslt: xsltproc segfault
If you build the net/libaccounts-glib port frequently (or in a loop), sooner or later you'll see this: ... cd html && gtkdoc-mkhtml $mkhtml_options libaccounts-glib ../libaccounts-glib-docs.xml Computing chunks... Writing index.sgml for book(index) Writing libaccounts-glib.devhelp2 for book(index) Segmentation fault (core dumped) The segfault is xsltproc's. Anybody feel like debugging this? #0 0x1fafefe4b84b in xmlXPathFreeNodeSet () from /usr/local/lib/libxml2.so.15.1 #1 0x1fafefe285bf in xmlHashFree () from /usr/local/lib/libxml2.so.15.1 #2 0x1faff3911a90 in xsltFreeKeyTable (keyt=0x1faf5b0d2060) at keys.c:162 #3 0x1faff3911adf in xsltFreeKeyTableList (keyt=0x1fb008b8b7c0) at keys.c:181 #4 0x1faff3913151 in xsltFreeDocumentKeys (idoc=0x1fb01dcef900) at keys.c:932 #5 0x1faff391e5ea in xsltFreeDocuments (ctxt=0x1fafbf185200) at documents.c:258 #6 0x1faff39235b2 in xsltFreeTransformContext (ctxt=0x1fafbf185200) at transform.c:652 #7 0x1fad33402ade in xsltProcess (doc=0x1faf6e5fda00, cur=0x1fafbb6b0400, filename=0x7f7ce04f "../libaccounts-glib-docs.xml") at xsltproc.c:418 #8 0x1fad334045a0 in main (argc=19, argv=0x7f7cdc68) at xsltproc.c:892 -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: make cheksum fails for net/pear-Net-SMTP tag OPENBSD_5_8
Hi, On Fri, Feb 05, 2016 at 02:59:34PM -0500, Josh Grosse wrote: > On Fri, Feb 05, 2016 at 02:46:38PM -0500, Josh Grosse wrote: > > On Fri, Feb 05, 2016 at 08:20:53PM +0100, Peter Hessler wrote: > > > What changed? Can you find a copy of the old tarball, and compare the > > > two? > > > > I couldn't find an old copy when I went looking; the only distfile at > > ftp.openbsd.org is 1.5.2 from 2011. > > > > > Did someone trojan the distfile? > > > > I don't know. The file from upstream is 83 bytes larger than the distinfo > > in > > our tree. > > OK, I found a copy of the "old" smaller distfile at the Fedora Project, and > compared the unpacked tarball contents with the contents of the "new" tarball. > > The contents appears identical, except for the tarball size. Confirmed. I still had an old distfile on my build machine: -rw-rw-r-- 1 kili kili 13077 Feb 11 2015 Net_SMTP-1.6.2.tgz Copied over to https://openbsd.dead-parrot.de/distfiles/Net_SMTP-1.6.2.tgz if anyone else want to check. Ciao, Kili
Re: UPDATE: net/synergy 1.7.4 => 1.7.5
Ping... Comments, tests welcome. On 01/31/16 19:50, Michael Lesniewski wrote: Hi All, Attached is an update to the latest synergy. Tested on amd64, also take maintainer. Regards, Michael Index: Makefile === RCS file: /cvs/ports/net/synergy/Makefile,v retrieving revision 1.29 diff -u -p -r1.29 Makefile --- Makefile21 Oct 2015 19:51:28 - 1.29 +++ Makefile31 Jan 2016 11:15:05 - @@ -2,11 +2,11 @@ COMMENT= mouse and keyboard sharing utility -VERSION= 1.7.4 +VERSION= 1.7.5 DISTNAME= synergy-${VERSION} CATEGORIES=net x11 -GH_ACCOUNT=synergy +GH_ACCOUNT=symless GH_PROJECT=synergy GH_TAGNAME=v${VERSION}-stable Index: distinfo === RCS file: /cvs/ports/net/synergy/distinfo,v retrieving revision 1.12 diff -u -p -r1.12 distinfo --- distinfo21 Oct 2015 19:51:28 - 1.12 +++ distinfo31 Jan 2016 11:15:05 - @@ -1,2 +1,2 @@ -SHA256 (synergy-1.7.4.tar.gz) = IV3DkYufPd+1fMlj+N9nUeXoNP2QwKiydnCRWJsBK98= -SIZE (synergy-1.7.4.tar.gz) = 13665193 +SHA256 (synergy-1.7.5.tar.gz) = b50c79f5c8aca2048cb0e11ba37f75722d1acdda23b0352e25ad66aff999f192 +SIZE (synergy-1.7.5.tar.gz) = 13668296 cvs server: Diffing patches Index: patches/patch-CMakeLists_txt === RCS file: /cvs/ports/net/synergy/patches/patch-CMakeLists_txt,v retrieving revision 1.8 diff -u -p -r1.8 patch-CMakeLists_txt --- patches/patch-CMakeLists_txt21 Oct 2015 19:51:28 - 1.8 +++ patches/patch-CMakeLists_txt31 Jan 2016 11:15:05 - @@ -5,8 +5,8 @@ $OpenBSD: patch-CMakeLists_txt,v 1.8 201 # warnings as errors: # we have a problem with people checking in code with warnings. -- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror") -+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}") +- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror -Wno-unused-local-typedef") ++ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Werror") if (NOT APPLE) set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC")
Re: graphics/djvulibre: fix a bug in documents with duplicate page titles
On Thu, Feb 04, 2016 at 02:47:55AM +0100, Juan Francisco Cantero Hurtado wrote: > On Wed, Feb 03, 2016 at 03:08:53AM +0100, Juan Francisco Cantero Hurtado > wrote: > > The patch adds support for documents with duplicate page titles. I > > need this change to update pdf2djvu to the latest version. > > > > I've not tested any djvu viewer, just the conversion. So any test is > > welcome. > > Tested with zathura-djvu and everything works fine. > no regress with my djvu files, ok shadchin@ > > > > OK? > > > > > > Index: Makefile > > === > > RCS file: /cvs/ports/graphics/djvulibre/Makefile,v > > retrieving revision 1.34 > > diff -u -p -r1.34 Makefile > > --- Makefile12 May 2015 16:10:27 - 1.34 > > +++ Makefile3 Feb 2016 01:53:18 - > > @@ -3,6 +3,7 @@ > > COMMENT= view, decode and encode DjVu files > > > > DISTNAME= djvulibre-3.5.27 > > +REVISION= 0 > > SHARED_LIBS= djvulibre 26.0# 27.0 > > CATEGORIES=graphics print > > > > Index: patches/patch-libdjvu_DjVmDir_cpp > > === > > RCS file: patches/patch-libdjvu_DjVmDir_cpp > > diff -N patches/patch-libdjvu_DjVmDir_cpp > > --- /dev/null 1 Jan 1970 00:00:00 - > > +++ patches/patch-libdjvu_DjVmDir_cpp 3 Feb 2016 01:53:18 - > > @@ -0,0 +1,94 @@ > > +$OpenBSD$ > > + > > +"accept documents with duplicate page titles" > > + > > +http://sourceforge.net/p/djvu/djvulibre-git/ci/77a4dca8dd3acd0acc1680fa14a352c11084e25d/ > > +https://bitbucket.org/jwilk/pdf2djvu/issues/113/duplicate-page-title-1 > > + > > +--- libdjvu/DjVmDir.cpp.orig Tue Jul 8 23:15:07 2014 > > libdjvu/DjVmDir.cppWed Feb 3 01:51:28 2016 > > +@@ -223,7 +223,6 @@ DjVmDir::decode(const GP &gstr) > > +page2file.resize(-1); > > +name2file.empty(); > > +id2file.empty(); > > +- title2file.empty(); > > + > > +int ver=str.read8(); > > +bool bundled=(ver & 0x80)!=0; > > +@@ -375,18 +374,6 @@ DjVmDir::decode(const GP &gstr) > > + G_THROW( ERR_MSG("DjVmDir.dupl_id") "\t" + file->id); > > + id2file[file->id]=file; > > + } > > +- > > +- // Generate title2file map > > +- for(pos=files_list;pos;++pos) > > +- { > > +- GP file=files_list[pos]; > > +- if (file->title.length()) > > +- { > > +-if (title2file.contains(file->title)) > > +- G_THROW( ERR_MSG("DjVmDir.dupl_title") "\t" + file->title); > > +-title2file[file->title]=file; > > +- } > > +- } > > +} > > + } > > + > > +@@ -556,11 +543,19 @@ DjVmDir::id_to_file(const GUTF8String &id) const > > + } > > + > > + GP > > +-DjVmDir::title_to_file(const GUTF8String &title) const > > ++DjVmDir::title_to_file(const GUTF8String &title, GPosition spos) const > > + { > > +- GCriticalSectionLock lock((GCriticalSection *) &class_lock); > > +- GPosition pos; > > +- return (title2file.contains(title, > > pos))?title2file[pos]:(GP(0)); > > ++ if (! title) > > ++return 0; > > ++ GCriticalSectionLock lock((GCriticalSection *) &class_lock); > > ++ if (! spos) > > ++for (GPosition pos = spos; pos; ++pos) > > ++ if (files_list[pos]->is_page() && files_list[pos]->title == title) > > ++return files_list[pos]; > > ++ for (GPosition pos = files_list; pos; ++pos) > > ++if (files_list[pos]->is_page() && files_list[pos]->title == title) > > ++ return files_list[pos]; > > ++ return 0; > > + } > > + > > + GP > > +@@ -661,14 +656,7 @@ DjVmDir::insert_file(const GP & file, int pos_nu > > + G_THROW( ERR_MSG("DjVmDir.dupl_name2") "\t" + file->name); > > +name2file[file->name]=file; > > +id2file[file->id]=file; > > +- if (file->title.length()) > > +- { > > +- if (title2file.contains(file->title)) > > +- // duplicate titles may become ok some day > > +- G_THROW( ERR_MSG("DjVmDir.dupl_title2") "\t" + file->title); > > +- title2file[file->title]=file; > > +- } > > +- > > ++ > > + // Make sure that there is no more than one file with shared > > annotations > > +if (file->is_shared_anno()) > > +{ > > +@@ -727,7 +715,6 @@ DjVmDir::delete_file(const GUTF8String &id) > > + { > > + name2file.del(f->name); > > + id2file.del(f->id); > > +- title2file.del(f->title); > > + if (f->is_page()) > > + { > > + for(int page=0;page > +@@ -788,9 +775,7 @@ DjVmDir::set_file_title(const GUTF8String &id, const G > > +if (!id2file.contains(id, pos)) > > + G_THROW( ERR_MSG("DjVmDir.no_info") "\t" + GUTF8String(id)); > > +GP file=id2file[pos]; > > +- title2file.del(file->title); > > +file->title=title; > > +- title2file[title]=file; > > + } > > + > > + GPList > > Index: patches/patch-libdjvu_DjVmDir_h > > ===
Re: make cheksum fails for net/pear-Net-SMTP tag OPENBSD_5_8
On Fri, Feb 05, 2016 at 02:46:38PM -0500, Josh Grosse wrote: > On Fri, Feb 05, 2016 at 08:20:53PM +0100, Peter Hessler wrote: > > What changed? Can you find a copy of the old tarball, and compare the two? > > I couldn't find an old copy when I went looking; the only distfile at > ftp.openbsd.org is 1.5.2 from 2011. > > > Did someone trojan the distfile? > > I don't know. The file from upstream is 83 bytes larger than the distinfo in > our tree. OK, I found a copy of the "old" smaller distfile at the Fedora Project, and compared the unpacked tarball contents with the contents of the "new" tarball. The contents appears identical, except for the tarball size.
Re: make cheksum fails for net/pear-Net-SMTP tag OPENBSD_5_8
On Fri, Feb 05, 2016 at 08:20:53PM +0100, Peter Hessler wrote: > What changed? Can you find a copy of the old tarball, and compare the two? I couldn't find an old copy when I went looking; the only distfile at ftp.openbsd.org is 1.5.2 from 2011. > Did someone trojan the distfile? I don't know. The file from upstream is 83 bytes larger than the distinfo in our tree. > > > On 2016 Feb 05 (Fri) at 11:30:56 -0500 (-0500), Josh Grosse wrote: > :Noticed while doing some 5.8-stable dpb(). > : > :Upstream may have revised the tarball without changing the file's > :name. Or, there's an integrity issue. > : > :I'm not sure if the distinfo should be revised before discussing > :with upstream. There's no maintainer, so I'm not sure if anyone > :has already been conversation with upstream regarding this. > : > : > :Index: distinfo > :=== > :RCS file: /systems/cvs/ports/net/pear-Net-SMTP/distinfo,v > :retrieving revision 1.7 > :diff -u -p -r1.7 distinfo > :--- distinfo 10 Feb 2015 11:34:50 - 1.7 > :+++ distinfo 12 Jan 2016 03:17:04 - > :@@ -1,2 +1,2 @@ > :-SHA256 (Net_SMTP-1.6.2.tgz) = mNOrKOmd4qixw5ZQw6wQesHK8JY5sdIBit8FjdmGR4U= > :-SIZE (Net_SMTP-1.6.2.tgz) = 13077 > :+SHA256 (Net_SMTP-1.6.2.tgz) = QgTMMTPpLsQfpt94gFqlZQ62xuexUFGSh815HWc3/mQ= > :+SIZE (Net_SMTP-1.6.2.tgz) = 13160 > : > > -- > The superfluous is very necessary. > -- Voltaire >
Re: make cheksum fails for net/pear-Net-SMTP tag OPENBSD_5_8
What changed? Can you find a copy of the old tarball, and compare the two? Did someone trojan the distfile? On 2016 Feb 05 (Fri) at 11:30:56 -0500 (-0500), Josh Grosse wrote: :Noticed while doing some 5.8-stable dpb(). : :Upstream may have revised the tarball without changing the file's :name. Or, there's an integrity issue. : :I'm not sure if the distinfo should be revised before discussing :with upstream. There's no maintainer, so I'm not sure if anyone :has already been conversation with upstream regarding this. : : :Index: distinfo :=== :RCS file: /systems/cvs/ports/net/pear-Net-SMTP/distinfo,v :retrieving revision 1.7 :diff -u -p -r1.7 distinfo :--- distinfo 10 Feb 2015 11:34:50 - 1.7 :+++ distinfo 12 Jan 2016 03:17:04 - :@@ -1,2 +1,2 @@ :-SHA256 (Net_SMTP-1.6.2.tgz) = mNOrKOmd4qixw5ZQw6wQesHK8JY5sdIBit8FjdmGR4U= :-SIZE (Net_SMTP-1.6.2.tgz) = 13077 :+SHA256 (Net_SMTP-1.6.2.tgz) = QgTMMTPpLsQfpt94gFqlZQ62xuexUFGSh815HWc3/mQ= :+SIZE (Net_SMTP-1.6.2.tgz) = 13160 : -- The superfluous is very necessary. -- Voltaire
Re: fix inkscape segmentation fault
On Thu, Feb 04, 2016 at 09:34:46PM +0100, Rafael Sadowski wrote: Hello Rafael, > last days I debug inkscape. Could anybody reproduce my segfault on > amd64-current: Yes, for me, inkscape was segfaulting all over the place, generally within 20 or 30 seconds of starting up (as Stuart mentioned, I managed to make it run for a bit longer with MALLOC_OPTIONS, but even then it died fairly often). With your patch, it no longer segfaults almost immediately, which is a very promising sign! I think this patch definitely improves the situation on OpenBSD. Thanks (particularly as I had got no further than running gdb on it once)! Laurie -- Personal http://tratt.net/laurie/ Software Development Teamhttp://soft-dev.org/ https://github.com/ltratt http://twitter.com/laurencetratt
make cheksum fails for net/pear-Net-SMTP tag OPENBSD_5_8
Noticed while doing some 5.8-stable dpb(). Upstream may have revised the tarball without changing the file's name. Or, there's an integrity issue. I'm not sure if the distinfo should be revised before discussing with upstream. There's no maintainer, so I'm not sure if anyone has already been conversation with upstream regarding this. Index: distinfo === RCS file: /systems/cvs/ports/net/pear-Net-SMTP/distinfo,v retrieving revision 1.7 diff -u -p -r1.7 distinfo --- distinfo10 Feb 2015 11:34:50 - 1.7 +++ distinfo12 Jan 2016 03:17:04 - @@ -1,2 +1,2 @@ -SHA256 (Net_SMTP-1.6.2.tgz) = mNOrKOmd4qixw5ZQw6wQesHK8JY5sdIBit8FjdmGR4U= -SIZE (Net_SMTP-1.6.2.tgz) = 13077 +SHA256 (Net_SMTP-1.6.2.tgz) = QgTMMTPpLsQfpt94gFqlZQ62xuexUFGSh815HWc3/mQ= +SIZE (Net_SMTP-1.6.2.tgz) = 13160
Re: [update] games/stone-soup
ping
Re: lang/gcc on macppc
On Thu, Feb 04, 2016 at 11:26:48PM +0100, Tobias Ulmer wrote: > > Is this a known issue? Let me know if a full build log would be useful. > > News to me, I'll see whether I can reproduce it. Keep the failed build > around for a while if possible. Can't reproduce :/. Are you interested in debugging this? Ports gdb should work. You can iirc set a breakpoint on 'constraint_error' (exception handler), the function that caused the SIGBUS should be in the stack trace. > > > > > > > true DO=all multi-do # gmake > > gmake[4]: Leaving directory '/home/build/build-powerpc/libbacktrace' > > gmake[3]: Leaving directory '/home/build/build-powerpc/libbacktrace' > > gmake[3]: Entering directory '/home/build/build-powerpc/libcpp' > > test -f config.h || (rm -f stamp-h1 && gmake stamp-h1) > > gmake[3]: Leaving directory '/home/build/build-powerpc/libcpp' > > gmake[3]: Entering directory '/home/build/build-powerpc/libdecnumber' > > gmake[3]: Nothing to be done for 'all'. > > gmake[3]: Leaving directory '/home/build/build-powerpc/libdecnumber' > > gmake[3]: Entering directory '/home/build/build-powerpc/gcc' > > /home/build/build-powerpc/./prev-gcc/gnatbind -nostdinc -I- -I. -Iada > > -I/home/build/gcc-4.9.3/gcc/ada > > -I/home/build/gcc-4.9.3/gcc/ada/gcc-interface -o b_gnat1.adb -n > > ada/gnat1drv.ali > > > > raised CONSTRAINT_ERROR : SIGBUS > > /home/build/gcc-4.9.3/gcc/ada/gcc-interface/Make-lang.in:932: recipe for > > target 'ada/b_gnat1.adb' failed > > gmake[3]: *** [ada/b_gnat1.adb] Error 1 > > gmake[3]: Leaving directory '/home/build/build-powerpc/gcc' > > Makefile:4256: recipe for target 'all-stage2-gcc' failed > > gmake[2]: *** [all-stage2-gcc] Error 2 > > gmake[2]: Leaving directory '/home/build/build-powerpc' > > Makefile:18532: recipe for target 'stage2-bubble' failed > > gmake[1]: *** [stage2-bubble] Error 2 > > gmake[1]: Leaving directory '/home/build/build-powerpc' > > Makefile:18551: recipe for target 'bootstrap2' failed > > gmake: *** [bootstrap2] Error 2 > > >
Re: NEW: audio/moc
Vadim Zhukov said: > 2016-02-05 2:03 GMT+03:00 Dmitrij D. Czarkoff : > > Michael Seyfert said: > >> I'm trying to get this into the ports tree yet again. > >> > >> MOC is a console audio player with simple ncurses interface. It > >> supports OGG, WAV, MP3 and other formats. Just run mocp, go to some > >> directory using the menu and press enter to start playing the file. > >> The program will automatically play the rest of the files in the > >> directory. > > > > I added a patch to use file(1) instead of libmagic and marked this port > > as SHARED_ONLY. > > > > Comments? OKs? > > Why not just use fork+exec, without need to care about escaping anymore? This version uses fork+execl. FWIW I am getting convinced that just disabling this functionality is the best approach: it is basically used for detecting music files with wrong filename suffixes. Very few legitimate use cases for this are better handled through renaming files. P.S.: As is pretty obvious from previous messages in this thread, I have little experience with exec and friends in C. I'd appreciate feedback. -- Dmitrij D. Czarkoff moc-2.5.0.tgz Description: application/tar-gz
Re: NEW: audio/moc
On Fri, Feb 05, 2016 at 09:22:43AM +0100, Dmitrij D. Czarkoff wrote: > Marc Espie said: > > On Fri, Feb 05, 2016 at 02:14:54AM +0300, Vadim Zhukov wrote: > > > 2016-02-05 2:03 GMT+03:00 Dmitrij D. Czarkoff : > > > > Michael Seyfert said: > > > >> I'm trying to get this into the ports tree yet again. > > > >> > > > >> MOC is a console audio player with simple ncurses interface. It > > > >> supports OGG, WAV, MP3 and other formats. Just run mocp, go to some > > > >> directory using the menu and press enter to start playing the file. > > > >> The program will automatically play the rest of the files in the > > > >> directory. > > > > > > > > I added a patch to use file(1) instead of libmagic and marked this port > > > > as SHARED_ONLY. > > > > > > > > Comments? OKs? > > > > > > Why not just use fork+exec, without need to care about escaping anymore? > > > > > > -- > > > WBR, > > > Vadim Zhukov > > > > Yep, definitely NOT OKAY. > > popen is a *broken* interface. > > > > Do not ever use it; > > Good to know. Maybe manual for popen should explain the reasons? It does. In BUGS. The popen() argument always calls sh(1). so you have to jump thru hoops to try to sanitize stuff coming from outside, ultimately failing. Admittedly, system(3) does a better job of explaining it.
Re: fix inkscape segmentation fault
On Thu Feb 04, 2016 at 09:41:17PM +, Stuart Henderson wrote: > On 2016/02/04 21:34, Rafael Sadowski wrote: > > Hi everybody, > > > > last days I debug inkscape. Could anybody reproduce my segfault on > > amd64-current: > > > > 1.) starts inkscape > > 2.) Ctrl+F6 (select brush strokers) > > 3.) draw something > > 4.) change "Thinning" or an other value in the SpinButton/SpinBox in the > > menu-bar. > > or > > > > 4.1) Shift+Ctrl+F (This will trigger the GtkSpinButton) > > > > If it crash, we need to convert the GtkSpinButton::get_text() in UTF-8 to > > pass g_utf8_validate. > > Great, that is a lot better, it fixes the problem Laurie Tratt had too > (worked around with malloc flags 'j' to disable junking). > > Unless there are objections I'll commit it soon, could you send it > upstream as well please? Of course, will send upstream. Happy Weekend, Rafael
Re: NEW: audio/moc
Marc Espie said: > On Fri, Feb 05, 2016 at 02:14:54AM +0300, Vadim Zhukov wrote: > > 2016-02-05 2:03 GMT+03:00 Dmitrij D. Czarkoff : > > > Michael Seyfert said: > > >> I'm trying to get this into the ports tree yet again. > > >> > > >> MOC is a console audio player with simple ncurses interface. It > > >> supports OGG, WAV, MP3 and other formats. Just run mocp, go to some > > >> directory using the menu and press enter to start playing the file. > > >> The program will automatically play the rest of the files in the > > >> directory. > > > > > > I added a patch to use file(1) instead of libmagic and marked this port > > > as SHARED_ONLY. > > > > > > Comments? OKs? > > > > Why not just use fork+exec, without need to care about escaping anymore? > > > > -- > > WBR, > > Vadim Zhukov > > Yep, definitely NOT OKAY. > popen is a *broken* interface. > > Do not ever use it; Good to know. Maybe manual for popen should explain the reasons? -- Dmitrij D. Czarkoff