Re: F21 System Wide Change: Headless Java
Quoting Jerry James (2013-11-18 16:54:28) On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I believe OpenJDK maintainers will agree that automatically detecting if java or java-headless is supposed to be required is not really feasible. There's too many variables at play. Then how are we maintainers supposed to determine if our packages require full java, or just java-headless? Needs X or audio is too vague. Is there a list of packages and/or classes that are present in full java but not in java-headless? Or some kind of explicit set of guidelines I can use to examine my packages to see which they need? You can use following Oracle article as a starting point[1]. But maybe OpenJDK maintainers can provide better alternative. Generally though there are *very* few packages in Fedora that would require full java. [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote: Quoting Toshio Kuratomi (2013-11-18 17:08:12) On Nov 15, 2013 4:09 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jaroslav Reznik (2013-11-15 12:28:11) * (optional) Mass-change spec files that have Requires: java to Requires: java-headless Other developers: * Modify spec files to have Requires: java-headless instead of Requires: java Could you say a few words about why a java-headless package was chosen instead of java-x11 (as an example name)? I believe the term was chosen because it's widely used term in Java world. Oracle uses that term in official documentation as well[1]. Last but not least, Debian uses that term as well and I see no reason to be different just for the sake of it. I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). -Toshio pgpY1XGxzp3Tw.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Using git for patch management in Fedora
Several packages are using git for patch management. eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
Some of these packages have invented home-brewed methods to generate
the Patch lines in the spec file, eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
More importantly, all are using random git repositories to store the
exploded tree. This makes it difficult for co-maintainers and proven
packagers to fit in with the patch management chosen by the
maintainer. Usually they won't have access to the git repository for
these patches, making it difficult to add patches and near impossible
to upgrade to a new version.
I think that git is an excellent way to manage patches, but we ought
to think about formalizing this process. I think the goals should be:
(1) A git repository is used that co-maintainers and proven packagers
automatically have access to.
(2) A single method script is used to update the patches in the spec file.
Although there is already a git repository satisfying (1) above,
namely dist-git, it isn't suitable for storing the exploded tree since
commits to the spec file would conflict with commits (patches) to the
tree. So either a separate side repository which packages could
opt-in to, or perhaps a separate branch of the same git repo could be
used. I think using a branch would require no additional
infrastructure.
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Thoughts on this?
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, 2013-11-19 at 10:22 +, Richard W.M. Jones wrote:
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Or maybe we could start using %autosetup ?
http://www.rpm.org/wiki/PackagerDocs/Autosetup
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
2013/11/19 Richard W.M. Jones rjo...@redhat.com: Several packages are using git for patch management. eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22 http://pkgs.fedoraproject.org/cgit/qemu.git/tree/ http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16 Some of these packages have invented home-brewed methods to generate the Patch lines in the spec file, eg: I hope we'll see some progress in RPM in regards to VCS integrations soon. Because that's the main issue with RPM and related infrastructure nowadays. More importantly, all are using random git repositories to store the exploded tree. This makes it difficult for co-maintainers and proven packagers to fit in with the patch management chosen by the maintainer. Usually they won't have access to the git repository for these patches, making it difficult to add patches and near impossible to upgrade to a new version. I'm using https://git.fedorahosted.org/git/ for that. For example erlang is stored here: https://git.fedorahosted.org/git/erlang.git It contains a mirror of main upstream repo and few branches with Fedora-related patches. I think we should expand this practise (mirroring of a git-reposiories of upstream projects with a Fedora-specific patches) further and add more git mirrors here, at Fedorahosted. I personally love to see fedora kernel as a Git-managed tree instead of few dozens of random patches and a spec-file. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 06:28:47PM +0800, Mathieu Bridon wrote:
On Tue, 2013-11-19 at 10:22 +, Richard W.M. Jones wrote:
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Or maybe we could start using %autosetup ?
http://www.rpm.org/wiki/PackagerDocs/Autosetup
'%autosetup -S git' for sure, not plain %autosetup.
Git correctly handles file modes and binary patches (not that binary
patches should be much of a concern here, but file modes definitely
are).
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 02:32:58PM +0400, Peter Lemenkov wrote: 2013/11/19 Richard W.M. Jones rjo...@redhat.com: Several packages are using git for patch management. eg: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22 http://pkgs.fedoraproject.org/cgit/qemu.git/tree/ http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16 Some of these packages have invented home-brewed methods to generate the Patch lines in the spec file, eg: I hope we'll see some progress in RPM in regards to VCS integrations soon. Because that's the main issue with RPM and related infrastructure nowadays. More importantly, all are using random git repositories to store the exploded tree. This makes it difficult for co-maintainers and proven packagers to fit in with the patch management chosen by the maintainer. Usually they won't have access to the git repository for these patches, making it difficult to add patches and near impossible to upgrade to a new version. I'm using https://git.fedorahosted.org/git/ for that. For example erlang is stored here: https://git.fedorahosted.org/git/erlang.git It contains a mirror of main upstream repo and few branches with Fedora-related patches. Peter, is the comment in the spec file wrong? It refers to two github repos: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 In any case, fedorahosted would be an improvement, but AIUI it doesn't automatically give access to co-maintainers and proven packagers. 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
2013/11/19 Richard W.M. Jones rjo...@redhat.com: Peter, is the comment in the spec file wrong? It refers to two github repos: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 Oops, thanks for pointing me on this. Yes, that's just leftover and should be removed. And the entire patch generation process should be greatly simplified. Patches are welcome btw :) In any case, fedorahosted would be an improvement, but AIUI it doesn't automatically give access to co-maintainers and proven packagers. Yes indeed. Our infrastructure lacks proper integration. What should I do to add you into giterlang group? -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
2013/11/19 Peter Lemenkov lemen...@gmail.com: 2013/11/19 Richard W.M. Jones rjo...@redhat.com: Peter, is the comment in the spec file wrong? It refers to two github repos: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 Oops, thanks for pointing me on this. Yes, that's just leftover and should be removed. And the entire patch generation process should be greatly simplified. Patches are welcome btw :) In any case, fedorahosted would be an improvement, but AIUI it doesn't automatically give access to co-maintainers and proven packagers. Yes indeed. Our infrastructure lacks proper integration. What should I do to add you into giterlang group? Ok, just figured it out by myself. -- With best regards, Peter Lemenkov. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
Richard W.M. Jones rjo...@redhat.com writes:
Several packages are using git for patch management. eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
Some of these packages have invented home-brewed methods to generate
the Patch lines in the spec file, eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
More importantly, all are using random git repositories to store the
exploded tree. This makes it difficult for co-maintainers and proven
packagers to fit in with the patch management chosen by the
maintainer. Usually they won't have access to the git repository for
these patches, making it difficult to add patches and near impossible
to upgrade to a new version.
I think that git is an excellent way to manage patches, but we ought
to think about formalizing this process. I think the goals should be:
(1) A git repository is used that co-maintainers and proven packagers
automatically have access to.
(2) A single method script is used to update the patches in the spec file.
Although there is already a git repository satisfying (1) above,
namely dist-git, it isn't suitable for storing the exploded tree since
commits to the spec file would conflict with commits (patches) to the
tree. So either a separate side repository which packages could
opt-in to, or perhaps a separate branch of the same git repo could be
used. I think using a branch would require no additional
infrastructure.
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Thoughts on this?
ordering, you cannot run $ git am without ordering. Nevertheless, I
would rather use quilt for managing patches in dist-git.
--
Nikola
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 10:22:42AM +, Richard W.M. Jones wrote:
Several packages are using git for patch management. eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
Some of these packages have invented home-brewed methods to generate
the Patch lines in the spec file, eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
More importantly, all are using random git repositories to store the
exploded tree. This makes it difficult for co-maintainers and proven
packagers to fit in with the patch management chosen by the
maintainer. Usually they won't have access to the git repository for
these patches, making it difficult to add patches and near impossible
to upgrade to a new version.
Yep, I've done the same thing for all the packages I maintain in Fedora
and RHEL too. It makes maintaining RPMs soo much easier, particularly
when you have lots of patches to manage. The script I use is
http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patches.pl
I think that git is an excellent way to manage patches, but we ought
to think about formalizing this process. I think the goals should be:
(1) A git repository is used that co-maintainers and proven packagers
automatically have access to.
(2) A single method script is used to update the patches in the spec file.
Although there is already a git repository satisfying (1) above,
namely dist-git, it isn't suitable for storing the exploded tree since
commits to the spec file would conflict with commits (patches) to the
tree. So either a separate side repository which packages could
opt-in to, or perhaps a separate branch of the same git repo could be
used. I think using a branch would require no additional
infrastructure.
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Thoughts on this?
It would certainly be nice to formalize things in this area given that
so many people are re-inventing the wheel here.
I agree that I wouldn't want to have the upstream GIT repo merged into
the Fedora dist-git repos, since that would increase their size by
many orders of magnitude.
It seems like we'd want to have a Fedora hosted parallel GIT repos for
tracking upstream GIT repos that are relevant to the Fedora RPMs.
Preferrably something that could be automated so it auto-synchronizes
the upstream branches, so Fedora maintainers just need to create a new
branch and then cherry-pick -x the patches they need.
Daniel
--
|: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org -o- http://virt-manager.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Source file audit - 2013-11-17
On Mon, Nov 18, 2013 at 5:54 PM, Kevin Fenzi ke...@scrye.com wrote: - I didn't explicitly mention it last time, but you can find the output of the script for your package at: http://www.scrye.com/~kevin/fedora/sourcecheck-20131117/$packagename-dl.txt That should be http://www.scrye.com/~kevin/fedora/sourcecheck/sourcechecl-20131117/$packagename-dl.txt (one sourcecheck dir missing, and sourcechecl typo in the latter) scop:BADURL:bash-completion-2.1.tar.bz2:bash-completion 503, hopefully a transient issue: http://lists.debian.org/debian-infrastructure-announce/2013/11/msg1.html -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, 2013-11-19 at 10:32 +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 06:28:47PM +0800, Mathieu Bridon wrote: Or maybe we could start using %autosetup ? http://www.rpm.org/wiki/PackagerDocs/Autosetup '%autosetup -S git' for sure, not plain %autosetup. Git correctly handles file modes and binary patches (not that binary patches should be much of a concern here, but file modes definitely are). Fair enough. I wasn't really suggesting any option (or the absence of it), but point taken. To be honest, I'd go even further: just like we got rid of %clean sections, maybe we could get rid of %prep sections in most cases? rpmbuild could just assume that if no %prep section is present, then it should just use %autosetup, with a certain set of options agreed upon. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 02:42:00PM +0400, Peter Lemenkov wrote: 2013/11/19 Peter Lemenkov lemen...@gmail.com: 2013/11/19 Richard W.M. Jones rjo...@redhat.com: Peter, is the comment in the spec file wrong? It refers to two github repos: http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46 Oops, thanks for pointing me on this. Yes, that's just leftover and should be removed. And the entire patch generation process should be greatly simplified. Patches are welcome btw :) In any case, fedorahosted would be an improvement, but AIUI it doesn't automatically give access to co-maintainers and proven packagers. Yes indeed. Our infrastructure lacks proper integration. What should I do to add you into giterlang group? Ok, just figured it out by myself. Thanks. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 11:46:46AM +0100, Nikola Pajkovsky wrote:
Richard W.M. Jones rjo...@redhat.com writes:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Thoughts on this?
ordering, you cannot run $ git am without ordering.
This recipe has worked for me for years. The patches are probably
implicitly ordered by their names (ie. 0001-...patch etc)
Nevertheless, I
would rather use quilt for managing patches in dist-git.
This doesn't stop you from using another method to apply the patches.
It doesn't even stop you from using your own home-brew method,
although I think standardizing would help for the majority of packages
since it lets co-maintainers and PPs work on them more easily.
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
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 10:51:01AM +, Daniel P. Berrange wrote: Yep, I've done the same thing for all the packages I maintain in Fedora and RHEL too. It makes maintaining RPMs soo much easier, particularly when you have lots of patches to manage. The script I use is http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patches.pl Cool. It would be nice to improve the script to read References: or Addresses: lines from the git commit messages and use the lines as comments for Patch%d: in the SPEC file. Something like: # https://bugzilla.redhat.com/show_bug.cgi?id=850355 Patch123: 0001-foo-bar.patch Maybe it would be also possible to use the URL to ask bugzilla for bug Id and Subject and then generate SPEC %changelog :-) Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [pkgdb2] call for testers, bug reports and RFE
On Sat, Nov 16, 2013 at 11:19:35AM +0100, Pierre-Yves Chibon wrote: On Sat, Nov 16, 2013 at 12:50:42AM +0100, Kevin Kofler wrote: One thing which is probably an issue with the import process: I looked at the package kdelibs-experimental which has been retired, as seen on pkgdb1: https://admin.fedoraproject.org/pkgdb/acls/name/kdelibs-experimental (see Status=Deprecated). Yet in pkgdb2 it shows up as a regular orphan: http://209.132.184.188/package/kdelibs-experimental/ and offers me to retire it (which it already is) or pick it up. Should I file a ticket for that on GitHub? The question is more likely, when did it get retired? As in: It contains the data from pkgdb1 from about a month ago. I have on my todo to update the database to a more recent version, I'll make sure to check the status of kdelibs-experimental then. I have since updated the database and it turned out to be really a bug in pkgdb2 which I fixed: http://209.132.184.188/package/kdelibs-experimental Best regards, Pierre -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 12:51:29PM +0100, Karel Zak wrote: On Tue, Nov 19, 2013 at 10:51:01AM +, Daniel P. Berrange wrote: Yep, I've done the same thing for all the packages I maintain in Fedora and RHEL too. It makes maintaining RPMs soo much easier, particularly when you have lots of patches to manage. The script I use is http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patches.pl Cool. It would be nice to improve the script to read References: or Addresses: lines from the git commit messages and use the lines as comments for Patch%d: in the SPEC file. Something like: # https://bugzilla.redhat.com/show_bug.cgi?id=850355 Patch123: 0001-foo-bar.patch Maybe it would be also possible to use the URL to ask bugzilla for bug Id and Subject and then generate SPEC %changelog :-) The erlang patches script also reads various information from the commit comments too. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Developers, who base their work on Fedora's *-devel packages, will publish something that's incompatible with pristine upstream releases. Unless they make their software detect the different install locations (or renamed libs even). 2. we ship a pkgconfig file, which upstream does not want A .pc file only adds value, if every API consumer uses pkg-config. Where pkg-config is not used, locating moved headers becomes troublesome, and lazy developers would simply hardcode search paths in Makefiles, or worse, in #include-statements. I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. To be fair, a single bug report doesn't have much weight. It's easy enough to list the package contents and notice where the headers are stored. The differences between multiple distributions (as well as upstream) are not so good, however. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. Agreed. Though, this is more of a problem for the API consumers, who ought to support not just Fedora's libev packages but also pristine upstream libev. Afterall, their software would only build for Fedora. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) Seems plausible. Personally, I don't mind explicitly conflicting -devel packages, especially not if they are unlikely to be present in the same buildroot (and libev's event.h is a libevent compatibility header). But in general, conflicts bear a risk and may lead to future problems, and I would have opened this thread on packaging@ list instead. * Drop our pkgconfig file. Upstream really doesn't like pkgconfig. Does anybody have any comment, or objection? This one is weird: https://bugzilla.redhat.com/672153 In order to make the perl-EV package not use a bundled libev source, you build a libev-source subpackage that perl-EV adds as BuildRequires. In other words, perl-EV now still bundles libev, but only indirectly. An update of libev does not affect perl-EV until perl-EV is rebuilt. libev has been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt. Such a dependency ought to be tracked in a special way, preferably with official blessing from the FPC. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 12:14:42PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 12:51:29PM +0100, Karel Zak wrote: On Tue, Nov 19, 2013 at 10:51:01AM +, Daniel P. Berrange wrote: Yep, I've done the same thing for all the packages I maintain in Fedora and RHEL too. It makes maintaining RPMs soo much easier, particularly when you have lots of patches to manage. The script I use is http://pkgs.fedoraproject.org/cgit/libvirt-sandbox.git/tree/update-patches.pl Cool. It would be nice to improve the script to read References: or Addresses: lines from the git commit messages and use the lines as comments for Patch%d: in the SPEC file. Something like: # https://bugzilla.redhat.com/show_bug.cgi?id=850355 Patch123: 0001-foo-bar.patch Maybe it would be also possible to use the URL to ask bugzilla for bug Id and Subject and then generate SPEC %changelog :-) The erlang patches script also reads various information from the commit comments too. We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git list log for exploded/upstream..exploded/f20 (or only --new commits which not found in .spec): fedpkg exploded-tree log [--new] generate PatchN: .spec file lines, call git format-patch and git-add from exploded/upstream..exploded/f20 stuff: fedpkg exploded-tree update-patches generate %changelog according to References: from commit messages: fedpkg exploded-tree update-changelog ... dreaming is so simple, volunteers? :-) Karel -- Karel Zak k...@redhat.com http://karelzak.blogspot.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Reminder: Fedora 20 Final Change Deadline in one week (2013-11-26)
Greetings, this is a reminder that Fedora 20 Final Change Deadline is in one week - 2013-11-26, see the Schedule [1]. Be aware of that period between Beta release and Final release is one week shorter as approved by FESCo [2] to avoid holidays. Make sure to submit and get karma for your updates in Bodhi on time. After the Final Change Deadline, only accepted Blockers [3] and Freeze Exception [4] will be allowed into Fedora 20 Final. All updates after this time are considered zero day updates. Please take a look on outstanding Final blocker tracker [5]. This is the list of accepted blockers still in NEW/ASSIGNED state: 1008732 anaconda LUKSError: luks device not configured 1013586 anaconda SizeNotPositiveError: spec= param must be =0 1020974 anaconda incorrectly treats a disk with partially corrupt GPT as having no partition at all 1027965 anaconda CreateException: Can't have a partition outside the disk! 1028110 anaconda LVMError: lvresize failed for root: running lvm lvresize --force -L 8712m fedora/root failed 1028367 anaconda Invalid resize operation crashes 864198 grubby grubby fatal error updating grub.cfg when /boot is btrfs 1028207 kbd non US keyboard layouts not working at console 1030719 pungi tmux segfaults on start in 32-bit Fedora 20 TC1 install images due to libevent-2.0.so.5 being corrupt, causing anaconda to fail to start 790339 system-config-services [abrt] system-config-services-0.101.7-2.fc17: connection.py:630:call_blocking:DBusException: org.freedesktop. DBus.Error.UnknownMethod: Method list_services with signature on interface org.fedoraproject.Config.Services.ServiceHerder doesn't exist 1008965 xorg-x11-server mouse cursor sometimes disappears on login Jaroslav [1] https://fedoraproject.org/wiki/Releases/20/Schedule [2] https://fedorahosted.org/fesco/ticket/1191 [3] https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process [4] https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process [5] https://qa.fedoraproject.org/blockerbugs/milestone/20/final/buglist ___ devel-announce mailing list devel-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel-announce -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 13:36 +0100, Michael Schwendt wrote: On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Developers, who base their work on Fedora's *-devel packages, will publish something that's incompatible with pristine upstream releases. Unless they make their software detect the different install locations (or renamed libs even). That's in fact what is happening, which is why I'd like to get the Fedora package inline with upstream and other distros. 2. we ship a pkgconfig file, which upstream does not want A .pc file only adds value, if every API consumer uses pkg-config. Where pkg-config is not used, locating moved headers becomes troublesome, and lazy developers would simply hardcode search paths in Makefiles, or worse, in #include-statements. I agree, but again, upstream refused it several times (Michal, the original libev maintainer offered it, I did, the awesome developers did too,...) At this point, I really just want to have the Fedora package inline with upstream, so that consumers of the library use it the same way everywhere. Personally, I don't mind explicitly conflicting -devel packages, especially not if they are unlikely to be present in the same buildroot (and libev's event.h is a libevent compatibility header). So, libev's ev.h and libevent's event.h might very well be installed on the same system, in the case of a developer working on two different applications, or on something like libverto (a wrapper for different event loops). But libev's event.h and libevent's event.h should not. But in general, conflicts bear a risk and may lead to future problems, and I would have opened this thread on packaging@ list instead. Oh? Should we move there now? I thought devel@ was better, as it needed to reach the maintainers of the packages which build against libev. Does anybody have any comment, or objection? This one is weird: https://bugzilla.redhat.com/672153 In order to make the perl-EV package not use a bundled libev source, you build a libev-source subpackage that perl-EV adds as BuildRequires. In other words, perl-EV now still bundles libev, but only indirectly. An update of libev does not affect perl-EV until perl-EV is rebuilt. libev has been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt. Right, it's certainly unorthodox. The problem is that libev is actually intended to be bundled by upstream, and perl-EV is made by the same people. As a result, they **really** don't want to unbundle libev from perl-EV. The approach I followed was a compromise, it's definitely not the most desirable outcome. Such a dependency ought to be tracked in a special way, preferably with official blessing from the FPC. I didn't pass it through FPC because there are a few precedents. The one I inspired myself from is xorg-x11-server-source. I assumed that given there were already quite a few of these, it was an accepted practice. Did I assume wrong? -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
F-20 Branched report: 20131119 changes
Compose started at Tue Nov 19 09:15:02 UTC 2013 Broken deps for armhfp -- [avro] avro-mapred-1.7.5-1.fc20.noarch requires hadoop-mapreduce avro-mapred-1.7.5-1.fc20.noarch requires hadoop-client [blueman] blueman-1.23-7.fc20.armv7hl requires obex-data-server = 0:0.4.3 blueman-1.23-7.fc20.armv7hl requires gvfs-obexftp [cloud-init] cloud-init-0.7.2-7.fc20.noarch requires dmidecode [cobbler] cobbler-2.4.0-2.fc20.noarch requires syslinux [condor-wallaby] condor-wallaby-client-5.0.3-5.fc20.noarch requires python-qpid-qmf = 0:0.9.1073306 [fence-agents] fence-agents-common-4.0.4-3.fc20.armv7hl requires pexpect [fts] fts-server-3.1.1-1.fc20.armv7hl requires libactivemq-cpp.so.14 [glpi] glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Version glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Stdlib glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-ServiceManager glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Loader glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-I18n glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache-apc glpi-0.84.3-1.fc20.noarch requires php-ZendFramework2-Cache [gnome-do-plugins] gnome-do-plugins-thunderbird-0.8.4-14.fc20.armv7hl requires thunderbird [gofer] ruby-gofer-0.75-4.fc20.noarch requires rubygem(qpid) = 0:0.16.0 [gtkd] gtkd-geany-tags-2.0.0-29.20120815git9ae9181.fc18.noarch requires gtkd = 0:2.0.0-29.20120815git9ae9181.fc18 [ipython] python-ipython-console-0.13.2-2.fc20.noarch requires pexpect python3-ipython-console-0.13.2-2.fc20.noarch requires python3-pexpect [kawa] 1:kawa-1.11-5.fc19.armv7hl requires servlet25 [koji] koji-vm-1.8.0-2.fc20.noarch requires python-virtinst [kyua-cli] kyua-cli-0.5-3.fc19.armv7hl requires liblutok.so.0 kyua-cli-tests-0.5-3.fc19.armv7hl requires liblutok.so.0 [mozilla-firetray] mozilla-firetray-thunderbird-0.3.6-0.5.143svn.fc18.1.armv7hl requires thunderbird = 0:11 [msp430-libc] msp430-libc-20120224-2.fc19.noarch requires msp430-gcc = 0:4.6.3 [nifti2dicom] nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtksys.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkWidgets.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkVolumeRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkViews.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkTextAnalysis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkRendering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkParallel.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkInfovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkImaging.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkIO.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkHybrid.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGraphics.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGeovis.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkGenericFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkFiltering.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCommon.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libvtkCharts.so.5.10 nifti2dicom-0.4.6-3.fc20.armv7hl requires libQVTK.so.5.10 [nocpulse-common] nocpulse-common-2.2.7-2.fc20.noarch requires perl(RHN::DBI) [openbox] gdm-control-3.5.2-2.fc20.armv7hl requires gnome-panel gnome-panel-control-3.5.2-2.fc20.armv7hl requires gnome-panel [openlmi-providers] openlmi-0.4.0-1.fc20.noarch requires openlmi-power [openpts] openpts-0.2.6-7.fc20.armv7hl requires tboot [perl-Language-Expr] perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) [pure] pure-doc-0.57-4.fc20.noarch requires pure = 0:0.57-4.fc20 [python-requests-oauthlib] python-requests-oauthlib-0.4.0-2.fc20.noarch requires python-oauthlib [python-tag] python-tag-2013.1-1.fc20.armv7hl requires libboost_python.so.1.53.0 [qpid-cpp] qpid-cpp-server-ha-0.24-6.fc20.armv7hl requires qpid-qmf(armv7hl-32) qpid-tools-0.24-6.fc20.noarch requires python-qpid-qmf [rootplot] rootplot-2.2.1-7.fc19.noarch requires root-python [ruby-spqr] ruby-spqr-0.3.6-7.fc20.noarch requires ruby-qpid-qmf [rubygem-audited-activerecord] rubygem-audited-activerecord-3.0.0-3.fc19.noarch requires rubygem(activerecord) 0:4 [scilab] scilab-doc-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20 scilab-tests-5.4.1-4.fc20.noarch requires scilab = 0:5.4.1-4.fc20 [sigul] sigul-0.100-3.fc20.noarch requires pexpect [spacewalk-admin] spacewalk-admin-2.0.1-2.fc20.noarch requires
[Bug 977266] perl-ExtUtils-Typemaps-Default-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=977266 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-ExtUtils-Typemaps-Default-1.04-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-ExtUtils-Typemaps-Default-1.04-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=g8pdsrw2lca=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 977266] perl-ExtUtils-Typemaps-Default-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=977266 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-ExtUtils-Typemaps-Default-1.04-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-ExtUtils-Typemaps-Default-1.04-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=k19fpBO4RQa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 977266] perl-ExtUtils-Typemaps-Default-1.04 is available
https://bugzilla.redhat.com/show_bug.cgi?id=977266 Fedora Update System upda...@fedoraproject.org changed: What|Removed |Added Status|CLOSED |MODIFIED Resolution|RAWHIDE |--- Keywords||Reopened -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=8WEYvn7D7Pa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. I agree in general that this could be something added to / aided by fedpkg. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Tk-Pod-0.9942.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Tk-Pod: 3cbd1b44b83a129ec7ac0a33f6913fa8 Tk-Pod-0.9942.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1032056] Slic3r 1.0.0RC1 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1032056 --- Comment #1 from Miro Hrončok mhron...@redhat.com --- Bundled admesh is one of the issues in this version we have to take care of: https://github.com/alexrj/Slic3r/issues/1525 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=sZsyXfiWlia=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Tk-Pod] 0.9942 bump
commit 94bbe49dbeea28fdbaa3653300ee62f028eb169a
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 19 14:29:21 2013 +0100
0.9942 bump
.gitignore |1 +
perl-Tk-Pod.spec | 102 ++
sources |2 +-
3 files changed, 89 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 27790f7..f0e2cc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Tk-Pod-0.9939.tar.gz
/Tk-Pod-0.9940.tar.gz
/Tk-Pod-0.9941.tar.gz
+/Tk-Pod-0.9942.tar.gz
diff --git a/perl-Tk-Pod.spec b/perl-Tk-Pod.spec
index 42c8a9e..f1ee681 100644
--- a/perl-Tk-Pod.spec
+++ b/perl-Tk-Pod.spec
@@ -1,44 +1,116 @@
%global use_x11_tests 1
Name: perl-Tk-Pod
-Version:0.9941
-Release:4%{?dist}
+Version:0.9942
+Release:1%{?dist}
Summary:Pod browser top-level widget
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Tk-Pod/
Source0:
http://www.cpan.org/authors/id/S/SR/SREZIC/Tk-Pod-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(Pod::Simple) = 2.05
BuildRequires: perl(Tk) = 800.004
-# Tests:
+# Run-time:
+# AnyDBM_File not used at tests
BuildRequires: perl(base)
-BuildRequires: perl(Devel::Hide)
+BuildRequires: perl(Benchmark)
+BuildRequires: perl(blib)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Class::Struct)
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+# Data::Dumper not used at tests
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::Command::MM)
+# Fcntl not used at tests
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Find)
+# File::HomeDir never used
BuildRequires: perl(File::Spec)
-BuildRequires: perl(File::Temp)
-BuildRequires: perl(FindBin)
BuildRequires: perl(Getopt::Long)
-BuildRequires: perl(Test::More)
+# I18N::Langinfo is optional
+BuildRequires: perl(IO::Socket)
+# Module::Refresh not used at tests
+# PerlIO::gzip is optional
+# Pod::Functions not used at tests
+BuildRequires: perl(Pod::Simple) = 2.05
+BuildRequires: perl(Pod::Simple::PullParser)
+# Pod::Simple::PullParserEndToken not used at tests
+# Pod::Simple::PullParserStartToken not used at tests
+# Pod::Simple::PullParserTextToken not used at tests
+# Pod::Simple::RTF is never used
+# Pod::Simple::Text is never used
+# Pod::Usage not used at tests
+BuildRequires: perl(POSIX)
+# Proc::ProcessTable is optional
+BuildRequires: perl(Safe)
+BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
+# Text::English not used at tests
+# Text::Wrap is never used
+# Tk::App::Debug is optional
+# Tk::App::Reloader is optional
+BuildRequires: perl(Tk::BrowseEntry)
+# Tk::Compound is optional and not needed wih Tk = 804
BuildRequires: perl(Tk::Derived)
+# Tk::DialogBox not used at tests
+# Tk::FileSelect not used at tests
+BuildRequires: perl(Tk::Frame)
+# Tk::HistEntry is optional
+# Tk::HList is not needed wih Tk = 800.024012
+BuildRequires: perl(Tk::ItemStyle)
+BuildRequires: perl(Tk::LabEntry)
+# Tk::Listbox is not needed wih Tk = 800.024012
BuildRequires: perl(Tk::ROText)
+# Tk::ToolBar is optional
+BuildRequires: perl(Tk::Toplevel)
+BuildRequires: perl(Tk::Tree)
+BuildRequires: perl(Tk::Widget)
+# URI::Escape is optional
+BuildRequires: perl(vars)
+# Win32 is never used
+# Win32Util is never used
+# Tests:
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Devel::Hide)
+BuildRequires: perl(ExtUtils::Command::MM)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(lib)
BuildRequires: perl(Test)
+BuildRequires: perl(Test::More)
# Optional tests:
#BuildRequires: perl(Tk::HistEntry) = 0.4
-#BuildRequires: perl(Text::English)
%if %{use_x11_tests}
# X11 tests:
BuildRequires: xorg-x11-server-Xvfb
BuildRequires: xorg-x11-xinit
BuildRequires: font(:lang=en)
%endif
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Benchmark)
+Requires: perl(blib)
Requires: perl(File::Temp)
+Requires: perl(Module::Refresh)
+Requires: perl(Pod::Functions)
Requires: perl(Pod::Simple) = 2.05
+Requires: perl(Pod::Simple::PullParserEndToken)
+Requires: perl(Pod::Simple::PullParserStartToken)
+Requires: perl(Pod::Simple::PullParserTextToken)
+Requires: perl(Pod::Usage)
+Requires: perl(POSIX)
+Requires: perl(Safe)
+Requires: perl(Storable)
Requires: perl(Tk) = 800.004
+Requires: perl(Tk::BrowseEntry)
+Requires: perl(Tk::DialogBox)
+Requires: perl(Tk::FileSelect)
+Requires: perl(Tk::LabEntry)
+Requires: perl(Tk::ROText)
+Requires: perl(Tk::Widget)
# URI::Escape is optional but usefull to
[perl-Tk-Pod/f20] 0.9942 bump
Summary of changes: 94bbe49... 0.9942 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Packaging changes for libev in Rawhide
On 11/19/2013 02:01 PM, Mathieu Bridon wrote: On Tue, 2013-11-19 at 13:36 +0100, Michael Schwendt wrote: On Tue, 19 Nov 2013 15:30:46 +0800, Mathieu Bridon wrote: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ That's a common way to resolve such a conflict: https://fedoraproject.org/wiki/Packaging:Conflicts#Header_Name_Conflicts However, it gets problematic when such a change is not accepted by upstream. Upstream needs to comprehend, they do not have any control over installation locations. Users/system integrators/installers have the freedom to choose installations locations at their choice, at free will. Ralf -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Tk-Pod/f19] 0.9942 bump
commit e778f67cdd5cfc95296023732b4d10e64286aff1
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 19 14:29:21 2013 +0100
0.9942 bump
.gitignore |1 +
perl-Tk-Pod.spec | 102 ++
sources |2 +-
3 files changed, 89 insertions(+), 16 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 27790f7..f0e2cc3 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
/Tk-Pod-0.9939.tar.gz
/Tk-Pod-0.9940.tar.gz
/Tk-Pod-0.9941.tar.gz
+/Tk-Pod-0.9942.tar.gz
diff --git a/perl-Tk-Pod.spec b/perl-Tk-Pod.spec
index 8a584e4..0cc5af4 100644
--- a/perl-Tk-Pod.spec
+++ b/perl-Tk-Pod.spec
@@ -1,44 +1,116 @@
%global use_x11_tests 1
Name: perl-Tk-Pod
-Version:0.9941
-Release:2%{?dist}
+Version:0.9942
+Release:1%{?dist}
Summary:Pod browser top-level widget
License:GPL+ or Artistic
Group: Development/Libraries
URL:http://search.cpan.org/dist/Tk-Pod/
Source0:
http://www.cpan.org/authors/id/S/SR/SREZIC/Tk-Pod-%{version}.tar.gz
BuildArch: noarch
+BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Temp)
BuildRequires: perl(Pod::Simple) = 2.05
BuildRequires: perl(Tk) = 800.004
-# Tests:
+# Run-time:
+# AnyDBM_File not used at tests
BuildRequires: perl(base)
-BuildRequires: perl(Devel::Hide)
+BuildRequires: perl(Benchmark)
+BuildRequires: perl(blib)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Class::Struct)
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+# Data::Dumper not used at tests
BuildRequires: perl(Exporter)
-BuildRequires: perl(ExtUtils::Command::MM)
+# Fcntl not used at tests
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Find)
+# File::HomeDir never used
BuildRequires: perl(File::Spec)
-BuildRequires: perl(File::Temp)
-BuildRequires: perl(FindBin)
BuildRequires: perl(Getopt::Long)
-BuildRequires: perl(Test::More)
+# I18N::Langinfo is optional
+BuildRequires: perl(IO::Socket)
+# Module::Refresh not used at tests
+# PerlIO::gzip is optional
+# Pod::Functions not used at tests
+BuildRequires: perl(Pod::Simple) = 2.05
+BuildRequires: perl(Pod::Simple::PullParser)
+# Pod::Simple::PullParserEndToken not used at tests
+# Pod::Simple::PullParserStartToken not used at tests
+# Pod::Simple::PullParserTextToken not used at tests
+# Pod::Simple::RTF is never used
+# Pod::Simple::Text is never used
+# Pod::Usage not used at tests
+BuildRequires: perl(POSIX)
+# Proc::ProcessTable is optional
+BuildRequires: perl(Safe)
+BuildRequires: perl(Storable)
+BuildRequires: perl(strict)
+# Text::English not used at tests
+# Text::Wrap is never used
+# Tk::App::Debug is optional
+# Tk::App::Reloader is optional
+BuildRequires: perl(Tk::BrowseEntry)
+# Tk::Compound is optional and not needed wih Tk = 804
BuildRequires: perl(Tk::Derived)
+# Tk::DialogBox not used at tests
+# Tk::FileSelect not used at tests
+BuildRequires: perl(Tk::Frame)
+# Tk::HistEntry is optional
+# Tk::HList is not needed wih Tk = 800.024012
+BuildRequires: perl(Tk::ItemStyle)
+BuildRequires: perl(Tk::LabEntry)
+# Tk::Listbox is not needed wih Tk = 800.024012
BuildRequires: perl(Tk::ROText)
+# Tk::ToolBar is optional
+BuildRequires: perl(Tk::Toplevel)
+BuildRequires: perl(Tk::Tree)
+BuildRequires: perl(Tk::Widget)
+# URI::Escape is optional
+BuildRequires: perl(vars)
+# Win32 is never used
+# Win32Util is never used
+# Tests:
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Devel::Hide)
+BuildRequires: perl(ExtUtils::Command::MM)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(lib)
BuildRequires: perl(Test)
+BuildRequires: perl(Test::More)
# Optional tests:
#BuildRequires: perl(Tk::HistEntry) = 0.4
-#BuildRequires: perl(Text::English)
%if %{use_x11_tests}
# X11 tests:
BuildRequires: xorg-x11-server-Xvfb
BuildRequires: xorg-x11-xinit
BuildRequires: font(:lang=en)
%endif
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Benchmark)
+Requires: perl(blib)
Requires: perl(File::Temp)
+Requires: perl(Module::Refresh)
+Requires: perl(Pod::Functions)
Requires: perl(Pod::Simple) = 2.05
+Requires: perl(Pod::Simple::PullParserEndToken)
+Requires: perl(Pod::Simple::PullParserStartToken)
+Requires: perl(Pod::Simple::PullParserTextToken)
+Requires: perl(Pod::Usage)
+Requires: perl(POSIX)
+Requires: perl(Safe)
+Requires: perl(Storable)
Requires: perl(Tk) = 800.004
+Requires: perl(Tk::BrowseEntry)
+Requires: perl(Tk::DialogBox)
+Requires: perl(Tk::FileSelect)
+Requires: perl(Tk::LabEntry)
+Requires: perl(Tk::ROText)
+Requires: perl(Tk::Widget)
# URI::Escape is optional but usefull to
Agenda for today's Env-and-Stacks WG meeting (2013-11-19)
My apologies for the last minute agenda. We'll be holding our initial WG meeting today at 16:00 UTC in #fedora-meeting on Freenode. We'll cover the various items below. I will try and keep the meeting under 1 hour. == Status == - wiki page - trac instance https://fedorahosted.org/fedora-infrastructure/ticket/4124 == Next Steps == - PRD == Open Floor == -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 19 Nov 2013 21:01:06 +0800, Mathieu Bridon wrote:
This one is weird:
https://bugzilla.redhat.com/672153
In order to make the perl-EV package not use a bundled libev source,
you build a libev-source subpackage that perl-EV adds as BuildRequires.
In other words, perl-EV now still bundles libev, but only indirectly. An
update of libev does not affect perl-EV until perl-EV is rebuilt. libev has
been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been rebuilt.
Right, it's certainly unorthodox.
The problem is that libev is actually intended to be bundled by
upstream, and perl-EV is made by the same people.
It's similar with libeio (retired) and Perl IO::AIO by the same author.
The Perl module contains a renamed and private DSO lib built from a
bundled copy of the library sources. Even if the Perl module could be
patched to use the system-wide DSO lib instead, there are no guarantees
about API/ABI stability. Even if the system lib has been compatible for a
long time, it may break in future releases, and e.g. the module may include
a modified bundled lib source eventually.
As a result, they **really** don't want to unbundle libev from perl-EV.
The approach I followed was a compromise, it's definitely not the most
desirable outcome.
Such a dependency ought to be tracked in a special way, preferably with
official blessing from the FPC.
I didn't pass it through FPC because there are a few precedents. The one
I inspired myself from is xorg-x11-server-source.
I assumed that given there were already quite a few of these, it was an
accepted practice.
Did I assume wrong?
I think so.
The current packaging approach is circumventing the packaging policies:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
perl-EV does not use the system libev. No real unbundling has been
achieved by replacing the bundled source with another copy at build-time.
A bug-fix (or security-fix) of libev would not affect perl-EV without
rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
dependency, but only:
BuildRequires: libev-source = %{version}
As a result, it is not ensured that a rebuild picks up the latest patched
libev-source. Even a buildroot override would be needed.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
This is definitely worth formalizing.
On 11/19/2013 10:22 AM, Richard W.M. Jones wrote:
Several packages are using git for patch management. eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/erlang.spec#n46
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/libguestfs.spec?h=f20#n22
http://pkgs.fedoraproject.org/cgit/qemu.git/tree/
http://pkgs.fedoraproject.org/cgit/ocaml.git/tree/ocaml.spec#n16
All the OpenStack packages also use this technique too:
Specifically you use a comment of the form to mark the auto generated patches:
# patches_base=$tag
For example see:
http://pkgs.fedoraproject.org/cgit/openstack-nova.git/tree/openstack-nova.spec#n37
One can also add an optional +number to skip that many patches after a tag,
which we found useful in various cases.
Some of these packages have invented home-brewed methods to generate
the Patch lines in the spec file, eg:
http://pkgs.fedoraproject.org/cgit/erlang.git/tree/otp-get-patches.sh
http://pkgs.fedoraproject.org/cgit/libguestfs.git/tree/copy-patches.sh?h=f20
https://github.com/redhat-openstack/redhat-openstack.github.com/blob/scripts/update-patches.sh
More importantly, all are using random git repositories to store the
exploded tree. This makes it difficult for co-maintainers and proven
packagers to fit in with the patch management chosen by the
maintainer. Usually they won't have access to the git repository for
these patches, making it difficult to add patches and near impossible
to upgrade to a new version.
I think that git is an excellent way to manage patches, but we ought
to think about formalizing this process. I think the goals should be:
(1) A git repository is used that co-maintainers and proven packagers
automatically have access to.
This would be the crux of formalizing this.
For the OpenStack packages we use a separate github organisation
to manage this (as well as other things):
http://github.com/redhat-openstack/
(2) A single method script is used to update the patches in the spec file.
Although there is already a git repository satisfying (1) above,
namely dist-git, it isn't suitable for storing the exploded tree since
commits to the spec file would conflict with commits (patches) to the
tree. So either a separate side repository which packages could
opt-in to, or perhaps a separate branch of the same git repo could be
used. I think using a branch would require no additional
infrastructure.
For (2) I would suggest a lightweight technique where git-managed
patches are marked in the spec file using:
### GIT-MANAGED-PATCHES ###
### END-GIT-MANGED-PATCHES ###
and a simple script that replaces everything between those marks with
Patch lines. The script could be adapted from copy-patches.sh
(see above).
To apply the patches, a standard RPM macro could be created:
%prep
%setup -q
%{git_apply_patches}
which would expand to something like:
git init
git config user.email %{name}-ow...@fedoraproject.org
git config user.name %{name}
git add .
git commit -a -q -m %{version} baseline
git am %{patches}
Thoughts on this?
Using patch(1) to apply patches mostly works with a few caveats
(binary patches come to mind). Using git to apply is a new dependency
but also the most general method for applying.
thanks,
Pádraig.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the rawhide tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a Upstream GIT URL option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
* Stanislav Ochotnicky sochotni...@redhat.com [2013-11-19 03:35]: Quoting Jerry James (2013-11-18 16:54:28) On Sun, Nov 17, 2013 at 11:20 PM, Stanislav Ochotnicky sochotni...@redhat.com wrote: I believe OpenJDK maintainers will agree that automatically detecting if java or java-headless is supposed to be required is not really feasible. There's too many variables at play. Then how are we maintainers supposed to determine if our packages require full java, or just java-headless? Needs X or audio is too vague. Is there a list of packages and/or classes that are present in full java but not in java-headless? Or some kind of explicit set of guidelines I can use to examine my packages to see which they need? You can use following Oracle article as a starting point[1]. But maybe OpenJDK maintainers can provide better alternative. Generally though there are *very* few packages in Fedora that would require full java. Another possible resource is checking the Debian package repo -- they have had headless/full separated for a while (maybe even from the start?): e.g. Azureus needs full: http://packages.debian.org/wheezy/azureus and ant needs headless: http://packages.debian.org/wheezy/ant Of course it is no guarantee that Debian is perfect -- if we find any known issues, we can report back accordingly to help improve their set up too. Deepak [1] http://www.oracle.com/technetwork/articles/javase/headless-136834.html -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File ExtUtils-Typemap-1.00.tar.gz uploaded to lookaside cache by churchyard
A file has been added to the lookaside cache for perl-ExtUtils-Typemap: a7175a06e27939a83b1b781e91c13ad0 ExtUtils-Typemap-1.00.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Typemap] Initial import (#1032055)
commit bd91bc96e61a21e404b4c289a2e993afdf716899
Author: Miro Hrončok m...@hroncok.cz
Date: Tue Nov 19 17:03:53 2013 +0100
Initial import (#1032055)
.gitignore |1 +
perl-ExtUtils-Typemap.spec | 53
sources|1 +
3 files changed, 55 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..c0c57a6 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/ExtUtils-Typemap-1.00.tar.gz
diff --git a/perl-ExtUtils-Typemap.spec b/perl-ExtUtils-Typemap.spec
new file mode 100644
index 000..0b90230
--- /dev/null
+++ b/perl-ExtUtils-Typemap.spec
@@ -0,0 +1,53 @@
+Name: perl-ExtUtils-Typemap
+Version:1.00
+Release:1%{?dist}
+Summary:Read/Write/Modify Perl/XS typemap files
+# README says as Perl...
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/ExtUtils-Typemap/
+Source0:
http://www.cpan.org/authors/id/S/SM/SMUELLER/ExtUtils-Typemap-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::Typemaps)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+
+%description
+This module exists merely as a compatibility wrapper around
+ExtUtils::Typemaps. In a nutshell, ExtUtils::Typemap was renamed to
+ExtUtils::Typemaps because the Typemap directory in lib/ could collide with
+the typemap file on case-insensitive file systems.
+
+%prep
+%setup -q -n ExtUtils-Typemap-%{version}
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=%{buildroot}
+
+find %{buildroot} -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} %{buildroot}/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorlib}/ExtUtils/Typemap.pm
+%{perl_vendorlib}/ExtUtils/Typemap/
+%{_mandir}/man3/ExtUtils::Typemap.3*
+%{_mandir}/man3/ExtUtils::Typemap::*
+
+%changelog
+* Tue Nov 19 2013 Miro Hrončok mhron...@redhat.com 1.00-1
+- Specfile autogenerated by cpanspec 1.78 and revised
diff --git a/sources b/sources
index e69de29..8a7def0 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+a7175a06e27939a83b1b781e91c13ad0 ExtUtils-Typemap-1.00.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1031270] perl-PPIx-Regexp-0.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031270 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|MODIFIED Fixed In Version||perl-PPIx-Regexp-0.035-1.fc ||21 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=hAww6UBCQqa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1031270] perl-PPIx-Regexp-0.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031270 --- Comment #2 from Fedora Update System upda...@fedoraproject.org --- perl-PPIx-Regexp-0.035-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/perl-PPIx-Regexp-0.035-1.fc20 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=TYczRZZ3fea=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1031270] perl-PPIx-Regexp-0.035 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031270 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-PPIx-Regexp-0.035-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-PPIx-Regexp-0.035-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uvyanUFu2la=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 962125] perl-PPIx-Regexp-0.034 is available
https://bugzilla.redhat.com/show_bug.cgi?id=962125 --- Comment #3 from Fedora Update System upda...@fedoraproject.org --- perl-PPIx-Regexp-0.035-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/perl-PPIx-Regexp-0.035-1.fc19 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=kNuoaHdeZha=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Typemap/f20] Initial import (#1032055)
Summary of changes: bd91bc9... Initial import (#1032055) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Typemap/f19] Initial import (#1032055)
Summary of changes: bd91bc9... Initial import (#1032055) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-ExtUtils-Typemap/el6] Initial import (#1032055)
Summary of changes: bd91bc9... Initial import (#1032055) (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: Headless Java
Quoting Toshio Kuratomi (2013-11-19 10:49:57) On Tue, Nov 19, 2013 at 09:29:40AM +0100, Stanislav Ochotnicky wrote: Quoting Toshio Kuratomi (2013-11-18 17:08:12) On Nov 15, 2013 4:09 AM, Stanislav Ochotnicky sochotni...@redhat.com wrote: Quoting Jaroslav Reznik (2013-11-15 12:28:11) * (optional) Mass-change spec files that have Requires: java to Requires: java-headless Other developers: * Modify spec files to have Requires: java-headless instead of Requires: java Could you say a few words about why a java-headless package was chosen instead of java-x11 (as an example name)? I believe the term was chosen because it's widely used term in Java world. Oracle uses that term in official documentation as well[1]. Last but not least, Debian uses that term as well and I see no reason to be different just for the sake of it. I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). If someone wanted to install just OpenJDK for their own in-house Java application they would have to know to request full -x11 version. I would wager we'd be receiving a lot of bugs if we went this way. If someone needs headless they will be actively looking for it. If they want java they will not consider that they might get incomplete version. Not to mention possible 3rd party RPMs that might exist -- Stanislav Ochotnicky sochotni...@redhat.com Software Engineer - Developer Experience PGP: 7B087241 Red Hat Inc. http://cz.redhat.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Coro-6.33.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Coro: edad4fbd0458e95b3f1734b09852d273 Coro-6.33.tar.gz -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Re: F21 System Wide Change: Headless Java
Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky: I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). If someone wanted to install just OpenJDK for their own in-house Java application they would have to know to request full -x11 version. I would wager we'd be receiving a lot of bugs if we went this way. If someone needs headless they will be actively looking for it. If they want java they will not consider that they might get incomplete version. Not to mention possible 3rd party RPMs that might exist what about having a java-1.7.0-openjdk meta-package obsoleting the existing one and pulling *both* but decide if Fedora packages if the headless is enough for dependencies and so packagers of sevrer software can require this? this way you would have the least surprise for someone who does not care about the difference and expects the full one by install java-1.7.0-openjdk but make it really easy to uninstall any graphical dependencies on servers signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[perl-Coro] 6.33 bump
commit b5215cc6286b3f54b0f9d1d6e0a40ddcfdb99b23
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 19 17:22:50 2013 +0100
6.33 bump
.gitignore |1 +
perl-Coro.spec |5 -
sources|2 +-
3 files changed, 6 insertions(+), 2 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index f6cb42b..a61af71 100644
--- a/.gitignore
+++ b/.gitignore
@@ -14,3 +14,4 @@
/Coro-6.29.tar.gz
/Coro-6.31.tar.gz
/Coro-6.32.tar.gz
+/Coro-6.33.tar.gz
diff --git a/perl-Coro.spec b/perl-Coro.spec
index 968ab8d..4505ee4 100644
--- a/perl-Coro.spec
+++ b/perl-Coro.spec
@@ -1,5 +1,5 @@
Name: perl-Coro
-Version:6.32
+Version:6.33
Release:1%{?dist}
Summary:The only real threads in perl
# Coro/libcoro:GPLv2 or BSD
@@ -148,6 +148,9 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 19 2013 Petr Pisar ppi...@redhat.com - 6.33-1
+- 6.33 bump
+
* Wed Nov 06 2013 Petr Pisar ppi...@redhat.com - 6.32-1
- 6.32 bump
diff --git a/sources b/sources
index c8ed044..bf2c9b0 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-2797d7bef2d332ef58c939728cba729c Coro-6.32.tar.gz
+edad4fbd0458e95b3f1734b09852d273 Coro-6.33.tar.gz
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-de...@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[Bug 1031988] perl-Coro-6.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031988 --- Comment #1 from Petr Pisar ppi...@redhat.com --- This is a bug-fixing release suitable for F≥20. -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=uPO3Vugrzsa=cc_unsubscribe -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Coro/f20] 6.33 bump
Summary of changes: b5215cc... 6.33 bump (*) (*) This commit already existed in another branch; no separate mail sent -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
Packaing question: need some includes from kernel source
I'm looking at packaing mpt-status (get status info from LSI MPT SAS RAID controllers) for Fedora and EPEL. However, to build, it needs some include files from the kernel source, specifically from the drivers/message/fusion directory. I've built an RPM using an extra tarball of all the .h files under that directory (using the 3.11.7 kernel source), and it works (and it also works on an older kernel under RHEL 6). Is this allowed under the packaging guidelines, or is there a better way? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
Hi, Is kernel-headers enough ? https://apps.fedoraproject.org/packages/kernel-headers Dridi On Tue, Nov 19, 2013 at 5:47 PM, Chris Adams li...@cmadams.net wrote: I'm looking at packaing mpt-status (get status info from LSI MPT SAS RAID controllers) for Fedora and EPEL. However, to build, it needs some include files from the kernel source, specifically from the drivers/message/fusion directory. I've built an RPM using an extra tarball of all the .h files under that directory (using the 3.11.7 kernel source), and it works (and it also works on an older kernel under RHEL 6). Is this allowed under the packaging guidelines, or is there a better way? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
Once upon a time, Dridi Boukelmoune dridi.boukelmo...@gmail.com said: Hi, Is kernel-headers enough ? https://apps.fedoraproject.org/packages/kernel-headers I should have mentioned that neither kernel-headers nor kernel-devel has the necessary headers. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Ticket #47384 (plugin library path validation) and out-of-tree modules
On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote: Hi, everyone. I was recently adding a couple of changes to slapi-nis, and when I went to run its self-tests, some of the tests that modify the plugin entry started failing with LDAP_UNWILLING_TO_PERFORM. I tracked the denial down to validation code that was added as part of ticket #47384. While the tests don't modify the nsslapd-pluginPath attribute (the entry's added to dse.ldif before the server starts up), some make other changes to the plugin entry, and when they attempt that, check_plugin_path() rejects the modify request. The checks that were added, which ensure that plugins are only loaded from the server's plugin directory, make it kind of difficult to run tests using the copies of plugins in my build tree. The language in the ticket description's pretty firm that this isn't going to be changed, and while I can _probably_ work around it on my end, I figured I'd ask here before going down that route: is there room to expand this check to a whitelist, a search path, or some other method that could be used to provide for my use case? Sure. Please file a ticket. We can figure out some way to hack this for testing. What would you suggest? Thanks, Nalin -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Packaing question: need some includes from kernel source
Maybe this should be added to an existing package. I forgot to mention that during a review I was told not to have multiple sources. On Tue, Nov 19, 2013 at 5:59 PM, Chris Adams li...@cmadams.net wrote: Once upon a time, Dridi Boukelmoune dridi.boukelmo...@gmail.com said: Hi, Is kernel-headers enough ? https://apps.fedoraproject.org/packages/kernel-headers I should have mentioned that neither kernel-headers nor kernel-devel has the necessary headers. -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Test-Announce] 2013-11-20 @ **17:00 UTC** - F20 Final Blocker Bug Review #2
# F20 Final Blocker Review meeting #2 # Date: 2013-11-20 # Time: 17:00 UTC (12:00 EST, 09:00 PST) # Location: #fedora-blocker-review on irc.freenode.net It's that time again! Tomorrow (2013-11-20) we'll be having another Blocker Review Meeting for Fedora 20. We currently have 6 proposed blockers and 3 proposed freeze exceptions to review. The full list is located here: http://qa.fedoraproject.org/blockerbugs/current We'll be reviewing the bugs to ensure they meet the Final release criteria [1] as blocking final release and that the bugs are getting the attention they need. For more information about the Blocker and Freeze exception process, check out these links: - https://fedoraproject.org/wiki/QA:SOP_blocker_bug_process - https://fedoraproject.org/wiki/QA:SOP_freeze_exception_bug_process And for those of you who are curious how a Blocker Review Meeting works - or how it's supposed to go - check out the SOP on the wiki: - https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting See you tomorrow! [1] https://fedoraproject.org/wiki/Fedora_20_Final_Release_Criteria == // Mike Fedora QA irc: roshi | twitter: roshi_fedora blog: roshi.fedorapeople.org signature.asc Description: PGP signature ___ test-announce mailing list test-annou...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/test-announce-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On 19.11.2013 16:20, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a Upstream GIT URL option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. What about intermediate step: optional fNN-upstream branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing external clones)? Kind Regards, Alek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
On Tue, Nov 19, 2013 at 10:47:12AM -0600, Chris Adams wrote: I'm looking at packaing mpt-status (get status info from LSI MPT SAS RAID controllers) for Fedora and EPEL. However, to build, it needs some include files from the kernel source, specifically from the drivers/message/fusion directory. I've built an RPM using an extra tarball of all the .h files under that directory (using the 3.11.7 kernel source), and it works (and it also works on an older kernel under RHEL 6). If the headers describe a stable interface that should be used by userland then it's a kernel bug that they're not being exported. If they don't, you shouldn't use them. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote: On 19.11.2013 16:20, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a Upstream GIT URL option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. What about intermediate step: optional fNN-upstream branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing external clones)? I think it would be better to keep the upstream repo separate for sake of size. People who just want to checkout the latest RPM branches don't want to have to pull down 100's of MB, potentially GB, worth of GIT repo, when current Fedora GIT repos are a mere few MB. Only maintainers actively updating patches need that burden. Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-19)
#fedora-meeting: Env and Stacks (2013-11-19) Meeting started by mmaslano at 16:04:20 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2013-11-19/env_and_stacks.2013-11-19-16.04.log.html . Meeting summary --- * init process (mmaslano, 16:07:42) * ACTION: pkovar will hunt handsome_pirate for content of WG wiki pages (mmaslano, 16:11:59) * use urls like http://fp.o/wiki/Environment and Stacks/* (mmaslano, 16:13:15) * and categories should use [[Category: Environment and Stacks]] (mmaslano, 16:13:52) * put a link to our homepage to https://fedoraproject.org/wiki/Fedora.next (mmaslano, 16:17:44) * PRD (mmaslano, 16:19:29) * LINK: http://piratepad.net/PwUiH4MEPR (abadger1999, 17:04:53) * ACTION: everyone to send one general thing they want the WG to enable and one specific thing they'd personally want to work on to the mailing list this week (abadger1999, 17:37:44) Meeting ended at 17:43:04 UTC. Action Items * pkovar will hunt handsome_pirate for content of WG wiki pages * everyone to send one general thing they want the WG to enable and one specific thing they'd personally want to work on to the mailing list this week Action Items, by person --- * handsome_pirate * pkovar will hunt handsome_pirate for content of WG wiki pages * pkovar * pkovar will hunt handsome_pirate for content of WG wiki pages * **UNASSIGNED** * everyone to send one general thing they want the WG to enable and one specific thing they'd personally want to work on to the mailing list this week People Present (lines said) --- * abadger1999 (101) * mmaslano (70) * tjanez (27) * samkottler (17) * drieden (14) * pkovar (11) * hhorak (9) * zodbot (4) * sochotni (2) * nirik (1) * bkabrda (0) * juhp (0) * handsome_pirate (0) Generated by `MeetBot`_ 0.1.4 .. _`MeetBot`: http://wiki.debian.org/MeetBot 16:04:20 mmaslano #startmeeting Env and Stacks (2013-11-19) 16:04:20 zodbot Meeting started Tue Nov 19 16:04:20 2013 UTC. The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:04:20 zodbot Useful Commands: #action #agreed #halp #info #idea #link #topic. 16:04:27 mmaslano #meetingname env and stacks 16:04:27 zodbot The meeting name has been set to 'env_and_stacks' 16:05:37 mmaslano #chair abadger1999 pkovar tjanez samkottler bkabrda handsome_pirate hhorak juhp 16:05:37 zodbot Current chairs: abadger1999 bkabrda handsome_pirate hhorak juhp mmaslano pkovar samkottler tjanez 16:06:06 mmaslano how many people is here? 16:06:14 hhorak Hi, I am 16:06:24 tjanez hi 16:06:24 drieden Hello 16:06:24 * pkovar is here 16:06:27 * sochotni 16:07:36 mmaslano ok, we have some members here 16:07:42 mmaslano #topic init process 16:08:01 mmaslano let's go through old stuff first 16:08:27 mmaslano I admit I forgot to create trac request, I opened a ticket now https://fedorahosted.org/fedora-infrastructure/ticket/4124 16:08:34 mmaslano what about wiki pages? 16:09:15 pkovar keep them where they are? 16:09:34 pkovar i think that other WG are also using fedora wiki, no? 16:10:03 mmaslano someone had to create them 16:10:06 tjanez I believe handsome_pirate said he'll setup our Wiki page 16:10:14 tjanez on Fedora wiki, of course 16:10:32 mmaslano I understand he will put content about WG on one place 16:10:33 pkovar good, i can help with that 16:10:53 mmaslano pkovar: do you want to poke him what's the status or if we have any problem? 16:11:09 * abadger1999 here 16:11:13 pkovar sure, will try to hunt him down :-) 16:11:42 drieden is handsome_pirate in Westford? If so, want me to follow up with him? 16:11:43 * abadger1999 nots that space on the wiki should just be convention. 16:11:59 mmaslano #action pkovar will hunt handsome_pirate for content of WG wiki pages 16:12:15 mmaslano drieden: I do not know, where is he located 16:12:17 abadger1999 with mediawiki, convention is usually like [[Category: Environment and Stacks]] 16:12:50 abadger1999 but in Fedora, we like using urls like http://fp.o/wiki/Environment and Stacks/* 16:13:15 mmaslano #info use urls like http://fp.o/wiki/Environment and Stacks/* 16:13:28 abadger1999 mmaslano: We should also use categories. 16:13:44 abadger1999 as categories have support in mediawiki (like the listing of all pages in the categories) 16:13:52 mmaslano #info and categories should use [[Category: Environment and Stacks]] 16:13:59 mmaslano abadger1999: feel free to mark it by yourself 16:14:12 hhorak maybe put a link to our homepage to https://fedoraproject.org/wiki/Fedora.next 16:17:44 mmaslano #info put a link to our homepage to https://fedoraproject.org/wiki/Fedora.next 16:17:49 mmaslano more comments to wiki? 16:19:21 mmaslano I understand no 16:19:29 mmaslano #topic PRD 16:19:41 mmaslano let's move what
Re: Packaging changes for libev in Rawhide
Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch Cheers, Tim - Original Message - From: Mathieu Bridon boche...@fedoraproject.org To: Development discussions related to Fedora devel@lists.fedoraproject.org Sent: Tuesday, November 19, 2013 1:30:46 AM Subject: Packaging changes for libev in Rawhide Hi, I would like to finally fix this bug in Fedora: https://bugzilla.redhat.com/show_bug.cgi?id=985610 Basically, our libev package diverges from upstream in two ways: 1. we install the header files in /usr/include/libev/ whereas upstream installs them in /usr/include/ 2. we ship a pkgconfig file, which upstream does not want I'm not happy with these Fedora-specific changes, and upstream is completely uninterested in them. It's confusing users who don't find the headers where they expect them, as demonstrated by this bug report. Worst of all, it's causing changes in software consuming libev, which have often had to be modified for the Fedora-specific change in libev. Those changes were sometimes made in the respective upstreams, but most often in additional Fedora-specific changes. I've been talking to upstream libev, and they really don't want the changes we made. They'd be much happier if we were packaging libev the way Debian is, as that's how they intended libev to be used. So I'd like to follow upstream libev wishes, and stop confusing everybody with our Fedora-only changes. My plan is to do the following in Rawhide (the future Fedora 21) : * Move the headers back to /usr/include, as upstream intended * Put the event.h header into a libev-libevent-devel subpackage, and make it Conflicts: libevent-devel (this is what Debian did) * Drop our pkgconfig file. Here is the list of packages I could find with a build requirement on libev: $ repoquery --enablerepo=\*source --archlist=src --whatrequires 'pkgconfig(libev)' libev-devel awesome-0:3.5.1-8.fc20.src i3-0:4.6-1.fc20.src i3lock-0:2.5-2.fc20.src libverto-0:0.2.5-3.fc20.src ocaml-lwt-0:2.4.2-3.fc20.src picviz-0:0.6-12.fc20.src rubygem-passenger-0:4.0.18-2.fc20.src rubygem-passenger-0:4.0.18-4.fc20.src spectrum-0:1.4.8-11.fc20.src stud-0:0.3-4.20120814git.fc20.src weighttp-0:0.3-5.fc20.src I'll fix weighttp, as it is my package, but I can't do much about the other ones. I'm adding a breakdown of how these packages use libev and what needs to be done for them at the end of this email. Does anybody have any comment, or objection? Cheers, -- Mathieu awesome --- Our package has some downstream patches to require our Fedora-only pkgconfig file for libev. Making it build-require libev-devel instead and dropping this downstream patch should be enough. i3 -- Nothing should need to be done here. Upstream checks for libev with pkg-config, but it ignores errors. And once I move the libev headers in /usr/include, then they'll be found anyway. i3lock -- The spec file calls pkgconfig to find the libev headers. This should just be removed, and the package should build just fine, as intended by upstream. libverto Upstream itself requires the pkgconfig file for libev. That's just a terrible idea, as it means libverto won't build on e.g Debian, or with the upstream libev. libverto should be fixed upstream here IMHO. ocaml-lwt - The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. picviz -- The package has a patch to make it find the headers int he Fedora-specific location. It should be dropped, and that should be it. rubygem-passenger - Upstream hardcodes -I/usr/include/libev in the cflags, which is only needed with our current libev package in Fedora, nowhere else. Anyway, the package should just build without any change once I move the libev headers to /usr/include. spectrum Upstream searches for the ev.h header in various folders, so things should continue to work without a change. stud Our package has a patch to hardcode -I/usr/include/libev in the CFLAGS. That can be dropped. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct -- Cheers, Tim -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Schedule for Wednesday's FESCo Meeting (2013-11-20)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1193 reboots for all updates -- are we ready for this? .fesco 1193 https://fedorahosted.org/fesco/ticket/1193 #topic #1185 Enable -Werror=format-security by default .fesco 1185 https://fedorahosted.org/fesco/ticket/1185 #topic #1198 Possible changes to Fedora EOL bug procedure .fesco 1198 https://fedorahosted.org/fesco/ticket/1198 #topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17 .fesco 1140 https://fedorahosted.org/fesco/ticket/1140 = New business = #topic #1203 Soft dependencies .fesco 1203 https://fedorahosted.org/fesco/ticket/1203 #topic #1202 Release and Support lifecycle questions .fesco 1202 https://fedorahosted.org/fesco/ticket/1202 #topic #1206 Allowed licenses in Copr .fesco 1206 https://fedorahosted.org/fesco/ticket/1206 #topic #1204 F21 System Wide Change: Python 3.4 - https://fedoraproject.org/wiki/Changes/Python_3.4 .fesco 1204 https://fedorahosted.org/fesco/ticket/1204 = Open Floor = For more complete details, please visit each individual ticket. The report of the agenda items can be found at https://fedorahosted.org/fesco/report/9 If you would like to add something to this agenda, you can reply to this e-mail, file a new ticket at https://fedorahosted.org/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKLpiEACgkQeiVVYja6o6Md5QCfRemqDz8A6BbiDkQ7phk8d6rT 2iYAniV+9K9I803N+w1pYNhNbFw9x+3f =Ipob -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: [389-devel] Ticket #47384 (plugin library path validation) and out-of-tree modules
On Tue, Nov 19, 2013 at 10:05:13AM -0700, Rich Megginson wrote: On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote: The language in the ticket description's pretty firm that this isn't going to be changed, and while I can _probably_ work around it on my end, I figured I'd ask here before going down that route: is there room to expand this check to a whitelist, a search path, or some other method that could be used to provide for my use case? Sure. Please file a ticket. We can figure out some way to hack this for testing. What would you suggest? Great! I've opened ticket #47601 for this, and we can continue there if you like. In case there's more to discuss on the list, here are the options that come to mind: * When checking a modify request, only check the nsslapd-pluginPath value if it shows up in the mods list. * Add a run-time-configurable whitelist of acceptable locations. * Replace the check with logic to go ahead and try loading the module, unloading it if the load succeeds. I haven't tried any of these, but I think any of them would be enough. Thanks, Nalin -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: [389-devel] Ticket #47384 (plugin library path validation) and out-of-tree modules
On 11/19/2013 11:06 AM, Nalin Dahyabhai wrote: On Tue, Nov 19, 2013 at 10:05:13AM -0700, Rich Megginson wrote: On 11/19/2013 09:44 AM, Nalin Dahyabhai wrote: The language in the ticket description's pretty firm that this isn't going to be changed, and while I can _probably_ work around it on my end, I figured I'd ask here before going down that route: is there room to expand this check to a whitelist, a search path, or some other method that could be used to provide for my use case? Sure. Please file a ticket. We can figure out some way to hack this for testing. What would you suggest? Great! I've opened ticket #47601 for this, and we can continue there if you like. Yes. In case there's more to discuss on the list, here are the options that come to mind: * When checking a modify request, only check the nsslapd-pluginPath value if it shows up in the mods list. * Add a run-time-configurable whitelist of acceptable locations. * Replace the check with logic to go ahead and try loading the module, unloading it if the load succeeds. I haven't tried any of these, but I think any of them would be enough. Thanks, Nalin -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: Using git for patch management in Fedora
On 19.11.2013 19:32, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote: What about intermediate step: optional fNN-upstream branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing external clones)? I think it would be better to keep the upstream repo separate for sake of size. People who just want to checkout the latest RPM branches don't want to have to pull down 100's of MB, potentially GB, worth of GIT repo, when current Fedora GIT repos are a mere few MB. Only maintainers actively updating patches need that burden. Git submodules are just references to external revision, not materialized inclusion of the referenced repo, aren't they? Someone should explicitly add --recursive or git submodule command to pull them. Kind Regards, Alek I just checked once again: git clone https://github.com/JulesAU/node-msgpack Working directory contains file .gitmodules with 3 lines: [submodule deps/msgpack-full] path = deps/msgpack-full url = https://github.com/msgpack/msgpack.git Site web interface shows: https://github.com/JulesAU/node-msgpack/tree/master/deps git submodule status: -d642487f9916dfe571531d0c6d0727b3ee449d36 deps/msgpack-full ls -al deps/msgpack-full: total 8 drwxrwsr-x 2 alek src 4096 Nov 19 20:06 . drwxrwsr-x 3 alek src 4096 Nov 19 20:06 .. However if: git clone --recursive https://github.com/JulesAU/node-msgpack node-msgpack-with-deps ls -al deps/msgpack-full: total 72 drwxrwsr-x 15 alek src 4096 Nov 19 20:14 . drwxrwsr-x 3 alek src 4096 Nov 19 20:13 .. drwxrwsr-x 4 alek src 4096 Nov 19 20:14 cpp drwxrwsr-x 2 alek src 4096 Nov 19 20:14 csharp ... -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: F21 System Wide Change: Headless Java
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2013 11:23 AM, Reindl Harald wrote: Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky: I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). If someone wanted to install just OpenJDK for their own in-house Java application they would have to know to request full -x11 version. I would wager we'd be receiving a lot of bugs if we went this way. If someone needs headless they will be actively looking for it. If they want java they will not consider that they might get incomplete version. Not to mention possible 3rd party RPMs that might exist what about having a java-1.7.0-openjdk meta-package obsoleting the existing one and pulling *both* but decide if Fedora packages if the headless is enough for dependencies and so packagers of sevrer software can require this? this way you would have the least surprise for someone who does not care about the difference and expects the full one by install java-1.7.0-openjdk but make it really easy to uninstall any graphical dependencies on servers I agree with Reindl here, if I understand him correctly. It would certainly break upgrades in an unexpected way if an upgrade from java-1.7.0-openjdk suddenly stopped carrying the graphical components. We did something similar in the SSSD project where we broke up the standard install into sssd-core and a series of sssd-* plugin packages. We then created an 'sssd' metapackage that included all of the plugins, since that was how it used to be shipped. This allows a user to easily and trivially install the complete suite (via 'yum install sssd') but if they want to trim down, such as for an embedded system, they can pick only the components they need. I think it would be wise to do the same for Java. Create 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then have the 'java-openjdk-1.7.0' metapackage install both of them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKLriUACgkQeiVVYja6o6PHEQCfd7bdLe+yS14b4kiOxFEF8mrx UYkAn3pflqngx9SYPQl6lpFtSv+9UotL =p3rs -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[Fedora QA] #435: bugzilla sync operations are not using the correct config items
#435: bugzilla sync operations are not using the correct config items --+- Reporter: tflink| Owner: tflink Type: defect| Status: new Priority: critical | Milestone: Component: Blocker bug tracker page | Version: Keywords:| Blocked By: Blocking:| --+- = bug description = After the change for #423, the configuration options for bugzilla's XMLRPC interface changed from BUGZILLA_URL to BUGZILLA_XMLRPC to get rid of the hardcoded partial url in our templates. Unfoturnately, the sync code is still using 'BUGZILLA_URL' and with an updated config, sync blows up with errors. To work around this bug, I've kept the old value for 'BUGZILLA_URL' which allows sync to work but has the side-effect of breaking display of the tracker bugs. = bug analysis = All references to 'BUGZILLA_URL' and 'BUGZILLA_XMLRPC' need to be checked to make sure that we're getting the right urls in the right places. -- Ticket URL: https://fedorahosted.org/fedora-qa/ticket/435 Fedora QA http://fedorahosted.org/fedora-qa Fedora Quality Assurance ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: F21 System Wide Change: Headless Java
On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2013 11:23 AM, Reindl Harald wrote: Am 19.11.2013 17:15, schrieb Stanislav Ochotnicky: I mean (and sorry that I wasn't clear), why the choice to make java-headless the special case? Especially if (as it appears from the reply to Jerry James), most packages in Fedora will only need the headless version. (So the headless version would be the java package, The version with the gui nevironmen deps would be java-x11 or similar). If someone wanted to install just OpenJDK for their own in-house Java application they would have to know to request full -x11 version. I would wager we'd be receiving a lot of bugs if we went this way. If someone needs headless they will be actively looking for it. If they want java they will not consider that they might get incomplete version. Not to mention possible 3rd party RPMs that might exist nod what about having a java-1.7.0-openjdk meta-package obsoleting the existing one and pulling *both* but decide if Fedora packages if the headless is enough for dependencies and so packagers of sevrer software can require this? this way you would have the least surprise for someone who does not care about the difference and expects the full one by install java-1.7.0-openjdk but make it really easy to uninstall any graphical dependencies on servers I agree with Reindl here, if I understand him correctly. It would certainly break upgrades in an unexpected way if an upgrade from java-1.7.0-openjdk suddenly stopped carrying the graphical components. Note -- I think that the way the feature has things constructed would achieve something similar. The java package is essentially java-x11. It would Require: java-headless. So yum install java will get you the java w/X11 support. [...] I think it would be wise to do the same for Java. Create 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then have the 'java-openjdk-1.7.0' metapackage install both of them. I can see one advantage to this approach: it lets us tell packagers that Requires: java should no longer be used. Packagers should determine whether they're using APIs that require X and either Requires: java-x11 or Requires: java-headless based on what they really need. We can then audit the packageset at a later date to determine which packages haven't adjusted their Requirements yet. -Toshio pgplD91lxhEjm.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: On Tue, Nov 19, 2013 at 10:47:12AM -0600, Chris Adams wrote: I'm looking at packaing mpt-status (get status info from LSI MPT SAS RAID controllers) for Fedora and EPEL. However, to build, it needs some include files from the kernel source, specifically from the drivers/message/fusion directory. I've built an RPM using an extra tarball of all the .h files under that directory (using the 3.11.7 kernel source), and it works (and it also works on an older kernel under RHEL 6). If the headers describe a stable interface that should be used by userland then it's a kernel bug that they're not being exported. If they don't, you shouldn't use them. I believe the headers describe what is intended to be a stable interface. Would that be something I should bring up on linux-kernel? If the interface is supposed to be stable, asking upstream kernel to change isn't going to help make a package any time soon (and likely never for EPEL). Is it permissible to carry the necessary headers in the SRPM until they are no longer needed? -- Chris Adams li...@cmadams.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote: On 19.11.2013 16:20, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a Upstream GIT URL option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. What about intermediate step: optional fNN-upstream branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing external clones)? The real issue is still access control. The upstream repo should be accessible read/write by the same people who are permitted to commit to the dist-git repo. It's my understanding that git submodules don't necessarily help with that. It's a shame that git can't reference an external repo (for history). That would massively reduce the amount of storage needed. [AFAIK ...] 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 Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-11-20)
On Nov 19, 2013 12:55 PM, Stephen Gallagher sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1193 reboots for all updates -- are we ready for this? .fesco 1193 https://fedorahosted.org/fesco/ticket/1193 #topic #1185 Enable -Werror=format-security by default .fesco 1185 https://fedorahosted.org/fesco/ticket/1185 #topic #1198 Possible changes to Fedora EOL bug procedure .fesco 1198 https://fedorahosted.org/fesco/ticket/1198 #topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17 .fesco 1140 https://fedorahosted.org/fesco/ticket/1140 = New business = FESCo asked that I file a separate ticket for the third party repo question. Is it not going to be discussed? josh -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaing question: need some includes from kernel source
On Tue, Nov 19, 2013 at 01:31:20PM -0600, Chris Adams wrote: Once upon a time, Matthew Garrett mj...@srcf.ucam.org said: If the headers describe a stable interface that should be used by userland then it's a kernel bug that they're not being exported. If they don't, you shouldn't use them. I believe the headers describe what is intended to be a stable interface. Would that be something I should bring up on linux-kernel? Probably better to look the driver up in MAINTAINERS and contact the people there. If the interface is supposed to be stable, asking upstream kernel to change isn't going to help make a package any time soon (and likely never for EPEL). Is it permissible to carry the necessary headers in the SRPM until they are no longer needed? From a technical perspective? Sure. Better to do that than add a gratuitous additional package. -- Matthew Garrett | mj...@srcf.ucam.org -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Meeting minutes - today's Env-and-Stacks WG meeting (2013-11-19)
On Tue, Nov 19, 2013 at 06:46:29PM +0100, Marcela Mašláňová wrote: * PRD (mmaslano, 16:19:29) * LINK: http://piratepad.net/PwUiH4MEPR (abadger1999, 17:04:53) * ACTION: everyone to send one general thing they want the WG to enable and one specific thing they'd personally want to work on to the mailing list this week (abadger1999, 17:37:44) Here's the backup copy of the piratepad session: https://fedoraproject.org/wiki/User:Toshio/Env_and_Stacks_Charter_Brainstorming I'm not sure how persistent or reliable piratepad is. I'll look at syncing from piratepad to the wiki again on Friday. -Toshio pgp06ZSf_42Xz.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Schedule for Wednesday's FESCo Meeting (2013-11-20)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/19/2013 02:47 PM, Josh Boyer wrote: On Nov 19, 2013 12:55 PM, Stephen Gallagher sgall...@redhat.com mailto:sgall...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 18:00UTC in #fedora-meeting on irc.freenode.net http://irc.freenode.net. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto or run: date -d '-MM-DD HH:MM UTC' Links to all tickets below can be found at: https://fedorahosted.org/fesco/report/9 = Followups = #topic #1193 reboots for all updates -- are we ready for this? .fesco 1193 https://fedorahosted.org/fesco/ticket/1193 #topic #1185 Enable -Werror=format-security by default .fesco 1185 https://fedorahosted.org/fesco/ticket/1185 #topic #1198 Possible changes to Fedora EOL bug procedure .fesco 1198 https://fedorahosted.org/fesco/ticket/1198 #topic #1140 F20 Self Contained Changes - week 2013-07-10 - 2013-07-17 .fesco 1140 https://fedorahosted.org/fesco/ticket/1140 = New business = FESCo asked that I file a separate ticket for the third party repo question. Is it not going to be discussed? Sorry, wasn't tagged with the meeting keyword. Consider it added. #topic #1201 Enabling third party repositories .fesco 1201 https://fedorahosted.org/fesco/ticket/1201 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlKLxVQACgkQeiVVYja6o6OtHACeMv2BYNV80I0j/I9lbbX7ltbH DvQAnjgdqeFcfBlA5BZtprOu0kiRr2r9 =A1lW -END PGP SIGNATURE- -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Blockerbugs 0.4 Released and Deployed
After a bit more of a delay than we were anticipating, blockerbugs 0.4 has been released and deployed to production! https://qa.fedoraproject.org/blockerbugs/ New features and enhancements: - Spin requests * add updates and/or koji builds to the request - API Support * get latest blockers, blocker-related updates, spin contents etc. - Improved Update Display * URLs include update ID once it's available from bodhi * Stale updates are removed from list * Updates in need of testing are displayed with their associated bug - UI Enhancements * Needinfo bugs are indicated in the blocker tables * Sort order in IRC format matches html * IRC Format has correct MIME type * Improved admin interface for app admins Thanks to Martin Krizek and Ilgiz Islamgulov for their hard work on this new release! As always, please let us know if you hit any issues. Tim signature.asc Description: PGP signature ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Packaing question: need some includes from kernel source
On Tue, Nov 19, 2013 at 06:05:20PM +0100, Dridi Boukelmoune wrote: Maybe this should be added to an existing package. I forgot to mention that during a review I was told not to have multiple sources. nod The main reason is so that the two packages can evolve independent of each other. You don't want to have to update your package because the other source changed. That would seem to apply here as well. -Toshio pgpINYcX0Jklg.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
[389-devel] Revised: Ticket 47599 - Reduce lock scope in retro changelog plug-in
https://fedorahosted.org/389/ticket/47599 https://fedorahosted.org/389/attachment/ticket/47599/0001-Ticket-47599-Reduce-lock-scope-in-retro-changelog-pl.patch -- 389-devel mailing list 389-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/389-devel
Re: F21 System Wide Change: Headless Java
Am 19.11.2013 20:29, schrieb Toshio Kuratomi: On Tue, Nov 19, 2013 at 01:29:58PM -0500, Stephen Gallagher wrote: On 11/19/2013 11:23 AM, Reindl Harald wrote: what about having a java-1.7.0-openjdk meta-package obsoleting the existing one and pulling *both* but decide if Fedora packages if the headless is enough for dependencies and so packagers of sevrer software can require this? this way you would have the least surprise for someone who does not care about the difference and expects the full one by install java-1.7.0-openjdk but make it really easy to uninstall any graphical dependencies on servers I agree with Reindl here, if I understand him correctly. It would certainly break upgrades in an unexpected way if an upgrade from java-1.7.0-openjdk suddenly stopped carrying the graphical components. Note -- I think that the way the feature has things constructed would achieve something similar. The java package is essentially java-x11. It would Require: java-headless. So yum install java will get you the java w/X11 support. I think it would be wise to do the same for Java. Create 'java-openjdk-1.7.0-headless' and 'java-openjdk-1.7.0--x11' and then have the 'java-openjdk-1.7.0' metapackage install both of them. I can see one advantage to this approach: it lets us tell packagers that Requires: java should no longer be used. Packagers should determine whether they're using APIs that require X and either Requires: java-x11 or Requires: java-headless based on what they really need. We can then audit the packageset at a later date to determine which packages haven't adjusted their Requirements yet agreed, but with the meta-package nobody is forced to change anything while any maintainer at any time can say hey, we do not need the graphical components and so we relax now the dependencies so anybody can point at any time to whatever package and ask for relax the deps to java-headless and at no point in time any change is forced since the expierience shows changes can't be forced inside Fedora - look how long it took to get native systemd-units and there are still packages with sysv-init-scripts signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Using git for patch management in Fedora
On Tue, Nov 19, 2013 at 05:32:01PM +, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 07:27:20PM +0200, Alek Paunov wrote: On 19.11.2013 16:20, Daniel P. Berrange wrote: On Tue, Nov 19, 2013 at 01:29:06PM +, Richard W.M. Jones wrote: On Tue, Nov 19, 2013 at 01:39:50PM +0100, Karel Zak wrote: We have to learn fedpkg to do all the magic ;-) Something like add remote git tree with exploded tree: fedpkg exploded-tree add ssh://git.fedorahosted.org/git/foo.git This is all great, but the problem is that co-maintainers and provenpackagers need to be (automatically if possible) added to the fedorahosted tree. Otherwise there's a big extra step for them if they want to follow the package owner's preferred patching system. Ideally the GIT SCM request added to bugzilla when reviews are approved would have a Upstream GIT URL option and would setup a clone of this, and create branches for the fedora releases, and apply the same permissioning model from dist-git branches of the same names. What about intermediate step: optional fNN-upstream branch in addition to fNN, containing relevant upstream revision as git submodule (preferably referencing fedorahosted mirror, but initially also allowing external clones)? I think it would be better to keep the upstream repo separate for sake of size. People who just want to checkout the latest RPM branches don't want to have to pull down 100's of MB, potentially GB, worth of GIT repo, when current Fedora GIT repos are a mere few MB. Only maintainers actively updating patches need that burden. It probably makes sense to have a lookaside git that's similar to the lookaside cache. One note though, I think that in the past one of the discussion points we've foundered on is whether we want to be mirroring upstream's git repo or (approximately) upstream's releases. I think that's probably where we'd need to start discussion. -Toshio pgp2ZlEZbZSlo.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 12:43 -0500, Tim St Clair wrote: Sorry to disagree, but segregation is standard practice and is far better then polluting /usr/include. I actually agree with that. Upstream libev doesn't, though. And with our current package in Fedora, we are creating a situation where developers of software using libev have to juggle weirdly to support Fedora because it's different from upstream libev and other distros. Also, I have a package which has separate patches which I'm uncertain if upstream has adopted. https://github.com/apache/mesos/blob/master/3rdparty/libprocess/3rdparty/libev-4.15.patch That seems off-topic for this discussion, you should send that upstream instead. -- Mathieu -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Packaging changes for libev in Rawhide
On Tue, 2013-11-19 at 14:38 +0100, Michael Schwendt wrote:
On Tue, 19 Nov 2013 21:01:06 +0800, Mathieu Bridon wrote:
This one is weird:
https://bugzilla.redhat.com/672153
In order to make the perl-EV package not use a bundled libev source,
you build a libev-source subpackage that perl-EV adds as BuildRequires.
In other words, perl-EV now still bundles libev, but only indirectly. An
update of libev does not affect perl-EV until perl-EV is rebuilt. libev
has
been updated from 4.11 to 4.15 in Fedora, but perl-EV has not been
rebuilt.
Right, it's certainly unorthodox.
The problem is that libev is actually intended to be bundled by
upstream, and perl-EV is made by the same people.
It's similar with libeio (retired) and Perl IO::AIO by the same author.
The Perl module contains a renamed and private DSO lib built from a
bundled copy of the library sources. Even if the Perl module could be
patched to use the system-wide DSO lib instead, there are no guarantees
about API/ABI stability. Even if the system lib has been compatible for a
long time, it may break in future releases, and e.g. the module may include
a modified bundled lib source eventually.
As a result, they **really** don't want to unbundle libev from perl-EV.
The approach I followed was a compromise, it's definitely not the most
desirable outcome.
Such a dependency ought to be tracked in a special way, preferably with
official blessing from the FPC.
I didn't pass it through FPC because there are a few precedents. The one
I inspired myself from is xorg-x11-server-source.
I assumed that given there were already quite a few of these, it was an
accepted practice.
Did I assume wrong?
I think so.
The current packaging approach is circumventing the packaging policies:
https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
perl-EV does not use the system libev. No real unbundling has been
achieved by replacing the bundled source with another copy at build-time.
A bug-fix (or security-fix) of libev would not affect perl-EV without
rebuilding perl-EV. Even rebuilding perl-EV isn't safe. There's no strict
dependency, but only:
BuildRequires: libev-source = %{version}
As a result, it is not ensured that a rebuild picks up the latest patched
libev-source. Even a buildroot override would be needed.
I know all that. :)
Unbundling was a pre-requisite of the review request, though, and the
reviewer found the current solution more acceptable than keeping the
bundled libev in perl-EV.
I'm really just trying to fix all this mess here, so what do you think
would be the better solution?
Thanks,
--
Mathieu
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
File Module-Build-0.4201.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-Module-Build: 6210376a3b126cab2d4a40279e7c35c6 Module-Build-0.4201.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-Module-Build] 0.4201 bump
commit 6cfb7504a6efd502647126e22cd406a84ffaf908
Author: Jitka Plesnikova jples...@redhat.com
Date: Tue Nov 19 09:35:18 2013 +0100
0.4201 bump
.gitignore |1 +
perl-Module-Build.spec |9 ++---
sources|2 +-
3 files changed, 8 insertions(+), 4 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index b88c003..4502846 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@ Module-Build-0.2808.tar.gz
/Module-Build-0.4005.tar.gz
/Module-Build-0.4007.tar.gz
/Module-Build-0.4008.tar.gz
+/Module-Build-0.4201.tar.gz
diff --git a/perl-Module-Build.spec b/perl-Module-Build.spec
index 2830fae..3d5232a 100644
--- a/perl-Module-Build.spec
+++ b/perl-Module-Build.spec
@@ -1,5 +1,5 @@
-%global cpan_version_major 0.40
-%global cpan_version_minor 08
+%global cpan_version_major 0.42
+%global cpan_version_minor 01
%global cpan_version %{cpan_version_major}%{?cpan_version_minor}
Name: perl-Module-Build
@@ -49,7 +49,7 @@ BuildRequires: perl(if)
BuildRequires: perl(lib)
# perl(Module::Build) is loaded from ./lib
BuildRequires: perl(Module::Metadata) = 1.02
-BuildRequires: perl(Parse::CPAN::Meta)
+BuildRequires: perl(Parse::CPAN::Meta) = 1.4401
BuildRequires: perl(Perl::OSType) = 1
BuildRequires: perl(strict)
# Optional tests:
@@ -123,6 +123,9 @@ LANG=C TEST_SIGNATURE=1 MB_TEST_EXPERIMENTAL=1 ./Build test
%{_mandir}/man3/*
%changelog
+* Tue Nov 19 2013 Jitka Plesnikova jples...@redhat.com - 2:0.42.01-1
+- 0.4201 bump
+
* Tue Nov 05 2013 Jitka Plesnikova jples...@redhat.com - 2:0.40.08-1
- 0.4008 bump
diff --git a/sources b/sources
index e07fd09..e559bdb 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-01675c01f6a42c528d02dc34cc5383bf Module-Build-0.4008.tar.gz
+6210376a3b126cab2d4a40279e7c35c6 Module-Build-0.4201.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
File Test-Moose-More-0.022.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-Test-Moose-More: e4826b1719bf17976a1d899419ccb3c5 Test-Moose-More-0.022.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-Moose-More] 0.022 bump
commit 4acde7e92a5b65235cb637a67812595c9067d86c
Author: Petr Písař ppi...@redhat.com
Date: Tue Nov 19 09:40:07 2013 +0100
0.022 bump
.gitignore |1 +
...Test-Simple-0.98_04-describes-inheritance.patch | 53
...-Test-Simple-0.98_05-outputs-subtest-name.patch | 31 ---
perl-Test-Moose-More.spec | 31 ++--
sources|2 +-
5 files changed, 18 insertions(+), 100 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index efc9a21..4f1532d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -10,3 +10,4 @@
/Test-Moose-More-0.018.tar.gz
/Test-Moose-More-0.019.tar.gz
/Test-Moose-More-0.020.tar.gz
+/Test-Moose-More-0.022.tar.gz
diff --git a/perl-Test-Moose-More.spec b/perl-Test-Moose-More.spec
index 94b6b69..b855150 100644
--- a/perl-Test-Moose-More.spec
+++ b/perl-Test-Moose-More.spec
@@ -1,20 +1,14 @@
Name: perl-Test-Moose-More
-Version:0.020
+Version:0.022
Release:1%{?dist}
Summary:More tools for testing Moose packages
License:LGPLv2+
Group: Development/Libraries
URL:http://search.cpan.org/dist/Test-Moose-More/
Source0:
http://www.cpan.org/authors/id/R/RS/RSRCHBOY/Test-Moose-More-%{version}.tar.gz
-# Adjust to Test-Simple 0.98_05
-# https://github.com/RsrchBoy/Test-Moose-More/issues/4
-Patch0:
Test-Moose-More-0.020-Test-Simple-0.98_05-outputs-subtest-name.patch
-# Adjust to Test-Simple 0.98_04
-# https://github.com/RsrchBoy/Test-Moose-More/issues/5
-Patch1:
Test-Moose-More-0.020-Test-Simple-0.98_04-describes-inheritance.patch
BuildArch: noarch
BuildRequires: perl
-BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(ExtUtils::MakeMaker) = 6.30
BuildRequires: perl(strict)
BuildRequires: perl(warnings)
# Run-time:
@@ -27,17 +21,23 @@ BuildRequires: perl(Sub::Exporter)
BuildRequires: perl(Syntax::Keyword::Junction)
BuildRequires: perl(Test::Builder)
BuildRequires: perl(Test::Moose)
-BuildRequires: perl(Test::More) = 0.88
+BuildRequires: perl(Test::More) = 0.94
# Tests only:
-BuildRequires: perl(Capture::Tiny)
+BuildRequires: perl(aliased)
+BuildRequires: perl(constant)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(IO::Handle)
+BuildRequires: perl(IPC::Open3)
BuildRequires: perl(Moose)
BuildRequires: perl(Moose::Deprecated)
BuildRequires: perl(Moose::Role)
BuildRequires: perl(namespace::autoclean)
-BuildRequires: perl(TAP::SimpleOutput)
+BuildRequires: perl(Perl::Version)
+BuildRequires: perl(TAP::SimpleOutput) = 0.002
BuildRequires: perl(Test::Builder::Tester)
+BuildRequires: perl(Test::CheckDeps) = 0.010
Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
-Requires: perl(Test::More) = 0.88
+Requires: perl(Test::More) = 0.94
# Removed under-specified dependencies
%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\(Test::More\\)$
@@ -48,8 +48,6 @@ against Moose classes/roles. It is intended to replace
Test::Moose.
%prep
%setup -q -n Test-Moose-More-%{version}
-%patch0 -p1
-%patch1 -p1
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -64,12 +62,15 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
\;
make test
%files
-# README is the same as main POD
+# README is the same as the main POD
%doc Changes
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Mon Nov 18 2013 Petr Pisar ppi...@redhat.com - 0.022-1
+- 0.022 bump
+
* Sat Aug 03 2013 Petr Pisar ppi...@redhat.com - 0.020-1
- 0.020 bump
diff --git a/sources b/sources
index c8b27a5..a72180a 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-a90b37d58f3206e9721a92928bed8098 Test-Moose-More-0.020.tar.gz
+e4826b1719bf17976a1d899419ccb3c5 Test-Moose-More-0.022.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
[Bug 1030919] perl-Test-Moose-More-0.022 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1030919 Petr Pisar ppi...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-Test-Moose-More-0.022- ||1.fc21 Resolution|--- |RAWHIDE Last Closed||2013-11-19 03:49:45 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=cGlBahME2ra=cc_unsubscribe -- 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
[Bug 1030913] perl-Module-Build-0.4200 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1030913 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Module-Build-0.42.01-1 ||.fc21 Resolution|--- |RAWHIDE Last Closed||2013-11-19 03:49:50 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NMtFrr9KnAa=cc_unsubscribe -- 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-Text-ParseWords] Add licence statement from the upstream ticket. Resolves: rhbz#1030808
commit f898b33a1b061ae1ebcdc2ef3bdae7724847009b
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Nov 19 10:03:25 2013 +0100
Add licence statement from the upstream ticket. Resolves: rhbz#1030808
perl-Text-ParseWords.spec | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
---
diff --git a/perl-Text-ParseWords.spec b/perl-Text-ParseWords.spec
index 3ccbb68..4cb9b4e 100644
--- a/perl-Text-ParseWords.spec
+++ b/perl-Text-ParseWords.spec
@@ -1,8 +1,15 @@
Name: perl-Text-ParseWords
Version:3.29
-Release:3%{?dist}
+Release:4%{?dist}
Summary:Parse text into an array of tokens or array of arrays
License:GPL+ or Artistic
+#statement of the upstream license
https://rt.cpan.org/Public/Bug/Display.html?id=90483
+# It would be a big help if you have better defined license. License text in
.pm
+# file would be enough.
+#Will do in next version.
+# I found Perl license in Makefile.PL, so we assumed it's Perl (GPL+ or
Artistic).
+# Is it correct?
+#yes
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-ParseWords/
Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/Text-ParseWords-%{version}.tar.gz
@@ -57,6 +64,10 @@ make test
%{_mandir}/man3/*
%changelog
+* Tue Nov 19 2013 Marcela Mašláňová mmasl...@redhat.com 3.29-4
+- Add licence statement from the upstream ticket
+- Resolves: rhbz#1030808
+
* Sun Aug 04 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 3.29-3
- Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass_Rebuild
--
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
[Bug 1031988] New: perl-Coro-6.33 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031988 Bug ID: 1031988 Summary: perl-Coro-6.33 is available Product: Fedora Version: rawhide Component: perl-Coro Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: boche...@fedoraproject.org, kwiz...@gmail.com, mmasl...@redhat.com, perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 6.33 Current version/release in Fedora Rawhide: 6.32-1.fc21 URL: http://search.cpan.org/dist/Coro/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=vpTr0ohMLZa=cc_unsubscribe -- 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
[Bug 1031990] New: perl-HTTP-Tiny-0.038 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031990 Bug ID: 1031990 Summary: perl-HTTP-Tiny-0.038 is available Product: Fedora Version: rawhide Component: perl-HTTP-Tiny Keywords: FutureFeature, Triaged Assignee: ppi...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, ppi...@redhat.com Latest upstream release: 0.038 Current version/release in Fedora Rawhide: 0.037-1.fc21 URL: http://search.cpan.org/dist/HTTP-Tiny/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=ub7LYFxfnja=cc_unsubscribe -- 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
[Bug 1031268] perl-IPC-Cmd-0.90 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1031268 Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org changed: What|Removed |Added Summary|perl-IPC-Cmd-0.88 is|perl-IPC-Cmd-0.90 is |available |available --- Comment #1 from Upstream Release Monitoring upstream-release-monitor...@fedoraproject.org --- Latest upstream release: 0.90 Current version/release in Fedora Rawhide: 0.86-1.fc21 URL: http://search.cpan.org/dist/IPC-Cmd/ Please consult the package updates policy before you issue an update to a stable branch: https://fedoraproject.org/wiki/Updates_Policy More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=1lb1kOfEsya=cc_unsubscribe -- 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-Text-ParseWords] According to guidelines must be email statement added as new source.
commit 3777aa3f23749ce37c52650909e5fe6d12ee96f1
Author: Marcela Mašláňová mmasl...@redhat.com
Date: Tue Nov 19 12:44:39 2013 +0100
According to guidelines must be email statement added as new source.
license.email | 57 +
perl-Text-ParseWords.spec | 16 +---
2 files changed, 64 insertions(+), 9 deletions(-)
---
diff --git a/license.email b/license.email
new file mode 100644
index 000..65d6fad
--- /dev/null
+++ b/license.email
@@ -0,0 +1,57 @@
+Return-Path: rt-cpan-org-ret...@perl.org
+Received: from zmta04.collab.prod.int.phx2.redhat.com (LHLO
+ zmta04.collab.prod.int.phx2.redhat.com) (10.5.81.11) by
+ zmail14.collab.prod.int.phx2.redhat.com with LMTP; Mon, 18 Nov 2013
+ 11:06:10 -0500 (EST)
+Received: from zmta04.collab.prod.int.phx2.redhat.com (localhost [127.0.0.1])
+ by zmta04.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id
9A08BDA0C9
+ for mmasl...@redhat.com; Mon, 18 Nov 2013 11:06:10 -0500 (EST)
+Received: from int-mx10.intmail.prod.int.phx2.redhat.com
(int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23])
+ by zmta04.collab.prod.int.phx2.redhat.com (Postfix) with ESMTP id
954E9D1F23
+ for mmasl...@mail.corp.redhat.com; Mon, 18 Nov 2013 11:06:10 -0500
(EST)
+Received: from mx1.redhat.com (ext-mx14.extmail.prod.ext.phx2.redhat.com
[10.5.110.19])
+ by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP
id rAIG6A3W024510
+ for mmasl...@redhat.com; Mon, 18 Nov 2013 11:06:10 -0500
+Received: from rtcpan.develooper.com (rtcpan.develooper.com [207.171.7.181])
+ by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id rAIG69Uk032392
+ for mmasl...@redhat.com; Mon, 18 Nov 2013 11:06:09 -0500
+Received: by rtcpan.develooper.com (Postfix, from userid 536)
+ id D3030FA; Mon, 18 Nov 2013 08:06:08 -0800 (PST)
+Precedence: normal
+Subject: [rt.cpan.org #90483] missing license file
+From: Alexandr Ciornii via RT bug-text-parsewo...@rt.cpan.org
+Reply-To: bug-text-parsewo...@rt.cpan.org
+In-Reply-To: rt-4.0.18-4704-1384789048-1647.90483-...@rt.cpan.org
+References: rt-ticket-90...@rt.cpan.org
+ rt-4.0.18-4704-1384789048-1647.90483-...@rt.cpan.org
+Message-ID: rt-4.0.18-2172-1384790768-1347.90483-...@rt.cpan.org
+X-RT-Loop-Prevention: rt.cpan.org
+RT-Ticket: rt.cpan.org #90483
+Managed-BY: RT 4.0.18 (http://www.bestpractical.com/rt/)
+RT-Originator: cho...@cpan.org
+To: mmasl...@redhat.com
+MIME-Version: 1.0
+Content-Transfer-Encoding: 8bit
+Content-Type: text/plain; charset=utf-8
+X-RT-Original-Encoding: utf-8
+Date: Mon, 18 Nov 2013 11:06:08 -0500
+X-RedHat-Spam-Score: -1.9 (BAYES_00,SPF_PASS,URIBL_BLOCKED)
+X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23
+X-Scanned-By: MIMEDefang 2.68 on 10.5.110.19
+
+URL: https://rt.cpan.org/Ticket/Display.html?id=90483
+
+On Mon Nov 18 10:37:28 2013, mmasl...@redhat.com wrote:
+ It would be a big help if you have better defined license. License
+ text in .pm file would be enough.
+
+Will do in next version.
+
+ I found Perl license in Makefile.PL,
+ so we assumed it's Perl (GPL+ or Artistic). Is it correct?
+
+yes
+
+--
+Alexandr Ciornii, http://chorny.net
+
diff --git a/perl-Text-ParseWords.spec b/perl-Text-ParseWords.spec
index 4cb9b4e..8bb33f2 100644
--- a/perl-Text-ParseWords.spec
+++ b/perl-Text-ParseWords.spec
@@ -1,18 +1,12 @@
Name: perl-Text-ParseWords
Version:3.29
-Release:4%{?dist}
+Release:5%{?dist}
Summary:Parse text into an array of tokens or array of arrays
License:GPL+ or Artistic
-#statement of the upstream license
https://rt.cpan.org/Public/Bug/Display.html?id=90483
-# It would be a big help if you have better defined license. License text in
.pm
-# file would be enough.
-#Will do in next version.
-# I found Perl license in Makefile.PL, so we assumed it's Perl (GPL+ or
Artistic).
-# Is it correct?
-#yes
Group: Development/Libraries
URL:http://search.cpan.org/dist/Text-ParseWords/
Source0:
http://www.cpan.org/authors/id/C/CH/CHORNY/Text-ParseWords-%{version}.tar.gz
+Source1:license.email
BuildArch: noarch
BuildRequires: perl
BuildRequires: perl(ExtUtils::MakeMaker)
@@ -45,6 +39,7 @@ for F in CHANGES README; do
touch -r $F ${F}.unix
mv ${F}.unix $F
done
+cp %{SOURCE1} ./
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -59,11 +54,14 @@ find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {}
\;
make test
%files
-%doc CHANGES README
+%doc CHANGES README license.email
%{perl_vendorlib}/*
%{_mandir}/man3/*
%changelog
+* Tue Nov 19 2013 Marcela Mašláňová mmasl...@redhat.com 3.29-5
+- According to guidelines must be email statement added as new source.
+
* Tue Nov 19 2013 Marcela Mašláňová mmasl...@redhat.com 3.29-4
- Add licence statement from the upstream ticket
- Resolves: rhbz#1030808
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel
Broken dependencies: perl-Language-Expr
perl-Language-Expr has broken dependencies in the F-20 tree: On x86_64: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On i386: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) On armhfp: perl-Language-Expr-0.19-4.fc19.noarch requires perl(:MODULE_COMPAT_5.16.2) 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
[Bug 914307] perl-PDL: FTBFS in rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=914307 Christopher Meng cicku...@gmail.com changed: What|Removed |Added Status|MODIFIED|CLOSED Resolution|--- |CURRENTRELEASE Last Closed||2013-11-19 07:28:03 -- You are receiving this mail because: You are on the CC list for the bug. Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=tpxwgRV8xZa=cc_unsubscribe -- 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-ExtUtils-Typemaps-Default/f20] New upstream release 1.04 (#977266)
Summary of changes: b9822ab... New upstream release 1.04 (#977266) (*) (*) This commit already existed in another branch; no separate mail sent -- 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-ExtUtils-Typemaps-Default/f19] (3 commits) ...New upstream release 1.04 (#977266)
Summary of changes: 1dc5ee6... Perl 5.18 rebuild (*) ce3161d... - Rebuilt for https://fedoraproject.org/wiki/Fedora_20_Mass (*) b9822ab... New upstream release 1.04 (#977266) (*) (*) This commit already existed in another branch; no separate mail sent -- 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
