Re: BuildRequires for texlive stuff for F18 and beyond
Hi Jonathan,
On Fri, Jan 25, 2013 at 12:05:47PM +, Jonathan Underwood wrote:
Dear All,
I have various packages that use (La)TeX to generate documentation at
package build time. In the past, this was usually handled fine with a
BuildRequires: tex(latex) which would bring in enough of a latex
environment to build most things.
With the more fine grained texlive packaging in F18 where tex(latex) is
provided by texlive-collection-latex I am finding that this is insufficient
to build most documents. I see two options in these cases:
1) Add BuildRequires; texlive-collection-latexextra (nb.
texlive-collection-latexrecommended isn't usually sufficient)
2) Generate a list of specific style files using an incantation such as
egrep -R 'usepackage|documentclass|RequirePackage' * | cut -d']' -f2 | cut
-s -d'{' -f 2 | sed s/}/.sty}/g | cut -d'}' -f1 | sort | uniq
and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
If (1) is the preferred route, then I think we should move the virtual
provides for tex(latex) to the texlive-collection-latexextra package. If
(2) is the preferred route we probably need a wiki page and possibly a
packaging guideline explaining this. I personally lean towards the first
option (i.e. moving the tex(latex) provides to
texlive-collection-latexextra package) as it will fix a lot of packages
that currently will fail to build.
What do folks think?
the purpose of tex(*) virtual provides is to make a TeX feature
available regardlessly on TeX distribution available (texlive, miktex,
tetex, etc.) in Fedora. From this POV (1) doesn't seem to be an optimal
solution because:
* your package will be dependend on texlive TeX distro
* you are going to pull in tons of dependencies you don't actually
need
Every TeX package contains virtual provides of:
.tfm, .ttf, .ttc, .pfa, .pfb, .pcf,
.otf, .tex, .cnf, .cfg, .def, .dat,
.ldf, .fd, .enc, .map, .vf, .vpl,
.clo, .bug, .bg2, .cbx, .bbx, .cls, .sty
files if it ships any of file of such an extension. So the process of
my tex file doesn't compile should be addressed like this:
a) figure out which file is missing - (La)TeX is quite explicit about
this in error logs
b) install tex(file.extension) and add the BR to package
c) does it compile now? No = go to a)
d) done
The tex(tex), tex(latex), etc. dependencies are here to cover
minimalistic, most frequently used styles to reduce the amount of
manual work.
Example pdflatex error in log - style missing:
! LaTeX Error: File `upquote.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
solution:
# yum install 'tex(upquote.sty)'
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
-- Running transaction check
--- Package texlive-upquote.noarch 2:svn26059.v1.3-13.fc18 will be
installed
-- Finished Dependency Resolution
Dependencies Resolved
===
Package Arch VersionRepository
Size
===
Installing:
texlive-upquote noarch 2:svn26059.v1.3-13.fc18updates15 k
Transaction Summary
===
Install 1 Package
Total download size: 15 k
Installed size: 1.0 k
Is this ok [y/N]
Another example - font missing:
This is pdfTeX, Version 3.1415926-2.5-1.40.13 (TeX Live 2013/dev)
restricted \write18 enabled.
entering extended mode
(./x.tex
LaTeX2e 2011/06/27
Babel v3.8m and hyphenation patterns for english, dumylang,
nohyphenation, lo
aded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/pslatex/pslatex.sty
kpathsea: Running mktextfm ptmr7t
/usr/share/texlive/texmf/web2c/mktexnam: Could not map source
abbreviation for ptmr7t.
/usr/share/texlive/texmf/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1;
nonstopmode; input ptmr7t
This is METAFONT, Version 2.718281 (TeX Live 2013/dev)
kpathsea: Running mktexmf ptmr7t
! I can't find file `ptmr7t'.
* ...:=ljfour; mag:=1; nonstopmode; input ptmr7t
Please type another input file name
! Emergency stop.
* ...:=ljfour; mag:=1; nonstopmode; input ptmr7t
Transcript written on mfput.log.
Solution:
# yum install 'tex(ptmr7t.tfm)'
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
-- Running transaction check
--- Package texlive-times.noarch 2:svn28614.0-13.fc18 will be
installed
-- Finished Dependency Resolution
Dependencies Resolved
Re: Making rygel build in rawhide
2013/1/26 Nathaniel McCallum nathan...@natemccallum.com Could someone apply this patch to rygel so at least we can get a successful build? http://git.gnome.org/browse/rygel/commit/?h=wip/new-gupnp-dlnaid=118af0f588879703e0dd7d01787897b5893032e0 That won't do. Gupnp-dlna 0.9.4 has to hit rawhide first. Then instead of patching, packaging Rygel 0.17.7 should be enough. Thanks, Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BuildRequires for texlive stuff for F18 and beyond
On Sex, 2013-01-25 at 12:56 -0800, Benjamin De Kosnik wrote:
[...]
With the more fine grained texlive packaging in F18 where
tex(latex) is provided by texlive-collection-latex I am finding
that this is insufficient to build most documents. I see two
options in these cases:
1) Add BuildRequires; texlive-collection-latexextra (nb.
texlive-collection-latexrecommended isn't usually sufficient)
Yes. Do this.
I think, especially now as this dep tuning is going on, that the first
step should be to bring out these big gun dependencies like:
BuildRequires: texlive-collection-latexextra
And get stuff working quickly.
After the dust has settled with the transition and deps are even
slightly modularized (from the old latex), then maybe at a future
date the Deps can be investigated with more granularity, and
the texlive-collections can be optimized.
For
/usr/share/doc/VirtualBox-4.2.6/UserManual.pdf
/usr/share/doc/VirtualBox-4.2.6/UserManual_fr_FR.pdf
I need add
%if 0%{?fedora} = 18
BuildRequires: doxygen-latex
BuildRequires: texlive-collection-fontsrecommended
BuildRequires: texlive-ec
BuildRequires: texlive-ucs
BuildRequires: texlive-tabulary
BuildRequires: texlive-fancybox
%endif
texlive-collection-latexextra seems is not required
Regards,
--
Sérgio M. B.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le samedi 26 janvier 2013 à 06:21 +, Matthew Garrett a écrit : On Sat, Jan 26, 2013 at 02:16:29AM +0100, Michael Scherer wrote: Well, slightly bit longer is around 2 to 3h vs 2 to 3 minutes. And I already did version upgrade taking 6 to 8h due to slow internet or slow hard drives, that's IMHO a pretty significant downtime. fedup does all network activity before reboot, so presumably you're talking about some upgrade system other than the currently supported one? You are right, the 6 to 8h is indeed unrelated, this was on a very old computer, not using fedup, and this was for the download + install part, just to give a order of magnitude ( heck, i should really refrain from using evo during the night ) And for the 2 to 3h, I didn't look at the details, it was in the LUG meeting and the time between I gave the instruction and the time the person came back to me. While I think the exact time is not important, let me do a test to have more precise data, so my bad memories do not muddle the discussion ( as people around me say depend, maybe 1h, maybe more when asked about fedup ). -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BuildRequires for texlive stuff for F18 and beyond
2013/1/26 Sérgio Basto ser...@serjux.com:
On Sex, 2013-01-25 at 12:56 -0800, Benjamin De Kosnik wrote:
[...]
With the more fine grained texlive packaging in F18 where
tex(latex) is provided by texlive-collection-latex I am finding
that this is insufficient to build most documents. I see two
options in these cases:
1) Add BuildRequires; texlive-collection-latexextra (nb.
texlive-collection-latexrecommended isn't usually sufficient)
Yes. Do this.
I did split texlive some time ago for Mandriva, and to avoid
dependency problems, what I did was to make the default
install require texlive-scheme-medium, texlive-scheme-xml
texlive-collection-latexextra and texlive-tlpkg.
There is significantly complex logic in the script to translate
from the texlive metadata to specs, but in the end there were
no dependency problems, other then from time to time people
not happy with installing way more packages than required.
The script with a lot of quirks and logic to provides for
tetex (no longer used in Mandriva), etc, is:
http://svn.mandriva.com/cgi-bin/viewvc.cgi/packages/cooker/texlive-tlpkg/current/SOURCES/tlpobj2spec.pl
If only building info docs, the texinfo package was modified
to install minimal dependencies, that is, it has a
requires to texlive-collection-texinfo
I think, especially now as this dep tuning is going on, that the first
step should be to bring out these big gun dependencies like:
BuildRequires: texlive-collection-latexextra
And get stuff working quickly.
After the dust has settled with the transition and deps are even
slightly modularized (from the old latex), then maybe at a future
date the Deps can be investigated with more granularity, and
the texlive-collections can be optimized.
For
/usr/share/doc/VirtualBox-4.2.6/UserManual.pdf
/usr/share/doc/VirtualBox-4.2.6/UserManual_fr_FR.pdf
I need add
%if 0%{?fedora} = 18
BuildRequires: doxygen-latex
BuildRequires: texlive-collection-fontsrecommended
BuildRequires: texlive-ec
BuildRequires: texlive-ucs
BuildRequires: texlive-tabulary
BuildRequires: texlive-fancybox
%endif
texlive-collection-latexextra seems is not required
Not for your specific case :-) A generic solution needs it.
I believe upstream texlive should be made aware of a few
texlive-foo that should be in the base texlive-collection-latex,
becase if I recall correctly, only 2 or 3 are commonly used,
but I am just suggesting something that was in my todo...
Regards,
--
Sérgio M. B.
Paulo
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
On Qua, 2013-01-16 at 15:36 +0100, Jakub Jelinek wrote: On Wed, Jan 16, 2013 at 02:26:00PM +0100, Jan Kratochvil wrote: On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. That would be great, I have not found any official request for it, there was only short -g3 discussion in: Summary/Minutes from today's FESCo Meeting (2012-06-18) http://lists.fedoraproject.org/pipermail/devel/2012-June/168884.html The new -g3 format by Jakub Jelinek has only very small debug info size increase requirement (FIXME: missing numbers here). The tests performed on average meant that all or most of the space savings thanks to dwz were consumed again by the .debug_macro addition (+ .debug_str growth), which is why I've given up on the request to use -g3 in RPM_OPT_FLAGS by default. What is state of this macro , to have -g3 we need update what ? rpm ? rpmbuild ? -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Shall we modify '-g' to '-g3' to have gcc save the macro info?
On Sáb, 2013-01-26 at 13:13 +, Sérgio Basto wrote: On Qua, 2013-01-16 at 15:36 +0100, Jakub Jelinek wrote: On Wed, Jan 16, 2013 at 02:26:00PM +0100, Jan Kratochvil wrote: On Wed, 16 Jan 2013 04:12:29 +0100, xning wrote: Shall we should modify '-g' to '-g3' to have gcc save the macro info? So when we install *-debuginfo packages, we can look up a macro definition, just like we can look up a function definition. That would be great, I have not found any official request for it, there was only short -g3 discussion in: Summary/Minutes from today's FESCo Meeting (2012-06-18) http://lists.fedoraproject.org/pipermail/devel/2012-June/168884.html The new -g3 format by Jakub Jelinek has only very small debug info size increase requirement (FIXME: missing numbers here). The tests performed on average meant that all or most of the space savings thanks to dwz were consumed again by the .debug_macro addition (+ .debug_str growth), which is why I've given up on the request to use -g3 in RPM_OPT_FLAGS by default. What is state of this macro , to have -g3 we need update what ? rpm ? rpmbuild ? we have already gcc-4.8 in rawhide mirrors gcc-4.8.0-0.6.fc19.src.rpm 24-Jan-2013 12:36 75M RPM Package -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130125 changes
Kevin Fenzi wrote, at 01/26/2013 02:34 PM +9:00: Another week, another broken stuff in rawhide... ... snip ... After harfbuzz is fixed, someone should go through and rebuild all those things blocked on it. ;) kevin I fixed harfbuzz build. harfbuzz-0.9.12-3.fc19 got built successfully, which should appear on F-19 buildroot soon. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130125 changes
On Sat, Jan 26, 2013 at 23:36:53 +0900, Mamoru TASAKA mtas...@fedoraproject.org wrote: I fixed harfbuzz build. harfbuzz-0.9.12-3.fc19 got built successfully, which should appear on F-19 buildroot soon. Thanks. wfut has now been rebuilt. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
On Fri, Jan 25, 2013 at 03:35:58PM -0700, Orion Poplawski wrote: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Also breaks boost in the buildroot: http://koji.fedoraproject.org/koji/getfile?taskID=4904621name=root.log Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
On Sat, Jan 26, 2013 at 3:51 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Jan 25, 2013 at 03:35:58PM -0700, Orion Poplawski wrote: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Also breaks boost in the buildroot: http://koji.fedoraproject.org/koji/getfile?taskID=4904621name=root.log I've just rebuilt boost, just waiting for it to land in the repo so I can test whether the boost rebuild fixes it. koji wait-repo f19-build --build=boost-1.50.0-7.fc19; Peter Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 24, 2013, at 10:42 PM, Matthew Garrett mj...@srcf.ucam.org wrote: Well, that's the problem. Most of our users (including many of the professional sysadmins) are *not* able to make a fully informed choice about whether an online upgrade will ensure that they're no longer running any code with known security issues. That's not a criticism of them - it's just a much harder problem than almost everyone realises. My Scottish co-author and dear friend referred to such cases as giving users razor blades, and telling them to go play on the freeway. After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes). Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 25, 2013, at 9:20 PM, Sam Varshavchik mr...@courier-mta.com wrote: William Brown writes: In the future, hopefully once btrfs is a bit more mature, perhaps it could be considered to make a new writable snapshot subvolume of the system, and the use yum prefix to update the new subvolume. When you reboot, the new subvolume can become the new root. a) Currently running system files aren't affected. b) All upgrades are done online c) the update would merely be a switching of the root device on next reboot d) you could even roll-back by remounting the old root subvolume as the root fs. Now, what's not clear to me – what exactly happens if, say, at the same time I'm browsing the web at the same time, watching videos. That generates write activity, changes to the disk, so what happens to all other disk activity while the upgrade takes place. Disk contention, and things may be sluggish. Chances are your videos won't stutter, but I guess that depends on the video bit rate, effectiveness of disk and file system read ahead, and application buffering all are. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BuildRequires for texlive stuff for F18 and beyond
Hi Jonathan,
On Fri, Jan 25, 2013 at 12:05:47PM +, Jonathan Underwood wrote:
Dear All,
I have various packages that use (La)TeX to generate documentation at
package build time. In the past, this was usually handled fine with a
BuildRequires: tex(latex) which would bring in enough of a latex
environment to build most things.
With the more fine grained texlive packaging in F18 where tex(latex) is
provided by texlive-collection-latex I am finding that this is insufficient
to build most documents. I see two options in these cases:
1) Add BuildRequires; texlive-collection-latexextra (nb.
texlive-collection-latexrecommended isn't usually sufficient)
2) Generate a list of specific style files using an incantation such as
egrep -R 'usepackage|documentclass|RequirePackage' * | cut -d']' -f2 | cut
-s -d'{' -f 2 | sed s/}/.sty}/g | cut -d'}' -f1 | sort | uniq
and turn this into a list of specific BuildRequires: tex(foo.sty) lines.
If (1) is the preferred route, then I think we should move the virtual
provides for tex(latex) to the texlive-collection-latexextra package. If
(2) is the preferred route we probably need a wiki page and possibly a
packaging guideline explaining this. I personally lean towards the first
option (i.e. moving the tex(latex) provides to
texlive-collection-latexextra package) as it will fix a lot of packages
that currently will fail to build.
What do folks think?
the purpose of tex(*) virtual provides is to make a TeX feature
available regardlessly on TeX distribution available (texlive, miktex,
tetex, etc.) in Fedora. From this POV (1) doesn't seem to be an
optimal
solution because:
* your package will be dependend on texlive TeX distro
* you are going to pull in tons of dependencies you don't actually
need
Every TeX package contains virtual provides of:
.tfm, .ttf, .ttc, .pfa, .pfb, .pcf,
.otf, .tex, .cnf, .cfg, .def, .dat,
.ldf, .fd, .enc, .map, .vf, .vpl,
.clo, .bug, .bg2, .cbx, .bbx, .cls, .sty
files if it ships any of file of such an extension. So the process of
my tex file doesn't compile should be addressed like this:
a) figure out which file is missing - (La)TeX is quite explicit about
this in error logs
b) install tex(file.extension) and add the BR to package
c) does it compile now? No = go to a)
d) done
The tex(tex), tex(latex), etc. dependencies are here to cover
minimalistic, most frequently used styles to reduce the amount of
manual work.
Example pdflatex error in log - style missing:
! LaTeX Error: File `upquote.sty' not found.
Type X to quit or RETURN to proceed,
or enter new name. (Default extension: sty)
solution:
# yum install 'tex(upquote.sty)'
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
-- Running transaction check
--- Package texlive-upquote.noarch 2:svn26059.v1.3-13.fc18 will be
installed
-- Finished Dependency Resolution
Dependencies Resolved
===
Package Arch VersionRepository
Size
===
Installing:
texlive-upquote noarch 2:svn26059.v1.3-13.fc18updates15 k
Transaction Summary
===
Install 1 Package
Total download size: 15 k
Installed size: 1.0 k
Is this ok [y/N]
Another example - font missing:
This is pdfTeX, Version 3.1415926-2.5-1.40.13 (TeX Live 2013/dev)
restricted \write18 enabled.
entering extended mode
(./x.tex
LaTeX2e 2011/06/27
Babel v3.8m and hyphenation patterns for english, dumylang,
nohyphenation, lo
aded.
(/usr/share/texlive/texmf-dist/tex/latex/base/article.cls
Document Class: article 2007/10/19 v1.4h Standard LaTeX document class
(/usr/share/texlive/texmf-dist/tex/latex/base/size10.clo))
(/usr/share/texlive/texmf-dist/tex/latex/pslatex/pslatex.sty
kpathsea: Running mktextfm ptmr7t
/usr/share/texlive/texmf/web2c/mktexnam: Could not map source
abbreviation for ptmr7t.
/usr/share/texlive/texmf/web2c/mktexnam: Need to update ?
mktextfm: Running mf-nowin -progname=mf \mode:=ljfour; mag:=1;
nonstopmode; input ptmr7t
This is METAFONT, Version 2.718281 (TeX Live 2013/dev)
kpathsea: Running mktexmf ptmr7t
! I can't find file `ptmr7t'.
* ...:=ljfour; mag:=1; nonstopmode; input ptmr7t
Please type another input file name
! Emergency stop.
* ...:=ljfour; mag:=1; nonstopmode; input ptmr7t
Transcript written on mfput.log.
Solution:
# yum install 'tex(ptmr7t.tfm)'
Loaded plugins: langpacks, presto, refresh-packagekit
Resolving Dependencies
-- Running transaction check
--- Package texlive-times.noarch 2:svn28614.0-13.fc18 will be
installed
-- Finished Dependency Resolution
Dependencies Resolved
===
Package Arch Version
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 12:11, Chris Murphy wrote: After 1/2 dozen fedup upgrades during testing, on average the downtime portion of the upgrade was between 25 and 40 minutes. On a five year old laptop, with 4GB of RAM, and WDC Scorpio Blue rust drive (the new computer with SSD did the fedup upgrade in less than 10 minutes). Meanwhile, a yum upgrade involves a transition from download to upgrade without notification, concomitant with the potential for arbitrary and untimely implosion that could hose the entire upgrade. And this is on a supposedly important computer that can't be down for 2 hours? Umm? I really don't understand this thread. Over the years, I have yum upgraded remote boxes from RHL 7.3 to F16. On a remote yum upgrade, you can follow yum's progress -- see if it hangs, see any failure warnings, etc., fix what you can after it finishes -- then hold your breath when you reboot. If the box isn't back online within 2 minutes, you know you have a major problem and contact the data center immediately. If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off- track. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
On Sat, Jan 26, 2013 at 03:59:25PM +, Peter Robinson wrote: On Sat, Jan 26, 2013 at 3:51 PM, Richard W.M. Jones rjo...@redhat.com wrote: On Fri, Jan 25, 2013 at 03:35:58PM -0700, Orion Poplawski wrote: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Also breaks boost in the buildroot: http://koji.fedoraproject.org/koji/getfile?taskID=4904621name=root.log I've just rebuilt boost, just waiting for it to land in the repo so I can test whether the boost rebuild fixes it. koji wait-repo f19-build --build=boost-1.50.0-7.fc19; Thanks Peter. The libguestfs build seems to be chugging along now. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into KVM guests. http://libguestfs.org/virt-v2v -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
Orion Poplawski wrote, at 01/26/2013 07:35 AM +9:00: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Looks like several packages fails to build against new icu, with errors like: /builddir/build/BUILD/calligra-2.5.93/libs/db/drivers/sqlite/icu/icu.c:375: undefined reference to `ucol_close_50' CMakeFiles/kexidb_sqlite3_icu.dir/icu.c.o: In function `icuCollationColl': /builddir/build/BUILD/calligra-2.5.93/libs/db/drivers/sqlite/icu/icu.c:391: undefined reference to `ucol_strcoll_50' or /builddir/build/BUILD/webkitgtk-1.11.4/.libs/libwebkit2gtk-3.0.so: undefined reference to `u_charMirror_50' /builddir/build/BUILD/webkitgtk-1.11.4/.libs/libwebkit2gtk-3.0.so: undefined reference to `ublock_getCode_50' I guess these errors will be resolved by adding icu-config --cppflags (especially adding -DU_DISABLE_RENAMING=1) to compiler flags (harfbuzz changed so). This change comes from https://bugzilla.redhat.com/show_bug.cgi?id=856594 . While I think this change is appropriate, maybe adding -DU_DISABLE_RENAMING=1 also to icu pkgconfig file is more desirable. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a: journalcti --follow And I get live updates throughout the process. I don't recall hang without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. I don't know any company that allows major upgrades without user processes being required to quit. Apple and Microsoft both download and stage their upgrades, no user processes allowed, a partially upgraded system reboots, completes the primary upgrade tasks before user sessions are allowed again (and Windows might have one more reboot, I forget). Once upon a time, Apple allows user session to stay live during the installation of minor system software updates. They don't even do this anymore. Apparently it was so fraught with peril. So now, the download occurs in the background during the user session, and you have the option to being the install which also requires a restart. If you agree, you're logged out, user processes quit, the update begins, the system reboots. I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On Jan 26, 2013, at 11:16 AM, Reindl Harald h.rei...@thelounge.net wrote: Am 26.01.2013 19:09, schrieb Chris Murphy: I just don't see how it's best practices to be doing updates on live processes. This seems sorta like a game to find out just how much one can cheat the upgrade process before the ship will in fact sink. bullshit upgraded more than 20 production server from F9 to F18 with yum without any single problem because the upgrade takes around5 minutes and there are no new processes start most of the time and the few are nothing critical I think that's unicorn poop you're talking about. But hey, if you are ninja enough to avoid being cut by machine guns shooting razor blades at you, nice job. But asking other people make you an inflatable raft that can withstand being shot by razor blade shooting machine guns, write documentation for it, test, and support it? I will laugh out loud, and then give you the phone number for my unicorn dealer. Chris Murphy -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 18:00, schrieb Nicolas Mailhot: Le Ven 25 janvier 2013 00:12, Lennart Poettering a écrit : Applications have deps on all kinds of data in /usr/lib, not just shared libraries. Such as locale data, icons, fonts, artwork, documentation. BTW Firefox seems to be the only application that goes bonkers when fonts are updated while it's running, so it looks more like a bug in Firefox's text rendering than a general problem to me and on the other hand i had longer time ago troubles with my systemdisk suddenly disappear until hard power off and more than one time i used firefox for half an hour because it had anything in the memory and freezed only if it should display a dialog with icons not loaded before proven by /var/log/ on a different disk with errors in a tail -f while all aplications worked for minutes and even VMware machines could be CLEAN powered off via SSH from a notebook as long they were on a different physical drive so no - it's not that bad doing updates while things running signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Am 25.01.2013 18:57, schrieb Rahul Sundaram: Just to be clear, RHEL != Fedora. Red Hat policy for RHEL kernel is not acceptable to Fedora and Fedora kernel continues to have the patches split out. You cannot use that to defend MySQL policies here. You can do whatever you want to do for the MySQL enterprise edition which is a commercial product but the community project should have transparency and openness in how it handles bugs, security issues, test cases etc. If you are willing to commit to that, that is a step forward. this is all nice and fine but keep in mind that Fedora is the base for RHEL applications may be certified for mysql and yes you are unsopported to run them at all on Fedora but run them additionally on a fork of mysql which maybe more and more incompatible over the years you are out of hope and have not anything from the subjective freedom if there is no way to have both, mysqld AND mariadb Fedora should do itself a favour and keep mysqld, not for now - forever or as long not most other software supports mariadb explicitly which is not the case now has mysqld any technical problem which makes it unstable? no it has not! is mariadb supported from any software which does not for mysqld? not it does not! is mysqld opensource? yes it is! did we had enough subsystem changes the last few years? yes - we had way too much for the time-window! signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 19:20, schrieb Lennart Poettering: Nonsense, for a distribution upgrade you just recommend the admin to reboot the system when done. Everybody expects to reboot after a big distro-sync anyway as there is a new kernel and basically new-everything. Ah, so you have to reboot anyway, so where is the difference between your approach and proper offline updates then? Either way you have to interrupt your work to reboot the machine. One just takes a slight bit longer for rebooting... i had enough anaconda upgrades which failed to boot after that by such things like missing initrd, missing rub-entry and so on to have learend i want a upgrade where i can VERIFY all this basic stuff, fix things, cleanup configurations, package-cleanup and AFTER THAT i reboot the machine guess - since i do it this way i survived calculated more than 300 dist-upgares with yum and not a single one had any problem coming up again, said that: from FC7 until F18 und the oldest setups are started with FC8 and now F18 signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Am 25.01.2013 21:17, schrieb Jóhann B. Guðmundsson: On 01/25/2013 07:39 PM, Michał Piotrowski wrote: I use Fedora as a server system for my daily developer work. I use many services with different configurations. Actually updating it with preupgrade/fedup is sometimes hard. Reinstalling whole system after each release will be super painful. ? Keep your server configuration in git and keep the relevant data on separated partition then reinstall and checkout the config(s) which part of the configuration? all /etc - well this would be more damage than resolution :-) sorry but this does not work i have made some hundret dist-upgrades with yum over the years nearly zero downtime, normally not more as a kernel update with reboot well, i keep all my systems 100% clear but with reinstalls i had wasted so much more time the big benefit (especially in VM environments) is that the update goes so fast (as long you not install every bullshit) that the timeframe is to short to make any troubles for running services 4-7 minutes per instance here since years signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Hi On Fri, Jan 25, 2013 at 1:05 PM, Reindl Harald if there is no way to have both, mysqld AND mariadb Fedora should do itself a favour and keep mysqld, not for now - forever or as long not most other software supports mariadb explicitly which is not the case now It is very much possible to have them and that is already the case in Fedora now. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
stop service ; remove some files ; start service in RPM %postun ?
I have an rpm package where I need to stop the running service, remove some files and start the service again depending on which package version was already installed. I assume I need to do this in %postun, where we normally do condrestart, but I don't know how to check the version of the previously installed package. Could someone help me here / does anybody have examples doing something similar ? For sysv-init i guess it should be trivial to check service $name status to see if it was running, and then stop/start it. But what's the equivalent for systemd ? Currently I use %systemd_postun_with_restart, but that needs to be split up so that I can delete the files while the service is down.. -jf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Am 26.01.2013 19:59, schrieb Rahul Sundaram: On Fri, Jan 25, 2013 at 1:05 PM, Reindl Harald if there is no way to have both, mysqld AND mariadb Fedora should do itself a favour and keep mysqld, not for now - forever or as long not most other software supports mariadb explicitly which is not the case now It is very much possible to have them and that is already the case in Fedora now and even if any package in fedora is built this way a operating systemd / distribution should not built for it's own with the attitude what does us bother software outside our repos? this NIH syndrome is very very bad typically a user see a operating system as base for running applications, and this does not mean only the limited ones coming with the OS itself signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: stop service ; remove some files ; start service in RPM %postun ?
On Sat, 26 Jan 2013 20:17:14 +0100 Jan-Frode Myklebust janfr...@tanso.net wrote: I have an rpm package where I need to stop the running service, remove some files and start the service again depending on which package version was already installed. Perhaps %triggerpostun? http://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/ch10s02.html I assume I need to do this in %postun, where we normally do condrestart, but I don't know how to check the version of the previously installed package. Could someone help me here / does anybody have examples doing something similar ? You might take a look at the sendmail package, where the scriptlets are done manually because the systemd version uses two services whilst the sysv version had just the one, so some conversion was needed. For sysv-init i guess it should be trivial to check service $name status to see if it was running, and then stop/start it. But what's the equivalent for systemd ? systemctl try-restart $name See: http://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet Paul. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130125 changes
On 1/25/13, Kevin Fenzi ke...@scrye.com wrote: Hey node.js people. Can you please fix these up? This should be fixed early next week. Two of the missing deps are already under review, and if somebody wants to take the last one I can do a review in kind. [node-gyp] node-gyp-0.8.2-3.fc19.noarch requires npm(request) [nodejs-couch-login] nodejs-couch-login-0.1.15-2.fc19.noarch requires npm(request) Almost done. [nodejs-form-data] nodejs-form-data-0.0.6-2.fc19.noarch requires npm(combined-stream) = 0:0.0.3 https://bugzilla.redhat.com/show_bug.cgi?id=891183 [nodejs-fstream-npm] nodejs-fstream-npm-0.1.3-2.fc19.noarch requires npm(fstream-ignore) 0:0.1 nodejs-fstream-npm-0.1.3-2.fc19.noarch requires npm(fstream-ignore) = 0:0.0.5 Also under review. I pinged the reviewer; must have slipped past his radar. [nodejs-npm-registry-client] nodejs-npm-registry-client-0.2.11-2.fc19.noarch requires npm(request) [npm] npm-1.2.1-2.fc19.noarch requires npm(request) 0:3 npm-1.2.1-2.fc19.noarch requires npm(request) = 0:2.9 Thanks! -T.C. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Hi a operating systemd / distribution should not built for it's own with the attitude what does us bother software outside our repos? this NIH syndrome is very very bad Both MySQL and MariaDB is available and neither was invented here and either can be used as per your preference. When use terms like NIH, make sure they are actually applicable. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Le vendredi 25 janvier 2013 à 19:05 +0100, Reindl Harald a écrit : Am 25.01.2013 18:57, schrieb Rahul Sundaram: Just to be clear, RHEL != Fedora. Red Hat policy for RHEL kernel is not acceptable to Fedora and Fedora kernel continues to have the patches split out. You cannot use that to defend MySQL policies here. You can do whatever you want to do for the MySQL enterprise edition which is a commercial product but the community project should have transparency and openness in how it handles bugs, security issues, test cases etc. If you are willing to commit to that, that is a step forward. this is all nice and fine but keep in mind that Fedora is the base for RHEL applications may be certified for mysql If you take a look at the RHEL channels, you will see that RH is perfectly able to offer packages not coming from Fedora and to support them ( exemple, passenger for openshift, or jboss, cloudforms ). And Oracle can perfectly offer mysql rpms for Fedora if you need them. And again as Rahul said, RHEL != Fedora. If the Fedora Mysql maintainer all think this is too time consuming to keep Mysql in Fedora , then he is right. We should keep the sustainability in mind, or that's the recipe for long term problems. and yes you are unsopported to run them at all on Fedora but run them additionally on a fork of mysql which maybe more and more incompatible over the years you are out of hope and have not anything from the subjective freedom if there is no way to have both, mysqld AND mariadb Fedora should do itself a favour and keep mysqld, not for now - forever or as long not most other software supports mariadb explicitly which is not the case now No one is going to support mariadb explicitly unless it start to be distributed widely. And instead of spreading FUD, please take a look at smaller distribution that did switch to mariadb ( for example, mageia, who did since more than 1 year ). Ask them if this cause problems or not, if they have lots of unsupported softwares, etc. Then you will be able to claim this is not supported. From what I know, the switch was handled without problem. -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If a fedup upgrade can go offline for a lengthy, but uncertain, amount of time, then the lack of feedback is worrying. You can't hold your breath for 25 minutes, you don't know when to conclude that you have a serious problem that will require help from the data center staff, and you don't have any idea where the process went off-track. I think the lack of feedback with fedup is a known weak area that needs improvement. I found that by deleting 'quiet rhgb' and adding one of the debug options to the fedup kenel at reboot time, I can get to a shell during the upgrade, and issue a: journalcti --follow And I get live updates throughout the process. I don't recall hang without some sort of feedback for more than maybe 5 minutes. I forget off hand if top and/or ps are available, I think at least one of them is. I can see how this would help when sitting in front of the box, but when you're hundreds or thousands of miles away, it isn't really an option. If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? It would be nice if one could start fedup with a flag that would tell it to start the network and sshd upon reboot, and enable feedback to a remote user. That would make the process a lot less worrisome. -- Mike -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Fri, 2013-01-25 at 19:05 +0100, Reindl Harald wrote: Am 25.01.2013 18:57, schrieb Rahul Sundaram: Just to be clear, RHEL != Fedora. Red Hat policy for RHEL kernel is not acceptable to Fedora and Fedora kernel continues to have the patches split out. You cannot use that to defend MySQL policies here. You can do whatever you want to do for the MySQL enterprise edition which is a commercial product but the community project should have transparency and openness in how it handles bugs, security issues, test cases etc. If you are willing to commit to that, that is a step forward. this is all nice and fine but keep in mind that Fedora is the base for RHEL applications may be certified for mysql And that is Fedora's problem how? Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Making rygel build in rawhide
The attached patches upgrade gupnp-dlna to 0.9.4 and fix the rygel 0.17.7 build. Please apply to get people working again. I have also emailed the typo fix patch upstream. I've attached it here for convenience. It would be nice if upstream rygel didn't require us to strip rpath after the build. Nathaniel On Sat, Jan 26, 2013 at 5:01 AM, Krzesimir Nowak qdl...@gmail.com wrote: 2013/1/26 Nathaniel McCallum nathan...@natemccallum.com Could someone apply this patch to rygel so at least we can get a successful build? http://git.gnome.org/browse/rygel/commit/?h=wip/new-gupnp-dlnaid=118af0f588879703e0dd7d01787897b5893032e0 That won't do. Gupnp-dlna 0.9.4 has to hit rawhide first. Then instead of patching, packaging Rygel 0.17.7 should be enough. Thanks, Nathaniel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel 0001-update-to-gupnp-dlna-0.9.4.patch Description: Binary data 0001-make-rygel-0.17.7-actually-build-add-docs-subpackage.patch Description: Binary data rygel-0.17.7-typofix.patch Description: Binary data -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
Le samedi 26 janvier 2013 à 15:20 -0500, Mike Pinkerton a écrit : On 26 Jan 2013, at 13:09, Chris Murphy wrote: On Jan 26, 2013, at 10:45 AM, Mike Pinkerton pseli...@mindspring.com wrote: If you could SSH into fedup during its offline period and get real time feedback about what it is doing and any errors it encounters, and perhaps the ability to fix any problems when it finishes but before it attempts to reboot, then it would be less scary for remote upgrades. I haven't tried 'systemctl start sshd' during the upgrade to see what happens; it's probably not totally benign to do this, since ssh will be upgraded, but it seems a lot safer, vastly so, than a live yum update while a server is running. Would it work for the network and sshd to be run from the initramfs rather than the file system that is being updated? Then you need to have the network configuration, etc. This can be done, but for now, the feature is not in dracut, see this bug for a similar request for encrypted root : https://bugzilla.redhat.com/show_bug.cgi?id=524727 -- Michael Scherer -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On Sat, 2013-01-26 at 21:34 +0100, Reindl Harald wrote: Am 26.01.2013 21:24, schrieb Pierre-Yves Chibon: but keep in mind that Fedora is the base for RHEL applications may be certified for mysql And that is Fedora's problem how? and THAT is the problem with many pieces of fedora-development the last few years - what do we care for the real world usage, we are only a design study.. I agree, we care for real world usage of Fedora, not XYZ. Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Am 26.01.2013 21:14, schrieb Rahul Sundaram: a operating systemd / distribution should not built for it's own with the attitude what does us bother software outside our repos? this NIH syndrome is very very bad Both MySQL and MariaDB is available and neither was invented here and either can be used as per your preference. When use terms like NIH, make sure they are actually applicable. seems you did not understand what i said NIH in context of the distributoon at all not a single package means the sometimes snappy feedback with any software outside the repos we do not care and there maybe software which works with mysqld and does not bother for mariadb and so - this thread is about REPLACE MYSQL signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
Am 26.01.2013 21:24, schrieb Pierre-Yves Chibon: but keep in mind that Fedora is the base for RHEL applications may be certified for mysql And that is Fedora's problem how? and THAT is the problem with many pieces of fedora-development the last few years - what do we care for the real world usage, we are only a design study.. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Replace MySQL with MariaDB
On 01/26/2013 08:42 PM, Pierre-Yves Chibon wrote: On Sat, 2013-01-26 at 21:34 +0100, Reindl Harald wrote: Am 26.01.2013 21:24, schrieb Pierre-Yves Chibon: but keep in mind that Fedora is the base for RHEL applications may be certified for mysql And that is Fedora's problem how? and THAT is the problem with many pieces of fedora-development the last few years - what do we care for the real world usage, we are only a design study.. I agree, we care for real world usage of Fedora, not XYZ. Yup rhel != Fedora The third party support can be distribution agnostic like for example [1] Running on Fedora does not break support there however using mariadb will. If the current maintainers orphan mysql anyone can pick it up including Oracle employees and continue it's maintenance within the distribution. Any beef, competition or what not between Red Hat and Oracle ( or anyone else for that matter ) is between Red Hat and Oracle not Fedora and I cant imagine FESCO/Board standing in the way of Oracle wanting to packaging and maintain anything in the distribution unless it breaks some legal jargon just like everyone else. JBG 1.https://confluence.atlassian.com/display/JIRA/Supported+Platforms -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
Hi Mamoru, On Sunday, 2013-01-27 03:09:22 +0900, Mamoru TASAKA wrote: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Looks like several packages fails to build against new icu, with errors like: /builddir/build/BUILD/calligra-2.5.93/libs/db/drivers/sqlite/icu/icu.c:375: undefined reference to `ucol_close_50' I guess these errors will be resolved by adding icu-config --cppflags (especially adding -DU_DISABLE_RENAMING=1) to compiler flags (harfbuzz changed so). This change comes from https://bugzilla.redhat.com/show_bug.cgi?id=856594 . While I think this change is appropriate, maybe adding -DU_DISABLE_RENAMING=1 also to icu pkgconfig file is more desirable. How exactly is that to be done? And sorry if someone was caught in surprise, I tried to warn in advance with my mail to the list. Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgphmVrL5DOdO.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Jan 25, 2013 3:45 PM, Marcela Mašláňová mmasl...@redhat.com wrote: On 01/25/2013 12:17 AM, Adam Williamson wrote: On Thu, 2013-01-24 at 23:03 +, Jóhann B. Guðmundsson wrote: It's best to rip the bandage of this in one release. The churn from this should have been more or less covered when we implement biosdevname so the fallout from this change should be minimal if any... I see the 's' word in there ;) That's always the hope, and then we meet the cold reality, where someone just patched 'em1' into everything and hoped that was good enough. But sure, 'damn the torpedoes' is a viable approach too. I guess I was just kind of hoping F19 would be a release without yet more churn in the core system where we could try and stabilize things a bit. I agree. The scope says no impact, but who knows how many packages depend on hardcoded names. I guess we just have to cross that bridge when we get there... JBG -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wednesday 23 January 2013 23:49:48 Kay Sievers wrote: ... We had no better idea really, than to copy the successful model we do for disks (and other subsystems) with /dev/disk/by-*/ symlinks. It was a well-known scheme, but it was certainly not know for network devices so far. So we picked up the basic ideas from biosdevname and combined them with the proven scheme we do for all other subsystems in udev. This necessarily lead to different names, but from udev's point of view they are entirely justified. The /dev/disk/... is nice because of *two* properties: * It indeed provides unique, persistent names * But people can still use /dev/sda Which is useful in the super-common case of single disk PC I.e: the predictable names are just aliases for the traditional names. In another mail on this thread, someone mentioned that this possibility was looked into, but the related kernel code cannot be easily modified to support multiple-names per interface. However, maybe implementing this aliasing in user-space is more tractable? IMO, my following proposal is only feasible if (and it's a big iff), the number of system calls and library functions that accept a network interface name is not large [things like if_nameindex(), the ifreq ioctl()'s, etc.] If that's the case, we can map predictable names to traditional ones in user-space, on the entry to said library functions, or entry to the said glibc syscall wrappers. Example of a possible mapping scheme: * Have udev create a symlink that maps the predictable name into the string of the traditional name. E.g: /dev/netdev/enp2s0 - eth0 * Of course, there's no eth0 file, but nevertheless the symlink can contain this string. * Now implement ifname_mapto(const char *name, char *new_name) as follows: - If there's no /dev/netdev/name, use name as new_name (identity) - Otherwise, new_name is the result of readlink(/dev/netdev/name) Now if there aren't zillions of functions that process network interface names, modifying them seems reasonable. The advantage is that it allows the use the traditional names for the most common cases (e.g: a laptop with one eth0 and one wlan0) while still providing a predictable naming to be used when needed. Now, what do my .signature try to tell me? ;-) -- Oron Peled Voice: +972-4-8228492 o...@actcom.co.il http://users.actcom.co.il/~oron ... Complex problems have simple, easy to understand wrong answers. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Fedora Upgrade - using yum
25.01.2013 22:27, Lennart Poettering пишет: On Fri, 25.01.13 13:02, Przemek Klosowski (przemek.klosow...@nist.gov) wrote: On 01/24/2013 06:12 PM, Lennart Poettering wrote: If you restart any of those you bring down the entire machine basically, or bring down at least the bits you really want to avoid, i.e. the user's sessions... Then all code that runs that is not a system service is difficult to restart from a system script. How do you plan to restart Evolution or Firefox, or Gimp? ... Of course, you could tell the user as last step of your script to please reboot now, but if you do that your update isn't online anymore, but is awfully close to real offline upgrades, except that during the upgrade period you have a ton of processes around that might be seriously confused by not being able to find their own resources anymore or in wrong versions... This is a pessimistic view but I think it's not as intractable. There are two separate aspects to it: discovery what needs to be restarted, and the actual process of restarting. The discovery is almost there: we know the resources (libs, files, etc) that were replaced, so it's a matter of walking the list of running processes and checking if they depend on those resources. I can see how transient I/O, including dlopen() could be tricky, but I don't think it's fundamentally impossible---at worst, it'd be implementing some sort of /proc/1234/history-of-opened-fd mechanism. That doesn't work. Let's say my app needs to display a certain icon in some dialog. The next version of that app doesn't need that icon anymore, so on upgrade the icon is deleted. At the same time the user is still running that app, and then enters the dialog. The app now looks for the icon, and doesn't find it. Bang. There is no sane way to determine all these dependencies, because many of them are never explicit, and only temporary in nature. Well written apps load a lot of resources lazily. That has the side effect that you can never know those deps, until they are actually needed. The icon thing is just one example, you can now extrapolate from that... Sorry but how such use case different from simple firefox update in current release when it happened parallel with browsing?? It may also lead to that unpredictable behavior. Off course you will say it shouldn't be major release in stable Fedora. And off course it is true. But anyone can't guaranty what even change or delete 1 file do not lead to unstable app. So for that cases graphical application similar to PackageKit suggests user reboot (and may suggest only reload certain apps) with list of apps, based on maintainers expectation from (suggest reboot in bodhi update system). I hope you do not suggest force reload such apps for user of force always offline update for that thinks. In that point of view online distro update differs only by amount of updated packages which suggest reboot for user. And I may himself plan reboot when I want... -- With best wishes, Pavel Alexeev (aka Pahan-Hubbitus). For fast contact with me use jabber: hubbi...@jabber.ru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130126 changes
Rebuilt by me: [389-adminutil] [389-ds-base] [R] [templates_parser] [aws] [dwdiff] [fcitx] [flush] [fmt-ptrn] [pion-net] [fatrat] [gridsite] [calibre] [webkitgtk] Failed (many icu flags thing: bug 856594) [389-admin] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4904943 [389-dsgw] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4904946 [bibletime] - needs sword [sword] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4904937 [dragonegg] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905007 [couchdb] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905017 [eclipse-linuxtools] - requires kernel-debuginfo? doesn't exist. [fawkes] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905075 [flowcanvas] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905127 [fcitx-keyboard] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905158 [fontmatrix] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905165 [gfal] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905189 [gdcm] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905178 [gnome-applets] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905213 [gnome-documents] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905216 Needs retiring or significant work: [bootconf] [compat-gcc-34] [epiphany-extensions] [gcc-python-plugin] hopefully known/people working on them/been broken for a while: [freewrl] [ghc-wai-extra] [node-gyp] [nodejs-couch-login] [nodejs-form-data] [nodejs-fstream-npm] [nodejs-npm-registry-client] [npm] [rygel] Then I had to leave and didn't get time to look at these: [webkitgtk3] [gnome-shell] [cinnamon] [ibus-qt] [idzebra] [lcgdm-dav] [leechcraft] [libcommuni] [libextractor] [libgda] [libguestfs] [libircclient-qt] [libreoffice] [libtranslit] [mapnik] [matreshka] [media-explorer] [meshmagick] [msort] [mygui] [nqp] [openttd] [osm2pgsql] [pam_mapi] [parrot] [php] [player] [plplot] [ppl] [pyicu] [python-basemap] [rakudo-star] [root] [rubygem-net-ping] [scala] [spacewalk-web] [springlobby] [testdisk] [tex-musixtex] [texlive] [the-board] [wine] [yaz] [zarafa] [zorba] signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
Eike Rathke wrote, at 01/27/2013 08:02 AM +9:00: Hi Mamoru, On Sunday, 2013-01-27 03:09:22 +0900, Mamoru TASAKA wrote: FYI - Looks like icu 50 landed in rawhide today with the usual soname bump Looks like several packages fails to build against new icu, with errors like: /builddir/build/BUILD/calligra-2.5.93/libs/db/drivers/sqlite/icu/icu.c:375: undefined reference to `ucol_close_50' I guess these errors will be resolved by adding icu-config --cppflags (especially adding -DU_DISABLE_RENAMING=1) to compiler flags (harfbuzz changed so). This change comes from https://bugzilla.redhat.com/show_bug.cgi?id=856594 . While I think this change is appropriate, maybe adding -DU_DISABLE_RENAMING=1 also to icu pkgconfig file is more desirable. How exactly is that to be done? And sorry if someone was caught in surprise, I tried to warn in advance with my mail to the list. Eike Looks like patching against /usr/include/unicode/urename.h is more appropriate. I wrote some comments on bug 856594. Regards, Mamoru -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, 26 Jan 2013 05:49:25 + (UTC)
Ben Boeckel maths...@gmail.com wrote:
Looking at this, how about a simple rule about what makes a fedpkg
build cascade up: While the next higher branch has the same version,
but older pre-dist release number, merge --ff-only and trigger a
build if one is not created within an hour of the current build
completing. With this, a bump in the form %{?dist}.1 wouldn't trigger
a build (since this implies that it's a release-specific fix) and a
build on fX won't trigger an fX+1 build if there's a version gap
between them.
Seems complex. Would it run on the client or on the server side?
It also seems... unexpected. You ask for a build, but it does commits
and builds behind your back?
Sending an email halfway between the end of the build and automation
of intent would probably be useful. If the next higher branch is
updated manually and no build appears, this could be interpreted as a
I know what I'm doing indication and cancel the automation.
Thoughts?
That would need some kind of queue...
kevin
signature.asc
Description: PGP signature
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: icu 50 soname bump
On Sun, 27 Jan 2013 11:30:22 +0900 Mamoru TASAKA mtas...@fedoraproject.org wrote: Looks like patching against /usr/include/unicode/urename.h is more appropriate. I wrote some comments on bug 856594. If that saves adding workarounds to a bunch of packages seems like the better solution. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On 01/25/2013 10:49 PM, Ben Boeckel wrote:
Looking at this, how about a simple rule about what makes a fedpkg build
cascade up: While the next higher branch has the same version, but older
pre-dist release number, merge --ff-only and trigger a build if one is
not created within an hour of the current build completing. With this, a
bump in the form %{?dist}.1 wouldn't trigger a build (since this implies
that it's a release-specific fix) and a build on fX won't trigger an
fX+1 build if there's a version gap between them.
Sending an email halfway between the end of the build and automation of
intent would probably be useful. If the next higher branch is updated
manually and no build appears, this could be interpreted as a I know
what I'm doing indication and cancel the automation.
Thoughts?
Doing more than one asks in certain situations sounds bad, but how about:
fn: fedpkg build --and-newer
Does:
fedpkg build
loop:
fedpkg switch-branch fn+1 (or master)
git merge fn
git push
fedpkg build
goto loop: unless at master
It could also take --nowait. If there was an error at any point it
would abort (assuming git gives some non-zero return codes).
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA/CoRA DivisionFAX: 303-415-9702
3380 Mitchell Lane or...@cora.nwra.com
Boulder, CO 80301 http://www.cora.nwra.com
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: drop inheritance at f19 branch point?
On Sat, Jan 26, 2013 at 19:48:25 -0700, Kevin Fenzi wrote: Seems complex. For the logic, the delay part, or a likely implementation? Would it run on the client or on the server side? I was thinking server side at first, but maybe we could have fedpkg detect this and ask if it's wanted when the build is requested (possibly with a per-package and global setting)? It also seems... unexpected. You ask for a build, but it does commits and builds behind your back? As written above, it wouldn't write any new commits (--ff-only should enforce that). It would only update branches and request builds along with a notice of intent. --Ben -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130126 changes
On 01/26/2013 08:51 PM, Kevin Fenzi wrote: Failed (many icu flags thing: bug 856594) ... [fawkes] - http://koji.fedoraproject.org/koji/taskinfo?taskID=4905075 Graphviz's API changed, I'm working on a fix for Fawkes now. Then I had to leave and didn't get time to look at these: ... [player] libphidget's API also changed, I fixed Player this afternoon. Rich -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: BuildRequires for texlive stuff for F18 and beyond
On Sat, Jan 26, 2013 at 2:59 AM, Jindrich Novy wrote: Example pdflatex error in log - style missing: ! LaTeX Error: File `upquote.sty' not found. Type X to quit or RETURN to proceed, or enter new name. (Default extension: sty) solution: # yum install 'tex(upquote.sty)' Loaded plugins: langpacks, presto, refresh-packagekit Resolving Dependencies -- Running transaction check --- Package texlive-upquote.noarch 2:svn26059.v1.3-13.fc18 will be installed -- Finished Dependency Resolution But if I have a .tex file that needs 40 such requirements, I have to go through the above fix 40 times. Isn't there a way to launch yum to install all the requirements automatically when I run latex? Thanks, Orcan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
FOSDEM 2013 call for papers
Seen on blogs.perl.org : hi all, on behalf of wendy https://nxadm.wordpress.com/2013/01/25/perlfosdem2013-a-very-late-call-for-papers/ --snip--- Dear Perl Mongers, I have to make this short and simple. Therefore most of this email is copied from last year's Call for Speakers. What? Fosdem, Brussels, 2 3 february 2013 https://fosdem.org/2013/ Where? Free University Brussels, Campus Solbosh: https://fosdem.org/2013/practical/transportation/ Why so late? Because our dev-room request was denied at first. They gave it to another programming language community. Now another community could not fill their dev-room. We are Perl, so we jumped in and we asked for this. We got it. Now we have to fill it. So be quick and send in your presentation proposal. To: Claudio Ramirez (nxadm, email: padre.claudio at apt-get.be) and Wendy van Dijk (email: nl.pm at wendy.org). Thank you. Hope to meet you all in Brussels. If you need an URL for twitter and the like: https://nxadm.wordpress.com/2013/01/25/perlfosdem2013-a-very-late-call-for-papers/ _ Copied and adapted from last year's Call for Speakers: Please forward to your Perl contacts. _ Taking place in the beautiful city of Brussels (Belgium), FOSDEM is the biggest free and non-commercial European event organized by and for the community. Its goal is to provide Free and Open Source developers a place to meet (see http://fosdem.org/2013/). Over the last years the Perl community had an increasing presence at FOSDEM. Over the last two years we managed to have both a booth and a dev-room. We collected an impressive positive return and wish to renew the experience. Our dev-room request for this upcoming edition (2013) was at first rejected, in favor of another programming language community. So we would only have a booth. But another open source community could not fill their dev-room and we hastily requested it for the Perl-community. Yesterday we got approval. The stand request is approved some time ago. The stand will be open throughout the weekend. The dev-room event will take place Saturday, February 2nd 2013 , between 11:00 and 19:00, in room AW.126. The room itself has 75 seats, WIFI and a VGA projector. This environment, being a university classroom with raised seats, lends itself perfectly for talks. This is a wonderful opportunity to present your Perl project big and small or talk about subjects you care about. We are looking for a variety of subjects on all levels: starter and advanced, generic and specialized, core internals and CPAN. We have 8 hours time, so we have the flexibility of using different time formats: e.g. talks of 20 minutes, more classic talks of 40 minutes or longer (although we learned from experience that longer talks should be split into slices of 20 or 40 minutes). Please don't doubt to send a proposal (information about yourself, subject, short description and time needed). If you have several subjects you are enthusiastic to talk about please send alternative proposals. In the case more than one talk is not selected, your proposal will help us when putting the schedule together and even have backup talks in case someone cancels. Also mention your time constraints (if any). Please send your talk proposal by e-mail to the address below as soon as you read this. You will receive an answer within 2 days. We will submit a definitive schedule on Sunday 2013-01-27 to the FOSDEM organizers. Please forward / distribute this call as wide as possible (certainly to your local mongers). Claudio Ramirez (nxadm, email: padre.claudio at apt-get.be) and Wendy van Dijk (email: nl.pm at wendy.org). NB1: This is a community event without sponsoring. We don't have the means to pay for your trip and time. If you want to sponsor part of the event, please feel free to contact us. NB2: We'll also appreciate volunteers, booth and dev-room. Please tell us your availabilities so we can also prepare a planning for this. -snap- -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
File Test-Mojibake-0.8.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-Test-Mojibake: 0baa9275af39fa7f60c62b5b2b3110bd Test-Mojibake-0.8.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Test-Mojibake] Update to 0.8
commit 094e57091cdda059acf9a0bebac05797619237f2
Author: Paul Howarth p...@city-fan.org
Date: Sat Jan 26 22:45:17 2013 +
Update to 0.8
- New upstream release 0.8
- Fixed cyclic t/ deps
- Added the standalone scan_mojibake utility
- Listed Unicode::CheckUTF8 as a recommended prerequisite
- Recognize utf8::all
- Passes perlcritic harsh
- Drop BR: perl(File::Spec)
- BR: perl(File::Spec::Functions), perl(Pod::Usage) and perl(Test::Script)
- BR: perl(Test::Pod::LinkCheck) where available
- Perl::Critic ≥ 1.094 now needed for the 'equivalent_modules' parameter in
TestingAndDebugging::RequireUseStrict, unavailable in EPEL-5
- Update patch for building with old Test::More versions
- Drop %defattr, redundant since rpm 4.4
Test-Mojibake-0.4-old-Test::More.patch | 74 --
Test-Mojibake-0.8-old-Test::More.patch | 77
perl-Test-Mojibake.spec| 41 -
sources|2 +-
4 files changed, 106 insertions(+), 88 deletions(-)
---
diff --git a/Test-Mojibake-0.8-old-Test::More.patch
b/Test-Mojibake-0.8-old-Test::More.patch
new file mode 100644
index 000..e604ff0
--- /dev/null
+++ b/Test-Mojibake-0.8-old-Test::More.patch
@@ -0,0 +1,77 @@
+diff -up Test-Mojibake-0.8/t/06-pp-vs-xs.t.orig
Test-Mojibake-0.8/t/06-pp-vs-xs.t
+--- Test-Mojibake-0.8/t/06-pp-vs-xs.t.orig 2013-01-26 20:28:12.0
+
Test-Mojibake-0.8/t/06-pp-vs-xs.t 2013-01-26 22:17:47.038813730 +
+@@ -2,7 +2,7 @@
+ use strict;
+ use warnings qw(all);
+
+-use Test::More;
++use Test::More 'no_plan';
+
+ ## no critic (ProhibitPackageVars, ProtectPrivateSubs)
+
+@@ -13,7 +13,6 @@ BEGIN {
+
+ unless ($Test::Mojibake::use_xs) {
+ diag('No XS module detected, will fallback to PP implementation!');
+-done_testing(2);
+ exit;
+ }
+
+@@ -36,8 +35,6 @@ ok($t0-iters $t1-iters, 'XS faster t
+
+ diag(sprintf('XS/PP speed ratio is %0.2f', $t0-iters / $t1-iters));
+
+-done_testing(7);
+-
+ sub run {
+ my $i = 0;
+ for (@buf) {
+diff -up Test-Mojibake-0.8/t/07-broken-utf8.t.orig
Test-Mojibake-0.8/t/07-broken-utf8.t
+--- Test-Mojibake-0.8/t/07-broken-utf8.t.orig 2013-01-26 20:28:12.0
+
Test-Mojibake-0.8/t/07-broken-utf8.t 2013-01-26 22:17:47.038813730
+
+@@ -27,7 +27,7 @@ my @tests = (
+ [11-overlong-5= 0 = \\xfc\x80\x80\x80\x80\xaf],
+ );
+
++plan tests = scalar @tests;
++
+ ok(Test::Mojibake::_detect_utf8($_-[2]) == $_-[1], $_-[0])
+ for @tests;
+-
+-done_testing(scalar @tests);
+diff -up Test-Mojibake-0.8/t/release-cpan-changes.t.orig
Test-Mojibake-0.8/t/release-cpan-changes.t
+--- Test-Mojibake-0.8/t/release-cpan-changes.t.orig2013-01-26
20:28:12.0 +
Test-Mojibake-0.8/t/release-cpan-changes.t 2013-01-26 22:17:47.038813730
+
+@@ -1,15 +1,11 @@
+ #!perl
+
++use Test::More;
++
+ BEGIN {
+- unless ($ENV{RELEASE_TESTING}) {
+-require Test::More;
+-Test::More::plan(skip_all = 'these tests are for release candidate
testing');
+- }
++ plan skip_all = 'these tests are for release candidate testing' unless
($ENV{RELEASE_TESTING});
++ eval 'use Test::CPAN::Changes';
++ plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ }
+
+-
+-use Test::More;
+-eval 'use Test::CPAN::Changes';
+-plan skip_all = 'Test::CPAN::Changes required for this test' if $@;
+ changes_ok();
+-done_testing();
+diff -up Test-Mojibake-0.8/t/release-test-version.t.orig
Test-Mojibake-0.8/t/release-test-version.t
+--- Test-Mojibake-0.8/t/release-test-version.t.orig2013-01-26
22:17:47.0 +
Test-Mojibake-0.8/t/release-test-version.t 2013-01-26 22:18:26.069722569
+
+@@ -26,5 +26,6 @@ push @imports, $params
+
+ Test::Version-import(@imports);
+
++plan tests = 2;
++
+ version_all_ok();
+-done_testing;
diff --git a/perl-Test-Mojibake.spec b/perl-Test-Mojibake.spec
index 5ab7b0c..617fa43 100644
--- a/perl-Test-Mojibake.spec
+++ b/perl-Test-Mojibake.spec
@@ -7,12 +7,8 @@
# noarch, but to avoid debug* files interfering with manifest test:
%global debug_package %{nil}
-# TODO:
-#
-# BuildRequires: perl(Test::Pod::LinkCheck) when available
-
Name: perl-Test-Mojibake
-Version: 0.7
+Version: 0.8
Release: 1%{?dist}
Summary: Check your source for encoding misbehavior
Group: Development/Libraries
@@ -20,7 +16,7 @@ License: GPL+ or Artistic
URL: http://search.cpan.org/dist/Test-Mojibake/
Source0:
http://search.cpan.org/CPAN/authors/id/S/SY/SYP/Test-Mojibake-%{version}.tar.gz
Patch0:Test-Mojibake-0.4-no-Test::Version.patch
-Patch1:Test-Mojibake-0.4-old-Test::More.patch
+Patch1:Test-Mojibake-0.8-old-Test::More.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
#
[perl-Test-Mojibake] Created tag perl-Test-Mojibake-0.8-1.fc19
The lightweight tag 'perl-Test-Mojibake-0.8-1.fc19' was created pointing to: 094e570... Update to 0.8 -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-Authen-Simple
perl-Authen-Simple has broken dependencies in the epel-6 tree: On ppc64: perl-Authen-Simple-0.4-5.el6.noarch requires perl(Crypt::PasswdMD5) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
F19 upgrade ICU to 50.1.1 in sync with Boost upgrade
Hi, I plan to upgrade ICU to version 50.1.1, best next week to have that ready before the Boost upgrade will happen to avoid having to rebuild the entire chain twice. So don't get overly alarmed by broken dependencies of other packages.. but still fix them in time for the Boost upgrade. Thanks Eike -- LibreOffice Calc developer. Number formatter stricken i18n transpositionizer. New GnuPG key 0x65632D3A : 2265 D7F3 A7B0 95CC 3918 630B 6A6C D5B7 6563 2D3A Old GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD Support the FSFE, care about Free Software! https://fsfe.org/support/?erack pgpwLG5hyS3OG.pgp Description: PGP signature ___ devel-announce mailing list devel-announce@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce
