Re: Problem overriding ports with portshaker.

2019-09-25 Thread Romain Tartière
[resending to ports@ with correct sender address]

On Wed, Sep 25, 2019 at 09:18:36AM -0700, George Hartzell wrote:
> Setting PORTSDIR fixes it for me (different directory, but it works).

Excellent!  I released portshaker 1.0.18 which address your issue and
updated the port accordingly.  Thank you for reporting it.

Regards,
Romain

-- 
Romain Tartière http://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Problem overriding ports with portshaker.

2019-09-24 Thread Romain Tartière
On Mon, Sep 23, 2019 at 11:24:47AM -0700, George Hartzell wrote:
>  > hartzell@corvid:/usr/portshaker/github_hartzell_freebsd-ports/audio % sudo 
> portshaker -M
>  > make: "/usr/share/mk/bsd.port.mk" line 32: Cannot open 
> /usr/ports/Mk/bsd.port.mk
>  > make: 
> "/usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver/Makefile"
>  line 87: Malformed conditional (${ARCH} == "i386")
>  > make: 
> "/usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver/Makefile"
>  line 94: Malformed conditional (${ARCH} == "amd64")
>  > make: "/usr/share/mk/bsd.port.mk" line 32: Cannot open 
> /usr/ports/Mk/bsd.port.mk
>  > make: Fatal errors encountered -- cannot continue[: make: stopped in 
> /usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver: bad 
> number
>  > make: "/usr/share/mk/bsd.port.mk" line 32: Cannot open 
> /usr/ports/Mk/bsd.port.mk
>  > make: 
> "/usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver/Makefile"
>  line 87: Malformed conditional (${ARCH} == "i386")
>  > make: 
> "/usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver/Makefile"
>  line 94: Malformed conditional (${ARCH} == "amd64")
>  > make: "/usr/share/mk/bsd.port.mk" line 32: Cannot open 
> /usr/ports/Mk/bsd.port.mk
>  > make: Fatal errors encountered -- cannot continue[: make: stopped in 
> /usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver: bad 
> number
>  > [: make: stopped in 
> /usr/portshaker/github_hartzell_freebsd-ports/audio/logitechmediaserver: bad 
> number

Can you try setting PORTSDIR to your target ports tree, e.g.

% sudo env PORTSDIR=/usr/local/poudriere/ports/default portshaker -M

My guess is that since Mk/bsd.port.mk was not found, ARCH is not set and
the Makefile is malformed.

If you confirm it fixes your issue, I'll commit something to do this
automagically.  It does not really make sense to not set PORTSDIR to the
target ports tree IMO…

Kind regards,
Romain

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Delete a port

2018-08-04 Thread Romain Tartière
On Sat, Aug 04, 2018 at 12:28:41PM +0200, Matthias Fechner wrote:
> ./rmport: svnlog: not found
> 
> Anyone an idea what is wrong?

Never used this script, but I guess you are hitting line 390:

| $EDITOR svnlog

Any chance $EDITOR is not set?

-- 
Romain Tartière   http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: New port: textproc/elasticsearch6

2018-02-15 Thread Romain Tartière
On Thu, Feb 15, 2018 at 09:49:24AM +0100, Walter Schwarzenfeld wrote:
> No, that's a misunderstood. Let the maintainer for the port (I don't 
> really want the port). It is better one maintainer make all elastisearch
> 
> ports. It was a request on FreeBSD Forum for elasticsearch6. First I 
> updated elasticsearch5 and as I was "in work" I make the PR for
> 
> elasticsearch6. It was committed very quick. But I never wanted to 
> override or overrule a maintainer.

Ooops, ETOOLATE :-)  BTW, assigning maintainership to someone is not a
great idea, and as noted in the previous e-mail, tj@ has not committed
to the ports repository in the last 6 month.

You can request to drop maintainership, but in this case, maybe it
wasn't worth doing a port?

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: New port: textproc/elasticsearch6

2018-02-15 Thread Romain Tartière
Adding concerned people in the loop.

On Wed, Feb 14, 2018 at 07:25:35PM -0500, John W. O'Brien wrote:
> I'm glad to see this in the tree and appreciate the work pi@ and
> w.schwarzenfeld have done.
> 
> I'm puzzled about why tj@, who is AWOL, ended up as maintainer. Could
> somebody help me understand this?
> 
> $ svn log -c 461559 /usr/ports | egrep "^r[0-9]|Submitted"
> r461559 | pi | 2018-02-12 01:49:48 -0500 (Mon, 12 Feb 2018) | 10 lines
> Submitted by:   w.schwarzenf...@utanet.at
> $ svn diff -c 461559 /usr/ports | grep MAINTAINER
> +MAINTAINER=t...@freebsd.org
> 
> Nothing against tj@, by the way.

I guess the submitter of the PR used a previous version of elasticsearch
(textproc/elasticsearch5) as a base and forgot to update the MAINTAINER
line:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225836

Thanks for catching this, I will:
  - Update the port so that it is copied from textproc/elasticsearch5
(in order to preserve history);
  - Assign it to Walter as it should have:

https://www.freebsd.org/doc/en_US.ISO8859-1/books/porters-handbook/book.html#makefile-maintainer

Regards,
Romain

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Mono 5.2 patch and DotNet Core 2 update

2018-01-10 Thread Romain Tartière
On Wed, Jan 10, 2018 at 08:55:45AM -0800, Russell Haley wrote:
> I'm getting size and checksum errors for the file
> dotnet-roslyn-322bd5b_GH0.tar.gz. This shouldn't be an issue: I
> changed the size of the file in distinfo from 22058493 to the actual
> size I received of 22058637 in order to make it build. My expectation
> is that I should then run make checksum to fix the distinfo file
> correctly. I run sudo make checksum and the target goes into an
> infinite loop downloading the file, deciding it doesn't match the
> checksum and then downloading it again. WTH?

Since there are checksums, the ports systems must be checking them when
downloading…  and since the checksum does not match, the download is
assumed to have failed…  I guess you can solve this chicken-and-egg
problem, vy simply removing the existing distinfo file.

The actual files checksums will then be written to distinfo. You can
`svn diff` to confirm only the expected files have been touched ;-)

Regards,
Romain

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Puppet SSL-related problems after updating Ruby

2018-01-06 Thread Romain Tartière
Hello

On Fri, Jan 05, 2018 at 07:01:39PM -0500, Josh Endries wrote:
> I recently updated packages on a 11.0 machine, which upgraded Ruby from
> 2.3.5 to 2.3.6 (I think), and my Puppet install broke. It is logging
> SSL-related issues with this message:
> 
> SSL_read: decryption failed or bad record mac

Please see:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224623

While we do not have a solution for your case yet, be informed that:
  - The rack based puppet master seems to perform well (I am using this
currently);
  - The sysutils/puppetserver / sysutils/puppetserver5 should work OK

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Porting github code to FreeBSD [configure]

2017-10-15 Thread Romain Tartière
On Sun, Oct 15, 2017 at 07:23:49PM +0800, blubee blubeeme wrote:
> trigger happy missed sending the error:
> 
> format=`echo tmp/tag.hpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
> sed -n \
> -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
> tmp/tag.hpp; \
> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
> tmp/tag.hpp
> format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
> sed -n \
> -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
> lib/tag.cpp; \
> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
> lib/tag.cpp
> sed -i 's/SEC_N_("%1%")/"%1%"/' tmp/tag.hpp
> sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
> sed: 1: "tmp/tag.hpp": invalid command code u
> sed: 1: "lib/tag.cpp": extra characters at the end of l command
> 
> You can see the FreeBSD version of sed failing on the commands, If I
> remember correctly this requires gnu sed to work properly.
> 
> How can I set that in my Makefile?

The easiest way could be BINARY_ALIAS introducted a few days ago:
https://svnweb.freebsd.org/ports?view=revision=451772

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-22 Thread Romain Tartière
On Thu, Sep 21, 2017 at 08:22:26AM +0200, Romain Tartière wrote:
> I am currently deploying this on my nodes in case this changes has other
> unexpected consequences.

So, it seems to be OK.  However, I am wondering if patching
devel/rubygem-gettext-setup is the way to go: instead, we can simply
install the .po files where Puppet expects them to be put when using
gems.  That way, puppet would rely on the LOCAL_PATH instead of the
POSIX_PATH here:
https://github.com/puppetlabs/puppet/blob/master/lib/puppet/gettext/config.rb#L4

Thoughts?

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-21 Thread Romain Tartière
On Wed, Sep 20, 2017 at 03:06:52PM +0200, Romain Tartière wrote:
> Unfortunately, changing locales works on my computer …
> [...]
> … but not on the other nodes I manage :-/
> [...]
> I currently fail at locating what is different between these nodes.

Found the culprit yesterday in the train! But Internet access is flaky
here :-/

The problems is in the gettext-setup gem, which detects the available
locales in a wrong way (it search for .po files, and when found, add the
directory name to the valid locales available):
https://github.com/puppetlabs/gettext-setup-gem/blob/master/lib/gettext-setup/gettext_setup.rb#L97-L102

Since we only have .mo files in the searched directory, you guess why
the 'ja' locale was not considered available.

But in fact the problem is deeper: the hunt for .po files happens in
multiple directories, and if such a file is available in any of these
directories, the locale is enabled…  So on my system, it looks like the
file /usr/local/share/locale/ja/gutenprint_ja.po installed by
print/gutenprint white-listed the 'ja' locale, and then
/var/puppet/share/locale/ja/LC_MESSAGES/puppet.mo could be used.

The patched gettext-setup gem is available here:
https://github.com/smortex/puppet5/commit/41ea629eca9112510613d966a8e0639f3cb91da1

I am currently deploying this on my nodes in case this changes has other
unexpected consequences.

Romain

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-20 Thread Romain Tartière
On Wed, Sep 20, 2017 at 09:43:23AM +0200, Romain Tartière wrote:
> I am currently building packages and updating the nodes I manage in
> order to catch any regression, and will commit this in the ports tree
> as soon as I am sure nothing breaks!


Unfortunately, changing locales works on my computer …

-- 8< --
% env LC_ALL=ja_JP.UTF-8 puppet apply -e 'exec { "/usr/bin/true": }'
Notice: コンパイルしましたカタログxxx環境production内 0.12 秒
Notice: /Stage[main]/Main/Exec[/usr/bin/true]/returns: 実行に成功しました。
Notice: カタログが適用されました。 0.04 秒
-- 8< --

… but not on the other nodes I manage :-/

-- 8< --
% env LC_ALL=ja_JP.UTF-8 puppet apply -e 'exec { "/usr/bin/true": }'
Notice: Compiled catalog for xxx in environment production in 0.08 
seconds
Notice: /Stage[main]/Main/Exec[/usr/bin/true]/returns: executed successfully
Notice: Applied catalog in 0.04 seconds
-- 8< --

I currently fail at locating what is different between these nodes.

If somebody spots anything in the ports, thank you for sharring!
https://github.com/smortex/puppet5/tree/master/sysutils/puppet5

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-20 Thread Romain Tartière
On Wed, Sep 20, 2017 at 08:41:16AM +0200, Romain Tartière wrote:
> I'll investigate quickly if it is possible to not use install.rb at all
> (it works well on Debian when installing puppet with `gem install
> puppet` after all).  If it's possible, I'll get rid of install.rb for
> the sake of simplicity, and if not, I'll tweak install.rb to do the
> things we expect it to do.

A fix that addesses the main issues was committed:
https://github.com/smortex/puppet5/commit/bbb3e629dd6ea61e15b44214cfbe297f0233383b

I am currently building packages and updating the nodes I manage in
order to catch any regression, and will commit this in the ports tree as
soon as I am sure nothing breaks!

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-20 Thread Romain Tartière
On Wed, Sep 20, 2017 at 07:46:03AM +0200, Karli Sjöberg wrote:
> Thank you both for the awesome response, two people working on this
> problem are definitely more than zero :)

After further investigation: with the way we install, Puppet thinks it's
running in AIO mode and look for .mo files (binary files generated from
the .po files) but they are not built at any point.  I guess that
puppetlab's AIO packaging system produce them when creating the AIO
packages, but the install.rb script we are using does not.

By using msgfmt, I could manage to build them and have them working with
the ja locale, but install.rb installs a lot of junk, so some cleanup is
required.

I'll investigate quickly if it is possible to not use install.rb at all
(it works well on Debian when installing puppet with `gem install
puppet` after all).  If it's possible, I'll get rid of install.rb for
the sake of simplicity, and if not, I'll tweak install.rb to do the
things we expect it to do.

Romain

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: gettextsetup warnings

2017-09-19 Thread Romain Tartière
Hello!

On Tue, Sep 19, 2017 at 09:09:59AM -0700, Zach wrote:
> On Tue 19.Sep.17 17:28, Karli Sjöberg wrote:
> > Recently I've been noticing hundreds of these messages that SirDice reports 
> > in
> > this thread on ask.puppet.com:
> > https://ask.puppet.com/question/31933/gettextsetup-warnings/
> 
> Indeed, I was looking at this about an hour ago.
> ;/

I am missing the initial context so please forgive me if this is out of
topic.

I guess this problem is partly fixed with the update to 5.2.0, not in
the Ports tree yet (for sysutils/puppet5).  I just found a few more
problems, I will try to address them tomorrow before leaving to
EuroBSDcon.  

There where a few problems:
  - The locales are installed in a weird location
(/usr/local/share/locale would be more usual than
/var/puppet/share/locales);
  - Some files should not be installed into this directory
(/var/puppet/share/locales/config.yaml and
/var/puppet/share/locales/puppet.pot as far as I understand).

However:
  1. The locales directory itself has not the usual layout (e.g. no
 LC_MESSAGES subdirectory);
  2. The installed files are not the good ones (.po instead of .mo)
  3. I was not able to switch language by setting LC_ALL / LANG to
 Japanese (the only locale that is currently installed).

As I said in the beginning I found a few more problems, and points 2 and
3 seems to be fixed with some efforts.  I'll try to integrated this in
the puppet5 port in the GitHub repo!

Regards,
Romain
-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Poudreiere auto-track quarterly ports?

2017-09-05 Thread Romain Tartière
Hi

On Tue, Sep 05, 2017 at 01:50:06AM +, Dan Mahoney wrote:
> Is there an easy way to have poudriere auto-track the latest quarterly 
> ports build tree, without having to manually reset it to a specific 
> branch?
> 
> Poudriere knows how to portsnap the latest ports/head, but not the latest 
> quarterly.

I guess the -B flag of poudriere(8) is designed for this, never used it
though…

Have you tried it?

poudriere -c -m svn -B branches/2017Q3 [other flags]

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: Maintaining mono/.net

2016-07-09 Thread Romain Tartière
Dear all,

I finally could manage to sync my local mess into some "shipable form"
and updated the bsd-sharp github repository with current WIP:

https://github.com/smortex/bsd-sharp

My main issue is devel/newtonsoft-json which fails to build.  I could
not manage to get more time to search for the root cause of the build
failure during the last couple of weeks :-(  If someone has insights or
a workaround, thank you for sharing !

Regards,
Romain

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: LetsEncrypt.sh

2016-03-23 Thread Romain Tartière
On Sat, Mar 19, 2016 at 06:40:13AM -0600, @lbutlr wrote:
> Is anyone using this port successfully?
> 
> It appears to be running here, but is generating some 0 length files:
> 
> total 64
> 8 -rw---  1 443  443  1854 Mar  4 23:38 cert-1457159890.csr
> 0 -rw---  1 443  443 0 Mar  4 23:38 cert-1457159890.pem
> 8 -rw---  1 443  443  1854 Mar  5 05:06 cert-1457179567.csr
> 0 -rw---  1 443  443 0 Mar  5 05:06 cert-1457179567.pem
> 8 -rw---  1 443  443  1854 Mar 12 04:35 cert-1457782552.csr
> 0 -rw---  1 443  443 0 Mar 12 04:35 cert-1457782552.pem
> 8 -rw---  1 443  443  1854 Mar 19 04:15 cert-1458382543.csr
> 0 -rw---  1 443  443 0 Mar 19 04:15 cert-1458382543.pem
> 8 -rw---  1 443  443  3243 Mar  4 23:38 privkey-1457159890.pem
> 8 -rw---  1 443  443  3243 Mar  5 05:06 privkey-1457179567.pem
> 8 -rw---  1 443  443  3247 Mar 12 04:35 privkey-1457782552.pem
> 8 -rw---  1 443  443  3243 Mar 19 04:15 privkey-1458382543.pem
> 
> Or I am missing a step.

I had empty files when the verification process failed (they seems to
not be removed in such a situation).  Your directory should also contain
symlinks without timestamp that point to the actual timestamped files.

What does `letsencrypt.sh -c` tells you (and if you are not using this,
what are you using?)

-- 
Romain Tartière <rom...@freebsd.org>  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


signature.asc
Description: PGP signature


Re: texlive (was: Re: huge distfiles policy)

2012-10-01 Thread Romain Tartière
Hi!

On Mon, Oct 01, 2012 at 01:14:27PM +0400, Boris Samorodov wrote:
 30.09.2012 19:31, Romain Tartière пишет:
  On Sun, Sep 30, 2012 at 12:17:03AM +0200, Baptiste Daroussin wrote:
 
  I CCed both hrs and romain so they can give their opinion and the status of
  their work.
  
  Yes, after 2 months away, I am back :-)
 
 OK, guys, what is the best way to proceed:
 1) either commit the PR with monolithic texlive and live with it for
 some time...
 2) or postpone the PR and wait until Romain finishes his work?
 
 Romain, can you give an estimation of when your ports may be ready to
 be committed?

I setup the mirror yesterday:
http://texlive-distfiles.blogreen.org/

svn is committing the ~2200 ports in the freebsd-texlive repository
right now (a few minutes to go I guess).  However, I have not looked at
updating ports depending on teTeX to make them work using TeX Live
instead…  If the idea is just to provide TeX Live, I would tell that
these ports do the job.  For a drop-in replacement of teTeX, more work
is required.

Romain

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpKCz1PIjdVZ.pgp
Description: PGP signature


Re: huge distfiles policy

2012-09-30 Thread Romain Tartière
Hi!

On Sun, Sep 30, 2012 at 12:17:03AM +0200, Baptiste Daroussin wrote:
 My second concern was discussed when Dominic Fandrey called for testing this
 port: at least 2 people have been working on texlive with different approach:
 hrs and romain.
 
 In particular Romain and I discussed on merging texlive to the ports tree 
 based
 on http://code.google.com/p/freebsd-texlive/ he has been contacted some 
 company
 to mirror the splitted distfiles for us, and was suppose to resumer his work 
 on
 this when back from vacations which should be the case now given that he has
 done some commit last week :D
 
 I CCed both hrs and romain so they can give their opinion and the status of
 their work.

Yes, after 2 months away, I am back :-)

While I was away,
  - I received access to a jail for hosting versionned distfiles;
  - I received a mail from hrs@ where he exposes a migration plan to
TeX Live and asked for comments / suggestions.

I replied to hrs@ and told him I would be happy to help, but have no
feedback yet.

Regarding the mirror of versionned distfiles, I have everything to set
it up I think, and I just have to take some time to hack something that
do the right thing and use it in my ports.  However, since there are
some boring flaws in the updating infrastructure, I postponed this,
thinking that an answer from hrs@ would have lead to working on funnier
things (with a better infrastructure).  While I have no news, I may
however setup the repository, it won't hurt I guess.

Best regards,
Romain
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Creating a port as plugin for multiple other ports

2012-07-11 Thread Romain Tartière
Hi!

On Wed, Jul 11, 2012 at 05:58:23PM -0400, Matthew Pounsett wrote:
 1) create two different ports (icinga-mod_gearman and nagios-mod_gearman).
 2) use options to select which system is being plugged into.

1) allows you to install both plugins simultaneously, which may be
better unless icinga and nagios are mutually exclusive.  You can make
your life easier by setting up a master and a slave port.  The slave
would inherit some aspects of the master one, overriding a few settings
(e.g. groups, installation directory).

More details in the porter handbook:
http://www.freebsd.org/doc/en/books/porters-handbook/makefile-masterdir.html

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: Ruby 1.9 as default

2012-06-05 Thread Romain Tartière
On Tue, Jun 05, 2012 at 02:04:33AM -0700, Stanislav Sedov wrote:
 Actually, the problem I'm trying to debug right now is more weird.
 When I run mono via system(3) from the ruby 1.9 process (I mean,
 exactly system(3), not via some ruby wrapper) twice, it hangs on some
 umtx the second time.  This works all the time.
 
 I'm still trying to track it down in mono, though it's not clear how
 this can happen at all.  Isn't execve(2) used by system(3) is supposed
 to clear everything (mutexes at least)?

Hum... mono hanging... I experience this with Banshee this is why it s
marked IGNORE:
http://www.freshports.org/multimedia/banshee/

I used to see the mono process in the STOP state, but last time I
tried it was in the umtx state.  Requesting a backtrace from mono make
it abort, attaching gdb to it also fails.  The problem happenning after
a random amount of time (a few minutes, a few hours) I have not been
able de localise the source of the problem yet.  If you have
experiencing the same problem but can reproduce it, it's a HUGE step
forward!  Can you please provide me a minimal working example ?  I tried
to jack something but it works as expected :-/

| $ cat foo.cs
| using System;
| 
| public static class Foo {
| public static void Main (string[] args) {
| Console.WriteLine (Hello World);
| }
| }
| $ dmcs foo.cs
| $ /var/www/projects.sigabrt.org/.rvm/bin/ruby --version
| ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-freebsd9.0]
| $ cat foo.rb
| #!/var/www/projects.sigabrt.org/.rvm/bin/ruby
| 
| system(/usr/local/bin/mono foo.exe);
| system(/usr/local/bin/mono foo.exe);
| $ ./foo.rb
| Hello World
| Hello World
| $


-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpiBztCY5gxc.pgp
Description: PGP signature


Re: Ruby 1.9 as default

2012-06-05 Thread Romain Tartière
On Tue, Jun 05, 2012 at 11:42:09AM +0200, Romain Tartière wrote:
 I used to see the mono process in the STOP state
oops: read pause state!

^T:
 load: 0.07  cmd: mono 46160 [pause] 4854.59r 165.68u 18.57s 0% 169264k
ps l 46160:
  UID   PID  PPID CPU PRI NIVSZRSS MWCHAN STAT TT TIME COMMAND
 1001 46160 46082   0  20  0 577332 161036 pause  I+6  3:04,25 mono: 
 banshee (mono)

Romain
-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpxiTQbL7nAA.pgp
Description: PGP signature


Re: Ruby 1.9 as default

2012-06-05 Thread Romain Tartière
On Tue, Jun 05, 2012 at 11:01:12AM -0700, Stanislav Sedov wrote:
 Sounds similar.  Unfortunately, my app is proprietary.  I'll try to
 prepare some smaller test case today.

Thanks!  In the meantime, I am trying to run Banshee with this in
/etc/libmap.conf:

| [/usr/local/bin/mono]
| libthr.so.3   libpthread.so

Since the hang appears randomly, I will let Banshee play music for a
while and see if it still hangs at some point.

Romain

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgp1kgj6zmvNV.pgp
Description: PGP signature


Re: Ruby 1.9 as default

2012-06-05 Thread Romain Tartière
On Tue, Jun 05, 2012 at 11:18:06AM -0700, Stanislav Sedov wrote:
 Why do you need this?  libpthread.so is exactly libthr right now.
meh.  I remembered some threading juggling with libpthread / libthr and
since ldd reported libthr.so I was wondering if the problem was not back
and switching to the other one would give better result.  Didn't though
about checking that everything was a set of symlinks to libthr.  Thanks
for the hint!

Romain

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpn1CLTn0rLo.pgp
Description: PGP signature


Re: TeXLive

2011-10-11 Thread Romain Tartière
Hello!

On Mon, Oct 10, 2011 at 07:23:48AM -0500, Stephen Montgomery-Smith wrote:
 On 10/10/2011 06:44 AM, Eitan Adler wrote:
  Are there any plans on getting these committed to the mainline ports
  tree? I'd be willing to work with you on that.
 
 I agree with Eitan.

I would also be pleased to see TeXLive in the FreeBSD ports (obviously).
There are a few issues to sort out before however:
  - The way TeXLive sources are distributed is not convenient: all
binaries are built and installed from a single sources tarball.
This leads to the big print/texlive-core but really lacks
scalability.  Back in 2008, Hiroki Sato was working on splitting all
this AFAICR.  Hiroki, I added you in Cc, can you please tell us if
you had any progress on this topic?
  - The way TeXLive sources are distributed is not convenient (I feel
like I am repeating myself): TeXLive packages tarballs are updated
'in place' (distfiles filename do not include versioning information
so when a tarball is updated, only it's checksum change).

At some users request a few weeks ago, I created a place where we can
discuss freebsd-texlive.  Since the project is hosted at Google, I took
the simple option and created a Google group called freebsd-texlive:
http://groups.google.com/group/freebsd-texlive

While the general direction of TeXLive on FreeBSD discussion may
continue here, I think that each particular issue should be discussed on
this list so if you are interested in this topic, want to help, or have
any valuable knowledge in TeXLive, fill free to subscribe!

Regards,
Romain

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org


Re: TeXLive

2011-10-10 Thread Romain Tartière
On Sun, Oct 09, 2011 at 09:58:50PM -0500, Stephen Montgomery-Smith wrote:
 Now I have a whole bunch of texlive ports installed under 
 /usr/ports/print.  Am I just supposed to build the ports I need, or is 
 there some grand texlive-build-all port that is in this long list somewhere?

I updated this page:
http://code.google.com/p/freebsd-texlive/wiki/Installing

You should at least install texlive-scheme-minimal but if you don't know
exactly what you need, you may consider texlive-scheme-full ;-)

Regards,
Romain

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpGB3s5Kxjyg.pgp
Description: PGP signature


Re: libgpod

2010-09-30 Thread Romain Tartière
Hi

On Wed, Sep 29, 2010 at 02:21:26PM -0500, Sam Fourman Jr. wrote:
 would anyone happen to have a port patch for the new libgpod
 http://sourceforge.net/projects/gtkpod/files/libgpod/libgpod-0.7.9x/libgpod-0.7.95.tar.gz/download

I was just digging in this: multimedia/banshee can conditionally depend
on it's mono binding which are only available in the 0.7.9x serie.  The
current situation is:
  - I don't track the projects and am not sure about it, but it's likely
0.7.9x are development versions that should lead to 0.8.0 and the
maintainer is maybe not willing to update before that point is
reached.  A workaround may be to create a libgpod-devel port;
  - It has extra dependencies, at least libplist for which no port
already exists (but I did one [1] which I am not satisfied about yet
but my priority is testing Banshee for regressions.

So basically I have a port for libgpod-0.7.95 [2] which probably needs
to be split in 3 parts: the library itselt, the python bindings
(libgpod-python ?) and the mono bindings (libgpod-sharp ?).  Since the
maintainer have told he will give a look for an update next week, he
might be interested by both links and can possibly give some advices
regarding splitting the port ?

Thanks!
Romain

References:
  1. https://vcs.sigabrt.org/svn/hack/ports/trunk/audio/libplist/
  2. https://vcs.sigabrt.org/svn/hack/ports/trunk/audio/libgpod/

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpTd6MVFKyoz.pgp
Description: PGP signature


Re: Distributed Version Control for ports(7) ( was: Re: autoconf update )

2010-09-20 Thread Romain Tartière
On Mon, Sep 20, 2010 at 05:20:39AM -0700, per...@pluto.rain.com wrote:
 SVN [...] is GPL;
nope, it's under Apache License 2.0, see:
http://svn.apache.org/repos/asf/subversion/trunk/LICENSE

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpo43k4CGz1N.pgp
Description: PGP signature


Re: INDEX build failed for 6.x

2010-06-01 Thread Romain Tartière
On Tue, Jun 01, 2010 at 03:51:56PM +, Erwin Lansing wrote:
 make_index: banshee-1.6.0_1,1: no entry for /usr/ports/devel/notify-sharp

I have just committed a fix that is supposed to unbreak INDEX build.

For some unknown reason, the exp-run that was performed to ensure the
mono update would not break anything did not have a verbatim copy of the
FreeBSD ports tree.  As a result, some ports available only in the BSD#
repository which should have been missing (and should have trigger
errors during the exp-run) where found and no error was triggered.

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgp5gu2gc0Fyw.pgp
Description: PGP signature


Re: [HEADS UP] GNOME 2.30.1 merge comming tomorrow.

2010-05-09 Thread Romain Tartière
Hi

On Sun, May 09, 2010 at 11:07:15PM +0200, Koop Mast wrote:
 The GNOME 2.30.1 will hit the tree tomorrow, late in the evening UTC.

Good news :-)

Here is a list of some potential problems reported by portshaker in the
MarcusCom repository:

| graphics/py-clutter: files/patch-clutter_cluttermodule.c changed but the 
port version is still the same.
New patch

| net-im/libpurple:Makefile changed but the port version is still the 
same.
Unconditionally --disable-gevolution

| sysutils/polkit-gnome:   Makefile pkg-plist changed but the port version is 
still the same.
Old dependencies removed

| sysutils/tracker-client: Makefile pkg-plist changed but the port version is 
still the same.
totem-plparser  libpng version bumps

| x11-toolkits/eel:files/patch-eel_eel-background.c changed but the 
port version is still the same.
New patch


Thanks!
Romain

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgp5E7yMyYYNT.pgp
Description: PGP signature


Re: State of gmime (mail/gmime24)

2010-04-15 Thread Romain Tartière
 g_mime_object_shutdown (void);
 
  GMimeObject *g_mime_object_new (GMimeContentType *content_type);
  GMimeObject *g_mime_object_new_type (const char *type, const char *subtype);
 
 
 
 --
 John Prather
 ___
 freebsd-ports@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-ports
 To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org

-- 
Romain Tartière rom...@freebsd.org  http://people.FreeBSD.org/~romain/
pgp: 8234 9A78 E7C0 B807 0B59  80FF BA4D 1D95 5112 336F (ID: 0x5112336F)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgp1tEK3Hqm35.pgp
Description: PGP signature


Re: Updating Moonlight

2010-01-24 Thread Romain Tartière
Hi Jerry

On Fri, Jan 22, 2010 at 07:50:23AM -0500, Jerry wrote:
 There appears to be a version 2 of Moonlight available on the
 http://www.mono-project.com/Moonlight web site. Is there any
 possibility that the port version could be updated? It is currently at
 1.x I believe.

Moonlight 2 depends on mono-2.6 which is unfortunately not in the
FreeBSD ports tree yet. You can however install it from the BSD#
repository [1] and contribute there a port for Moonlight 2.

Thanks,
Romain

References:
  1. http://code.google.com/p/bsd-sharp/wiki/Installing

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpul7qsxvSo6.pgp
Description: PGP signature


FreeBSD port of libtool

2009-05-09 Thread Romain Tartière
Dear devel/libtool maintainer (I added ports@ in CC since their might be
people with the answer there),

While updating FreeBSD ports I maintain, I encountered a dependency on
recent libltdl version: quoting libcanberra-0.12 (which I don't maintain
but a port I maintain depends on) configure.ac:

 dnl Unfortunately, even up to libtool 2.2.6a there is no way to know
 dnl exactly which version of libltdl is present in the system, so we
 dnl just assume that it's a working version as long as we have the
 dnl library and the header files.
 dnl
 dnl As an extra safety device, check for lt_dladvise_init() which is
 dnl only implemented in libtool 2.x, and refine as we go if we have
 dnl refined requirements.

... and configure says:

 checking ltdl.h usability... yes
 checking ltdl.h presence... yes
 checking for ltdl.h... yes
 checking for lt_dladvise_init in -lltdl... no
 configure: error: Unable to find libltdl.

So, I though I had to check the libtool version, thinking I was not
up-to-date with my port or that libcanberra was relying on an API that
had been added to libtool a few time ago.

However, I discovered that while libtool stable version is 2.2.6a,
FreeBSD had 1.5.26.

I could not find any relevant PR nor message in the mailing lists, and
am wondering about why isn't libtool up-to-date.  Is it just because of
a lack of time? Because introduced features are not used and their is no
need to update? Because it would require a big work to update all ports
depending of it? Something else?

I just would like to know how I should consider libtool on FreeBSD. If
taking time to update it is a loss of time or if it would be somewhat
useful.

In advance, thank you for your lights.

Regards,
Romain

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgph7LEw0meQs.pgp
Description: PGP signature


Re: TeXLive

2009-02-20 Thread Romain Tartière
Hi

On Wed, Feb 18, 2009 at 09:06:18PM +0300, Stanislav Sedov wrote:
 Thanks for throughout message about possibilities of
 porting TexLive to FreeBSD. This work is highly
 appeciated!
Thanks

 Personally, I think we should stick with #2 of your plan,
 as going with #3 will bring too many ports (thousands?)
 ports in our tree, which will be a nightmare to handle.
 I don't think we're ready for such a number of new ports
 in the three, even xorg with hundereds of ports slow
 down ports tree utils a lot. Also, I don't think TeX users
 ever want this kind of granularity. After all teTeX was
 only several ports.
Well, as Hiroki Sato is also working on it and has explained how cool
are his ports in the ports@ mailing list, I have just done the easiest
for me to have a TeXLive setup working on my computer while there is no
official TeXLive ports in the FreeBSD ports tree.  In other word, 1577
new ports, and you have to fix any other port depending on *TeX* that
fails by hand.

As it worked quite good (one you have all you want installed), and I
know at least one other person interested in having something --- even
somewhat broken --- *now*, I have just updated the freebsd-texlive
google group repository [1] with latest TeXLive packages,  tinderbuilt
the 1577 ports and created a tag.

If you can't wait for Hiroki's ports, you can merge them in your FreeBSD
ports tree, using portshaker [2] for example.

Regards,
Romain

References:
  1. http://code.google.com/p/freebsd-texlive/source/list
  2. http://bsd-sharp.googlecode.com/svn/branches/portshaker/
-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpG7DUZ1RtEr.pgp
Description: PGP signature


Re: TeXLive

2008-12-25 Thread Romain Tartière
Hi Nikola!

On Wed, Dec 24, 2008 at 11:26:07PM +0100, Nikola Lečić wrote:
 On Wed, 24 Dec 2008 14:10:12 +0100
 Romain Tartière rom...@blogreen.org wrote:
 
 [...] 
 
  1. TeXLive should be very modular
  
  It is then possible to run a  version of XeTeX more recent
  then the one provided with TeXLive (i.e. compile TeXLive
  --without-xetex and depend on a port print/xetex-devel).
 
 [...]
 
  If we consider that ports are build from source, it important to know
  that TeXLive provide a single tarball for all applications binaries
  source code. All the rest (macros, fonts, etc.) is provided as a lot
  of small tarball.  As a consequence, I see #1 as « Split the
  applications », and #2, #3 and #4 as « Split the rest ». But maybe
  the question is more about « Split both ».
  
  For now, I do not intend to make the port that install all binaries a
  meta-port (so no #1).  It is quite huge and complex, include modified
  version of libraries that are statically linked to the binaries, ...
  well, I don't want to spend time on this right now (maybe in the
  future but unsure — However, contributions are welcomed).
 
 (I am the one who wrote #1.) What do you exactly mean by making a
 meta-port for binaries? To make a port for every binary group provided
 in their source tree? Sounds interesting, although what I meant there
 was to use the internal TeXLive build options, such as --without-xetex,
 so it's basically as simple as any of WITH_* options used in thousands
 of existing ports.

Well, my vision of TeXLive may be wrong (remember that I am just a lower
average user of LaTeX), but AFAIK it can be compared to a GNU/Linux
distro. You have TeX (the Kernel), and a set of packages. This set of
package is a choice of the distribution and has been tested extensively,
so installing a distro you are sure to have all pieces working together.

So it's just like installing say Debian GNU/Linux: you switch-on a
time-travelling machine (your software packages are OLD) _but_ you
should not run into trouble with some buggy package.

The counterpart of this is less frequent and bigger updates (Debian 4.0
has been updated 6 times since April 2007) while the FreeBSD ports tree
has been updated ~60 times yesterday (Okay, this does not include system
updates, but I'm speaking about software packages).

So the idea is that TeXLive is just a set of TeX, LaTeX, etc. ;
TeXLive-2008 being this set of packages at a defined version. So if the
ports tree provide these package at that version, it is TeXLive-2008.

We can therefore consider a port for each piece (TeX, XeTeX, etc.) ...
or multiple ports for each piece (AFAICR, you are interested in the
latest XeTeX):

ports
`- print
|- tex
|- tex-texlive
|- xetex
|- xetex-devel
`- xetex-texlive

print/texlive should depend on print/xetex-texlive that provide
TeXLive's version of XeTeX (maybe not the latest, maybe patched), but
you can have the TeXLive port not depend on it but rather the latest
stable or the development version.

Then you, don't really have TeXLive because you have a different version
of XeTeX, but it is somewhat similar, you know what I mean.


So basically, you can apply this example for all the set of applications
that compose TeXLive, and you have many *-texlive ports in you
ports-tree.  A meta-port print/texlive can depend on all of them (with
options for building with non-default packages).

  3. One port per Package, grouping related packages (e.g. foo,
 foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
 Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
+ high granularity;
+ no conflict;
- many ports.
 
 The main thing with TeXLive is that they make releases once a year. My
 opinion is that if we just stick with their releases -- we don't need
 any fine-grained work because such year-long cemented code somehow
 contradicts the idea of FreeBSD's flexible ports. The idea is to
 provide porters a flexible TeXLive base that can be enriched with many
 TeX-related projects that are not included in current TeXLive
 distribution (new and updated LaTeX packages, new versions of TeX
 extensions, etc).

Yes, I totally agree.  But as explained, after a few days of hack for
having TeXLive building (and working), I don't have motivation to split
the binaries port now.  Moreover, the reply of Hiroki Sato on this list
seems to indicate that he has already do that.

So I'm waiting for more info about this work for now.

 Once an initial TeXLive ports structure is committed, I'd like to see
 many porters grabbing parts of their particular areas of interest (or
 creating -devel ports) in order to provide users with versions newer
 than those initially included.
 
 It seems to me that your your proposal #3 supports this approach.
#1 can be combined with #2, #3 and #4, since #1 is about binaries, and
#2, #3, #4 about the rest.

Kind regards,
Romain

-- 
Romain Tartière rom...@blogreen.orghttp

TeXLive

2008-12-24 Thread Romain Tartière
Hi!

There have been numerous mails about adding ports for TeXLive to FreeBSD
[1,2,3,4], unfortunately, nothing is available so far.


Since I really think TeXLive can be a plus for FreeBSD, and because I
use TeXLive on another system, I started another effort to bring it to
the ports tree.  In order to avoid loosing everything if I run out of
time, I created a Google code project for working:

http://code.google.com/p/freebsd-texlive/


Currently, I have all TeXLive binaries compiling from source
(installation is still not perfect though) and quite a precise idea of
how all TeXLive distfiles are organised and how to build FreeBSD ports
from the metadata they enclose (refer to the project's wiki for details,
I am trying to dump all there [5]).


I am now facing the problem of the organisation of the ports to create.
The freebsd-ports archives reveal some interesting points:

1. TeXLive should be very modular

It is then possible to run a  version of XeTeX more recent then
the one provided with TeXLive (i.e. compile TeXLive
--without-xetex and depend on a port print/xetex-devel).


2. TeXLive should be provided as 3-4 packages just like teTeX

It is the way teTeX fits in the FreeBSD ports tree, and TeXLive
is then kind-of a drop-in replacement of teTeX.


3. TeXLive should be provided as ~10 packages

TeXLive is too big to be included as just 3-4 packages, but
splitting everything will create 100's of ports and this will be
a mess. So group all in say 10 ports and it will be a good
compromise.

4. TeXLive should be provided as many many small packages

If I need a package, I don't want to install a set of thousands
of packages to have it: I just want it to be available and
install it.


If we consider that ports are build from source, it important to know
that TeXLive provide a single tarball for all applications binaries
source code. All the rest (macros, fonts, etc.) is provided as a lot of
small tarball.  As a consequence, I see #1 as « Split the applications
», and #2, #3 and #4 as « Split the rest ». But maybe the question is
more about « Split both ».



For now, I do not intend to make the port that install all binaries a
meta-port (so no #1).  It is quite huge and complex, include modified
version of libraries that are statically linked to the binaries, ...
well, I don't want to spend time on this right now (maybe in the future
but unsure — However, contributions are welcomed).



Splitting the rest (#2, #3, #4) is another problem: I am convinced that
is is important to have very low granularity for experienced users: as
an unexperienced TeX user, I would need this, so I guess that anybody
with more skills than I have will think the same.

But having a lot of ports does not necessarily leads to complexity to
beginners, since we can provide meta-ports (just like Xorg).

The big picture: TeXLive provide 5229 packages ...

Well... We can remove more than 1200 packages of binaries for various
platforms, and there is still distfiles related to the TeXLive
installation system that are not needed on FreeBSD.

So basically, we have 4000 distfiles to arrange in ports.

Some of the distfiles are sort of meta-packages, this helps grouping
[5, Categories].  Here are some ports organisation possibilities:

 1. One port per Scheme (10 ports)
   + very few ports;
   - low granularity;
   - each port conflict with others.

 2. One port per Collection (84 ports) + One meta-port per Scheme (10
Meta-ports)
   + no conflict (AFAIK);
   - low granularity.

 3. One port per Package, grouping related packages (e.g. foo,
foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
   + high granularity;
   + no conflict;
   - many ports.

 4. Same as #3 without grouping packages
   + highest granularity;
   - many many ports.


I am in favor of #3 since it allows TeXLive users to install a basic set
that fit their needs (a beginner will install the full scheme
meta-package and have everything, another will choose a minimal scheme,
another will directory install the collections he wants, it is possible
to install a particular package without installing loads of other
packages (say you have a document that use svninfo for example and you
don't have / want collection-latexextra)).

I would however be pleased to read what teTeX/TeXLive [future] users
think about all this.


With kind regards,
Romain


References:
  1. http://lists.freebsd.org/pipermail/freebsd-ports/2007-July/042729.html
  2. http://lists.freebsd.org/pipermail/freebsd-ports/2007-December/045860.html
  3. 
http://lists.freebsd.org/pipermail/freebsd-questions/2007-October/161492.html
  4. 
http://lists.freebsd.org/pipermail/freebsd-advocacy/2003-November/000705.html
  5. http://code.google.com/p/freebsd-texlive/wiki/source

-- 
Romain Tartière rom...@blogreen.orghttp

Re: TeXLive

2008-12-24 Thread Romain Tartière
On Wed, Dec 24, 2008 at 03:21:01PM +0100, Alexey Shuvaev wrote:
 On Wed, Dec 24, 2008 at 02:10:12PM +0100, Romain Tartière wrote:
   3. One port per Package, grouping related packages (e.g. foo,
  foo.source and foo.doc) (/[0-9]{4}/ ports) + meta-port for
  Collections (84 meta-ports) + meta-port for Scheme (10 meta-ports)
 + high granularity;
 + no conflict;
 - many ports.
 As a current teTeX and Xorg user, I like your choice #3.
 As a little note, you can consider sub-splitting Package port into 'meat' part
 (always installed), documentation, examples, etc. (controlled by
 NOPORTDOCS, NOPORTEXAMPLES, etc. variables set by the end user).
 So, it is still one FreeBSD port, but user can choose whether to install
 doc and so on, or not.
Yup! This is already planned this way in bsd.texlive.mk [1].

 Just FYI, debian seems to have chosen something between #1 and #2:
 ~ grep ^texlive allpackages | wc
   93 7757736
I will have a look at it!

Thanks!
Romain

References:
  1. 
http://code.google.com/p/freebsd-texlive/source/browse/trunk/print/texlive/bsd.texlive.mk

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpBAZlugWjPm.pgp
Description: PGP signature


Re: TeXLive

2008-12-24 Thread Romain Tartière
On Thu, Dec 25, 2008 at 12:32:46AM +0900, Hiroki Sato wrote:
 Romain Tartière rom...@blogreen.org wrote
   in 20081224131012.ga8...@blogreen.org:
 
 ro There have been numerous mails about adding ports for TeXLive to FreeBSD
 ro [1,2,3,4], unfortunately, nothing is available so far.
 
  I am the one who were saying the porting was going, and sorry for
  being out of touch with public lists, but the points include not only
  how to import them to our ports tree but also how to integrate them
  with the large number of ports depending TeX.

Well, I don't think of importing TeXLive into the FreeBSD ports tree as
a replacement of teTeX (sorry if that was unclear by what I meant by
drop-in replacement).  I was just thinking about having both in the
ports tree, leaving existing dependencies untouched so that ports that
used to depend on teTeX still depend on it... TeXLive would only be
installed if the user explicitly want TeXLive instead of teTeX.

 The reasons why I could not import them so far are: 1) some remaining
 issues could not be solved until the last month and 2) I need to wait
 for the recent releases being rolled out (much-delayed, as you know).
Err... Well in fact I am not a *TeX* addict... Just an user: I have a
document I started to typeset on Windows with TeXLive and it don't
compile on FreeBSD's teTeX (too old macros I guess)... I just want to
continue this document.  Porting TeXLive is a need, not a goal :-)  SO
no, I was not aware that another release was imminent.

  I have three sort of experimental ports of texlive now; the first is
  a large one, the second is completely-modularized one, and the last
  is a combination of modularized binaries and macro part in a few
  ports with scripts to interface CTAN between the installed macros.
  Considering migration from teTeX, I am planning to commit a part of
  1) just after 7.1R is rolled out, then break them, and finally form
  them into 3).
This sounds cool!

  This integration involves many other ports which depend on TeX, and
  probably the new category named tex.  Also, we are using TeX in our
  documentation infrastructure, so updating the related ports are very
  sensitive.  I think discussion of the organization in the ports tree
  would be a good thing, but please also consider this factor; for
  example, if we are not able to make JadeTeX work as before we need to
  solve the issue first, and we have solve the current situation that
  we have print/tex independent from the old teTeX, which often
  confuses the users.  Anyway, I think major technical issues
  (functionality, compatibility, and so on) are solved now while a
  large change is needed to TeX-related ports in the current ports
  tree.  And I think unless we are sure that these points and
  long-standing complaints which exist from the teTeX era can be
  solved, it should not be imported.
As I just explained, maybe teTeX and TeXLive can co-exist for a while?

  Again, please accept my sincere apologies for your inconvenience of
  missing TeXLive in FreeBSD for a long time.  I do not want to make
  others do duplicated work and conflict with other efforts, but at the
  same time I have no right to bothering your effort.  This is my
  comment at this moment as one of people who are involved.
Maybe having the TeXLive work available publicly may help people who
want TeXLive on FreeBSD to merge it into their ports-tree, give more
visibility to the porting effort, then contributions may arrive...

It's the way we try to handle the BSD# Project [1] that aims to update
all Mono related stuff for FreeBSD.  Individuals who are looking for
bleeding-edge .NET support in FreeBSD can access a ports tree that will
make them happy, even if they now it might be broken.

Kind regards,
Romain

References:
  1. http://code.google.com/p/bsd-sharp/


-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpkavoRc3RRJ.pgp
Description: PGP signature


Maintaining meta-data for patches

2008-12-13 Thread Romain Tartière
Hi!

As a port maintainer, you sometimes have to provide patches in your
ports in order to have a piece of code working.  If you maintain
projects in a team, you will likely have to handle patches that you
wrote along with patches that your co-workers have created.

While this situation is not hard to handle while creating the port, it
is slightly more complex when you want to update the port in question.
You have to deal with each patch and see if it is still relevant, and
since you don't have many info about it, you first have to figure out
what it is supposed to fix.  Generally, you try with / without the patch
and see if you keep it, but don't go any further (search is the bug has
been reported upstream, if solutions have been provided upstream, etc.).


If I consider for example the port of Mono:
http://code.google.com/p/bsd-sharp/source/browse/trunk/lang/mono/files

We have 13 patches I want to review in order to cleanup the port.

I would like to ask random questions like:
  - who made this patch? [*]
  - what is-it supposed to do? [*]
  - has it been reported upstream? where?
  - is it fixed in projects trunk upstream?
  - will it expire at some point (e.g. trunk has been fixed after
foo-1.0.1 was tagged so the patch will be useless as soon as foo is
at version1.0.1)

Questions marked with a * can be answered directly using some version
control system (even if in my case it will not help much since most
patches come from revision 3: «Initial import: copy of the cvs repo.»).


I am so wondering if anyone has ever setup some tools to ease
collaborative ports maintenance?


Thanks!
Romain

-- 
Romain Tartière rom...@blogreen.orghttp://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpw9XsEDqjNk.pgp
Description: PGP signature


Re: On pkg_trans

2008-11-12 Thread Romain Tartière
Hi Ivan.

On Wed, Nov 05, 2008 at 11:49:29PM +0100, Ivan Voras wrote:
 I'll probably have some time in the next few days to work on pkg_trans
 again, but first I'd like to get some input on the whole thing. The last
 time I talked about it I've made code available but I've received no
 feedback.

I have just grabbed the source tarball, and give pkg_trans a try.
Here are a few remarks:

1) As you said, $pkg_trans_save_deleted_packages should be set somewhere
else. Why not /etc/pkg_install.conf?  Another solution would be to rely
on a switch (as -b used by pkg_create(8) for creating backups.

However, the configuration file is surely safer.

2) Semantic remark: when I hear transaction I think commit /
rollback, not end nor undo.  I have not tested using `pkg_trans
-[bade]` with `pkg_{add,delete} -z` directly to build custom
transactions (e.g. update a package from one version to another as part
of a single transaction (or 2, one for removing outdated packages and a
second one of installs new packages versions)), but I guess it would be
something like this (please confirm, I did not have a look to the source
code and could not find informations about doing this in the links you
provided):

| z=`pkg_trans -b`
| pkg_trans -d package-1.0 -z $z
| pkg_delete package-1.0
| pkg_add package-2.0
| pkg_trans -a package-2.0 -z $z
| pkg_trans -e -z $z

Assuming package-2.0 depends on a package that is not available,
installation will fail. Is the only way to rollback this to end the
transaction and undo it?

3) If I pkg_add -r some_package, it will create as many transactions as
packages installed:

| [EMAIL PROTECTED] ~ # pkg_trans -l
| 0 transaction records found.
| [EMAIL PROTECTED] ~ # pkg_add -r most
| Fetching 
http://tinderbox.sigabrt.org/packages/7.0-BSD-sharp-latest-with-gnome/Latest/most.tbz...
 Done.
| Fetching 
http://tinderbox.sigabrt.org/packages/7.0-BSD-sharp-latest-with-gnome/All/png-1.2.32.tbz...
 Done.
| Fetching 
http://tinderbox.sigabrt.org/packages/7.0-BSD-sharp-latest-with-gnome/All/pcre-7.8.tbz...
 Done.
| Fetching 
http://tinderbox.sigabrt.org/packages/7.0-BSD-sharp-latest-with-gnome/All/libiconv-1.11_1.tbz...
 Done.
| Fetching 
http://tinderbox.sigabrt.org/packages/7.0-BSD-sharp-latest-with-gnome/All/libslang2-2.1.4.tbz...
 Done.
| [EMAIL PROTECTED] ~ # pkg_trans -l
| 1 (1 pkgs added) Sun Nov  9 18:01:20 2008
| 2 (1 pkgs added) Sun Nov  9 18:01:21 2008
| 3 (1 pkgs added) Sun Nov  9 18:01:22 2008
| 4 (1 pkgs added) Sun Nov  9 18:01:23 2008
| 5 (1 pkgs added) Sun Nov  9 18:01:24 2008
| 5 transaction records found.
| [EMAIL PROTECTED] ~ # 

Worst, reverting the situation is not as easy as:
| for t in 5 4 3 2 1; do pkg_trans -u -z $t; done

| [EMAIL PROTECTED] ~ # pkg_trans -i -z 5
| Transaction 5, started on Sun Nov  9 18:02:23 2008
| ADD libslang2-2.1.4
| [EMAIL PROTECTED] ~ # pkg_trans -i -z 1
| Transaction 1, started on Sun Nov  9 18:02:29 2008
| ADD most-5.0.0
| [EMAIL PROTECTED] ~ # 

Reading dependencies informations, we can determine the order in which
we have to undo changes:

| [EMAIL PROTECTED] /var/db/pkg # pkg_info -r *-*
| Information for libiconv-1.11_1:
| Depends on:
| 
| Information for libslang2-2.1.4:
| Depends on:
| Dependency: png-1.2.32
| Dependency: pcre-7.8
| Dependency: libiconv-1.11_1
| 
| Information for most-5.0.0:
| Depends on:
| Dependency: png-1.2.32
| Dependency: pcre-7.8
| Dependency: libiconv-1.11_1
| Dependency: libslang2-2.1.4
| 
| Information for pcre-7.8:
| Depends on:
| 
| Information for png-1.2.32:
| Depends on:
| 
| [EMAIL PROTECTED] /var/db/pkg # for t in 1 5 2 3 4; do pkg_trans -u -z$t; done
| [EMAIL PROTECTED] /var/db/pkg # pkg_trans -l
| 0 transaction records found.
| [EMAIL PROTECTED] /var/db/pkg #

Is there any plan regarding this?  I guess the best would be to have a
single transaction.


Kind regards,
Romain

-- 
Romain Tartière [EMAIL PROTECTED]http://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgpazEQGIYMy9.pgp
Description: PGP signature


Re: My interactive version of pkg_add - finished!

2008-10-04 Thread Romain Tartière
Hello

On Fri, Oct 03, 2008 at 10:24:37PM +0300, Marin Atanasov wrote:
 I was wondering how to create a man page for my program.
groff_mdoc(7) is probably what you are looking for... Having a look to
existing man pages is also really useful for seeing how things are done.

With kind regards,
Romain

-- 
Romain Tartière [EMAIL PROTECTED]http://romain.blogreen.org/
pgp: 8DAB A124 0DA4 7024 F82A  E748 D8E9 A33F FF56 FF43 (ID: 0xFF56FF43)
(plain text =non-HTML= PGP/GPG encrypted/signed e-mail much appreciated)


pgp03Rl9F8SCf.pgp
Description: PGP signature