On Sun, May 11, 2008 12:58 pm, Hasso Tepper wrote:
>> In other words 21.2% of pkg-src packages do not compile correctly as of
>> now.
>
> Quite depressing I have to say :). But situation should be much better
> already. I had some hours to look at reports during last days and I
> reported most of
Hasso Tepper wrote:
The question is what we should do? Due to fact that it's quite widely
used, we should do something, but what? I'd prefer to add fortran into
gcc-4.1 as well. Are there objections?
If you want to add it, I wouldn't object.
Sascha
--
http://yoyodyne.ath.cx
Hasso Tepper wrote:
> Quite a big number of pkgsrc build failures come from fact that we don't
> have Fortran compiler in our gcc-4.1. We have it in gcc-3.4 though, but
> for some reason not in gcc-4.1.
>
> The question is what we should do? Due to fact that it's quite widely
> used, we should do
On Sun, May 11, 2008 at 11:22 AM, Joerg Sonnenberger
<[EMAIL PROTECTED]> wrote:
> On Sun, May 11, 2008 at 10:46:38AM -0700, Freddie Cash wrote:
>> Instead of pulling in another app, consider pulling in libarchive and
>> friends from FreeBSD 6+, and then adding 7z support to that.
>
> You know that
Quite a big number of pkgsrc build failures come from fact that we don't
have Fortran compiler in our gcc-4.1. We have it in gcc-3.4 though, but
for some reason not in gcc-4.1.
The question is what we should do? Due to fact that it's quite widely
used, we should do something, but what? I'd pref
On Sun, May 11, 2008 at 10:46:38AM -0700, Freddie Cash wrote:
> Instead of pulling in another app, consider pulling in libarchive and
> friends from FreeBSD 6+, and then adding 7z support to that.
You know that one of the two reasons I wrote the compression_program
support in libarchive was 7z's l
On Sun, 11 May 2008 10:46:38 -0700
"Freddie Cash" <[EMAIL PROTECTED]> wrote:
> Compression algorithms are something that should be handled via an
> extendle library. And the front-end apps (gzip, bzip2, 7z, etc)
> should just use that library to do the heavy lifting.
>
> Instead of pulling in an
Compression algorithms are something that should be handled via an
extendle library. And the front-end apps (gzip, bzip2, 7z, etc)
should just use that library to do the heavy lifting.
Instead of pulling in another app, consider pulling in libarchive and
friends from FreeBSD 6+, and then adding 7
:So: I was thinking I would copy his files to pkgbox.dragonflybsd.org,
:along with some 1.12 packages tuxillo built, so that they could be
:mirrored from the same place.
:
:Any objections? We could use more binary package mirrors.
:
:Robert - make sure you send the report along to [EMAIL PROTECTE
Robert Luciani wrote:
> As Simon pointed out, many "big" packages never got compiled such as
> OpenOffice and KDE.
KDE should compile fine for. I committed all DragonFly BSD specific
patches to upstream before 3.5.9 release and as result 3.5 branch from
KDE repo compiles fine without any change
On Sun, May 11, 2008 at 05:16:51PM +0200, Robert Luciani wrote:
> Also, packages with special licenses are removed.
Just use the normal upload script and it will reduce the list
automatically according to the NO_BIN_ON_FTP attribute.
Joerg
Justin C. Sherrill wrote:
> On Sun, May 11, 2008 9:58 am, Robert Luciani wrote:
>> Alright, bulk-builds with DragonFly -HEAD and pkg-src -current should be
>> pretty up to date from now on. (Thanks to Justin's wiki page)
>
> So: I was thinking I would copy his files to pkgbox.dragonflybsd.org,
> a
On Sun, May 11, 2008 9:58 am, Robert Luciani wrote:
> Alright, bulk-builds with DragonFly -HEAD and pkg-src -current should be
> pretty up to date from now on. (Thanks to Justin's wiki page)
So: I was thinking I would copy his files to pkgbox.dragonflybsd.org,
along with some 1.12 packages tuxillo
Alright, bulk-builds with DragonFly -HEAD and pkg-src -current should be
pretty up to date from now on. (Thanks to Justin's wiki page)
Building pkg-src from scratch took me about 4 days with no major pauses
since I was near the server most of the time to catch things packages
that didn't want to f
14 matches
Mail list logo
