7:36 a.m.
Hi,
It is taking a bit too long for some dependencies to be rebuilt
in rawhide.
Could a compat-libgd be provided please? I am receiving daily
mails about broken deps, already posted to $pkg-owner@ asking
what I could help, but still no response neither problems corrected.
Remi Collet told me it appears there are some FTBFS packages in
the cycle.
I would like to also start working on packaging sagemath 5.10,
but am not providing as much time to work on fedora as I would
want, so also not providing a compat-libgd sample package,
sorry...
Thanks,
Paulo
7:40 a.m.
Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
Hi,
It is taking a bit too long for some dependencies to be rebuilt
in rawhide.
Could a compat-libgd be provided please? I am receiving daily
mails about broken deps, already posted to $pkg-owner@ asking
what I could help, but still no response neither problems corrected.
Remi Collet told me it appears there are some FTBFS packages in
the cycle.
As none of the FBTFS are related to libgd, I don't see any value to have
a compat-libgd package.
Remi.
I would like to also start working on packaging sagemath 5.10,
but am not providing as much time to work on fedora as I would
want, so also not providing a compat-libgd sample package,
sorry...
Thanks,
Paulo
7:52 a.m.
2013/6/26 Remi Collet <Fedora(a)famillecollet.com>:
Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
> Hi,
>
> It is taking a bit too long for some dependencies to be rebuilt
> in rawhide.
>
> Could a compat-libgd be provided please? I am receiving daily
> mails about broken deps, already posted to $pkg-owner@ asking
> what I could help, but still no response neither problems corrected.
> Remi Collet told me it appears there are some FTBFS packages in
> the cycle.
As none of the FBTFS are related to libgd, I don't see any value to have
a compat-libgd package.
I see this failure in root.log:
DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264: Error: Package: gdal-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-pdftex-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-luatex-bin-svn30739.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: You could try using --skip-broken to work around
the problem
s/i686/x86_64/ for the x86_64 build error. This is happening for almost
two weeks I believe.
Sorry for posting to the devel list, but I thought it could be required
to attract the proper attention.
Remi.
>
> I would like to also start working on packaging sagemath 5.10,
> but am not providing as much time to work on fedora as I would
> want, so also not providing a compat-libgd sample package,
> sorry...
Thanks,
Paulo
9:01 a.m.
On Wed, 2013-06-26 at 09:52 -0300, Paulo César Pereira de Andrade wrote:
2013/6/26 Remi Collet <Fedora(a)famillecollet.com>:
> Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
>> Hi,
>>
>> It is taking a bit too long for some dependencies to be rebuilt
>> in rawhide.
>>
>> Could a compat-libgd be provided please? I am receiving daily
>> mails about broken deps, already posted to $pkg-owner@ asking
>> what I could help, but still no response neither problems corrected.
>> Remi Collet told me it appears there are some FTBFS packages in
>> the cycle.
>
> As none of the FBTFS are related to libgd, I don't see any value to have
> a compat-libgd package.
I see this failure in root.log:
DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libgd.so.2
DEBUG util.py:264: Error: Package: gdal-1.9.2-7.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-pdftex-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: Error: Package:
2:texlive-luatex-bin-svn30739.0-24.20130531_r30819.fc20.i686 (build)
DEBUG util.py:264: Requires: libpoppler.so.34
DEBUG util.py:264: You could try using --skip-broken to work around
the problem
s/i686/x86_64/ for the x86_64 build error. This is happening for almost
two weeks I believe.
Sorry for posting to the devel list, but I thought it could be required
to attract the proper attention.
> Remi.
>
>>
>> I would like to also start working on packaging sagemath 5.10,
>> but am not providing as much time to work on fedora as I would
>> want, so also not providing a compat-libgd sample package,
>> sorry...
Thanks,
Paulo
GDAL is currently broken because it needs a rebuild for Poppler, but the
Texlive build is broken, as far as I can see.
Volker
2:37 a.m.
On Wed, 2013-06-26 at 16:01 +0200, Volker Fröhlich wrote:
On Wed, 2013-06-26 at 09:52 -0300, Paulo César Pereira de Andrade
wrote:
> 2013/6/26 Remi Collet <Fedora(a)famillecollet.com>:
> > Le 26/06/2013 14:36, Paulo César Pereira de Andrade a écrit :
> >> Hi,
> >>
> >> It is taking a bit too long for some dependencies to be rebuilt
> >> in rawhide.
> >>
> >> Could a compat-libgd be provided please? I am receiving daily
> >> mails about broken deps, already posted to $pkg-owner@ asking
> >> what I could help, but still no response neither problems corrected.
> >> Remi Collet told me it appears there are some FTBFS packages in
> >> the cycle.
> >
> > As none of the FBTFS are related to libgd, I don't see any value to have
> > a compat-libgd package.
>
> I see this failure in root.log:
>
> DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.i686 (build)
> DEBUG util.py:264: Requires: libgd.so.2
> DEBUG util.py:264: Error: Package: gdal-libs-1.9.2-7.fc20.i686 (build)
> DEBUG util.py:264: Requires: libpoppler.so.34
> DEBUG util.py:264: Error: Package:
> 2:texlive-dvipng-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
> DEBUG util.py:264: Requires: libgd.so.2
> DEBUG util.py:264: Error: Package: gdal-1.9.2-7.fc20.i686 (build)
> DEBUG util.py:264: Requires: libpoppler.so.34
> DEBUG util.py:264: Error: Package:
> 2:texlive-pdftex-bin-svn30088.0-24.20130531_r30819.fc20.i686 (build)
> DEBUG util.py:264: Requires: libpoppler.so.34
> DEBUG util.py:264: Error: Package:
> 2:texlive-luatex-bin-svn30739.0-24.20130531_r30819.fc20.i686 (build)
> DEBUG util.py:264: Requires: libpoppler.so.34
> DEBUG util.py:264: You could try using --skip-broken to work around
> the problem
>
> s/i686/x86_64/ for the x86_64 build error. This is happening for almost
> two weeks I believe.
>
> Sorry for posting to the devel list, but I thought it could be required
> to attract the proper attention.
>
> > Remi.
> >
> >>
> >> I would like to also start working on packaging sagemath 5.10,
> >> but am not providing as much time to work on fedora as I would
> >> want, so also not providing a compat-libgd sample package,
> >> sorry...
>
> Thanks,
> Paulo
GDAL is currently broken because it needs a rebuild for Poppler, but the
Texlive build is broken, as far as I can see.
Volker
Oh, turns out we've got a circular dependency for gdal via postgis and
libspatialite! I hope to fix that today.
Volker
10:31 a.m.
On 06/26/2013 08:01 AM, Volker Fröhlich wrote:
GDAL is currently broken because it needs a rebuild for Poppler, but the
Texlive build is broken, as far as I can see.
texlive has now been rebuilt.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
1:41 a.m.
On 27/06/13 17:31, Orion Poplawski wrote:
On 06/26/2013 08:01 AM, Volker Fröhlich wrote:
>
> GDAL is currently broken because it needs a rebuild for Poppler, but the
> Texlive build is broken, as far as I can see.
texlive has now been rebuilt.
We've got a working GDAL build again.
Volker
1:14 p.m.
2013/6/28 Volker Fröhlich <volker27(a)gmx.at>:
On 27/06/13 17:31, Orion Poplawski wrote:
>
> On 06/26/2013 08:01 AM, Volker Fröhlich wrote:
>>
>>
>> GDAL is currently broken because it needs a rebuild for Poppler, but the
>> Texlive build is broken, as far as I can see.
>
>
> texlive has now been rebuilt.
>
We've got a working GDAL build again.
Almost there, but still cannot generate chroot in mock.
DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libgd.so.2()(64bit)
Also cannot update my rawhide computer (yum loops forever if I
run with --skip-broken), after "yum erase sagemath gnuplot" still
fails:
Error: Package: libsss_sudo-1.10.0-7.fc20.beta1.x86_64 (@rawhide)
Requires: sssd = 1.10.0-7.fc20.beta1
Removing: sssd-1.10.0-7.fc20.beta1.x86_64 (@rawhide)
sssd = 1.10.0-7.fc20.beta1
Updated By: sssd-1.10.0-13.fc20.x86_64 (rawhide)
sssd = 1.10.0-13.fc20
Thanks,
Paulo
5:53 p.m.
On Fri, 2013-06-28 at 15:14 -0300, Paulo César Pereira de Andrade wrote:
2013/6/28 Volker Fröhlich <volker27(a)gmx.at>:
> On 27/06/13 17:31, Orion Poplawski wrote:
>>
>> On 06/26/2013 08:01 AM, Volker Fröhlich wrote:
>>>
>>>
>>> GDAL is currently broken because it needs a rebuild for Poppler, but the
>>> Texlive build is broken, as far as I can see.
>>
>>
>> texlive has now been rebuilt.
>>
>
> We've got a working GDAL build again.
Almost there, but still cannot generate chroot in mock.
DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
DEBUG util.py:264: Requires: libgd.so.2()(64bit)
gnuplot appears to be failing on some sort of texlive-related nonsense:
Execute script `gnuplot.lg'
/usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory
--- error --- improper command line
and then it just appears to loop over the tex4ht usage message forever
and ever. I don't know if the error is in texlive-tex4ht-bin (which
provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is
calling it. (But I don't have time to figure out that crap, so I'm just
going to yum remove gnuplot...)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
http://www.happyassassin.net
10:50 a.m.
2013/6/28 Adam Williamson <awilliam(a)redhat.com>:
> Almost there, but still cannot generate chroot in mock.
>
> DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
> DEBUG util.py:264: Requires: libgd.so.2()(64bit)
gnuplot appears to be failing on some sort of texlive-related nonsense:
Execute script `gnuplot.lg'
/usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory
/usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory
--- error --- improper command line
and then it just appears to loop over the tex4ht usage message forever
and ever. I don't know if the error is in texlive-tex4ht-bin (which
It fork bombs for me, and dies a bit later.
provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is
calling it. (But I don't have time to figure out that crap, so I'm just
going to yum remove gnuplot...)
It is not parsing correctly arguments, and t4ht does not check
arguments:
$ cat /usr/bin/t4ht
#!/bin/sh
$1 $2
$1 $2
$1 $2
tex4ht $2
t4ht $2 $3
on f18 at least, and other distros t4ht is a real binary:
$ t4ht --help
----------------------------
t4ht.c (2012-07-25-19:28 kpathsea)
t4ht --help
--- error ---
--------------------------------------------------------------------
t4ht [-f<dir char>]filename ...
-b ignore -d -m -M for bitmaps
-c... choose named segment in env file
-d... directory for output files (default: current)
-e... location of tex4ht.env
-i debugging info
-g ignore errors in system calls
-m... chmod ... of new output files (reused bitmaps excluded)
-p don't convert pictures (default: convert)
-r replace bitmaps of all glyphs (default: reuse old ones)
-M... chmod ... of all output files
-Q quit, if tex4ht.c had problems
-S... permission for system calls: *-always, filter
-X... content for field %%3 in X scripts
-.... content for field %%2 in . scripts
Example:
t4ht name -d/WWW/temp/ -etex4ht-32.env -m644
--------------------------------------------------------------------
but on rawhide:
$ t4ht --help
<< fork bombs -- do not try >>
Paulo
4:52 p.m.
On 06/29/2013 09:50 AM, Paulo César Pereira de Andrade wrote:
2013/6/28 Adam Williamson <awilliam(a)redhat.com>:
>> Almost there, but still cannot generate chroot in mock.
>>
>> DEBUG util.py:264: Error: Package: gnuplot-4.6.2-2.fc20.x86_64 (build)
>> DEBUG util.py:264: Requires: libgd.so.2()(64bit)
>
> gnuplot appears to be failing on some sort of texlive-related nonsense:
>
> Execute script `gnuplot.lg'
> /usr/bin/t4ht: line 2: -f/gnuplot: No such file or directory
> /usr/bin/t4ht: line 3: -f/gnuplot: No such file or directory
> /usr/bin/t4ht: line 4: -f/gnuplot: No such file or directory
> --- error --- improper command line
>
> and then it just appears to loop over the tex4ht usage message forever
> and ever. I don't know if the error is in texlive-tex4ht-bin (which
It fork bombs for me, and dies a bit later.
> provides /usr/bin/t4ht and /usr/bin/tex4ht), or in how gnuplot is
> calling it. (But I don't have time to figure out that crap, so I'm just
> going to yum remove gnuplot...)
It is not parsing correctly arguments, and t4ht does not check
arguments:
$ cat /usr/bin/t4ht
#!/bin/sh
$1 $2
$1 $2
$1 $2
tex4ht $2
t4ht $2 $3
on f18 at least, and other distros t4ht is a real binary:
$ t4ht --help
----------------------------
t4ht.c (2012-07-25-19:28 kpathsea)
t4ht --help
--- error ---
--------------------------------------------------------------------
t4ht [-f<dir char>]filename ...
-b ignore -d -m -M for bitmaps
-c... choose named segment in env file
-d... directory for output files (default: current)
-e... location of tex4ht.env
-i debugging info
-g ignore errors in system calls
-m... chmod ... of new output files (reused bitmaps excluded)
-p don't convert pictures (default: convert)
-r replace bitmaps of all glyphs (default: reuse old ones)
-M... chmod ... of all output files
-Q quit, if tex4ht.c had problems
-S... permission for system calls: *-always, filter
-X... content for field %%3 in X scripts
-.... content for field %%2 in . scripts
Example:
t4ht name -d/WWW/temp/ -etex4ht-32.env -m644
--------------------------------------------------------------------
but on rawhide:
$ t4ht --help
<< fork bombs -- do not try >>
Paulo
See https://bugzilla.redhat.com/show_bug.cgi?id=959696. Renaming ht to t4ht
was clearly the wrong thing to do. I'm reverting it for now.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
9:34 a.m.
On 07/01/2013 03:52 PM, Orion Poplawski wrote:
See https://bugzilla.redhat.com/show_bug.cgi?id=959696. Renaming ht
to
t4ht was clearly the wrong thing to do. I'm reverting it for now.
texlive and gnuplot now have been rebuilt in rawhide.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA Division FAX: 303-415-9702
3380 Mitchell Lane orion(a)cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
3949
days inactive
3956
days old
11 comments
5 participants
participants (5)
-
Adam Williamson -
Orion Poplawski -
Paulo César Pereira de Andrade -
Remi Collet -
Volker Fröhlich