FreeBSD Port: php5-5.2.8
Hello! When I make install a port, I see something like: Build complete. Don't forget to run 'make test'. Do we have a "make test" for the lang/php5 port? ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: $USE_[GU]ID for consistent [GU]ID handling
Hiroki Sato ha scritto: I would like your comments about the attached patch. Not tested, but it's a great idea. BTW, a lot of ports still check for / add www uid/gid, but actually we have such user in base system in all supported releases. Can/Should we drop such checks? -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
llvm-c++ fails to compile/link trivial c++ program
Hi, compiling the attached program test2.c++ using `llvm-c++ -Wall test2.c++` gives: /usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail elf64-amd64-fbsd.c:2166 /usr/bin/ld: BFD 2.15 [FreeBSD] 2004-05-23 assertion fail elf64-amd64-fbsd.c:2166 Is our linker too old or is it a llvm-gcc bug? Or an interference with the base compiler? I'm using the current llvm and llvm-gcc ports on FreeBSD RELENG_7 amd64. BTW: commenting out the '#include ' line fixes the error... Bye/2 --- Michael Reifenberger [EMAIL PROTECTED] http://www.Reifenberger.com ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[PROPOSAL] Ports using SCM repositories as source instead of distfiles
Hi all,
I'm to proposing an enhancement to existing FreeBSD ports system. I
think it'll be great if ports can use SCM (source code management)
repositories like CVS, Subversion, Git, etc. as their sources instead of
distfiles. Following are some of the {dis,}advantages of this approach:
* Anyone interested in tracking the development branch of any project
can do so with installation/deinstallation of the project integrated
in the ports management system. e.g. anyone interested in trying out
GNU Emacs CVS version, can simply use editors/emacs-cvs
(not-implemented atm), which will checkout from the Emacs's CVS
repository and build and install the port with all installed files
recorded in 'plist' of the port. And if anyone wants to uninstall the
Emacs CVS port, {s,}he can simply deinstall it in their preferred
ports/package way.
* ATM, development versions of ports are packaged as snapshots, and
maintainer has to keep updating ports snapshots. And sometimes,
it is not possible for maintainer (due to lack of time and other
issues) to update snapshots timely. So going proposed way can ease the
work for them, and beneficial for users who are interested in latest
bits.
* As far as PR related to such ports are concerned I think one should
directly submit them to the upstream rather than maintainer, unless
that PR has anything to do with its packaging, in which case it should
be submitted to FreeBSD PR system.
* I've not played (or worked) with dynamic packaging lists on FreeBSD,
so I'm not sure if it is possible to properly track all installed
files dynamically, e.g. if a new commit in the upstream causes 3 new
files to be installed, then is it possible for FreeBSD ports
management system to include those 3 files also in the packing list,
in the next installation of the port, hmm...?
BtW, I've implemented a basic proof-of-concept and hacked a port
audio/scrobby (for scrobby[1] application, not submitted to PR system
yet) based on proof-of-concept. The shar can be downloaded from following URL:
http://wahjava.googlepages.com/scm-ports.shar
(md5: 7f8392e7c9e31fe5842279e1730a2051, size: 4710 bytes)
Some existing tools like patchtool also needs to be modified which rely
for the presence of 'distinfo' file in the port directory, which in this
case will never be present.
References:
[1] - http://unkart.ovh.org/scrobby/
Thanks for trying it.
--
Ashish Shukla
pgpQJU0pd4l3k.pgp
Description: PGP signature
Re: FreeBSD Port: php5-5.2.8
Vlad GURDIGA ha scritto: Do we have a "make test" for the lang/php5 port? Yes, but the message is printed by the php makefile, not port makefile. You have to know also that the suhosin patch will make a few tests failing. -- Alex Dupre ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
print/cm-super installation error
Hi list, when I try to install the port print/cm-super from sources I get the following error on several machines: ===> Installing for cm-super-0.3.4 ===> cm-super-0.3.4 depends on executable: mktexlsr - found ===> Generating temporary packing list ===> Checking if print/cm-super already installed /bin/mkdir -p /usr/local/share/fonts/cm-super/afm install -o root -g wheel -m 444 /usr/ports/print/cm-super/work/cm-super/afm/* [.. snip ..] mktexlsr: Updating /usr/local/share/texmf/ls-R... mktexlsr: Done. Adding cm-super-t1.map... *** Error code 1 Obviously there is something wrong with 'updmap-sys'. After commenting out the option '--quiet' in print/cm-super/Makefile (line 37) I get this messages: ===> Installing for cm-super-0.3.4 ===> cm-super-0.3.4 depends on executable: mktexlsr - found ===> Generating temporary packing list ===> Checking if print/cm-super already installed /bin/mkdir -p /usr/local/share/fonts/cm-super/afm install -o root -g wheel -m 444 /usr/ports/print/cm-super/work/cm-super/afm/* [.. snip ..] mktexlsr: Updating /usr/local/share/texmf/ls-R... mktexlsr: Done. Adding cm-super-t1.map... updmap: This is updmap, version 1107552857 updmap: using transcript file `/usr/local/share/texmf-var/web2c/updmap.log' updmap: initial config file is `/usr/local/share/texmf-config/web2c/updmap.cfg' updmap: configuration (updmap.cfg) unchanged. *** Error code 1 Is it a known error or is something misconfigured within my teTeX installation? This is on FreeBSD 8.0-CURRENT from yesterday (i386). Please let me know if you need more information. Thanks in advance, Rainer Hurling ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
* Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote:
> I'm to proposing an enhancement to existing FreeBSD ports system. I
> think it'll be great if ports can use SCM (source code management)
> repositories like CVS, Subversion, Git, etc. as their sources instead of
> distfiles. Following are some of the {dis,}advantages of this approach:
This was discussed before. The summary: this won't work with ports.
Reasons:
- No way to track port updates.
- No way to save distfile. Source will be redownloaded on every rebuild.
- Security. No one can guarantee that malicious source won't be cheched
into the repository at some random time. Fixed versions can be at
least minimally checked and it is possible to not update the port to
new version if it contains problems and/or tell users to not install
version XXX. Impossible for SCM-based ports.
> * ATM, development versions of ports are packaged as snapshots, and
> maintainer has to keep updating ports snapshots. And sometimes,
> it is not possible for maintainer (due to lack of time and other
> issues) to update snapshots timely. So going proposed way can ease the
> work for them, and beneficial for users who are interested in latest
> bits.
- _Much_ more (instead of less) work for maintainer, as he won't be able
to test the port before committing it and will have to deal with all
the problems post factum, under extra pressure.
- Actually, any SCM-based port will become broken rather soon than
later with no ability to prevent it.
The port uses patches? Due to mutable source it'll become broken.
Any structural change upstream? Port broken. Changed build system?
Broken. Changed paths? Broken. Changed depends? Broken. Changed
options/configure args? Broken. Etc.
> * I've not played (or worked) with dynamic packaging lists on FreeBSD,
> so I'm not sure if it is possible to properly track all installed
> files dynamically, e.g. if a new commit in the upstream causes 3 new
> files to be installed, then is it possible for FreeBSD ports
> management system to include those 3 files also in the packing list,
> in the next installation of the port, hmm...?
- Generic dynamic plist generation is impossible unless the port
is installed into some clean chrooted environemnt (for example,
using DESTDIR). The latter, however takes extra space and time,
as you need the whole system and all dependent packages installed
there as well. Simply building the port will become more more like
producing package in a tinderbox:
- unpack the system image
- mount all required filesystems - devfs, ports, distfiles, packages
- install all required packages
- take list of all files in the chroot
- chroot and install the port
- take list of all files in the chroot, compare with previous one and
make a plist out of it
- umount and remove everything
- now you have package and may install in normally
> * As far as PR related to such ports are concerned I think one should
> directly submit them to the upstream rather than maintainer, unless
> that PR has anything to do with its packaging, in which case it should
> be submitted to FreeBSD PR system.
Sometimes it's hard to tell whether the problem is FreeBSD-specific.
Also, upstream is unlikely to have FreeBSD box for testing, so again
it'll be more work for maintainer.
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
[EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: $USE_[GU]ID for consistent [GU]ID handling
On Sun, Dec 7, 2008 at 6:32 PM, Hiroki Sato <[EMAIL PROTECTED]> wrote:
> Hello,
>
> I would like your comments about the attached patch. This is for
> adding USE_UID and USE_GID which allow uid/gid addition on
> installation and the removal on deinstallation. It uses
> ${PORTSDIR}/[GU]IDs for the detail information and can eliminate
> complex shell scripts from individual ports.
>
> For example, if you define
>
> USE_UID= foo
>
> in Makefile, the uid "foo" is added before pre-su-install, and
> removed on deinstallation by using pw(8). If the uid already exists,
> no error occurred. The multiple uids are also allowed.
>
> The attached patch includes an example of rewrite of an existing
> ports (japanese/sj3-server). After investigating ~300 ports in the
> ports tree which add uid/gid I think the attached implementation can
> cover most of the use case, but there may be something I missed.
> Comments are welcome.
Hi Hiroki-san,
There's an open PR with patches for this feature (ports/108514). Could
you have a look and maybe send your comments?
--
Florent Thoumie
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
Dmitry Marakasov writes:
> * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote:
>> I'm to proposing an enhancement to existing FreeBSD ports system. I
>> think it'll be great if ports can use SCM (source code management)
>> repositories like CVS, Subversion, Git, etc. as their sources instead of
>> distfiles. Following are some of the {dis,}advantages of this approach:
> This was discussed before. The summary: this won't work with ports.
> Reasons:
> - No way to track port updates.
> - No way to save distfile. Source will be redownloaded on every rebuild.
> - Security. No one can guarantee that malicious source won't be cheched
> into the repository at some random time. Fixed versions can be at
> least minimally checked and it is possible to not update the port to
> new version if it contains problems and/or tell users to not install
> version XXX. Impossible for SCM-based ports.
>> * ATM, development versions of ports are packaged as snapshots, and
>> maintainer has to keep updating ports snapshots. And sometimes,
>> it is not possible for maintainer (due to lack of time and other
>> issues) to update snapshots timely. So going proposed way can ease the
>> work for them, and beneficial for users who are interested in latest
>> bits.
> - _Much_ more (instead of less) work for maintainer, as he won't be able
> to test the port before committing it and will have to deal with all
> the problems post factum, under extra pressure.
> - Actually, any SCM-based port will become broken rather soon than
> later with no ability to prevent it.
> The port uses patches? Due to mutable source it'll become broken.
> Any structural change upstream? Port broken. Changed build system?
> Broken. Changed paths? Broken. Changed depends? Broken. Changed
> options/configure args? Broken. Etc.
These are the problems already expected with this but the only
suggestion is to have PRs filed if anything breaks during compilation
and investigate what caused it.
>> * I've not played (or worked) with dynamic packaging lists on FreeBSD,
>> so I'm not sure if it is possible to properly track all installed
>> files dynamically, e.g. if a new commit in the upstream causes 3 new
>> files to be installed, then is it possible for FreeBSD ports
>> management system to include those 3 files also in the packing list,
>> in the next installation of the port, hmm...?
> - Generic dynamic plist generation is impossible unless the port
> is installed into some clean chrooted environemnt (for example,
> using DESTDIR). The latter, however takes extra space and time,
> as you need the whole system and all dependent packages installed
> there as well. Simply building the port will become more more like
> producing package in a tinderbox:
> - unpack the system image
> - mount all required filesystems - devfs, ports, distfiles, packages
> - install all required packages
> - take list of all files in the chroot
> - chroot and install the port
> - take list of all files in the chroot, compare with previous one and
> make a plist out of it
> - umount and remove everything
> - now you have package and may install in normally
So, this is the main reason which prevents this :( .
>> * As far as PR related to such ports are concerned I think one should
>> directly submit them to the upstream rather than maintainer, unless
>> that PR has anything to do with its packaging, in which case it should
>> be submitted to FreeBSD PR system.
> Sometimes it's hard to tell whether the problem is FreeBSD-specific.
> Also, upstream is unlikely to have FreeBSD box for testing, so again
> it'll be more work for maintainer.
True, so either have all PRs should be submitted to FreeBSD PR system,
where maintainer will decide if its porting issue or upstream related
issue.
So with all the problems you mentioned above, I guess, I'll take my
proposal back :) .
Thanks for your comments.
--
Ashish Shukla
pgpKRJINBGVl7.pgp
Description: PGP signature
Re: print/cm-super installation error
> [.. snip ..] > mktexlsr: Updating /usr/local/share/texmf/ls-R... > mktexlsr: Done. > Adding cm-super-t1.map... > *** Error code 1 [snip] > Is it a known error or is something misconfigured within my teTeX > installation? FWIW I get this too, also on 8.0-CURRENT. I have not investigated. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <[EMAIL PROTECTED]>' Key retrieval: Send an E-Mail to [EMAIL PROTECTED] E-Mail: [EMAIL PROTECTED] Web: http://www.scode.org pgpwiu75wsry5.pgp Description: PGP signature
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
* Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote: > > - _Much_ more (instead of less) work for maintainer, as he won't be able > > to test the port before committing it and will have to deal with all > > the problems post factum, under extra pressure. > > > - Actually, any SCM-based port will become broken rather soon than > > later with no ability to prevent it. > > The port uses patches? Due to mutable source it'll become broken. > > Any structural change upstream? Port broken. Changed build system? > > Broken. Changed paths? Broken. Changed depends? Broken. Changed > > options/configure args? Broken. Etc. > > These are the problems already expected with this but the only > suggestion is to have PRs filed if anything breaks during compilation > and investigate what caused it. No, those problems will not arise as long as the maintainer tests the port before submitting an update. And the tested port of fixed version will be usable for a long time, unlike SCM-based one which may break every second. > > - Generic dynamic plist generation is impossible unless the port > > is installed into some clean chrooted environemnt (for example, > > using DESTDIR). The latter, however takes extra space and time, > > as you need the whole system and all dependent packages installed > > there as well. > > So, this is the main reason which prevents this :( . I'd say it's the least significant reason. The main reasons are the first three which can be shortened as `the port will be unuseable and sometimes dangerous'. What's for automatic plist generation, I've given it some thought, and it seems like there could be a more or less reliable way after all. I'm currently doing some experiments. > > Sometimes it's hard to tell whether the problem is FreeBSD-specific. > > Also, upstream is unlikely to have FreeBSD box for testing, so again > > it'll be more work for maintainer. > > True, so either have all PRs should be submitted to FreeBSD PR system, > where maintainer will decide if its porting issue or upstream related > issue. My opinion is that if you can diagnose the problem by yourself and come with a proper fix, you should submit it directly upstream. If you think that the problem is serious enough, you can send a port PR as well. If you cannot do it all by yourself though, you should submit a PR, in which case port's maintainer will take care of it. > So with all the problems you mentioned above, I guess, I'll take my > proposal back :) . It's not like your proposal is bad, ports instantaneously tracking upstream changes and not needing maintainers would really be cool, but unfortunately that's practically impossible. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D [EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
Dmitry Marakasov writes:
> * Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote:
>> > - _Much_ more (instead of less) work for maintainer, as he won't be able
>> > to test the port before committing it and will have to deal with all
>> > the problems post factum, under extra pressure.
>>
>> > - Actually, any SCM-based port will become broken rather soon than
>> > later with no ability to prevent it.
>> > The port uses patches? Due to mutable source it'll become broken.
>> > Any structural change upstream? Port broken. Changed build system?
>> > Broken. Changed paths? Broken. Changed depends? Broken. Changed
>> > options/configure args? Broken. Etc.
>>
>> These are the problems already expected with this but the only
>> suggestion is to have PRs filed if anything breaks during compilation
>> and investigate what caused it.
> No, those problems will not arise as long as the maintainer tests the
> port before submitting an update. And the tested port of fixed version
> will be usable for a long time, unlike SCM-based one which may break
> every second.
That is true, but the only problem I see with snapshots is, if
maintainer is busy you can't do anything except maintaining your own local
port version on your box. And anyone using these SCM ports is the one
who knows things can go wrong often, and this is only for development
use.
>> > - Generic dynamic plist generation is impossible unless the port
>> > is installed into some clean chrooted environemnt (for example,
>> > using DESTDIR). The latter, however takes extra space and time,
>> > as you need the whole system and all dependent packages installed
>> > there as well.
>>
>> So, this is the main reason which prevents this :( .
> I'd say it's the least significant reason. The main reasons are the
> first three which can be shortened as `the port will be unuseable and
> sometimes dangerous'.
> What's for automatic plist generation, I've given it some thought,
> and it seems like there could be a more or less reliable way after all.
> I'm currently doing some experiments.
Cool, would like to see the results of your experiments :).
>> > Sometimes it's hard to tell whether the problem is FreeBSD-specific.
>> > Also, upstream is unlikely to have FreeBSD box for testing, so again
>> > it'll be more work for maintainer.
>>
>> True, so either have all PRs should be submitted to FreeBSD PR system,
>> where maintainer will decide if its porting issue or upstream related
>> issue.
> My opinion is that if you can diagnose the problem by yourself and come
> with a proper fix, you should submit it directly upstream. If you think
> that the problem is serious enough, you can send a port PR as well. If
> you cannot do it all by yourself though, you should submit a PR, in
> which case port's maintainer will take care of it.
I agree.
>> So with all the problems you mentioned above, I guess, I'll take my
>> proposal back :) .
> It's not like your proposal is bad, ports instantaneously tracking
> upstream changes and not needing maintainers would really be cool,
> but unfortunately that's practically impossible.
Gentoo GNU/Linux which is a source-based GNU/Linux distribution has this
feature available, what is different in that is, that it uses a separate
root for recording the packing list port and optionally creating a
package.
Maybe we can introduce a hack in ports system like by adding some
variable like 'USES_DYNAMIC_PLIST=yes' in Makefile, which fill let the
port first installed with DESTDIR=/var/tmp/ports/${PORTNAME} and then a
packing list is generated and then finally whole tree is moved to
${PREFIX}, hmm...? What do you say ?
Thanks for you replies.
Ashish Shukla
P.S. do you've any ideas about when a discussion on this subject took
place on this list, hmm..?
pgpYjAw2dFrgM.pgp
Description: PGP signature
Commit request ports/128241
Hi, Would some kind committer please commit: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128241 It's been on the wait queue for more than a month now. Cheers. -- Jonathan Chen <[EMAIL PROTECTED]> -- Do not take life too seriously. You will never get out of it alive. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: [PROPOSAL] Ports using SCM repositories as source instead of distfiles
* Ashish Shukla आशीष शुक्ल ([EMAIL PROTECTED]) wrote:
> > No, those problems will not arise as long as the maintainer tests the
> > port before submitting an update. And the tested port of fixed version
> > will be usable for a long time, unlike SCM-based one which may break
> > every second.
>
> That is true, but the only problem I see with snapshots is, if
> maintainer is busy you can't do anything
There's no other way, unfortunately. There's 2 weeks maintainer timeout
(usually pot gets committed somewhere between 2 weeks and 1 month). But
there was and idea of having multiple maintainers for a port, maybe it
could lower response times.
> except maintaining your own local port version on your box. And
> anyone using these SCM ports is the one who knows things can go
> wrong often, and this is only for development use.
Having bleeding edge software and support for development versions is
not the goal of ports (though I consider ports pretty good in those).
Ports are intended for everyone's use and are expected to be more or
less stable.
> > I'd say it's the least significant reason. The main reasons are the
> > first three which can be shortened as `the port will be unuseable and
> > sometimes dangerous'.
> > What's for automatic plist generation, I've given it some thought,
> > and it seems like there could be a more or less reliable way after all.
> > I'm currently doing some experiments.
>
> Cool, would like to see the results of your experiments :).
I will post something on this list if I manage to get any useful
results.
> > It's not like your proposal is bad, ports instantaneously tracking
> > upstream changes and not needing maintainers would really be cool,
> > but unfortunately that's practically impossible.
>
> Gentoo GNU/Linux which is a source-based GNU/Linux distribution has this
> feature available, what is different in that is, that it uses a separate
> root for recording the packing list port and optionally creating a
> package.
Yes, I've heard of it. Maybe I'll look closely at how it's done.
> Maybe we can introduce a hack in ports system like by adding some
> variable like 'USES_DYNAMIC_PLIST=yes' in Makefile, which fill let the
> port first installed with DESTDIR=/var/tmp/ports/${PORTNAME} and then a
> packing list is generated and then finally whole tree is moved to
> ${PREFIX}, hmm...? What do you say ?
Current DESTDIR implementation uses chroot and obviously requires
complete system installed in DESTDIR. Also installing a port will
install all dependencies in the chroot as well.
There was proposal of another implementation that would behave as
you describe without chroot, but it would require too much work,
as most ports will need hacks so they install software into
${DESTDIR}/${PREFIX}, but the software would think that it's installed
into ${PREFIX}. That is not even always possible, so the idea was
dropped.
Thus, the only reliable way to generate plist with standart tools
is using fat chroot.
My idea however is monitor all filesystem writes by port's make and all
descendant processes. That may be done with monitoring or replacing
syscalls and may be done with LD_PRELOAD or some *trace kernel
facilities. The former is what I'm currently experimenting with.
> P.S. do you've any ideas about when a discussion on this subject took
> place on this list, hmm..?
The last one was, afair, this one:
http://groups.google.com/group/mailing.freebsd.ports/browse_thread/thread/5f6fca39526c0fc4/8987f328fd95f0c5?lnk=gst&q=fetch+from+vcs#8987f328fd95f0c5
there should be more
http://groups.google.com/group/mailing.freebsd.ports/search?group=mailing.freebsd.ports&q=fetch+from+repository
--
Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D
[EMAIL PROTECTED] ..: jabber: [EMAIL PROTECTED]http://www.amdmi3.ru
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Commit request ports/128241
Jonathan Chen píše v st 10. 12. 2008 v 10:37 +1300: > Would some kind committer please commit: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128241 > > It's been on the wait queue for more than a month now. Let me have a look. -- Pav Lucistnik <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> A)bort, R)etry, H)it with big hammer signature.asc Description: Toto je digitálně podepsaná část zprávy
Re: Commit request ports/128241
On Tuesday 09 December 2008 12:37:26 Jonathan Chen wrote: > Hi, > > Would some kind committer please commit: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/128241 > > It's been on the wait queue for more than a month now. > > Cheers. It's already been committed. I'll check why the pr wasn't closed. Beech -- --- Beech Rintoul - FreeBSD Developer - [EMAIL PROTECTED] /"\ ASCII Ribbon Campaign | FreeBSD Since 4.x \ / - NO HTML/RTF in e-mail | http://people.freebsd.org/~beech X - NO Word docs in e-mail | Skype: akbeech / \ - http://www.FreeBSD.org/releases/7.0R/announce.html --- ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
UNLIMITED Liberty Reserve ( LR ) for Sale!!!
UNLIMITED Liberty Reserve ( LR ) for Sale!!! We can provide you UNLIMITED Liberty Reserve for your need at the lowest rate. Just tell us how much LR you need and we will give you the best rate. Email me for more details [EMAIL PROTECTED] Or, chat with us via yahoo messenger ID: ( libertyreserveseller ) ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RFC: $USE_[GU]ID for consistent [GU]ID handling
"Florent Thoumie" <[EMAIL PROTECTED]> wrote in <[EMAIL PROTECTED]>: fl> There's an open PR with patches for this feature (ports/108514). Could fl> you have a look and maybe send your comments? Oh, sorry, I did not notice that. I will read the PR and follow-ups first. Thank you for the pointer. -- | Hiroki SATO pgpI8tRGzvN39.pgp Description: PGP signature
