Re: Should MariaDB touch my.cnf in %post?
Dennis Jacobfeuerborn denni...@conversis.de a écrit: Also MySQL 5.6 gains some of its speed through commercial extensions (like e.g. the thread pool). Since these cannot be packaged in Fedora you will be able to make a better/more fair comparison between the two based on the same Platform (Fedora). You mean non-Free Software extensions, right? If so, please say so, or say non Open Source, as you wish. Saying commercial in this context implies that Free Software cannot be used for commercial purposes, which is not true. AFAIK, MariaDB, which is completely Free Software is also distributed for the commercial purposes of the companies that fund its development. Sorry if I appear pedant on this, but I jump each time I see this Commercial/Free Software confusion. Thanks. -- Dodji -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/15/2013 11:58 PM, Till Maas wrote: On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote: - make a script to identify all the packages that are broken and shipping debug stuff. AT least for the directory a simple yum call should suffice: yum --disablerepo '*' --enablerepo fedora\* whatprovides /usr/lib/debug But it shows that a lot (all?) debuginfo packages own the directory which probably needs to be fixed in rpm itself. Regards Till I have filed a bug against filesystem: BZ 911831. I get 46 owners of /usr/lib/debug, that can't be all debug packages... Shall we file a bug against rpm, saying that claiming the complete path doesn't really work? I see the problems here, if rpm shouldn't claim the complete path /usr/lib/debug/lib/whatever, the part to claim is more or less arbitrary. Some macro defining the system paths i. e., the paths belonging to filesystem and not to the debug package? Must guidelines be updated.? Here are dragons... Chers! --alec -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Sat, 16 Feb 2013 10:44:27 +0100, Alec Leamas wrote: On 02/15/2013 11:58 PM, Till Maas wrote: On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote: - make a script to identify all the packages that are broken and shipping debug stuff. AT least for the directory a simple yum call should suffice: yum --disablerepo '*' --enablerepo fedora\* whatprovides /usr/lib/debug But it shows that a lot (all?) debuginfo packages own the directory which probably needs to be fixed in rpm itself. Regards Till I have filed a bug against filesystem: BZ 911831. I get 46 owners of /usr/lib/debug, that can't be all debug packages... Please do post the list somewhere. Also, are you running i686 or x86_64? 46 packages is not reproducible on x86_64 (albeit running Rawhide not F18). # setarch i686 repoquery --whatprovides /usr/lib/debug/.build-id/ nacl-devel-0:20110221-3.fc19.i686 # setarch i686 repoquery --whatprovides /usr/lib/debug/ nacl-devel-0:20110221-3.fc19.i686 # repoquery --whatprovides /usr/lib/debug/ nacl-devel-0:20110221-3.fc19.i686 # repoquery --whatprovides /usr/lib/debug/.build-id nacl-devel-0:20110221-3.fc19.i686 # repoquery --whatprovides /usr/src/debug filesystem-0:3.2-2.fc19.x86_64 # Shall we file a bug against rpm, saying that claiming the complete path doesn't really work? Why doesn't it work? -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git3.1.fc19.x86_64 loadavg: 0.10 0.14 0.19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 11:44 AM, Alec Leamas wrote: On 02/15/2013 11:58 PM, Till Maas wrote: On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote: - make a script to identify all the packages that are broken and shipping debug stuff. AT least for the directory a simple yum call should suffice: yum --disablerepo '*' --enablerepo fedora\* whatprovides /usr/lib/debug But it shows that a lot (all?) debuginfo packages own the directory which probably needs to be fixed in rpm itself. Regards Till I have filed a bug against filesystem: BZ 911831. I get 46 owners of /usr/lib/debug, that can't be all debug packages... Shall we file a bug against rpm, saying that claiming the complete path doesn't really work? I see the problems here, if rpm shouldn't claim the complete path /usr/lib/debug/lib/whatever, the part to claim is more or less arbitrary. Multiple owned directories might not be packaging purist clean :) but since -debuginfo packages are auto-generated and thus kinda guaranteed to be non-conflicting, it's just the less ugly option when the alternative is leaving empty directories behind. Which is what would happen if -debuginfo packages didn't own *all* the directories they put files into. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[Mass Rebuild] Strange parsing of %%doc
Hi all, WRT subject: before I go to file a bug report I want to make sure I'm not exploiting something unsupported in rpmbuild. In a couple of rpms (for which we're also upstream and I'm managing them, so it's fairly easy for me to workaround the issue) I have license saved in file with space, e.g. CC-BY-SA 3.0. In the spec I have a %%doc looking like this: %doc CC-BY-SA\ 3.0 Attribution Now, this has always worked and still works on Fedora 18 with rpm-build-4.10.3.1-1.fc18.i686 but the mass rebuilds fail with this message: -- Executing(%doc): /bin/sh -e /var/tmp/rpm-tmp.ENszch + umask 022 + cd /builddir/build/BUILD + cd beefy-miracle-backgrounds-16.91.0 + DOCDIR=/builddir/build/BUILDROOT/beefy-miracle-backgrounds-16.91.0-4.fc19.noarch/usr/share/doc/beefy-miracle-backgrounds-single-16.91.0 + export DOCDIR + /usr/bin/mkdir -p /builddir/build/BUILDROOT/beefy-miracle-backgrounds-16.91.0-4.fc19.noarch/usr/share/doc/beefy-miracle-backgrounds-single-16.91.0 + cp -pr 'CC-BY-SA /builddir/build/BUILDROOT/beefy-miracle-backgrounds-16.91.0-4.fc19.noarch/usr/share/doc/beefy-miracle-backgrounds-single-16.91.0' cp: missing destination file operand after 'CC-BY-SA /builddir/build/BUILDROOT/beefy-miracle-backgrounds-16.91.0-4.fc19.noarch/usr/share/doc/beefy-miracle-backgrounds-single-16.91.0' Try 'cp --help' for more information. -- The cp line in F18 is + cp -pr 'CC-BY-SA 3.0' Attribution /home/fedora/mso/rpmbuild/BUILDROOT/beefy-miracle-backgrounds-16.91.0-4.fc18.i386/usr/share/doc/beefy-miracle-backgrounds-single-16.91.0 So my question is, is this bug in my package(s) or in F19's rpmbuild? Thanks, Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/15/2013 09:47 PM, Michael Schwendt wrote:
On Fri, 15 Feb 2013 13:03:50 +0100, Alec Leamas wrote:
On 02/14/2013 11:19 PM, Michael Schwendt wrote:
On Thu, 14 Feb 2013 16:36:03 +0100, Alec Leamas wrote:
Running some automated tests I stumble over the debug directories. E. g.,
$ repoquery -qf /usr/lib/debug
shows 45 owners on current F18. Other directories under /usr/lib/debug
have a similar situation with many owners..
I note that /usr/src/debug is owned by filesystem, but filesystem does
not own /usr/lib/debug.
Is all this on purpose, or is something broken here? Thinking about it,
we never require anything for the debug package AFAICT. What's the story?
It depends on what the package stores below /usr/lib/debug.
Here's one that is mispackaged:
# repoquery -qf /usr/lib/debug
nacl-devel-0:20110221-3.fc19.i686
- http://koji.fedoraproject.org/koji/rpminfo?rpmID=3336721
It includes the -debuginfo package contents in the -devel package, most
likely because it does a lazy'n'risky %{_libdir}/* in its %files section.
Thanks for reply... Still, I'm puzzled about 45 packages owning
/usr/lib/debug, none of them the filesystem package. This looks weird,
although I don't grasp the consequences (if any).
Which packages are returned for your query?
I've tried repoquery --whatprovides /usr/lib/debug for both x86_64
and i686, but it doesn't return anything other than nacl-devel.
Yup, you're right about that. Besides the debuginfo, thats the one.
Do you have any -debuginfo packages installed from a -debuginfo repo?
Those do own /usr/lib/debug and /usr/src/debug.
rpm -qa \*debuginfo
Yes, they do. And this is the focal point here IMHO. According to Kevin,
this is a bug and should be fixed by having filesystem to own
/usr/lib/debug (like /usr/src/debug), and also having packages only to
own their own directories. Are saying that the current ownership is OK?
Whatever command I used, it was wrong. New datapoint:
$ repoquery --disablerepo='*' --enablerepo='fedora*' -qf /usr/lib/debug
| wc -l
6089
cheers!
-alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Mass Rebuild] Strange parsing of %%doc
On Sat, 16 Feb 2013 11:57:54 +0100, Martin Sourada wrote: Hi all, WRT subject: before I go to file a bug report I want to make sure I'm not exploiting something unsupported in rpmbuild. In a couple of rpms (for which we're also upstream and I'm managing them, so it's fairly easy for me to workaround the issue) I have license saved in file with space, e.g. CC-BY-SA 3.0. In the spec I have a %%doc looking like this: %doc CC-BY-SA\ 3.0 Attribution I've seen Panu commenting on it before, so I've searched a bit: http://lists.fedoraproject.org/pipermail/devel/2013-January/176565.html -- Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git3.1.fc19.x86_64 loadavg: 0.35 0.14 0.19 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 11:41 AM, Panu Matilainen wrote:
On 02/16/2013 11:44 AM, Alec Leamas wrote:
On 02/15/2013 11:58 PM, Till Maas wrote:
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote:
- make a script to identify all the packages that are broken and
shipping debug stuff.
AT least for the directory a simple yum call should suffice:
yum --disablerepo '*' --enablerepo fedora\* whatprovides
/usr/lib/debug
But it shows that a lot (all?) debuginfo packages own the directory
which probably needs to be fixed in rpm itself.
Regards
Till
I have filed a bug against filesystem: BZ 911831.
I get 46 owners of /usr/lib/debug, that can't be all debug packages...
Shall we file a bug against rpm, saying that claiming the complete path
doesn't really work? I see the problems here, if rpm shouldn't claim the
complete path /usr/lib/debug/lib/whatever, the part to claim is more or
less arbitrary.
Multiple owned directories might not be packaging purist clean :)
but since -debuginfo packages are auto-generated and thus kinda
guaranteed to be non-conflicting, it's just the less ugly option when
the alternative is leaving empty directories behind. Which is what
would happen if -debuginfo packages didn't own *all* the directories
they put files into.
- Panu -
Well, I try to be practical (believe it or not). This explanation looks
perfectly sound to me (although it still seems inconsistent that
filesystem owns /usr/src/debug but not /usr/lib/debug).
I ran into this while automating some tests about directory ownership in
fedora-review. If we all agree that Panu's position is OK, I would be
more than happy to just exclude /usr/l{lib,src}/debug from the ownership
checks. With that we should be able to close this discussion.
However, at least Kevin had other ideas. So did I, but I'm flexible and
have changed my mind :)
cheers,
--alec
cheers!
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Sat, 16 Feb 2013 11:59:08 +0100, Alec Leamas wrote:
According to Kevin,
this is a bug and should be fixed by having filesystem to own
/usr/lib/debug (like /usr/src/debug), and also having packages only to
own their own directories. Are saying that the current ownership is OK?
Whatever command I used, it was wrong. New datapoint:
$ repoquery --disablerepo='*' --enablerepo='fedora*' -qf /usr/lib/debug
| wc -l
6089
The typical -debuginfo package contains several dirs:
$ rpmls geeqie-debuginfo|grep ^d
drwxr-xr-x /usr/lib/debug
drwxr-xr-x /usr/lib/debug/.build-id
drwxr-xr-x /usr/lib/debug/.build-id/be
drwxr-xr-x /usr/lib/debug/usr
drwxr-xr-x /usr/lib/debug/usr/bin
drwxr-xr-x /usr/src/debug/geeqie-1.1
drwxr-xr-x /usr/src/debug/geeqie-1.1/src
drwxr-xr-x /usr/src/debug/geeqie-1.1/src/icons
Larger ones contain many more dirs:
$ rpmls gcc-debuginfo|grep ^d|wc -l
893
Obviously, multiple -debuginfo packages share some of the dirs with
eachother. A package must include a dir for it to be removed when the package
gets uninstalled and the dir would be empty afterwards. If multiple
packages include the same dir (with the same ownership and permissions),
that is okay. Upon erasing the last package, the dirs would be removed.
And don't just focus on just the top dir. If you wanted to move ownership
of dirs into a single package only, such as filesystem, you would need to
move other dirs too, such as /usr/lib/debug/usr/{bin,lib,libexec}, basically
any dir that may be used by more than one package some time in the future.
--
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git3.1.fc19.x86_64
loadavg: 0.27 0.21 0.20
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 01:33 PM, Alec Leamas wrote:
On 02/16/2013 11:41 AM, Panu Matilainen wrote:
On 02/16/2013 11:44 AM, Alec Leamas wrote:
On 02/15/2013 11:58 PM, Till Maas wrote:
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote:
- make a script to identify all the packages that are broken and
shipping debug stuff.
AT least for the directory a simple yum call should suffice:
yum --disablerepo '*' --enablerepo fedora\* whatprovides
/usr/lib/debug
But it shows that a lot (all?) debuginfo packages own the directory
which probably needs to be fixed in rpm itself.
Regards
Till
I have filed a bug against filesystem: BZ 911831.
I get 46 owners of /usr/lib/debug, that can't be all debug packages...
Shall we file a bug against rpm, saying that claiming the complete path
doesn't really work? I see the problems here, if rpm shouldn't claim the
complete path /usr/lib/debug/lib/whatever, the part to claim is more or
less arbitrary.
Multiple owned directories might not be packaging purist clean :)
but since -debuginfo packages are auto-generated and thus kinda
guaranteed to be non-conflicting, it's just the less ugly option when
the alternative is leaving empty directories behind. Which is what
would happen if -debuginfo packages didn't own *all* the directories
they put files into.
- Panu -
Well, I try to be practical (believe it or not). This explanation looks
perfectly sound to me (although it still seems inconsistent that
filesystem owns /usr/src/debug but not /usr/lib/debug).
Ah, didn't know filesystem owns some of the toplevel debug directories.
Not particularly harmful but consistency rarely hurts.
I ran into this while automating some tests about directory ownership in
fedora-review. If we all agree that Panu's position is OK, I would be
more than happy to just exclude /usr/l{lib,src}/debug from the ownership
checks. With that we should be able to close this discussion.
However, at least Kevin had other ideas. So did I, but I'm flexible and
have changed my mind :)
I think Kevin was talking about normal, ie non-debuginfo packages like
the example case of nacl-devel owning /usr/lib/debug, which indeed is a
(trivial) packaging bug. Except perhaps for the filesystem package which
is fairly special case anyway.
OTOH because -debuginfo packages always own all the relevant directories
there's no need for filesystem to own them, which would allow for a nice
and clean rule: any non-debuginfo package owning the *debug directories
can be considered an unnecessary multiple directory ownership (and a bug
of sorts).
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Mass Rebuild] Strange parsing of %%doc
On 02/16/2013 01:21 PM, Michael Schwendt wrote: On Sat, 16 Feb 2013 11:57:54 +0100, Martin Sourada wrote: Hi all, WRT subject: before I go to file a bug report I want to make sure I'm not exploiting something unsupported in rpmbuild. In a couple of rpms (for which we're also upstream and I'm managing them, so it's fairly easy for me to workaround the issue) I have license saved in file with space, e.g. CC-BY-SA 3.0. In the spec I have a %%doc looking like this: %doc CC-BY-SA\ 3.0 Attribution I've seen Panu commenting on it before, so I've searched a bit: http://lists.fedoraproject.org/pipermail/devel/2013-January/176565.html Yup. Rpm = 4.11 does not (and is unlikely to ever to) support all the shell-quoting styles that accidentally worked in older versions. Rpm = 4.10.3 supports double-quoting in %doc so in Fedora = 18 you can now use %doc CC-BY-SA 3.0 Attribution ...but if you need spec compatibility across all Fedora (and RHEL) versions, whitespace in %doc needs to be worked around with globs. Guess I should backport the double-quoting support to F17 too to allow consistency within the currently active Fedora versions. - Panu - -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [Mass Rebuild] Strange parsing of %%doc
On 02/16/2013 01:21 PM, Michael Schwendt wrote: I've seen Panu commenting on it before, so I've searched a bit: http://lists.fedoraproject.org/pipermail/devel/2013-January/176565.html Thanks, I didn't read the whole thread back then :-/ On Sat, 16 Feb 2013 14:06:44 +0200 Panu Matilainen wrote: Yup. Rpm = 4.11 does not (and is unlikely to ever to) support all the shell-quoting styles that accidentally worked in older versions. Rpm = 4.10.3 supports double-quoting in %doc so in Fedora = 18 you can now use %doc CC-BY-SA 3.0 Attribution ...but if you need spec compatibility across all Fedora (and RHEL) versions, whitespace in %doc needs to be worked around with globs. Guess I should backport the double-quoting support to F17 too to allow consistency within the currently active Fedora versions. Thanks! Martin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Gnome-shell workspaces
Trond Hasle Amundsen t.h.amund...@usit.uio.no wrote: Christopher Meng cicku...@gmail.com writes: Somewhat funny that many users even don't know this tweak tool and ask everywhere about this.. I always found it odd that gnome-tweak-tool even exists.. some functionality are found in the system settings, some in gnome-tweak-tool. If you ask me, gnome-tweak-tool should be part of the standard system settings. Call it advanced shell options or something. It would be easier for users to find, provide a more consistent GNOME experience, and ultimately happier users. The point of having the Tweak Tool is to provide an enhanced experience for those users who do want to tweak, while maintaining a sane set of options for those people who don't have an interest in customisation. I would personally love to see the Tweak Tool grow to become more comprehensive and interesting. There are no limits on what can be included there. This freedom of expansion is something you would never have with System Settings - there simply isn't space for everything you would want to include. I'd also like to see a Theme Tool or similar for those people who want to play around with themes. Having dedicated applications for these types of activities should allow a far better experience than lumping everything into the control center. System Settings simply isn't a good fit for this (the old GNOME 2 appearance settings were never great; compare them with something like Windows Blinds [1] and you'll see what having a dedicated application means in terms of quality of experience). Part of the issue here is that the Tweak Tool doesn't get a huge amount of developer time, which means that the value of having a separate tool hasn't been quite realised. If anyone wants to help with this, just step up. It's a simple Python app, and the maintainer is usually responsive. Allan [1] http://www.stardock.com/products/windowblinds/ -- IRC: aday on irc.gnome.org Blog: http://afaikblog.wordpress.com/ -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Fri, Feb 15, 2013 at 06:20:52PM -0800, Samuel Sieb wrote: My understanding is that the session list is dependent on the user selected. At least the default session is, so it made sense to wait until a user is chosen before showing the list. Using this you can show the correct default session for that user. You have two possibilities: 1. Show sessions before selecting/entering the user: Means basically including something like 'default session' or 'previous session' 2. Show sessions after selecting/entering the user: Means you can show the actual session that will be chosen. There are tradeoffs between both of them, GDM chose #2, making some stuff nicer, some stuff worse. It would be nice if someone would do a usability study on this (maybe session selector should be more obvious or something… thinking of maybe a list instead of a dropdown). -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: Cinnamon as Default Desktop
On Sat, Feb 16, 2013 at 12:15:10AM +0100, Martin Sourada wrote: What about users *without* password? It's insecure (in most cases), but possible. That is a known tradeoff/bug. IMO this is a case of 'it hurts when I do this'. Tradeoff is how often you have a nicer experience (showing the right session that will be selected) vs use cases that are broken or less nice. -- Regards, Olav -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 12:41 PM, Michael Schwendt wrote:
On Sat, 16 Feb 2013 11:59:08 +0100, Alec Leamas wrote:
According to Kevin,
this is a bug and should be fixed by having filesystem to own
/usr/lib/debug (like /usr/src/debug), and also having packages only to
own their own directories. Are saying that the current ownership is OK?
Whatever command I used, it was wrong. New datapoint:
$ repoquery --disablerepo='*' --enablerepo='fedora*' -qf /usr/lib/debug
| wc -l
6089
The typical -debuginfo package contains several dirs:
$ rpmls geeqie-debuginfo|grep ^d
drwxr-xr-x /usr/lib/debug
drwxr-xr-x /usr/lib/debug/.build-id
drwxr-xr-x /usr/lib/debug/.build-id/be
drwxr-xr-x /usr/lib/debug/usr
drwxr-xr-x /usr/lib/debug/usr/bin
drwxr-xr-x /usr/src/debug/geeqie-1.1
drwxr-xr-x /usr/src/debug/geeqie-1.1/src
drwxr-xr-x /usr/src/debug/geeqie-1.1/src/icons
Larger ones contain many more dirs:
$ rpmls gcc-debuginfo|grep ^d|wc -l
893
Obviously, multiple -debuginfo packages share some of the dirs with
eachother. A package must include a dir for it to be removed when the package
gets uninstalled and the dir would be empty afterwards. If multiple
packages include the same dir (with the same ownership and permissions),
that is okay. Upon erasing the last package, the dirs would be removed.
And don't just focus on just the top dir. If you wanted to move ownership
of dirs into a single package only, such as filesystem, you would need to
move other dirs too, such as /usr/lib/debug/usr/{bin,lib,libexec}, basically
any dir that may be used by more than one package some time in the future.
Yes, I have noted that in the bug. The basic question remains whether
to be kosher or not, Panu (and I think also you?) arguing that it's more
problems than benefit.
Personally, I have accepted Panu's explanation that the multiple
ownership is a working solution for the auto-generated debug packages.
Perhaps some of the elderly still thinks this should be done by the
rules, which means that the auto-generated Provides: needs to be
adjusted. However, nothing in this thread has convinced that it's worth
the effort so far.
cheers!
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 12:47 PM, Panu Matilainen wrote:
On 02/16/2013 01:33 PM, Alec Leamas wrote:
On 02/16/2013 11:41 AM, Panu Matilainen wrote:
On 02/16/2013 11:44 AM, Alec Leamas wrote:
On 02/15/2013 11:58 PM, Till Maas wrote:
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote:
- make a script to identify all the packages that are broken and
shipping debug stuff.
AT least for the directory a simple yum call should suffice:
yum --disablerepo '*' --enablerepo fedora\* whatprovides
/usr/lib/debug
But it shows that a lot (all?) debuginfo packages own the directory
which probably needs to be fixed in rpm itself.
Regards
Till
I have filed a bug against filesystem: BZ 911831.
I get 46 owners of /usr/lib/debug, that can't be all debug packages...
Shall we file a bug against rpm, saying that claiming the complete
path
doesn't really work? I see the problems here, if rpm shouldn't
claim the
complete path /usr/lib/debug/lib/whatever, the part to claim is
more or
less arbitrary.
Multiple owned directories might not be packaging purist clean :)
but since -debuginfo packages are auto-generated and thus kinda
guaranteed to be non-conflicting, it's just the less ugly option when
the alternative is leaving empty directories behind. Which is what
would happen if -debuginfo packages didn't own *all* the directories
they put files into.
- Panu -
Well, I try to be practical (believe it or not). This explanation looks
perfectly sound to me (although it still seems inconsistent that
filesystem owns /usr/src/debug but not /usr/lib/debug).
Ah, didn't know filesystem owns some of the toplevel debug
directories. Not particularly harmful but consistency rarely hurts.
I ran into this while automating some tests about directory ownership in
fedora-review. If we all agree that Panu's position is OK, I would be
more than happy to just exclude /usr/l{lib,src}/debug from the ownership
checks. With that we should be able to close this discussion.
However, at least Kevin had other ideas. So did I, but I'm flexible and
have changed my mind :)
I think Kevin was talking about normal, ie non-debuginfo packages
like the example case of nacl-devel owning /usr/lib/debug, which
indeed is a (trivial) packaging bug. Except perhaps for the filesystem
package which is fairly special case anyway.
OTOH because -debuginfo packages always own all the relevant
directories there's no need for filesystem to own them, which would
allow for a nice and clean rule: any non-debuginfo package owning the
*debug directories can be considered an unnecessary multiple directory
ownership (and a bug of sorts).
- Panu -
Well, isn't the rule is actually simpler than that: any package owning
a directory owned by another package is broken. It's just that we
should not apply this rule to debuginfo packages, which are
auto-generated and thus are OK by definition.
Perhaps it should might make sense to mention this in the guidelines,
which as of now actually states that any directory is owned by exactly
one package. This exception for debuginfo directories is not mentioned.
It doesn't really matter when doing regular packaging, but it does make
a difference when checking for guidelines compliance ...
--alec
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On 02/16/2013 04:01 PM, Alec Leamas wrote:
On 02/16/2013 12:47 PM, Panu Matilainen wrote:
On 02/16/2013 01:33 PM, Alec Leamas wrote:
On 02/16/2013 11:41 AM, Panu Matilainen wrote:
On 02/16/2013 11:44 AM, Alec Leamas wrote:
On 02/15/2013 11:58 PM, Till Maas wrote:
On Fri, Feb 15, 2013 at 10:50:28AM -0700, Kevin Fenzi wrote:
- make a script to identify all the packages that are broken and
shipping debug stuff.
AT least for the directory a simple yum call should suffice:
yum --disablerepo '*' --enablerepo fedora\* whatprovides
/usr/lib/debug
But it shows that a lot (all?) debuginfo packages own the directory
which probably needs to be fixed in rpm itself.
Regards
Till
I have filed a bug against filesystem: BZ 911831.
I get 46 owners of /usr/lib/debug, that can't be all debug packages...
Shall we file a bug against rpm, saying that claiming the complete
path
doesn't really work? I see the problems here, if rpm shouldn't
claim the
complete path /usr/lib/debug/lib/whatever, the part to claim is
more or
less arbitrary.
Multiple owned directories might not be packaging purist clean :)
but since -debuginfo packages are auto-generated and thus kinda
guaranteed to be non-conflicting, it's just the less ugly option when
the alternative is leaving empty directories behind. Which is what
would happen if -debuginfo packages didn't own *all* the directories
they put files into.
- Panu -
Well, I try to be practical (believe it or not). This explanation looks
perfectly sound to me (although it still seems inconsistent that
filesystem owns /usr/src/debug but not /usr/lib/debug).
Ah, didn't know filesystem owns some of the toplevel debug
directories. Not particularly harmful but consistency rarely hurts.
I ran into this while automating some tests about directory ownership in
fedora-review. If we all agree that Panu's position is OK, I would be
more than happy to just exclude /usr/l{lib,src}/debug from the ownership
checks. With that we should be able to close this discussion.
However, at least Kevin had other ideas. So did I, but I'm flexible and
have changed my mind :)
I think Kevin was talking about normal, ie non-debuginfo packages
like the example case of nacl-devel owning /usr/lib/debug, which
indeed is a (trivial) packaging bug. Except perhaps for the filesystem
package which is fairly special case anyway.
OTOH because -debuginfo packages always own all the relevant
directories there's no need for filesystem to own them, which would
allow for a nice and clean rule: any non-debuginfo package owning the
*debug directories can be considered an unnecessary multiple directory
ownership (and a bug of sorts).
- Panu -
Well, isn't the rule is actually simpler than that: any package owning
a directory owned by another package is broken. It's just that we
should not apply this rule to debuginfo packages, which are
auto-generated and thus are OK by definition.
That's not what I see in
http://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership:
---
Directory ownership is a little more complex than file ownership.
Packages must own all directories they put files in, except for:
any directories owned by the filesystem, man, or other explicitly
created -filesystem packages
any directories owned by other packages in your package's natural
dependency chain
---
It's the packages with unowned directories that are broken, not the ones
with multiply owned directories when there's no clean natural owner for
them.
Since debuginfo packages are automatically generated, there's no way to
manually select the least worst alternative between the directory
ownership options case-by-case. The only way to guarantee no unowned
directories in automatically generated packages is to own them all,
which is only really feasible because they are automatically generated :)
- Panu -
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Sat, 16 Feb 2013 15:01:32 +0100, Alec Leamas wrote:
Well, isn't the rule is actually simpler than that: any package owning
a directory owned by another package is broken.
It used to be like that, but nowadays the guidelines aren't that strict
anymore. See multiple ownership here:
https://fedoraproject.org/wiki/Packaging:Guidelines#File_and_Directory_Ownership
https://fedoraproject.org/wiki/Packaging:Guidelines#The_directory_is_owned_by_a_package_which_is_not_required_for_your_package_to_function
In order to have only a single package being the only owner of a directory,
there would be an inflation of either the filesystem package or
additional -filesystem subpackages elsewhere, which one could depend
on _only_ for proper directory ownership. This would create overhead.
To make fedora-review be extra careful when finding a %files entry
%{_libdir}/* might be worthwhile. Such an entry would include files
in /usr/lib/debug (where %_libdir = /usr/lib) and also bears a risk
of duplicating files included in subpackages. It shouldn't be too hard
for a packager to come up with a safer more-appropriate wildcard than '*'.
--
Fedora release 19 (Rawhide) - Linux 3.8.0-0.rc7.git3.1.fc19.x86_64
loadavg: 0.34 0.54 0.48
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: /usr/lib/debug ownership
On Sat, 16 Feb 2013 13:47:13 +0200 Panu Matilainen pmati...@laiskiainen.org wrote: I think Kevin was talking about normal, ie non-debuginfo packages like the example case of nacl-devel owning /usr/lib/debug, which indeed is a (trivial) packaging bug. Except perhaps for the filesystem package which is fairly special case anyway. Indeed I was. I was thinking we were talking about packages that mistakenly are shipping their debuginfo in the real package. OTOH because -debuginfo packages always own all the relevant directories there's no need for filesystem to own them, which would allow for a nice and clean rule: any non-debuginfo package owning the *debug directories can be considered an unnecessary multiple directory ownership (and a bug of sorts). Sounds fine to me. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
please fix the lie in ReplaceMySQLwithMariaDB
http://fedoraproject.org/wiki/Features/ReplaceMySQLwithMariaDB#Comments_and_Discussion MariaDB is binary compatible with MySQL of the same major version, so we don't need to change anything in packages depending on libmysqlclient.so that database-files are binary-compatible does NOT mean the bianries itself are binary-compatible and it is simply impossible if you take a breath and think about how ABI-compatibility is defined there where even a ABI-break in the GA-lifecycle of MySQL 5.5 without raise the soname which was done in a minor-update after GA __ since the changelog contains one of the feature owners for exactly this soname-bump it leaves the bad taste that the we don't need to change anything in packages depending on libmysqlclient.so was written to get the FESCo OK by knowing it is not true or someone does not mind the difference between API and ABI which would not make things better * Mon Mar 21 2011 Tom Lane t...@redhat.com 5.5.10-1 - Update to MySQL 5.5.10, for various fixes described at http://dev.mysql.com/doc/refman/5.5/en/news-5-5-10.html Note that this includes a rather belated soname version bump for libmysqlclient.so, from .16 to .18 __ there is no word about binary compatibility for shared libraries https://kb.askmonty.org/en/mariadb-versus-mysql-compatibility/ * Data and table definition files (.frm) files are binary compatible. * All client APIs, protocols and structs are identical. * All filenames, binaries, paths, ports, sockets, and etc... should be the same. * All MySQL connectors (PHP, Perl, Python, Java, .NET, MyODBC, Ruby, MySQL C connector etc) work unchanged with MariaDB. * There are some installation issues with PHP5 that you should be aware of (a bug in how the old PHP5 client checks library compatibility). The mysql-client package also works with MariaDB server. signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Should MariaDB touch my.cnf in %post?
HI On Sat, Feb 16, 2013 at 5:46 AM, Reindl Harald h.rei...@thelounge.netwrote: Am 16.02.2013 07:09, schrieb Rahul Sundaram: On Fri, Feb 15, 2013 at 8:23 PM, Reindl Harald wrote: and which fool has written the feature page without knowing what binary compatibility what about quoting the context? It doesn't matter what the context is. You have no excuse whatsoever to call anyone fools in this discussion. You have been repeatedly using offensive language and shouting on the mailing lists on a regular basis. Can you stop doing that? It is getting very tiresome. If you cannot ask politely, nobody is compelling you to participate at all you have really really no idea how i sound if i shout, really and write in the feature page MariaDB will be BINARY COMPATIBLE is foolish - there is no nicer word for the fact FYI, caps = shouting when writing online. If you don't know a respectful way to point out what you perceive to be incorrect claims, you don't have to participate at all Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Heads up: ARM build system outage for migration
The migration is complete, arm.koji is back up. We're still testing and doing some clean up bits and pieces but the migration has been successful. Peter On Fri, Feb 15, 2013 at 6:25 PM, Peter Robinson pbrobin...@gmail.com wrote: Hi All, A heads up that we're planning an outage of arm.koji.fedoraproject.org to migrate the koji instance to the new infrastructure in Phoenix. The outage will begin about 02:00 UTC on Saturday the 16th February and while we're not certain the exact time it should take we estimate it should be done in well under 12 hours. I'll reply to this message once we're up and building again. From there we'll kick off the ARM mass rebuild to give the currently deployed hardware a good burn in (it's almost like we planned it like this but we didn't :-P ) I'll be shutting down the shadowing processes shorts to allow builds to complete and to remove I/O to allow the data sync to complete. See you on the flip side! Cheers, Peter -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fortran module ABI issue
Often (though not always) with new GCC versions there is a new version for Fortran modules that is incompatible with old versions. An example error is here from the rebuild of the netcdf-fortran package: use mpi 1 Fatal Error: Cannot read module file 'mpi.mod' opened at (1), because it was created by a different version of GNU Fortran In the short term, we're going to need to get mpich2-1.5-2.fc19 tagged into the buildroot in order to rebuild netcdf-fortran and any other fortran module users. We also really need a fortran module ABI virtual provides/requires I think to handle this properly. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File IO-Socket-SSL-1.84.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-IO-Socket-SSL: 3878d8c84c1e8a611f4d0d9b3574ce35 IO-Socket-SSL-1.84.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-IO-Socket-SSL] Update to 1.84
commit 6f7e6bccfa56c917e41fe1494f6a84ec3211314f
Author: Paul Howarth p...@city-fan.org
Date: Sat Feb 16 10:31:38 2013 +
Update to 1.84
- New upstream release 1.84
- Disabled client side SNI for openssl version 1.0.0 because of
CPAN RT#83289
- Added functions can_client_sni, can_server_sni and can_npn to check
availability of SNI and NPN features
- Added more documentation for SNI and NPN
perl-IO-Socket-SSL.spec | 22 +-
sources |2 +-
2 files changed, 14 insertions(+), 10 deletions(-)
---
diff --git a/perl-IO-Socket-SSL.spec b/perl-IO-Socket-SSL.spec
index c678134..1e9731a 100644
--- a/perl-IO-Socket-SSL.spec
+++ b/perl-IO-Socket-SSL.spec
@@ -1,15 +1,11 @@
-# Don't want to break rpm upgrade path if/when upstream reverts to two
-# digits after the decimal point for version number
-%global extraversion 1
-
Name: perl-IO-Socket-SSL
-Version: 1.83
-Release: 2%{?dist}
+Version: 1.84
+Release: 1%{?dist}
Summary: Perl library for transparent SSL
Group: Development/Libraries
License: GPL+ or Artistic
URL: http://search.cpan.org/dist/IO-Socket-SSL/
-Source0:
http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/IO-Socket-SSL-%{version}%{?extraversion}.tar.gz
+Source0:
http://search.cpan.org/CPAN/authors/id/S/SU/SULLR/IO-Socket-SSL-%{version}.tar.gz
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(id -nu)
BuildArch: noarch
BuildRequires: perl(Carp)
@@ -46,7 +42,7 @@ SSL version selection. As an extra bonus, it works perfectly
with
mod_perl.
%prep
-%setup -q -n IO-Socket-SSL-%{version}%{?extraversion}
+%setup -q -n IO-Socket-SSL-%{version}
%build
perl Makefile.PL INSTALLDIRS=vendor
@@ -70,9 +66,17 @@ rm -rf %{buildroot}
%{_mandir}/man3/IO::Socket::SSL.3pm*
%changelog
+* Sat Feb 16 2013 Paul Howarth p...@city-fan.org - 1.84-1
+- Update to 1.84
+ - Disabled client side SNI for openssl version 1.0.0 because of
+CPAN RT#83289
+ - Added functions can_client_sni, can_server_sni and can_npn to check
+availability of SNI and NPN features
+ - Added more documentation for SNI and NPN
+
* Thu Feb 14 2013 Paul Howarth p...@city-fan.org - 1.83-2
- Update to 1.831
- - Separated documention of non-blocking I/O from error handling
+ - Separated documentation of non-blocking I/O from error handling
- Changed and documented behavior of readline to return the read data on
EAGAIN/EWOULDBLOCK in case of non-blocking socket
(see https://github.com/noxxi/p5-io-socket-ssl/issues/1)
diff --git a/sources b/sources
index acbfacd..caae868 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-630fec02564c2941b5bea40b69d321bc IO-Socket-SSL-1.831.tar.gz
+3878d8c84c1e8a611f4d0d9b3574ce35 IO-Socket-SSL-1.84.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-IO-Socket-SSL] Created tag perl-IO-Socket-SSL-1.84-1.fc19
The lightweight tag 'perl-IO-Socket-SSL-1.84-1.fc19' was created pointing to: 6f7e6bc... Update to 1.84 -- 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 570979] UTF8 PO files not being read as UTF8
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=570979 --- Comment #6 from Fedora Update System upda...@fedoraproject.org --- Package perl-Locale-PO-0.23-1.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing perl-Locale-PO-0.23-1.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2594/perl-Locale-PO-0.23-1.fc18 then log in and leave karma (feedback). -- 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=fZiSP4YkMva=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
Broken dependencies: perl-WWW-GoodData
perl-WWW-GoodData has broken dependencies in the epel-5 tree: On ppc: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 On i386: perl-WWW-GoodData-1.6-1.el5.noarch requires perl(Getopt::Long) = 0:2.36 Please resolve this as soon as possible. -- Fedora Extras Perl SIG http://www.fedoraproject.org/wiki/Extras/SIGs/Perl perl-devel mailing list perl-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/perl-devel
[perl-Algorithm-Dependency] Add BR: perl(ExtUtils::MakeMaker) (Fix Fedora_19_Mass_Rebuild FTBFS).
commit 164188f7ee4ecd3c545a6d4000f5494fba5a2abb
Author: Ralf Corsépius corse...@fedoraproject.org
Date: Sun Feb 17 08:23:40 2013 +0100
Add BR: perl(ExtUtils::MakeMaker) (Fix Fedora_19_Mass_Rebuild FTBFS).
- Spec-file cleanup.
perl-Algorithm-Dependency.spec | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
---
diff --git a/perl-Algorithm-Dependency.spec b/perl-Algorithm-Dependency.spec
index 8667e85..e90a2b6 100644
--- a/perl-Algorithm-Dependency.spec
+++ b/perl-Algorithm-Dependency.spec
@@ -1,16 +1,16 @@
Name: perl-Algorithm-Dependency
Version: 1.110
-Release: 12%{?dist}
+Release: 13%{?dist}
Summary: Algorithmic framework for implementing dependency trees
License: GPL+ or Artistic
Group: Development/Libraries
URL: http://search.cpan.org/dist/Algorithm-Dependency/
Source0:
http://search.cpan.org/CPAN/authors/id/A/AD/ADAMK/Algorithm-Dependency-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo $version))
BuildArch: noarch
+BuildRequires: perl(ExtUtils::MakeMaker)
BuildRequires: perl(File::Spec)= 0.82
BuildRequires: perl(Test::ClassAPI)= 0.6
BuildRequires: perl(Test::More)= 0.47
@@ -34,15 +34,11 @@ items in the set, and require actions on them as well.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} ';'
find $RPM_BUILD_ROOT -type d -depth -exec rmdir {} 2/dev/null ';'
chmod -R u+w $RPM_BUILD_ROOT/*
-%clean
-rm -rf $RPM_BUILD_ROOT
-
%check
make test AUTOMATED_TESTING=1
@@ -53,6 +49,10 @@ make test AUTOMATED_TESTING=1
%{_mandir}/man3/*
%changelog
+* Sun Feb 17 2013 Ralf Corsépius corse...@fedoraproject.org - 1.110-13
+- Add BR: perl(ExtUtils::MakeMaker) (Fix Fedora_19_Mass_Rebuild FTBFS).
+- Spec-file cleanup.
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 1.110-12
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_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
[perl-Algorithm-Dependency/f18: 3/3] Merge cleanup.
commit 90d128f7cacd399fe261ceb996e9b0249aee8e81 Author: Ralf Corsépius corse...@fedoraproject.org Date: Sun Feb 17 08:24:56 2013 +0100 Merge cleanup. perl-Algorithm-Dependency.spec |3 --- 1 files changed, 0 insertions(+), 3 deletions(-) --- diff --git a/perl-Algorithm-Dependency.spec b/perl-Algorithm-Dependency.spec index e90a2b6..d365ce9 100644 --- a/perl-Algorithm-Dependency.spec +++ b/perl-Algorithm-Dependency.spec @@ -53,9 +53,6 @@ make test AUTOMATED_TESTING=1 - Add BR: perl(ExtUtils::MakeMaker) (Fix Fedora_19_Mass_Rebuild FTBFS). - Spec-file cleanup. -* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.110-12 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild - * Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.110-11 - Rebuilt for https://fedoraproject.org/wiki/Fedora_18_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
[perl-Algorithm-Dependency/f17: 6/6] Merge cleanup.
commit 78cea31fd5a97f9240d8a1b55a609a783fc89b66 Author: Ralf Corsépius corse...@fedoraproject.org Date: Sun Feb 17 08:28:18 2013 +0100 Merge cleanup. perl-Algorithm-Dependency.spec |6 -- 1 files changed, 0 insertions(+), 6 deletions(-) --- diff --git a/perl-Algorithm-Dependency.spec b/perl-Algorithm-Dependency.spec index d365ce9..f2c77d0 100644 --- a/perl-Algorithm-Dependency.spec +++ b/perl-Algorithm-Dependency.spec @@ -53,12 +53,6 @@ make test AUTOMATED_TESTING=1 - Add BR: perl(ExtUtils::MakeMaker) (Fix Fedora_19_Mass_Rebuild FTBFS). - Spec-file cleanup. -* Fri Jul 20 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.110-11 -- Rebuilt for https://fedoraproject.org/wiki/Fedora_18_Mass_Rebuild - -* Thu Jun 21 2012 Petr Pisar ppi...@redhat.com - 1.110-10 -- Perl 5.16 rebuild - * Fri Jan 13 2012 Fedora Release Engineering rel-...@lists.fedoraproject.org - 1.110-9 - Rebuilt for https://fedoraproject.org/wiki/Fedora_17_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
