From buildfarm at lists.opencsw.org Sat Mar 7 18:41:56 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Sat, 7 Mar 2015 18:41:56 +0100 Subject: libffi on solaris 9 In-Reply-To: <54FAF1EB.1080708@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FAF1EB.1080708@opencsw.org> Message-ID: <93778141-314A-4EFB-8631-1045E67642C9@opencsw.org> Hi, > Am 07.03.2015 um 13:41 schrieb Laurent Blume : > > Le 2015/03/07 11:39 +0100, Matchek a ?crit: >> Or $PATH? We don't add /opt/csw/bin to PATH system-wide. > > Yes, it's done by Baltic Online stuff in /etc/environment, which is not > installed on unstable9x. > > Definitely a request for buildfarm at . Done. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Sat Mar 7 22:08:59 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Sat, 7 Mar 2015 22:08:59 +0100 Subject: libffi on solaris 9 In-Reply-To: <54FB5BF3.8040906@opencsw.org> References: <54FABF4A.50701@opencsw.org> <54FB37ED.60204@opencsw.org> <475E0804-C60F-4686-9F16-CCD2132E6169@opencsw.org> <54FB5BF3.8040906@opencsw.org> Message-ID: Hi Riccardo, > Am 07.03.2015 um 21:13 schrieb Riccardo Mottola : > > solaris 9 packages built and uploaded! > > Dago, can you install them on all respective 4 machines? Sure, done. Please mail to buildfarm@ next time. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Sun Mar 15 23:50:36 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Sun, 15 Mar 2015 23:50:36 +0100 Subject: new libffi packages Message-ID: <55060CBC.4040909@opencsw.org> Hi, please update unstable9x unstable9s unstable10x and unstable10s with the new libffi6 and libffi-dev packages I just uploaded. They should be 64bit too! Riccardo From buildfarm at lists.opencsw.org Mon Mar 16 09:57:14 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Mon, 16 Mar 2015 09:57:14 +0100 Subject: new libffi packages In-Reply-To: <55060CBC.4040909@opencsw.org> References: <55060CBC.4040909@opencsw.org> Message-ID: <5748FAF3-C7F4-4E30-8D75-1F351853D7E9@opencsw.org> Hi Riccardo, > Am 15.03.2015 um 23:50 schrieb Riccardo Mottola via buildfarm : > > please update unstable9x unstable9s unstable10x and unstable10s with the new libffi6 and libffi-dev packages I just uploaded. > They should be 64bit too! Done. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Mon Mar 16 10:10:25 2015 From: buildfarm at lists.opencsw.org (Carsten Grzemba via buildfarm) Date: Mon, 16 Mar 2015 10:10:25 +0100 Subject: CSWnetsnmp-dev auf buildfarm In-Reply-To: References: Message-ID: CSWnetsnmp-dev is gone from buildfarm ? Can you please reinstall this Carsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Mon Mar 16 10:13:50 2015 From: buildfarm at lists.opencsw.org (Jan Holzhueter via buildfarm) Date: Mon, 16 Mar 2015 10:13:50 +0100 Subject: CSWnetsnmp-dev auf buildfarm In-Reply-To: References: Message-ID: <55069ECE.9020403@opencsw.org> Hi, hjb is working on an update for netsnmp right now. We still have kind of the problem that it pulls it's own old libs. So I would love to let it uninstalled for a few Days. Unless you need it right now. Greetings Jan Am 16.03.15 um 10:10 schrieb Carsten Grzemba via buildfarm: > CSWnetsnmp-dev is gone from buildfarm ? > Can you please reinstall this > > Carsten From buildfarm at lists.opencsw.org Mon Mar 16 17:15:09 2015 From: buildfarm at lists.opencsw.org (Jan Holzhueter via buildfarm) Date: Mon, 16 Mar 2015 17:15:09 +0100 Subject: CSWnetsnmp-dev auf buildfarm In-Reply-To: References: <55069ECE.9020403@opencsw.org> Message-ID: <5507018D.2080404@opencsw.org> Hi, ok package up to date. Installed it Again on unstable10 hosts. Greetings Jan Am 16.03.15 um 10:37 schrieb Carsten Grzemba: > it's old libs or headers? order of -I options problem ;) It > is often taken. > No problem, fix this first. > > Am 16.03.15 schrieb *Jan Holzhueter via buildfarm * > : >> Hi, >> hjb is working on an update for netsnmp right now. >> We still have kind of the problem that it pulls it's own old libs. So I >> would love to let it uninstalled for a few Days. Unless you need it >> right now. >> >> Greetings >> Jan >> >> >> >> >> Am 16.03.15 um 10:10 schrieb Carsten Grzemba via buildfarm: >> > CSWnetsnmp-dev is gone from buildfarm ? >> > Can you please reinstall this >> > >> > Carsten >> From buildfarm at lists.opencsw.org Wed Mar 18 15:41:30 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Wed, 18 Mar 2015 15:41:30 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <20150318141331.GA32582@athene.usta.de> References: <20150318141331.GA32582@athene.usta.de> Message-ID: <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> Hi Ingo, > Am 18.03.2015 um 15:13 schrieb Ingo Schwarze : > > Hi, > > this is the maintainer of mandoc (mdocml.bsd.lv) speaking. > > For the last few years, the result of asking for release testing > of mandoc has consistently been that a large fraction of portability > issues reported, and in particular usually the most severe ones, > up to and including incomplete POSIX support, were related to > commercial SUN Solaris or Oracle Solaris platforms - compared to > that, OpenBSD, FreeBSD, NetBSD and DragonFly very rarely cause > portability issues, and the issues that arise on Linux are typically > easy to solve. Even illumos appears to be less hostile to foreign > software than commercial Solaris... > > So it might make sense that i do systematic testing of mandoc > on commercial Solaris. Is that possible with your project? > A Solaris 10 user (Sevan Janiyan) pointed me to > > http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ > > which seems to indicate just that. Sure, our buildfarm is equipped with Solaris 8, 9, 10 and 11 both Sparc and x86 and multiple compilers. Just send me your ssh public key and intended user name and I?ll set up an account for you. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Wed Mar 18 16:51:05 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Wed, 18 Mar 2015 16:51:05 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <20150318151442.GB32582@athene.usta.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <20150318151442.GB32582@athene.usta.de> Message-ID: Hallo Ingo, > Am 18.03.2015 um 16:14 schrieb Ingo Schwarze : > > Dagobert Michelsen wrote on Wed, Mar 18, 2015 at 03:41:30PM +0100: >> Am 18.03.2015 um 15:13 schrieb Ingo Schwarze : > >>> this is the maintainer of mandoc (mdocml.bsd.lv) speaking. >>> >>> For the last few years, the result of asking for release testing >>> of mandoc has consistently been that a large fraction of portability >>> issues reported, and in particular usually the most severe ones, >>> up to and including incomplete POSIX support, were related to >>> commercial SUN Solaris or Oracle Solaris platforms - compared to >>> that, OpenBSD, FreeBSD, NetBSD and DragonFly very rarely cause >>> portability issues, and the issues that arise on Linux are typically >>> easy to solve. Even illumos appears to be less hostile to foreign >>> software than commercial Solaris... >>> >>> So it might make sense that i do systematic testing of mandoc >>> on commercial Solaris. Is that possible with your project? >>> A Solaris 10 user (Sevan Janiyan) pointed me to >>> >>> http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ >>> >>> which seems to indicate just that. > >> Sure, our buildfarm is equipped with Solaris 8, 9, 10 and 11 both >> Sparc and x86 and multiple compilers. Just send me your ssh public >> key and intended user name and I???ll set up an account for you. > > User name (if still free): schwarze > Real name: Ingo Schwarze > Project name: mandoc > Project homepage: mdocml.bsd.lv > > SSH public key: > > ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8rsUvXcSVqeclE+hihGHTucaHABskYr7PRJSeGyjwPBYv6A7a2ExtrwNhoWFLRN8aGEEdJ6DrQedmQappjLsM7ySmI5EGTYfkfV9PrfRVbzaonb7e11g+OQ8Yt4CQpC7TNlHpLQO5e9g6ief4EBzWNVT2ZuHXLF1+VqTTohxTVcTCh0kYXwFVgef76TR3InvYh/cCtOFatd5g9/C8r/rs7922zW/Lu36MFprioO7I9NF6L3aJZiMEbp0ll1N4MIzD+eD0IFp1sGKG+3h3LByRVyXVUyGB6In8mN1i2LFWQiXHjdzpHl4hH3UrBHSjalAaszCmDg+cNmZjanU+pmGb schwarze at isnote.usta.de Das sollte jetzt gehen: ssh schwarze at login.opencsw.org In /etc/SETUP steht wie die Buildfarm aufgebaut ist. Melde Dich einfach wenn Du was auf der Farm brauchst. Beste Gr??e ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Tue Mar 17 17:28:22 2015 From: buildfarm at lists.opencsw.org (Sevan Janiyan via buildfarm) Date: Tue, 17 Mar 2015 16:28:22 +0000 Subject: pkgsrc on Solaris Message-ID: <55085626.7090301@NetBSD.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Following up from twitter as advised, I'd like to resume bulk building the pkgsrc tree on Solaris 10 & 11 on intel & SPARC. If you can assist in any way, it'd be much appreciated. Regards Sevan -----BEGIN PGP SIGNATURE----- iQIcBAEBAgAGBQJVCFYmAAoJENE/+DdOy3tCeVgP/3bWWpk16QeU3T3lXcqsJC1+ Ebo6+Nyw4qS1dwfgVUekwi0OKX1CFc1bh5vWDabt2Zi4YcLeUn04gFZpWp/JvcCq 3/GDzVJj9OnBdvAbb2mfxcZ3Y3Rjs+AmfDXyL5mpmNQgusxfYQsWOB4z7xDAf7SC gHGHAI9tj3Evm6f7q3kxTL/ElguTWGORS5buGzlZ8hVMM4hJFWulH1wLAwwEjbCQ Vjst+f6HHSYTZqQoOd3lRH+SHuQHqTwfEaLDhYh8CCYdEIpjxcTkJlIceXDO0kmW BMl+fJWRCi5x3TQHldzEFcT5EWzL6ezTnQF/WVJrJJ8XJ2/6WVcXTjuPVg/mWc1W XWIAKcr7NQETztun3P++S2e+houfgWqU7stBUWi0h4IEVNJM8lGsoPIUBILxw6FD Gcf4MuVxX7CRip7/F2wKM65SvYYdrrsChFImrzJ4BZRYYWGlL6/+6aZwSvkbGqKs IQ3KLNn6GywpZZwLNEyMRo1HbzW88d6Lq21+SFXoI8ymRiSbUBfTHl4d0sC/a57+ x1tSlce4GlexiZrvlz3Ot/s2sqxaWcdHPobTxrETd5Hku/HQdMrv89zwO3p9cn6M mJs4ycZVWhAkN7qpYnrqK/taiOWTfo2WDFiKZuHTHiiIf8Px6xzMQsQC9f+I8nkr EHPOFJBk5/URBWi+ZNOl =fDws -----END PGP SIGNATURE----- From buildfarm at lists.opencsw.org Wed Mar 18 16:14:42 2015 From: buildfarm at lists.opencsw.org (Ingo Schwarze via buildfarm) Date: Wed, 18 Mar 2015 16:14:42 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> Message-ID: <20150318151442.GB32582@athene.usta.de> Hi Dagobert, Dagobert Michelsen wrote on Wed, Mar 18, 2015 at 03:41:30PM +0100: > Am 18.03.2015 um 15:13 schrieb Ingo Schwarze : >> this is the maintainer of mandoc (mdocml.bsd.lv) speaking. >> >> For the last few years, the result of asking for release testing >> of mandoc has consistently been that a large fraction of portability >> issues reported, and in particular usually the most severe ones, >> up to and including incomplete POSIX support, were related to >> commercial SUN Solaris or Oracle Solaris platforms - compared to >> that, OpenBSD, FreeBSD, NetBSD and DragonFly very rarely cause >> portability issues, and the issues that arise on Linux are typically >> easy to solve. Even illumos appears to be less hostile to foreign >> software than commercial Solaris... >> >> So it might make sense that i do systematic testing of mandoc >> on commercial Solaris. Is that possible with your project? >> A Solaris 10 user (Sevan Janiyan) pointed me to >> >> http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ >> >> which seems to indicate just that. > Sure, our buildfarm is equipped with Solaris 8, 9, 10 and 11 both > Sparc and x86 and multiple compilers. Just send me your ssh public > key and intended user name and I???ll set up an account for you. User name (if still free): schwarze Real name: Ingo Schwarze Project name: mandoc Project homepage: mdocml.bsd.lv SSH public key: ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC8rsUvXcSVqeclE+hihGHTucaHABskYr7PRJSeGyjwPBYv6A7a2ExtrwNhoWFLRN8aGEEdJ6DrQedmQappjLsM7ySmI5EGTYfkfV9PrfRVbzaonb7e11g+OQ8Yt4CQpC7TNlHpLQO5e9g6ief4EBzWNVT2ZuHXLF1+VqTTohxTVcTCh0kYXwFVgef76TR3InvYh/cCtOFatd5g9/C8r/rs7922zW/Lu36MFprioO7I9NF6L3aJZiMEbp0ll1N4MIzD+eD0IFp1sGKG+3h3LByRVyXVUyGB6In8mN1i2LFWQiXHjdzpHl4hH3UrBHSjalAaszCmDg+cNmZjanU+pmGb schwarze at isnote.usta.de Thanks! Ingo From buildfarm at lists.opencsw.org Thu Mar 19 11:45:13 2015 From: buildfarm at lists.opencsw.org (Honkman GMail via buildfarm) Date: Thu, 19 Mar 2015 11:45:13 +0100 Subject: test Message-ID: <528F5429-3560-404A-82E2-E3D06F0DA269@gmail.com> From buildfarm at lists.opencsw.org Thu Mar 19 12:00:15 2015 From: buildfarm at lists.opencsw.org (Joerg Schilling via buildfarm) Date: Thu, 19 Mar 2015 12:00:15 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> Message-ID: <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> Dagobert Michelsen via buildfarm wrote: > Hi Ingo, > > > Am 18.03.2015 um 15:13 schrieb Ingo Schwarze : > > > > Hi, > > > > this is the maintainer of mandoc (mdocml.bsd.lv) speaking. > > > > For the last few years, the result of asking for release testing > > of mandoc has consistently been that a large fraction of portability > > issues reported, and in particular usually the most severe ones, > > up to and including incomplete POSIX support, were related to > > commercial SUN Solaris or Oracle Solaris platforms - compared to > > that, OpenBSD, FreeBSD, NetBSD and DragonFly very rarely cause > > portability issues, and the issues that arise on Linux are typically > > easy to solve. Even illumos appears to be less hostile to foreign > > software than commercial Solaris... > > > > So it might make sense that i do systematic testing of mandoc > > on commercial Solaris. Is that possible with your project? > > A Solaris 10 user (Sevan Janiyan) pointed me to > > > > http://www.opencsw.org/extend-it/signup/to-upstream-maintainers/ > > > > which seems to indicate just that. > > Sure, our buildfarm is equipped with Solaris 8, 9, 10 and 11 both > Sparc and x86 and multiple compilers. Just send me your ssh public > key and intended user name and I???ll set up an account for you. I did recently run a test with the mandoc program on Solaris and tried to check the results. In general, the tbl support is extremely bad. Many tables are unreadable or disappear from the output. In general, the mandoc _format_ (introduced with BSD-4.4-lite) is not a problem on Solaris if you use the enhanced man program I created some years ago and that is published together with Schillix-ON, see: https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/man/ What I did was to take the mandoc troff macros from BSD-4.4-lite (those that still work with original troff) and added a few minor fixes (e.g. a Y2000 fix). What I don't understand is why the mandoc program was written at all. Compared to most software that has been recently developped, it looks nice, but if I remember correctly, the sourcecode for "mandoc" is 2-3x more that the sourcecode for "man", "troff", "tbl", "soelim", "col" ... all together and the current state seems to be that only 80-90% of the Solaris man pages work with the mandoc program. The former problem that groff is under GPL is no longer a problem since the original AT&T troff has been made OpenSource under a free license together with OpenSolaris in June 2005. Can you enlighten me please? J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' From buildfarm at lists.opencsw.org Thu Mar 19 12:36:49 2015 From: buildfarm at lists.opencsw.org (Kristaps Dzonsons via buildfarm) Date: Thu, 19 Mar 2015 12:36:49 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <550AB4D1.4070108@bsd.lv> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > I did recently run a test with the mandoc program on Solaris and > tried to check the results. In general, the tbl support is > extremely bad. Many tables are unreadable or disappear from the > output. > > In general, the mandoc _format_ (introduced with BSD-4.4-lite) is > not a problem on Solaris if you use the enhanced man program I > created some years ago and that is published together with > Schillix-ON, see: > > https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/man/ > > > What I did was to take the mandoc troff macros from BSD-4.4-lite > (those that still work with original troff) and added a few minor > fixes (e.g. a Y2000 fix). > > What I don't understand is why the mandoc program was written at > all. Compared to most software that has been recently developped, > it looks nice, but if I remember correctly, the sourcecode for > "mandoc" is 2-3x more that the sourcecode for "man", "troff", > "tbl", "soelim", "col" ... all together and the current state seems > to be that only 80-90% of the Solaris man pages work with the > mandoc program. > > The former problem that groff is under GPL is no longer a problem > since the original AT&T troff has been made OpenSource under a > free license together with OpenSolaris in June 2005. > > Can you enlighten me please? Hi Jorg, I think I can answer this--I originally wrote mandoc(1). First, mandoc(1) is NOT a troff implementation. It's a compiler for mdoc(7) and man(7). If you run mandoc(1) on an mdoc(7) document, it understands the mdoc(7) itself. Thus, an mdoc(7) manpage has its full semantic tree available to mandoc(1) for formatting and analysis. This is incredibly helpful, because mandoc(1) knows that `Fn foo' describes a function, not just text in bold. Moreover, since mdoc(7) and man(7) are both hierarchical (i.e., `Ss' in `Sh', `Em' in `Bd', etc.), mandoc(1) can even convert mdoc(7) and man(7) into hierarchical mark-up languages like HTML. On OpenBSD, FreeBSD, and NetBSD, this is great: most manuals are written in mdoc(7), so mandoc(1) has a lot of power in understanding the entire manpage corpus as a semantic body. To cope with the larger body of manuals not written in mdoc(7) or man(7) (or written poorly), mandoc(1) has over the years been extended to cope with more and more roff(7) macros, which have no semantic value at all. This is difficult for mandoc(1): roff(7) is not hierarchical, and moreover, as mandoc(1) considers mdoc(7) and man(7) their own languages and roff(7) can change the behaviour of these macros, conflicts can and do arise. I don't know about Solaris' manpages, so I'm not sure how representative documents look. If mandoc(1) and your troff(1) have dissimilar output, the reason is often because of roff(7) macros in the manpages used for line formatting. As for tbl(7), if you have issues, then please send us the offending manpages and we'll look at them! mandoc(1) tries to handle tbl(7) and eqn(7), but it doesn't always get them right. As for source size, mandoc(1) does pretty well considering that it parses tbl(7), eqn(7), man(7), mdoc(7), and some roff(7); converts these into PDF, PS, HTML; has a database indexer makewhatis(8); full semantic querying on the command line or over CGI in apropos(1) and man.cgi(8); and even a man(1) implementation. GNU troff's C/C++ files are over 100K LOC, while mandoc's amount to 36K. Best, Kristaps -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCrTQAAoJEMT2SUY9XBEST+YP/jpfmR44pFB1p2BoCAP/Mlbe oTwBnd9xmDTdDWOTUdS5azK/jZGgn8tXe8RNVZdN+tCdcC9PC849+v6vKyBmH6nO kWm0nIyhxoNo4W1gBS33N/q2FKHSWG7sbwbd6c1iebAjZVDGBApfoNzbn8qXFIxN ounpjuuB7wzQ/Hq0x2nrqkkHHgjPHnF8Rrp8zilM1TMYJLW+6awHQb7GBVRl4Wz2 fBeu2BSbD+9FgFCzHpwcfqiVhHQiU6afhBWqij4Q/olG/OUXcpbelw/wNtWwDYWY C2VK4bYPaWkyukHeBWhkaVF+XMYjx7ELTLBrRUa1skyVEkiXkBtVDLg0YdmV0daM TykFILjowRev4SGkfMq3Nb1Xh5TzrjmcbC4eyz6yEc3pI2Nrosl6YJ8V7MrHTEJ5 Pir+Kr7ZurnvqbOEXn2bjxqktOS8jvA1VCpaAH12C9XMfAkLJFSAZJGljneIBxN2 zy0AgSaVw7mSv7eGOdyWiabP3T8gg6wtaUyPBCkSCFeTpdPUjr5mTx+Rv5HJzlyE VqTbXOqw272N2Pz1cWgXOEJQICO6oiZBIMG/B0fsLOv3zDMRnPYY0lEeqV/qdNye SbQOjNOrQ130bJZVkN/bAOXW8kKaSLwJjs7rxRPyGGFDdKS+bQnbul2FUudpGjZh AgDpqSvS3v5PDbThxYFe =YpYT -----END PGP SIGNATURE----- From buildfarm at lists.opencsw.org Thu Mar 19 13:11:42 2015 From: buildfarm at lists.opencsw.org (Ingo Schwarze via buildfarm) Date: Thu, 19 Mar 2015 13:11:42 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20150319121142.GE6929@athene.usta.de> Hi Joerg, Joerg Schilling wrote on Thu, Mar 19, 2015 at 12:00:15PM +0100: > I did recently run a test with the mandoc program on Solaris > and tried to check the results. In general, the tbl support > is extremely bad. Many tables are unreadable It is true that tbl(7) support is still not as good as mdoc(7) support. That is mostly due to the fact that BSD manuals rarely use tables, but it can certainly be improved. In fact, i implemented some improvements recently, for example horizontal centering of tables as a whole. > or disappear from the output. That is one of the things i recently improved, so it should be better in mandoc-1.13.3 than in 1.13.2. I don't claim that all of such issues are gone, though. > In general, the mandoc _format_ (introduced with BSD-4.4-lite) I assume you are talking about the mdoc(7) format designed and implemented by Cynthia Livingston - as opposed to the traditional Version 7 AT&T UNIX man(7) format. > is not a problem on Solaris if you use the enhanced man program > I created some years ago and that is published together with > Schillix-ON, see: > > https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/man/ > > What I did was to take the mandoc troff macros from BSD-4.4-lite (those > that still work with original troff) and added a few minor fixes (e.g. > a Y2000 fix). I wasn't aware of that and have not checked your work in detail, but i have a rough idea of the quality of Cynthia's original macro implementation because it is still in use in Heirloom roff; Carsten Kunze is working on improvements right now. These macros are usable for historical manuals, but less so for modern manuals. For example, they still have the nine argument limit, and some macros are not parsed and/or not callable that are generally assumed to be in modern manuals. Basically, this old version of the macros lacks all the improvements that Werner Lemberg (GNU) and Ruslan Ermilov (FreeBSD) did for groff, in particular the rewrite for groff-1.17, which many modern manuals now depend on. Note that Werner was kind enough to not change the license from BSD to GPL on the occasion of his rewrite, but the macros need groff features that are not available in older roff implementations. > What I don't understand is why the mandoc program was written at all. There are a number of reasons: 1. Kristaps wasn't satisfied with groff's HTML output quality, and due to the basic architecture of groff, that's almost impossible to improve. 2. OpenBSD wanted to remove groff from the bases system, both for licensing reasons, to get rid of a major chunk of code written in C++ (which is generally considered an inappropriate language for the OpenBSD base system), and because groff is relatively hard to maintain properly. 3. While groff is a rather fast typesetting system, it is a rather slow documentation formatter (though still *much*, much better than DocBook-based toolchains which are positively ridiculously slow in addition to producing man(7) output of abysmal quality; never use DocBook for anything!). Typically, mandoc is by a factor of 3 to 20 faster than groff, depending on the source language and manual size. That allowed switching from installing preformatted manuals to installing manual sources and formatting on the fly, even on older, slower architectures. That also sped up the system build, which is considered an important point in OpenBSD's developer-centric culture. 4. mandoc has support for semantic searching in apropos(1), see my conference presentations available from mdocml.bsd.lv for details. Anyway, these arguments convinced FreeBSD, OpenBSD, NetBSD, Minix 3 and illumos to use mandoc as the system default formatter. > Compared to most software that has been recently developped, > it looks nice, Thanks. :) > but if I remember correctly, the sourcecode for "mandoc" is 2-3x more > that the sourcecode for "man", "troff", "tbl", "soelim", "col" ... > all together It is still much smaller than groff, even though it does support a subset of roff(7) that is now and then used in manuals (including full support for user-defined macros, conditional and numerical expressions). > and the current state seems to be that only 80-90% of the Solaris > man pages work with the mandoc program. The sounds like Solaris manuals tend to use some features that are less commonly used elsewhere - now that i have an account on your build cluster, i can have a look what exactly that is. To put this into perspective, all OpenBSD manuals work with mandoc, and i'm not aware of any current complaints with respect to FreeBSD, NetBSD, or illumos base system manuals. The OpenBSD ports tree contains about 9000 third-party packages; more than 3000 of those contain manuals; less than 300 still use groff for formatting, and the vast majority of those 300 are DocBook generated manuals. There are plans to improve mandoc to deal with even DocBook insanity, but that will still need a bit of work. > The former problem that groff is under GPL is no longer a problem > since the original AT&T troff has been made OpenSource under a free > license together with OpenSolaris in June 2005. CDDL-licensed software is considered free software by the OSI, but the OpenBSD project regards the CDDL as a non-free license, and CDDL-licensed code cannot be used in the OpenBSD base system, but only in the OpenBSD ports tree. The CDDL has at least two defects that disqualifies it for free software: 1. It has strings attached with respect to patent law (6.2). 2. It is viral (3.2). Even if Heirloom roff were free software, i doubt the code quality would be sufficient for inclusion into OpenBSD. It probably would have been good enough in 1994, but i doubt it is still good enough by today's standards. Cynthia's original mdoc(7) macros - even though i highly admire has work, it was excellent for the time, and the language itself is still the best documentation language available IMHO - certainly aren't good enough by today's standards. > Can you enlighten me please? Sure, i hope the above helps. Note that we may well disagree on parts of it, but you asked for the motivation for mandoc, and these are the main points motivating it. I hope you don't consider these informations too off-topic here, but i didn't want to let the questions go unanswered. Yours, Ingo From buildfarm at lists.opencsw.org Thu Mar 19 14:14:27 2015 From: buildfarm at lists.opencsw.org (Joerg Schilling via buildfarm) Date: Thu, 19 Mar 2015 14:14:27 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <20150319121142.GE6929@athene.usta.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> <20150319121142.GE6929@athene.usta.de> Message-ID: <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> Ingo Schwarze wrote: > It is true that tbl(7) support is still not as good as mdoc(7) > support. That is mostly due to the fact that BSD manuals rarely > use tables, but it can certainly be improved. In fact, i implemented > some improvements recently, for example horizontal centering of > tables as a whole. > > > or disappear from the output. > > That is one of the things i recently improved, so it should be better > in mandoc-1.13.3 than in 1.13.2. I don't claim that all of such > issues are gone, though. I tested two months ago using 1.13.2. > > In general, the mandoc _format_ (introduced with BSD-4.4-lite) > > I assume you are talking about the mdoc(7) format designed and > implemented by Cynthia Livingston - as opposed to the traditional > Version 7 AT&T UNIX man(7) format. I did not try to find out who was the author. It was hard enough to find a useful version from dozens of variants that appear on the BSD snapshot from Kirk McKusick that comes with SCCS and a most recent edit timestamp from June 23 1995. > > https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/man/ > > > > What I did was to take the mandoc troff macros from BSD-4.4-lite (those > > that still work with original troff) and added a few minor fixes (e.g. > > a Y2000 fix). > > I wasn't aware of that and have not checked your work in detail, > but i have a rough idea of the quality of Cynthia's original macro > implementation because it is still in use in Heirloom roff; Carsten > Kunze is working on improvements right now. If there are improvements, please keep me informed. > These macros are usable for historical manuals, but less so for modern > manuals. For example, they still have the nine argument limit, and > some macros are not parsed and/or not callable that are generally > assumed to be in modern manuals. Basically, this old version of Are there *BSD man pages that go beyond the official 6 argument limit for troff macros? From my interpretation, using such features is not a good idea if you intend to create portable man pages. For this reason I decided not to enhance the Solaris man macros to support more than 6 arguments, just to be sure to detect problems early if I write or enhance man pages. > the macros lacks all the improvements that Werner Lemberg (GNU) and > Ruslan Ermilov (FreeBSD) did for groff, in particular the rewrite > for groff-1.17, which many modern manuals now depend on. Note that > Werner was kind enough to not change the license from BSD to GPL > on the occasion of his rewrite, but the macros need groff features > that are not available in older roff implementations. I cannot speak for *BSD man pages as a whole, but the man pages I checked did not show problems with the macros I provide with SchilliX-ON. > > What I don't understand is why the mandoc program was written at all. > > There are a number of reasons: > > 1. Kristaps wasn't satisfied with groff's HTML output quality, > and due to the basic architecture of groff, that's almost > impossible to improve. Is there something that is significantly better than man2html? This is what I use when I format man pages for the Web. > 2. OpenBSD wanted to remove groff from the bases system, both > for licensing reasons, to get rid of a major chunk of code > written in C++ (which is generally considered an inappropriate > language for the OpenBSD base system), and because groff is > relatively hard to maintain properly. Well, I agree that there are three basic problems with groff: - It is huge with respect to AT&Ts troff - It is written in C++ - It uses a license that contains ambiguous text and thus is miss-interpreted by too many people in an extremely restrictive way. Note that the GPL was listed as a non-free license by opensource.org for some years. This changed after the FSF confirmed that the GPL has to be interpreted in a way that makes it compatible to the OpenSource.org OSS guidelines. Given the fact that you cannot enforce all of the GPL in court and that what you can enforce is not more than what's in the CDDL, the GPL is a license with unneeded restrictions that just afflict those people who intend to follow the written rules. > 3. While groff is a rather fast typesetting system, it is a rather > slow documentation formatter (though still *much*, much better > than DocBook-based toolchains which are positively ridiculously > slow in addition to producing man(7) output of abysmal quality; > never use DocBook for anything!). Typically, mandoc is by a > factor of 3 to 20 faster than groff, depending on the source > language and manual size. That allowed switching from > installing preformatted manuals to installing manual sources > and formatting on the fly, even on older, slower architectures. > That also sped up the system build, which is considered an > important point in OpenBSD's developer-centric culture. The performance of troff (the AT&T original code) is comparable to what you get from mandoc. My tests resulted in aprox. 30% performance benefit with mandoc, but this seems to be neglible if you compare to gtroff. > 4. mandoc has support for semantic searching in apropos(1), > see my conference presentations available from mdocml.bsd.lv > for details. I'll need to remember this next week, when I am back from CLT. Tomorow, I'll move to Chemnitz and before there is not much time. > Anyway, these arguments convinced FreeBSD, OpenBSD, NetBSD, Minix 3 > and illumos to use mandoc as the system default formatter. Well illumos originally have a major bug in their i18n configuration tables for character classification. For this reason, "col -x" does not work correctly on illumos. The illumos people have been in hope to use mandoc to cover their i18n bug, but last week, they reported wimilar problems with mandoc ;-) > It is still much smaller than groff, even though it does support > a subset of roff(7) that is now and then used in manuals (including > full support for user-defined macros, conditional and numerical > expressions). UNIX-V7 man pages did not use more from tbl than what seems to be implemented in mandoc. This changed in the 1980s for some UNIX distros and UNIX man pages not usually expect to be able to define column widths. > > and the current state seems to be that only 80-90% of the Solaris > > man pages work with the mandoc program. > > The sounds like Solaris manuals tend to use some features that are > less commonly used elsewhere - now that i have an account on your > build cluster, i can have a look what exactly that is. > > To put this into perspective, all OpenBSD manuals work with mandoc, > and i'm not aware of any current complaints with respect to FreeBSD, > NetBSD, or illumos base system manuals. The OpenBSD ports tree > contains about 9000 third-party packages; more than 3000 of those > contain manuals; less than 300 still use groff for formatting, and > the vast majority of those 300 are DocBook generated manuals. There > are plans to improve mandoc to deal with even DocBook insanity, but > that will still need a bit of work. most of the man pages for my OSS packages use tbl features that do not work with mandoc. > > The former problem that groff is under GPL is no longer a problem > > since the original AT&T troff has been made OpenSource under a free > > license together with OpenSolaris in June 2005. > > CDDL-licensed software is considered free software by the OSI, > but the OpenBSD project regards the CDDL as a non-free license, > and CDDL-licensed code cannot be used in the OpenBSD base system, > but only in the OpenBSD ports tree. The CDDL has at least two > defects that disqualifies it for free software: > > 1. It has strings attached with respect to patent law (6.2). The missing patent defending support is usually seen as a problem with the BSD license. Note that this usually _is_ a problem if a company that owns patents published code under the BSD license. This is why most people (including me and opensource.org) recommend to use Apache-2 to people that like to publish software under an "academic license" (see the book from Lawrence Rosen for the definition of OSS license categories). > 2. It is viral (3.2). Lawrence Rosen calls it "reciprocal". I convinced the FreeBSD people in February 2006 on the "Chemnitzer Linux Tage" that the CDDL is not a problem for FreeBSD and they started to port ZFS since then. > Even if Heirloom roff were free software, i doubt the code > quality would be sufficient for inclusion into OpenBSD. > It probably would have been good enough in 1994, but i doubt > it is still good enough by today's standards. Cynthia's original > mdoc(7) macros - even though i highly admire has work, it was > excellent for the time, and the language itself is still the best > documentation language available IMHO - certainly aren't good > enough by today's standards. My impression with the mdoc() macro set is that it mainly tries to provide new macros for use cases that work with classical man(5) macros if you know that there is \c to innterupt line processing with [nt]roff. The mdoc() macros look unmneeded complex to me. This is why I still prefer man(5). I did not yet check the quality of Heirloom troff. I know however that there is not much maintenance for all the projects in Heirloom that I checked before. Example 1: The Bourne Shell. The Heirloom Bourne Shell still uses the old sbrk(2) based allocator and thus is not really portable. Few bugs have been fixed since the code was taken from OpenSolaris. My Bourne Shell fixed all "documented bugs" and converted the code to be based on malloc()/free(). I added my command line history editor from 1982..1984 and a lot of other new features like an advanced alias system. My Bourne Shell even works on Cygwin and is much faster than bash on Cygwin. Example 2: SCCS.... The Heirloom variant changed 1-2% of the code and introduced a limited portability. The first published version did not even work on Linux as multiple calls to fclose() caused the software to dump core on Linux. My SCCS implementation fixed a lot of problems in the code and enhanced performance by a factor of 3x. Many new features have been introduced and the code works nearly evrywhere. Aprox. 60-70% of the current SCCS code base is code written by me. There soon will be a "project mode" that supports groups of files and network support to allow to use it as a distributed SCM. > > Can you enlighten me please? > > Sure, i hope the above helps. Note that we may well disagree > on parts of it, but you asked for the motivation for mandoc, > and these are the main points motivating it. > > I hope you don't consider these informations too off-topic here, > but i didn't want to let the questions go unanswered. Thank you for the explanation. When I've time, I'll give the new version a try. I will however stay with the classical man(1) + troff on SchilliX. BTW: One reason is line formatting. I prefer full justification before left aligned text. J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' From buildfarm at lists.opencsw.org Thu Mar 19 17:54:17 2015 From: buildfarm at lists.opencsw.org (Ingo Schwarze via buildfarm) Date: Thu, 19 Mar 2015 17:54:17 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> <20150319121142.GE6929@athene.usta.de> <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20150319165416.GG6929@athene.usta.de> Hi Joerg, Joerg Schilling wrote on Thu, Mar 19, 2015 at 02:14:27PM +0100: > Ingo Schwarze wrote: >> Joerg Schilling wrote: [...] >>> In general, the mandoc _format_ (introduced with BSD-4.4-lite) >> I assume you are talking about the mdoc(7) format designed and >> implemented by Cynthia Livingston - as opposed to the traditional >> Version 7 AT&T UNIX man(7) format. > I did not try to find out who was the author. Oh, that is actually not easy to find out. I didn't find the information on the Internet either. But i confirmed it by talking to Kirk in person and by exchanging email with Cynthia herself. > It was hard enough to find a useful version from dozens of variants > that appear on the BSD snapshot from Kirk McKusick that comes with > SCCS and a most recent edit timestamp from June 23 1995. According to Cynthia, three noteworthy versions existed: * mdoc(7) version 1 was never checked into version control, never published, and the source code is probably lost. It was what Cynthia used when starting the work. * mdoc(7) version 2 is still available here: http://svnweb.freebsd.org/csrg/share/tmac/tmac.doc.old That version was short-lived: It was only contained in 4.3BSD-Reno and 4.3BSD-Net/2, but in Reno, only a small number of manuals was converted to mdoc(7), most were still shipped in the old man(7) format, and in Net/2, conversion to version 3 had already started. * mdoc(7) version 3 is available here: http://svnweb.freebsd.org/csrg/share/tmac/doc (and the doc-* files in the same directory) That's the version used in all variants of 4.4BSD, and the only one people usually have in mind when talking about "mdoc(7)" today. >> I wasn't aware of that and have not checked your work in detail, >> but i have a rough idea of the quality of Cynthia's original macro >> implementation because it is still in use in Heirloom roff; Carsten >> Kunze is working on improvements right now. > If there are improvements, please keep me informed. You should probably just follow https://github.com/n-t-roff/heirloom-doctools/ Carsten also announces releases on . I'm not directly involved with Heirloom troff development, so i'm not the ideal person to keep people informed about it. > Are there *BSD man pages that go beyond the official 6 argument > limit for troff macros? Yes, we dropped that restriction in OpenBSD about four years ago, and i doubt that FreeBSD and NetBSD still abide by it. > From my interpretation, using such features is not a good idea if you > intend to create portable man pages. Well, portable to what? Historic systems? That particular restriction makes writing manuals unnecessarily hard for manual authors. Given that we want *developers* to write documentation - who usually aren't documentation specialists and don't want to waste too much time on it - making it easy to write documentation is important. That seemed much more relevant than portability to, say, 4.4BSD-Lite2 or System V.4, which nobody is running today, anyway. > For this reason I decided not to enhance the Solaris man macros > to support more than 6 arguments, just to be sure to > detect problems early if I write or enhance man pages. I'm not sure that's a wise choice. Probably, the only effect is that Solaris may be the only modern system out there that has problems rendering modern manuals (admittedly, i didn't try, but that's what i would expect). Maybe, when i'm bored, i might copy the OpenBSD manuals to the OpenCSW cluster and have a look... [...] > Is there something that is significantly better than man2html? You would have to ask Kristaps. I never used that particular program. The following is generated directly with mandoc: http://www.openbsd.org/cgi-bin/man.cgi # many releases of OpenBSD http://mdocml.bsd.lv/cgi-bin/man.cgi # UNIX-7, 4.4BSD, Net, Free, ... [...] > The performance of troff (the AT&T original code) is comparable to > what you get from mandoc. My tests resulted in aprox. 30% performance > benefit with mandoc, but this seems to be neglible if you compare > to gtroff. Performance very much depends on the language (mdoc(7) vs. man(7), and possibly tbl(7) and eqn(7)) and the size of the page in question, so giving a single number does not tell me very much. In general, performance differs more for mdoc(7) than for man(7) and more for smaller pages than for larger ones. [...] > most of the man pages for my OSS packages use tbl features > that do not work with mandoc. Using unusual tbl(7) features in manuals doesn't look like a particularly good idea to me, in particular if you care about portability. [...] > My impression with the mdoc() macro set is that it mainly tries > to provide new macros for use cases that work with classical > man(5) macros if you know that there is \c to innterupt line > processing with [nt]roff. Not at all. The point of mdoc(7) is semantic markup, while man(7) is purely presentational markup. So the two languages serve completely different purposes. [...] > I did not yet check the quality of Heirloom troff. I know however > that there is not much maintenance for all the projects in Heirloom > that I checked before. Heirloom troff is now maintained seperately from the rest of the Heirloom tools. [...] > I will however stay with the classical man(1) + troff on SchilliX. Feel free to use whatever you like for your personal purposes. :-) > BTW: One reason is line formatting. I prefer full justification > before left aligned text. That's indeed a matter of taste. The vast majority of OpenBSD developers prefer flush-left, and i don't remeber hearing complaints about it from FreeBSD, NetBSD, DragonFly, illumos or any of the Linux ports either. Implementing .ad would not be that difficult, but demand is tiny, so i'm treating it as a low-priority task. Yours, Ingo From buildfarm at lists.opencsw.org Thu Mar 19 18:31:48 2015 From: buildfarm at lists.opencsw.org (Joerg Schilling via buildfarm) Date: Thu, 19 Mar 2015 18:31:48 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <20150319165416.GG6929@athene.usta.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> <20150319121142.GE6929@athene.usta.de> <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> <20150319165416.GG6929@athene.usta.de> Message-ID: <550b0804.BAAuf0sHx9DRczBy%Joerg.Schilling@fokus.fraunhofer.de> Ingo Schwarze wrote: > According to Cynthia, three noteworthy versions existed: > > * mdoc(7) version 1 was never checked into version control, never > published, and the source code is probably lost. It was what > Cynthia used when starting the work. > > * mdoc(7) version 2 is still available here: > http://svnweb.freebsd.org/csrg/share/tmac/tmac.doc.old > That version was short-lived: It was only contained > in 4.3BSD-Reno and 4.3BSD-Net/2, but in Reno, only a small > number of manuals was converted to mdoc(7), most were still > shipped in the old man(7) format, and in Net/2, conversion > to version 3 had already started. > > * mdoc(7) version 3 is available here: > http://svnweb.freebsd.org/csrg/share/tmac/doc > (and the doc-* files in the same directory) > That's the version used in all variants of 4.4BSD, > and the only one people usually have in mind when talking > about "mdoc(7)" today. I am trying to find out which version I used and reply later. BTW: I am soon going to publish the CSRG source SCCS without a loss of meta data once I have SCCSv6 ready enough. I discussed this with Kirk McKusick a while ago and it seems that if I manually fix all the bugs from the disk crash that happened to the BSD people and if I convert the format from SCCSv4 to SCCSv6, the license problems with the original CSRG CDs will go agay as they did with the svn converted version. > [...] > > most of the man pages for my OSS packages use tbl features > > that do not work with mandoc. > > Using unusual tbl(7) features in manuals doesn't look like a > particularly good idea to me, in particular if you care about > portability. I am not using unusual features of tbl, but standard features. As people usually assume that a man page is processed by calling: soelim | tbl | nroff -u1 -Tlp -man - | col -x' all standard tbl features are OK. If mandoc does not support the features in use, then it seems to be a bad idea... J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' From buildfarm at lists.opencsw.org Thu Mar 19 18:54:28 2015 From: buildfarm at lists.opencsw.org (Joerg Schilling via buildfarm) Date: Thu, 19 Mar 2015 18:54:28 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <20150319165416.GG6929@athene.usta.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> <20150319121142.GE6929@athene.usta.de> <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> <20150319165416.GG6929@athene.usta.de> Message-ID: <550b0d54.Sj/QcL6WIWdJmcLM%Joerg.Schilling@fokus.fraunhofer.de> Ingo Schwarze wrote: > According to Cynthia, three noteworthy versions existed: > > * mdoc(7) version 1 was never checked into version control, never > published, and the source code is probably lost. It was what > Cynthia used when starting the work. > > * mdoc(7) version 2 is still available here: > http://svnweb.freebsd.org/csrg/share/tmac/tmac.doc.old > That version was short-lived: It was only contained > in 4.3BSD-Reno and 4.3BSD-Net/2, but in Reno, only a small > number of manuals was converted to mdoc(7), most were still > shipped in the old man(7) format, and in Net/2, conversion > to version 3 had already started. > > * mdoc(7) version 3 is available here: > http://svnweb.freebsd.org/csrg/share/tmac/doc > (and the doc-* files in the same directory) > That's the version used in all variants of 4.4BSD, > and the only one people usually have in mind when talking > about "mdoc(7)" today. OK, I am using a file based on: CSRG/CSRG_Archive_3/4.4/usr/share/tmac/tmac.doc I have no idea how this is related to the svn conversion. > > If there are improvements, please keep me informed. > > You should probably just follow > > https://github.com/n-t-roff/heirloom-doctools/ I would need to download this as the web interface is not nice to compare such things. > Carsten also announces releases on . > > I'm not directly involved with Heirloom troff development, > so i'm not the ideal person to keep people informed about it. So is the development of this decoupled from Gunnar Ritter? > > Are there *BSD man pages that go beyond the official 6 argument > > limit for troff macros? > > Yes, we dropped that restriction in OpenBSD about four years ago, > and i doubt that FreeBSD and NetBSD still abide by it. > > > From my interpretation, using such features is not a good idea if you > > intend to create portable man pages. > > Well, portable to what? Historic systems? I create portable software and I assume that my software also works on HP-UX and AIX. > > For this reason I decided not to enhance the Solaris man macros > > to support more than 6 arguments, just to be sure to > > detect problems early if I write or enhance man pages. > > I'm not sure that's a wise choice. Probably, the only effect is > that Solaris may be the only modern system out there that has > problems rendering modern manuals (admittedly, i didn't try, but > that's what i would expect). Maybe, when i'm bored, i might > copy the OpenBSD manuals to the OpenCSW cluster and have a look... I am sure there are other systems with this restriction. > Performance very much depends on the language (mdoc(7) vs. man(7), > and possibly tbl(7) and eqn(7)) and the size of the page in > question, so giving a single number does not tell me very much. > In general, performance differs more for mdoc(7) than for man(7) > and more for smaller pages than for larger ones. As I fixed the Solaris man pages (Sun did destroy them when converting them to sgxml for a Framemaker plugin and later back to troff. You can have a look at the current state of the man pages in the Mercurial of SchilliX-ON and HTML converted at: http://schillix.sourceforge.net/man/ As the conversion could do bad thingd and as (unlike illumos) I have quality standards for the man pages, I do a 100% check for all man pages after each conversion step. I used a similar script to roff all Solaris man pages using troff, groff and mandoc and I compared the time. > [...] > > My impression with the mdoc() macro set is that it mainly tries > > to provide new macros for use cases that work with classical > > man(5) macros if you know that there is \c to innterupt line > > processing with [nt]roff. > > Not at all. The point of mdoc(7) is semantic markup, while man(7) > is purely presentational markup. So the two languages serve > completely different purposes. Where/how does this help? > [...] > > I did not yet check the quality of Heirloom troff. I know however > > that there is not much maintenance for all the projects in Heirloom > > that I checked before. > > Heirloom troff is now maintained seperately from the rest of the > Heirloom tools. Is there a place where I can read something about the background for this project? > > BTW: One reason is line formatting. I prefer full justification > > before left aligned text. > > That's indeed a matter of taste. The vast majority of OpenBSD > developers prefer flush-left, and i don't remeber hearing complaints > about it from FreeBSD, NetBSD, DragonFly, illumos or any of the > Linux ports either. Implementing .ad would not be that difficult, > but demand is tiny, so i'm treating it as a low-priority task. Then it would look like classical man pages. J?rg -- EMail:joerg at schily.net (home) J?rg Schilling D-13353 Berlin joerg.schilling at fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/ URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/' From buildfarm at lists.opencsw.org Thu Mar 19 20:29:52 2015 From: buildfarm at lists.opencsw.org (Ingo Schwarze via buildfarm) Date: Thu, 19 Mar 2015 20:29:52 +0100 Subject: trying to improve mandoc Solaris support In-Reply-To: <550b0d54.Sj/QcL6WIWdJmcLM%Joerg.Schilling@fokus.fraunhofer.de> References: <20150318141331.GA32582@athene.usta.de> <439D3B87-7655-4048-A2E6-FC0BF935E4BC@opencsw.org> <550aac3f.48mGy/57CtE3Lxcd%Joerg.Schilling@fokus.fraunhofer.de> <20150319121142.GE6929@athene.usta.de> <550acbb3.bjUObkA8XQ1Pxhzt%Joerg.Schilling@fokus.fraunhofer.de> <20150319165416.GG6929@athene.usta.de> <550b0d54.Sj/QcL6WIWdJmcLM%Joerg.Schilling@fokus.fraunhofer.de> Message-ID: <20150319192952.GH6929@athene.usta.de> Hi Joerg, Joerg Schilling wrote on Thu, Mar 19, 2015 at 06:54:28PM +0100: > OK, I am using a file based on: > > CSRG/CSRG_Archive_3/4.4/usr/share/tmac/tmac.doc That would be "@(#)doc 8.1 (Berkeley) 6/8/93"? That's indeed Cynthia's final version. A good choice. > I have no idea how this is related to the svn conversion. The SCCS ID tag cited above is visible in the source code, hence it is also contained in file in SVN. Besides, the SVN version retains the original SCCS commit messages and Keith mentioned "4.4BSD snapshot (revision 8.1)" in his commit message. >> You should probably just follow >> https://github.com/n-t-roff/heirloom-doctools/ > I would need to download this as the web interface is not nice > to compare such things. Well, it's github, just use git(1). ;-) >> I'm not directly involved with Heirloom troff development, >> so i'm not the ideal person to keep people informed about it. > So is the development of this decoupled from Gunnar Ritter? Sadly, yes. Gunnar is a kind person, and Carsten repeatedly tried to contact him, but as far as i heard, contact wasn't established. Consequently, Carsten took over maintenance without authorization. In any case, as far as i know, Gunnar stopped working on the Heirloom doctools years ago. > I create portable software and I assume that my software also works > on HP-UX and AIX. Oh. I usually ignore such commercial systems because it is hard to get access. They are not freely available. Well, twenty years ago, i had access to them at CERN, but right now... Besides, the community using such systems seems almost non-existent. While i get lots of feedback from FreeBSD, NetBSD and even DragonFly, and also a bit regarding Solaris, i know of exactly one user on AIX and no user whatsoever on HP-UX. > I am sure there are other systems with this restriction. Maybe, but nobody ever complained, so i'm not sure how relevant they are. >> Performance very much depends on the language (mdoc(7) vs. man(7), >> and possibly tbl(7) and eqn(7)) and the size of the page in >> question, so giving a single number does not tell me very much. > As I fixed the Solaris man pages [...] > and I compared the time. Ah. So that would be a large corpus of almost exclusively man(7) pages of mixed sizes. Usually the bulk is small in size. I would expect a speed factor groff:mandoc of about 2:1 to 4:1 on such a corpus (the big factors of up to 20:1 only occur with mdoc(7), in particular for small pages). So your roff indeed seems a lot faster than groff and closer to mandoc. >>> [...] >>> My impression with the mdoc() macro set is that it mainly tries >>> to provide new macros for use cases that work with classical >>> man(5) macros if you know that there is \c to innterupt line >>> processing with [nt]roff. >> Not at all. The point of mdoc(7) is semantic markup, while man(7) >> is purely presentational markup. So the two languages serve >> completely different purposes. > Where/how does this help? Well, semantic markup is not exactly a new idea, and the advantages are more or less the same everywhere. For manuals, specifically, it helps CSS-driven customizable markup in HTML (and potentially other markup languages), and it allows semantic searching. For example: # Which POSIX interfaces are related to struct timespec? schwarze at isnote $ man -k St=POSIX.1 -a Vt,Ft,Fa=timespec clock_getres, clock_gettime, clock_settime(2) - get/set/calibrate date and time futimens, futimes, utimensat, utimes(2) - set file access and modification times nanosleep(2) - high resolution sleep poll, ppoll(2) - synchronous I/O multiplexing S_ISBLK, S_ISCHR, S_ISDIR, S_ISFIFO, S_ISLNK, S_ISREG, S_ISSOCK, fstat, fstatat, lstat, stat(2) - get file status pthread_cond_timedwait(3) - wait on a condition variable for a specific amount of time pthread_mutex_lock, pthread_mutex_timedlock, pthread_mutex_trylock(3) - lock a mutex sem_timedwait, sem_trywait, sem_wait(3) - decrement (lock) a semaphore # Which pci-attaching drivers did Jonathan Gray write/port? schwarze at isnote $ man -k An=Gray -a Cd=pci an(4) - Aironet Communications 4500/4800 IEEE 802.11FH/b wireless network device bwi(4) - Broadcom AirForce IEEE 802.11b/g wireless network device et(4) - Agere/LSI ET1310 10/100/Gigabit Ethernet device jme(4) - JMicron JMC25x/JMC26x 10/100/Gigabit Ethernet device nfe(4) - NVIDIA nForce MCP 10/100/Gigabit Ethernet device rtw(4) - Realtek RTL8180L IEEE 802.11b wireless network device # Did Joerg Schilling write any software? schwarze at isnote $ man -k An=Schilling schwarze at isnote $ man -k any=Schilling schwarze at isnote $ # Hmm, probably he didn't use mdoc(7), so no semantic searching... >> [...] >>> I did not yet check the quality of Heirloom troff. I know however >>> that there is not much maintenance for all the projects in Heirloom >>> that I checked before. >> Heirloom troff is now maintained seperately from the rest of the >> Heirloom tools. > Is there a place where I can read something about the background > for this project? No big mystery, Carsten simply took over because Gunnar kind of vanished. It was discussed a bit on . Yours, Ingo From buildfarm at lists.opencsw.org Fri Mar 20 01:34:37 2015 From: buildfarm at lists.opencsw.org (FNAC | Intelmail via buildfarm) Date: Fri, 20 Mar 2015 00:34:37 +0000 Subject: =?UTF-8?Q?Descontos_de_at=C3=A9_MIL_REAIS_em_TVs_e_muito_mais_novidades_p?= =?UTF-8?Q?ara_voc=C3=AA._Confira?= Message-ID: An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Sat Mar 21 19:01:38 2015 From: buildfarm at lists.opencsw.org (Centauro via buildfarm) Date: 21 Mar 2015 18:01:38 -0000 Subject: =?UTF-8?Q?Grande=20Festival=20das=20Marcas=20com=20Oxer=21?= =?UTF-8?Q?=20=2B=20T=C3=AAnis=20Mizuno=20Creation=2015=20em=20at?= =?UTF-8?Q?=C3=A9=2012x=21?= Message-ID: An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Mon Mar 23 09:08:47 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Mon, 23 Mar 2015 09:08:47 +0100 Subject: Ruby CI on Solaris In-Reply-To: References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> Message-ID: <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> Hi Naruse, > Am 22.03.2015 um 19:56 schrieb NARUSE, Yui : > > Thank you for the offer. > rubyci.org runs chkbuild (https://github.com/akr/chkbuild). > If you can provide vm or ssh account, I'll setup it. Sure, I would need your ssh public key and intended user name (?rubyci??). The normal setup has a login host that has direct internet access and a private network of buildhosts reachable from the login host which can access git, svn, http etc. on the internet via proxy. Is this sufficient or do you need outgoing NAT or direct incoming connections to the buildhosts? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Mon Mar 23 23:36:07 2015 From: buildfarm at lists.opencsw.org (NARUSE, Yui via buildfarm) Date: Tue, 24 Mar 2015 07:36:07 +0900 Subject: Ruby CI on Solaris In-Reply-To: <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> Message-ID: Hi Dago, My ssh publickey is https://github.com/nurse.keys and user name is rubyci. network is also sufficient as far as I remember. I'll use alternate way or tell you if I hit a issue. Best regards -- naruse 2015-03-23 17:08 GMT+09:00 Dagobert Michelsen : > Hi Naruse, > >> Am 22.03.2015 um 19:56 schrieb NARUSE, Yui : >> >> Thank you for the offer. >> rubyci.org runs chkbuild (https://github.com/akr/chkbuild). >> If you can provide vm or ssh account, I'll setup it. > > Sure, I would need your ssh public key and intended user name ("rubyci"?). > The normal setup has a login host that has direct internet access and a private > network of buildhosts reachable from the login host which can access git, > svn, http etc. on the internet via proxy. Is this sufficient or do you need > outgoing NAT or direct incoming connections to the buildhosts? > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > -- NARUSE, Yui From buildfarm at lists.opencsw.org Tue Mar 24 10:00:00 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Tue, 24 Mar 2015 10:00:00 +0100 Subject: Ruby CI on Solaris In-Reply-To: References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> Message-ID: <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> Hi Naruse, > Am 23.03.2015 um 23:36 schrieb NARUSE, Yui : > > My ssh publickey is https://github.com/nurse.keys > and user name is rubyci. > network is also sufficient as far as I remember. > I'll use alternate way or tell you if I hit a issue. You should be able to login now with ssh rubyci at login.opencsw.org Please take a look at /etc/SETUP, just let me know if you need anything. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Tue Mar 24 23:01:06 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Tue, 24 Mar 2015 23:01:06 +0100 Subject: gnustep-base install Message-ID: <5511DEA2.6000502@opencsw.org> Hi, I have finally the first package of gnustep-base for solaris 10 sparcn and intel! (solaris 9 almost works too, but it needs newer libicu, 99% done, but new libffi, which needs a newer gcc...) could you install them on unstable10s and unstable10x? So I will test it by going to the next package in the chain. Thanks. Riccardo From buildfarm at lists.opencsw.org Wed Mar 25 10:35:23 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Wed, 25 Mar 2015 10:35:23 +0100 Subject: gnustep-base install In-Reply-To: <5511DEA2.6000502@opencsw.org> References: <5511DEA2.6000502@opencsw.org> Message-ID: <3EC28325-469C-4BCE-91DF-27D3A9E5B15A@opencsw.org> Hi Riccardo, > Am 24.03.2015 um 23:01 schrieb Riccardo Mottola via buildfarm : > > I have finally the first package of gnustep-base for solaris 10 sparcn and intel! > (solaris 9 almost works too, but it needs newer libicu, 99% done, but new libffi, which needs a newer gcc...) > > could you install them on unstable10s and unstable10x? So I will test it by going to the next package in the chain. Sure, done. Can you please write the package names next time? Otherwise I may install not the packages you expected :-) Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Wed Mar 25 13:29:45 2015 From: buildfarm at lists.opencsw.org (NARUSE, Yui via buildfarm) Date: Wed, 25 Mar 2015 21:29:45 +0900 Subject: Ruby CI on Solaris In-Reply-To: <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> Message-ID: Hi Dago, Thanks, I can login the machine and build ruby. I'll setup CI. Thank you for providing CI environment. It helps ruby stability on Solaris like r50089 ;-) Best regards 2015-03-24 18:00 GMT+09:00 Dagobert Michelsen : > Hi Naruse, > >> Am 23.03.2015 um 23:36 schrieb NARUSE, Yui : >> >> My ssh publickey is https://github.com/nurse.keys >> and user name is rubyci. >> network is also sufficient as far as I remember. >> I'll use alternate way or tell you if I hit a issue. > > You should be able to login now with > ssh rubyci at login.opencsw.org > > Please take a look at /etc/SETUP, just let me know if you need anything. > > > Best regards > > -- Dago > > -- > "You don't become great by trying to be great, you become great by wanting to do something, > and then doing it so hard that you become great in the process." - xkcd #896 > -- NARUSE, Yui From buildfarm at lists.opencsw.org Fri Mar 27 16:45:46 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Fri, 27 Mar 2015 16:45:46 +0100 Subject: Fwd: OpenCSW catalog update report In-Reply-To: <3lD5pj4bzczGd@mail.opencsw.org> References: <3lD5pj4bzczGd@mail.opencsw.org> Message-ID: <55157B2A.7060304@opencsw.org> Hi, May you kindly install these packages on unstable10x and unstable10s ? Thank you, Riccardo -------- Original Message -------- Subject: OpenCSW catalog update report Date: Fri, 27 Mar 2015 15:55:57 +0100 (CET) From: Catalog update notifier To: rmottola at opencsw.org Catalog update report for rmottola at opencsw.org Catalog URL: http://mirror.opencsw.org/opencsw/ New packages: * gnustep_gui-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz In catalogs: - unstable: sparc (5.10, 5.11) * gnustep_gui-0.24.0,REV=2015.03.26-SunOS5.10-i386-CSW.pkg.gz In catalogs: - unstable: i386 (5.10, 5.11) -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Fri Mar 27 16:53:18 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Fri, 27 Mar 2015 16:53:18 +0100 Subject: OpenCSW catalog update report In-Reply-To: <55157B2A.7060304@opencsw.org> References: <3lD5pj4bzczGd@mail.opencsw.org> <55157B2A.7060304@opencsw.org> Message-ID: <718930AD-4327-4AFD-B676-B6B088642555@opencsw.org> Hi Riccardo, > Am 27.03.2015 um 16:45 schrieb Riccardo Mottola via buildfarm : > > May you kindly install these packages on unstable10x and unstable10s ? Sure, done. Best regards ? Dago PS: I can?t reproduce the issue on Solaris 9. If it happes again please let me know and give me the hostname, pwd and command that hangs and I become you and retry. > > Thank you, > > Riccardo > > > -------- Original Message -------- > Subject: OpenCSW catalog update report > Date: Fri, 27 Mar 2015 15:55:57 +0100 (CET) > From: Catalog update notifier > To: rmottola at opencsw.org > > Catalog update report for rmottola at opencsw.org > Catalog URL: http://mirror.opencsw.org/opencsw/ > > New packages: > * gnustep_gui-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz > In catalogs: > - unstable: sparc (5.10, 5.11) > > * gnustep_gui-0.24.0,REV=2015.03.26-SunOS5.10-i386-CSW.pkg.gz > In catalogs: > - unstable: i386 (5.10, 5.11) > > > -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Sat Mar 28 15:54:04 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Sat, 28 Mar 2015 15:54:04 +0100 Subject: install new gnustep-back packages Message-ID: <5516C08C.1020904@opencsw.org> Hi, please install gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-i386-CSW.pkg.gz gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz on unstable10s and unstable10x A rebuild will follow when the libpng situation is clarified. Riccardo From buildfarm at lists.opencsw.org Sat Mar 28 15:56:15 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Sat, 28 Mar 2015 15:56:15 +0100 Subject: hang when building packages on unstable9s Message-ID: <5516C10F.5020300@opencsw.org> Hi, I wrote Dago about it, but since yesterday I tried with a new package, does anybody of you experience hang when running "mgar package" on unstable9s ? For me it hangs after the packaging is complete.. and it happens for about any package I try. Just taking it public, in case Dago has news and it is not a problem only on my account. Riccardo From buildfarm at lists.opencsw.org Sat Mar 28 22:23:16 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Sat, 28 Mar 2015 22:23:16 +0100 Subject: install new gnustep-back packages In-Reply-To: <5516C08C.1020904@opencsw.org> References: <5516C08C.1020904@opencsw.org> Message-ID: Hi Riccardo, > Am 28.03.2015 um 15:54 schrieb Riccardo Mottola via buildfarm : > > please install > gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-i386-CSW.pkg.gz > gnustep_back-0.24.0,REV=2015.03.27-SunOS5.10-sparc-CSW.pkg.gz > > on unstable10s and unstable10x > > A rebuild will follow when the libpng situation is clarified. I can?t see gnustep_back in the unstable catalog yet. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Sun Mar 29 00:33:16 2015 From: buildfarm at lists.opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?= via buildfarm) Date: Sat, 28 Mar 2015 23:33:16 +0000 Subject: hang when building packages on unstable9s In-Reply-To: <5516C10F.5020300@opencsw.org> References: <5516C10F.5020300@opencsw.org> Message-ID: I also see reproducible hangs on unstable9s, e.g. when running mgar makepatch. "git diff" would never return. 2015-03-28 14:56 GMT+00:00 Riccardo Mottola via buildfarm < buildfarm at lists.opencsw.org>: > Hi, > > I wrote Dago about it, but since yesterday I tried with a new package, > does anybody of you experience hang when running "mgar package" on > unstable9s ? > > For me it hangs after the packaging is complete.. and it happens for about > any package I try. > > Just taking it public, in case Dago has news and it is not a problem only > on my account. > > Riccardo > -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Sun Mar 29 13:26:20 2015 From: buildfarm at lists.opencsw.org (=?windows-1252?Q?Jan_Holzh=FCter?= via buildfarm) Date: Sun, 29 Mar 2015 13:26:20 +0200 Subject: hang when building packages on unstable9s In-Reply-To: <5516C10F.5020300@opencsw.org> References: <5516C10F.5020300@opencsw.org> Message-ID: <5517E15C.4020201@opencsw.org> Am 28.03.15 um 15:56 schrieb Riccardo Mottola via buildfarm: > Hi, > > I wrote Dago about it, but since yesterday I tried with a new package, > does anybody of you experience hang when running "mgar package" on > unstable9s ? > > For me it hangs after the packaging is complete.. and it happens for > about any package I try. > > Just taking it public, in case Dago has news and it is not a problem > only on my account. rebootet unstable9s. Please try if the helps. If not I will investigate on Monday. Greetings Jan From buildfarm at lists.opencsw.org Sun Mar 29 18:50:22 2015 From: buildfarm at lists.opencsw.org (=?UTF-8?Q?Maciej_=28Matchek=29_Blizi=C5=84ski?= via buildfarm) Date: Sun, 29 Mar 2015 17:50:22 +0100 Subject: hang when building packages on unstable9s In-Reply-To: <5517E15C.4020201@opencsw.org> References: <5516C10F.5020300@opencsw.org> <5517E15C.4020201@opencsw.org> Message-ID: 2015-03-29 12:26 GMT+01:00 Jan Holzh?ter : > rebootet unstable9s. Please try if the helps. > If not I will investigate on Monday. > Didn't help unfortunately, the arc build still hangs on the step where git applies patches. Maciej -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildfarm at lists.opencsw.org Sun Mar 29 18:59:38 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Sun, 29 Mar 2015 18:59:38 +0200 Subject: hang when building packages on unstable9s In-Reply-To: <5517E15C.4020201@opencsw.org> Message-ID: <46503cfc83287ea06b92cf6ace77291c@fuchur.local> Hi Jan, On 2015-03-29 13:26:20 +0200 Jan Holzh?ter wrote: > rebootet unstable9s. Please try if the helps. > If not I will investigate on Monday. Unfortunately, it did not work. While doing any package (here a mgar remerge repackage. This is on unstable9s: ## Validating control scripts. ## Packaging complete. mkp: exec( pkgtrans -s /home/rmottola/spool.5.9-sparc /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg CSWpng ) Transferring package instance mkp: exec( gzip -9 -f /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg ) mkp: exec( mv /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg.gz /home/rmottola/pkgs ) mkp: exec( rm -rf /home/rmottola/spool.5.9-sparc/CSWpng ) ^CTraceback (most recent call last): File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in main() File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 150, in main username, password = rest.GetUsernameAndPassword() File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/rest.py", line 566, in GetUsernameAndPassword ret_code, stdout, stderr = shell.ShellCommand(args, allow_error=True) File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", line 45, in ShellCommand close_fds=True) File "/opt/csw/lib/python2.6/subprocess.py", line 623, in __init__ errread, errwrite) File "/opt/csw/lib/python2.6/subprocess.py", line 1130, in _execute_child data = _eintr_retry_call(os.read, errpipe_read, 1048576) File "/opt/csw/lib/python2.6/subprocess.py", line 455, in _eintr_retry_call return func(*args) KeyboardInterrupt gmake: *** [pkgcheck] Error 1 A python problem? From buildfarm at lists.opencsw.org Sun Mar 29 19:03:12 2015 From: buildfarm at lists.opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?= via buildfarm) Date: Sun, 29 Mar 2015 18:03:12 +0100 Subject: hang when building packages on unstable9s In-Reply-To: <46503cfc83287ea06b92cf6ace77291c@fuchur.local> References: <5517E15C.4020201@opencsw.org> <46503cfc83287ea06b92cf6ace77291c@fuchur.local> Message-ID: <20150329170312.GA5394@cotton.home.blizinski.pl> On Sun, Mar 29, 2015 at 06:59:38PM +0200, Riccardo Mottola via buildfarm wrote: > Hi Jan, > > > On 2015-03-29 13:26:20 +0200 Jan Holzh?ter wrote: > > > rebootet unstable9s. Please try if the helps. > > If not I will investigate on Monday. > > Unfortunately, it did not work. While doing any package (here a mgar remerge repackage. > > This is on unstable9s: > > ## Validating control scripts. > ## Packaging complete. > mkp: exec( pkgtrans -s /home/rmottola/spool.5.9-sparc /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg CSWpng ) > Transferring package instance > mkp: exec( gzip -9 -f /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg ) > mkp: exec( mv /tmp/png_stub-1.6.16,REV=2015.03.29-SunOS5.9-all-UNCOMMITTED.pkg.gz /home/rmottola/pkgs ) > mkp: exec( rm -rf /home/rmottola/spool.5.9-sparc/CSWpng ) > > > ^CTraceback (most recent call last): > File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 268, in > main() > File "/home/rmottola/opencsw/.buildsys/v2/gar//bin/../lib/python/checkpkg2.py", line 150, in main > username, password = rest.GetUsernameAndPassword() > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/rest.py", line 566, in GetUsernameAndPassword > ret_code, stdout, stderr = shell.ShellCommand(args, allow_error=True) > File "/home/rmottola/opencsw/.buildsys/v2/gar/lib/python/shell.py", line 45, in ShellCommand > close_fds=True) > File "/opt/csw/lib/python2.6/subprocess.py", line 623, in __init__ > errread, errwrite) > File "/opt/csw/lib/python2.6/subprocess.py", line 1130, in _execute_child > data = _eintr_retry_call(os.read, errpipe_read, 1048576) > File "/opt/csw/lib/python2.6/subprocess.py", line 455, in _eintr_retry_call > return func(*args) > KeyboardInterrupt > gmake: *** [pkgcheck] Error 1 > > > A python problem? I also see an error where "git diff" never completes (also "git apply"), and git isn't writen in python. Maciej From buildfarm at lists.opencsw.org Sun Mar 29 19:44:42 2015 From: buildfarm at lists.opencsw.org (Riccardo Mottola via buildfarm) Date: Sun, 29 Mar 2015 19:44:42 +0200 Subject: hang when building packages on unstable9s In-Reply-To: <20150329170312.GA5394@cotton.home.blizinski.pl> Message-ID: <11656a12396ff75b2079959eac57ab17@fuchur.local> Hi, On 2015-03-29 19:03:12 +0200 Maciej Blizi?ski wrote: > I also see an error where "git diff" never completes (also "git apply"), > and git isn't writen in python. I just tried on unstable9x to remerge/repackage and it hangs there too. So it is not a specific "host problem". How does git behave for you on unstable9x ? Riccardo From buildfarm at lists.opencsw.org Sun Mar 29 20:23:20 2015 From: buildfarm at lists.opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?= via buildfarm) Date: Sun, 29 Mar 2015 19:23:20 +0100 Subject: hang when building packages on unstable9s In-Reply-To: <11656a12396ff75b2079959eac57ab17@fuchur.local> References: <20150329170312.GA5394@cotton.home.blizinski.pl> <11656a12396ff75b2079959eac57ab17@fuchur.local> Message-ID: <20150329182320.GA1688@quince> On Sun, Mar 29, 2015 at 07:44:42PM +0200, Riccardo Mottola wrote: > Hi, > > On 2015-03-29 19:03:12 +0200 Maciej Blizi?ski wrote: > > > I also see an error where "git diff" never completes (also "git apply"), > > and git isn't writen in python. > > I just tried on unstable9x to remerge/repackage and it hangs there too. So it is not a specific "host problem". > > How does git behave for you on unstable9x ? Hangs in unstable9x too. From buildfarm at lists.opencsw.org Sun Mar 29 22:19:58 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Sun, 29 Mar 2015 22:19:58 +0200 Subject: hang when building packages on unstable9s In-Reply-To: <20150329182320.GA1688@quince> References: <20150329170312.GA5394@cotton.home.blizinski.pl> <11656a12396ff75b2079959eac57ab17@fuchur.local> <20150329182320.GA1688@quince> Message-ID: <49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org> Hi folks, > Am 29.03.2015 um 20:23 schrieb Maciej Blizi?ski via buildfarm : > > On Sun, Mar 29, 2015 at 07:44:42PM +0200, Riccardo Mottola wrote: >> Hi, >> >> On 2015-03-29 19:03:12 +0200 Maciej Blizi?ski wrote: >> >>> I also see an error where "git diff" never completes (also "git apply"), >>> and git isn't writen in python. >> >> I just tried on unstable9x to remerge/repackage and it hangs there too. So it is not a specific "host problem". >> >> How does git behave for you on unstable9x ? > > Hangs in unstable9x too. This is very strange as unstable9s uses a loopback filesystem and unstable10s works fine as far as I can tell. The testing I did worked fine, do you have a specific recipe I can run to reproduce the issue? I would like to understand the problem before booting the whole farm. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Sun Mar 29 22:21:52 2015 From: buildfarm at lists.opencsw.org (Maciej =?utf-8?Q?Blizi=C5=84ski?= via buildfarm) Date: Sun, 29 Mar 2015 21:21:52 +0100 Subject: hang when building packages on unstable9s In-Reply-To: <49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org> References: <20150329170312.GA5394@cotton.home.blizinski.pl> <11656a12396ff75b2079959eac57ab17@fuchur.local> <20150329182320.GA1688@quince> <49E2E1F8-3EEE-4CB1-82CA-251ACC0A02AE@opencsw.org> Message-ID: <20150329202152.GA15776@quince> On Sun, Mar 29, 2015 at 10:19:58PM +0200, Dagobert Michelsen wrote: > Hi folks, > > > Am 29.03.2015 um 20:23 schrieb Maciej Blizi?ski via buildfarm : > > > > On Sun, Mar 29, 2015 at 07:44:42PM +0200, Riccardo Mottola wrote: > >> Hi, > >> > >> On 2015-03-29 19:03:12 +0200 Maciej Blizi?ski wrote: > >> > >>> I also see an error where "git diff" never completes (also "git apply"), > >>> and git isn't writen in python. > >> > >> I just tried on unstable9x to remerge/repackage and it hangs there too. So it is not a specific "host problem". > >> > >> How does git behave for you on unstable9x ? > > > > Hangs in unstable9x too. > > This is very strange as unstable9s uses a loopback filesystem and unstable10s works > fine as far as I can tell. The testing I did worked fine, do you have a specific recipe > I can run to reproduce the issue? I would like to understand the problem before booting > the whole farm. I've submitted my changes, try building pkg/arc/trunk. This triggers the problem for me. From buildfarm at lists.opencsw.org Sun Mar 29 23:07:58 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Sun, 29 Mar 2015 23:07:58 +0200 Subject: Ruby CI on Solaris In-Reply-To: References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> Message-ID: <50670133-E974-4ECB-8C3C-86C5F99CD395@opencsw.org> Hi, > Am 25.03.2015 um 13:29 schrieb NARUSE, Yui : > > Thanks, I can login the machine and build ruby. > I'll setup CI. > > Thank you for providing CI environment. > It helps ruby stability on Solaris like r50089 ;-) Glad to hear that! Would you mind not building in /tmp as this is a memory filesystem in Solaris? That means filling it up directly occupies memory. It would be nice if you could reconfigure the build to use a directory inside ~rubyci. BTW, I noticed that you are already building on unstable10x, do you also plan to attach unstable10s and the Solaris 11 machines? Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: From buildfarm at lists.opencsw.org Tue Mar 31 19:38:46 2015 From: buildfarm at lists.opencsw.org (NARUSE, Yui via buildfarm) Date: Wed, 1 Apr 2015 02:38:46 +0900 Subject: Ruby CI on Solaris In-Reply-To: <50670133-E974-4ECB-8C3C-86C5F99CD395@opencsw.org> References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> <50670133-E974-4ECB-8C3C-86C5F99CD395@opencsw.org> Message-ID: Hi, 2015-03-30 6:07 GMT+09:00 Dagobert Michelsen : > Glad to hear that! Would you mind not building in /tmp as this is a memory filesystem > in Solaris? That means filling it up directly occupies memory. It would be nice if > you could reconfigure the build to use a directory inside ~rubyci. Oh, I fixed it. > BTW, I noticed that you are already building on unstable10x, do you also plan to > attach unstable10s and the Solaris 11 machines? I set up 11x and 11s. unstable10s is still under construction but will be available in the future. Best regards -- NARUSE, Yui From buildfarm at lists.opencsw.org Tue Mar 31 23:04:09 2015 From: buildfarm at lists.opencsw.org (Dagobert Michelsen via buildfarm) Date: Tue, 31 Mar 2015 23:04:09 +0200 Subject: Ruby CI on Solaris In-Reply-To: References: <1EA8DF6D-92BB-4C73-87F5-5BA4C3973775@opencsw.org> <9F1E6394-E4BB-4A3E-ACA5-516A377058C1@opencsw.org> <30D9969C-3384-411A-8A58-639AA80EF8BF@opencsw.org> <50670133-E974-4ECB-8C3C-86C5F99CD395@opencsw.org> Message-ID: <1268078D-6141-4337-A32E-89F45119A027@opencsw.org> Hi, > Am 31.03.2015 um 19:38 schrieb NARUSE, Yui : > > 2015-03-30 6:07 GMT+09:00 Dagobert Michelsen : >> BTW, I noticed that you are already building on unstable10x, do you also plan to >> attach unstable10s and the Solaris 11 machines? > > I set up 11x and 11s. > unstable10s is still under construction but will be available in the future. Excellent, regarding this error: checking if make is GNU make... ./configure: line 21753: make: command not found We have the GNU tools compiled in /opt/csw with a g-prefix, so GNU make is gmake. To access the GNU tools with their native names you can use /opt/csw/gnu early in your PATH. If I can assist in portability issues just let me know. I also noticed there is a public_html somewhere deep in your directory. You can access ~rubyci/public_html via https://buildfarm.opencsw.org/~rubyci if needed. Best regards ? Dago -- "You don't become great by trying to be great, you become great by wanting to do something, and then doing it so hard that you become great in the process." - xkcd #896 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2418 bytes Desc: not available URL: