I wrote:
What should I use for the release number in a spec when upstream does
not have releases, and *only* has git hashes? It's not a prerelease
since it is not clear that there will ever be any official release.
I meant version number, not release number. I imagine that the
release
On Mon, Oct 03, 2011 at 05:33:47PM -0500, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
At 100T it doesn't run out of memory, but the man behind the curtain
starts to show. The underlying qcow2 file grows to several gigs and I
had to kill it. I need to play with the
100T seems to work for light use.
I can create the filesystem, mount it, write files and directories and
read them back, and fsck doesn't report any problems.
Filesystem Size Used Avail Use% Mounted on
/dev/vda199T 129M 94T 1% /sysroot
Linux (none)
On 10/04/2011 01:03 AM, Eric Sandeen wrote:
On 10/3/11 5:53 PM, Farkas Levente wrote:
On 10/04/2011 12:33 AM, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
I wasn't able to give the VM enough memory to make this
On 10/04/2011 01:03 AM, Eric Sandeen wrote:
Large filesystem support for ext4 has languished upstream for a very
long time, and few in the community seemed terribly interested to test it,
either.
why? that's what i simple do not understand!?...
--
Levente Si
On 10/04/2011 08:04 AM, Eric Smith wrote:
I wrote:
What should I use for the release number in a spec when upstream does
not have releases, and *only* has git hashes? It's not a prerelease
since it is not clear that there will ever be any official release.
I meant version number, not
Hi,
I'm not starting by filing this as a bug as it encompasses a number of
issues and it's not clear where the problem really lies, so I thought
I'd start a discussion here first.
I posted on what I'm trying to do previously (in F13) here:
Le Lun 3 octobre 2011 17:09, Przemek Klosowski a écrit :
The bottom line is that the power supply is probably on the fritz and
likely to fail altogether. Decent power supplies aren't that expensive,
I recently got a nice, quiet one for around $30-40.
Thanks, but it's perfectly fine under
Le Lun 3 octobre 2011 18:56, Adam Jackson a écrit :
More to the point, your DPI numbers would be per-output anyway, so
there's no picking a single point size preference, the same size in
pixels would be different sizes in millimeters on each output.
So what? Yes dpi needs to be per-output
Hi,
the new retrace server HW is finally set up and running. Since it has
the same name as the old one (retrace.fedoraproject.org) no special
configuration is needed, it *should* just work.
pros:
- support for F16 (so we can use it on liveCD (need to fix: 742609))
- support for rawhide (testers
Hi,
On Mon, Oct 3, 2011 at 5:22 PM, Ralf Corsepius rc040...@freenet.de wrote:
The XP I occasionally can not avoid to use, in its system control menus
has controls to switch between normal, big very big fonts and
expert/advanced controls one can specify fonts sizes for many details
of the DE
On 3 October 2011 08:57, Richard Hughes hughsi...@gmail.com wrote:
That's what it was supposed to be, but due to an oversight on my part
the wrong keys were being set. I've fixed this upstream in
https://bugzilla.gnome.org/show_bug.cgi?id=660395 -- which will of
course be included in 3.2.1
On Tue, Oct 4, 2011 at 3:09 AM, Farkas Levente lfar...@lfarkas.org wrote:
On 10/04/2011 01:03 AM, Eric Sandeen wrote:
On 10/3/11 5:53 PM, Farkas Levente wrote:
On 10/04/2011 12:33 AM, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
On Mon, Oct 03, 2011 at 04:11:28PM -0500,
On 10/04/2011 03:12 AM, Farkas Levente wrote:
On 10/04/2011 01:03 AM, Eric Sandeen wrote:
Large filesystem support for ext4 has languished upstream for a very
long time, and few in the community seemed terribly interested to test it,
either.
why? that's what i simple do not understand!?...
, that's the
reason...
Fehler: Package: perl-SOAP-WSDL-2.00.10-10.fc15.rh.20111004.noarch
(/perl-SOAP-WSDL-2.00.10-10.fc15.rh.20111004.noarch)
Requires: perl(SOAP::WSDL::Header)
--
# Petr Sabata
pgppt0PpLPYHJ.pgp
Description: PGP signature
--
devel mailing list
devel
On Tue, Oct 4, 2011 at 04:01, Camilo Mesias cam...@mesias.co.uk wrote:
On Mon, Oct 3, 2011 at 5:22 PM, Ralf Corsepius rc040...@freenet.de wrote:
The XP I occasionally can not avoid to use, in its system control menus
has controls to switch between normal, big very big fonts and
expert/advanced
Hi,
I'm looking for some info on systemd and how filesystems are mounted in
Fedora. I've started looking into converting the gfs2-utils package to
the new init system and run into things which are not documented (so far
as I can tell).
Currently there are two init scripts in gfs2-utils, one is
::Std::Fast, which is not available in Fedora.
i know and building 4 packages for epp-interfaces:
2011-10-04 15:14 perl-Class-Std-Fast-0.0.8-10.fc15.rh.20111004.src.rpm
2011-10-04 15:14 perl-IO-Socket-INET6-2.67-2.fc15.rh.20111004.src.rpm
2011-10-04 15:14 perl-Net-DRI-0.96-2.fc15.rh.20111004
On 10/04/2011 02:39 PM, Steven Whitehouse wrote:
Hi,
I'm looking for some info on systemd and how filesystems are mounted in
Fedora. I've started looking into converting the gfs2-utils package to
the new init system and run into things which are not documented (so far
as I can tell).
Hi,
On Tue, 2011-10-04 at 14:54 +0100, Paul Howarth wrote:
On 10/04/2011 02:39 PM, Steven Whitehouse wrote:
Hi,
I'm looking for some info on systemd and how filesystems are mounted in
Fedora. I've started looking into converting the gfs2-utils package to
the new init system and run
On 04/10/11 14:54, Paul Howarth wrote:
I ran into a similar problem last month. I foolishly set up a bind mount
for a local filesystem, with the new mountpoint living on top of an NFS
filesystem, and set it up in fstab to mount on boot in an F-16 VM. When
I next rebooted, the attempted bind
The wiki at
http://fedoraproject.org/wiki/Features/Grub2
has instructions for upgrading from grub to grub2.
Do these instructions still apply, or will 'yum install grub2' do the work
in the post install script?
darrell
--
devel mailing list
devel@lists.fedoraproject.org
On Tue, Oct 4, 2011 at 3:41 PM, Reindl Harald h.rei...@thelounge.net wrote:
thank you for your feedback!
Am 04.10.2011 15:33, schrieb Petr Sabata:
On Tue, Oct 04, 2011 at 02:39:42PM +0200, Reindl Harald wrote:
hi
has anybody an idea why this package can no longer be used on F15
from F11
Hello,
I learned that for new Fedora releases the initrd file, used by
preupgrade, will contain *both* the initrd for the kernel as well as the
install image. (previously also called stage2?)
I think that this takes away upgrade flexibility.
I did not find an explanation that proves my
On Tue, 4 Oct 2011 16:08:58 +0200, IA (Iain) wrote:
a workaround with Provides does it's jon and all autotests are running
fine - (transferdomain, createdomain, updatedomain, createperson.)
Provides: perl(SOAP::WSDL::Header)
Please don't provide things that you're not really
On Tue, Oct 04, 2011 at 09:13:46AM +0200, Ralf Corsepius wrote:
On 10/04/2011 08:04 AM, Eric Smith wrote:
I wrote:
What should I use for the release number in a spec when upstream does
not have releases, and *only* has git hashes? It's not a prerelease
since it is not clear that there
Mark your calendars, and get ready to go exploring: The release of
Fedora 16, codenamed Verne, is scheduled for release in early
November. Fedora is the leading edge, free and open source operating
system that continues to bring everyone fresh, innovative features
with each release, delighting
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There's been a lot of requests lately for the new version of qtpfsgui called
Luminance HDR and I haven't had time to get the package updated,
re-reviewed, and deprecate the old one.
Would anyone be interested in helping/taking over this package?
-
commit 4d28970990224ee1253acba643eccb44a9c187ba
Author: Paul Howarth p...@city-fan.org
Date: Tue Oct 4 16:16:47 2011 +0100
BR/R: perl(Unicode::CheckUTF8) for improved performance
perl-Test-Mojibake.spec | 15 +++
1 files changed, 11 insertions(+), 4 deletions(-)
---
diff
On 10/4/11 2:09 AM, Farkas Levente wrote:
On 10/04/2011 01:03 AM, Eric Sandeen wrote:
On 10/3/11 5:53 PM, Farkas Levente wrote:
On 10/04/2011 12:33 AM, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
I wasn't
On 10/04/2011 09:36 AM, Jason D. Clinton wrote:
On Tue, Oct 4, 2011 at 04:01, Camilo Mesiascam...@mesias.co.uk wrote:
On Mon, Oct 3, 2011 at 5:22 PM, Ralf Corsepiusrc040...@freenet.de wrote:
The XP I occasionally can not avoid to use, in its system control menus
has controls to switch
On 4.10.2011 16:38, Toshio Kuratomi wrote:
The date should not go there
as you cannot tell if upstream will someday switch to an actual version
string (which will then need an Epoch to upgrade cleanly from the date).
That's your opinion or actually some rule? Well, it depends on the
upstream
On Sat, 2011-10-01 at 10:29 +0200, Hans de Goede wrote:
Hi All,
Please note that I'm not claiming that the critpath process is broken
in general. But it does not work for certain components. To be specific
it does not work for Xorg drivers for non common hardware.
This morning bodhi send
On Mon, 2011-10-03 at 17:27 +0100, Matthew Garrett wrote:
On Mon, Oct 03, 2011 at 04:48:11PM +0100, Camilo Mesias wrote:
Hi,
A daft question perhaps, but I thought...
I'm not sure how we can make DPI magically be correct in gazillions of
broken displays' EDID.
How do other
On Fri, 2011-09-23 at 16:31 -0400, Doug Ledford wrote:
- Original Message -
The setup inside Red Hat cannot be (directly) copied outside at this
time. Instead the autoQA project was started to re-create it as an
open source project. That's where effort should continue.
Am I
On Mon, 2011-10-03 at 12:56 -0400, Adam Jackson wrote:
More to the point, your DPI numbers would be per-output anyway, so
there's no picking a single point size preference, the same size in
pixels would be different sizes in millimeters on each output.
In fairness, for my dual head setup I
On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote:
Grovelling around in the F15 xorg-server sources and reviewing the Xorg
log file on my F15 box, I see, with _modern hardware_ at least, that we
do have the monitor geometry available from DDC or EDIC, and obviously
it is trivial
Thanks for writing this up! It was good info.
On Oct 4, 2011 7:55 PM, Adam Jackson a...@redhat.com wrote:
On Tue, 2011-10-04 at 11:46 -0400, Kaleb S. KEITHLEY wrote:
Grovelling around in the F15 xorg-server sources and reviewing the Xorg
log file on my F15 box, I see, with _modern hardware_
On Tue, Oct 04, 2011 at 05:58:33PM +0200, Matej Cepl wrote:
On 4.10.2011 16:38, Toshio Kuratomi wrote:
The date should not go there
as you cannot tell if upstream will someday switch to an actual version
string (which will then need an Epoch to upgrade cleanly from the date).
That's your
On 10/04/2011 01:24 PM, Adam Jackson wrote:
I am clearly going to have to explain this one more time, forever.
Let's see if I can't write it authoritatively once and simply answer
with a URL from here out. (As always, use of the second person you
herein is plural, not singular.)
We are going to be having another proventesters meetup tomorrow on IRC
in #fedora-meeting at 18:00UTC.
Purpose of meetup: Brainstorm ideas on improving testing and processes
for testing updates.
* Intro/gather more agenda items
* Recruiting more proventesters/testers.
* One stop page for
Ordinary users don't care about DPI any more than they do about what number
point or pixel size their favorite font size is.
Why can't something akin to
http://people.gnome.org/~federico/news-2007-01.html be employed so that no
one gets initialized or stuck with unsuitable sizes?
Snap the
Hi,
On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson a...@redhat.com wrote:
I am clearly going to have to explain this one more time, forever.
Let's see if I can't write it authoritatively once and simply answer
with a URL from here out. (As always, use of the second person you
herein is plural,
On Tue, Oct 4, 2011 at 4:03 PM, Camilo Mesias cam...@mesias.co.uk wrote:
Thanks for the explanation... There is an alternative to endless
explanation - roll out your best effort at a heuristic and let the
crowd contribute to an ever growing set of exceptions.
Well, actually, people complain a
On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote:
For fedora users, as others have mentioned, perhaps a UI that lets
users test a couple of possible dpi values might be useful (for those
users so inclined). It does have to cross a good chunk of the stack to
work well, and seems
Hi,
I performed a simple home test, a comparison of startup and shutdown times of:
- Live-CD Fedora 16 beta - systemd parallel boot, GNOME 3
- Live-CD Knoppix 6.7.1 - microknoppix-fast-parallel-boot (based on SysV/LSB
scripts), LXDE;
note that
On Tue, 2011-10-04 at 21:03 +0100, Camilo Mesias wrote:
Hi,
On Tue, Oct 4, 2011 at 6:54 PM, Adam Jackson a...@redhat.com wrote:
I am clearly going to have to explain this one more time, forever.
Let's see if I can't write it authoritatively once and simply answer
with a URL from here
On 10/04/2011 05:30 PM, Eric Sandeen wrote:
XFS has been proven at this scale on Linux for a very long time, is all.
the why rh do NOT support it in 32 bit? there're still system that
should have to run on 32 bit:-(
32-bit machines have a 32-bit index into the page cache; on x86, that
On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
Results interpretation.
---
Knoppix won by a wide margin, while:
- Knoppix having microknoppix fast-parallel boot (based on SysV/LSB scripts)
and DE with low resources usage and tailored for desktops
- Fedora
On Tue, 2011-10-04 at 23:45 +0200, Lennart Poettering wrote:
Another bigger source of slowness at boot is currently Plymouth which
also requires synchronous settling of devices (tough it's not as bad as
LVM in that regard though, but costs too since EDID probing is
apparently quite slow, and
On Tue, Oct 4, 2011 at 11:45 PM, Lennart Poettering
mzerq...@0pointer.de wrote:
On Tue, 04.10.11 21:01, JB (jb.1234a...@gmail.com) wrote:
Results interpretation.
---
Knoppix won by a wide margin, while:
- Knoppix having microknoppix fast-parallel boot (based on SysV/LSB
On Tue, 04.10.11 14:39, Steven Whitehouse (swhit...@redhat.com) wrote:
Hi,
Heya,
I'm looking for some info on systemd and how filesystems are mounted in
Fedora. I've started looking into converting the gfs2-utils package to
the new init system and run into things which are not documented
On Tue, Oct 04, 2011 at 11:59:09PM +0200, drago01 wrote:
And *sendmail* (in my vms it takes up to 60s to start even though I
never use it; and I it does not really make much sense on desktops).
https://fedoraproject.org/wiki/Features/NoMTA
Yeah ... I was technically the owner on that one,
On 10/04/2011 11:01 PM, JB wrote:
I performed a simple home test, a comparison of startup and shutdown times of:
- Live-CD Fedora 16 beta - systemd parallel boot, GNOME 3
- Live-CD Knoppix 6.7.1 - microknoppix-fast-parallel-boot (based on SysV/LSB
scripts), LXDE;
On Tue, 04.10.11 17:54, Adam Jackson (a...@redhat.com) wrote:
On Tue, 2011-10-04 at 23:45 +0200, Lennart Poettering wrote:
Another bigger source of slowness at boot is currently Plymouth which
also requires synchronous settling of devices (tough it's not as bad as
LVM in that regard
On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote:
On 04/10/11 14:54, Paul Howarth wrote:
I ran into a similar problem last month. I foolishly set up a bind mount
for a local filesystem, with the new mountpoint living on top of an NFS
filesystem, and set it up in fstab to
On Wed, 05.10.11 00:18, Lennart Poettering (mzerq...@0pointer.de) wrote:
On Tue, 04.10.11 15:02, Tom Hughes (t...@compton.nu) wrote:
On 04/10/11 14:54, Paul Howarth wrote:
I ran into a similar problem last month. I foolishly set up a bind mount
for a local filesystem, with the
On 10/03/2011 06:33 PM, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
testing something more real-world (20T ... 500T?) might still be
interesting.
Here's my test script:
qemu-img create -f qcow2
JB jb.1234abcd at gmail.com writes:
...
Notebook 1:
---
Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.
F16 beta
average t1=3m8s
average t2=10s
...
Let me append The Blame Game.
# less -i
On 10/04/2011 07:19 PM, Przemek Klosowski wrote:
On 10/03/2011 06:33 PM, Eric Sandeen wrote:
On 10/3/11 5:13 PM, Richard W.M. Jones wrote:
On Mon, Oct 03, 2011 at 04:11:28PM -0500, Eric Sandeen wrote:
testing something more real-world (20T ... 500T?) might still be
interesting.
Here's my
On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote:
Let me append The Blame Game.
# systemd-analyze blame
32983ms livesys.service
22828ms NetworkManager.service
That timing for NM is so vastly different than what I'm seeing on my
installed F15 system. I am intrigued.
-jef
--
On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote:
13837ms udev-settle.service
11392ms plymouth-start.service
if you use the plot option instead of blame option and produce the svg
of the service timing you get a better feel for what Lennart was
talking about with regard to the
Jef Spaleta jspaleta at gmail.com writes:
On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234abcd at gmail.com wrote:
Let me append The Blame Game.
# systemd-analyze blame
32983ms livesys.service
22828ms NetworkManager.service
That timing for NM is so vastly different than what I'm seeing
On Tue, 2011-10-04 at 13:54 -0400, Adam Jackson wrote:
I'm going to limit myself to observing that greatly is a matter of
opinion, and that in order to be really useful you'd need some way of
communicating I punted to the desktop.
Beyond that, sure, pick a heuristic, accept that it's going
On Tue, 2011-10-04 at 19:05 -0700, Adam Williamson wrote:
Is it
really a great idea, for instance, if we put Fedora 17 on a 1024x600, 7
tablet and it comes up with zonking huge fonts all over the place?
Er - s/zonking huge/ridiculously tiny/, of course.
--
Adam Williamson
Fedora QA Community
On Tue, 2011-10-04 at 16:24 -0400, Casey Dahlin wrote:
On Tue, Oct 04, 2011 at 04:17:08PM -0400, Martin Langhoff wrote:
For fedora users, as others have mentioned, perhaps a UI that lets
users test a couple of possible dpi values might be useful (for those
users so inclined). It does have
On Tue, 2011-10-04 at 15:53 -0800, Jef Spaleta wrote:
On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote:
Let me append The Blame Game.
# systemd-analyze blame
32983ms livesys.service
22828ms NetworkManager.service
That timing for NM is so vastly different than what I'm
On Tue, 2011-10-04 at 16:55 -0800, Jef Spaleta wrote:
On Tue, Oct 4, 2011 at 3:32 PM, JB jb.1234a...@gmail.com wrote:
13837ms udev-settle.service
11392ms plymouth-start.service
if you use the plot option instead of blame option and produce the svg
of the service timing you get a
On Tue, 2011-10-04 at 23:32 +, JB wrote:
JB jb.1234abcd at gmail.com writes:
...
Notebook 1:
---
Lenovo TP R61i, Intel Pentium Core 2 Duo 1.86 GHZ, Intel Mobile 965GM,
2 GB RAM, HD, CD-RW, sound, internal ethernet and wireless.
F16 beta
average t1=3m8s
average
On 2011-10-04 12:01, Toshio Kuratomi wrote:
So my solyution:
foo-0-1.20110120git.fc16 vs
Your solution:
foo-20110120-1.20110120git.fc16
(Since it's a snapshot, the date has to go into the release string anyway)
Which is uglier?
Also, since these are snapshots, a date in the upstream
On 10/04/2011 09:01 PM, Toshio Kuratomi wrote:
On Tue, Oct 04, 2011 at 05:58:33PM +0200, Matej Cepl wrote:
On 4.10.2011 16:38, Toshio Kuratomi wrote:
The date should not go there
as you cannot tell if upstream will someday switch to an actual version
string (which will then need an Epoch to
On Mon, 2011-09-26 at 21:49 +0200, Kevin Kofler wrote:
Doug Ledford wrote:
- Original Message -
Or Doug could take over grub if he is willing to fix the issues he
runs into. Or he could fork grub into maggot, use that for his needs.
If he is willing to support it and you are
On Tue, 2011-10-04 at 07:03 -0700, darrell pfeifer wrote:
The wiki at
http://fedoraproject.org/wiki/Features/Grub2
has instructions for upgrading from grub to grub2.
Do these instructions still apply,
Yes.
or will 'yum install grub2' do the work in the post install script?
On Thu, 2011-09-29 at 09:39 -0400, Jesse Keating wrote:
On Sep 29, 2011, at 6:22 AM, Nils Philippsen wrote:
Ahh I'm late. Anyway, that's a side-effect of using the bodhi interface
to manage something in koji then. It'd still be handy if we could use
that for Rawhide so we don't break all
On Sat, 2011-09-17 at 13:20 +0200, Kevin Kofler wrote:
(That said, there definitely needs to be a way to disable it, and maybe it
should even be disabled by default. I personally always uninstall yum-
presto. For me, it's much faster to just download packages than to rebuild
them from
perl-Pugs-Compiler-Rule has broken dependencies in the F-16 tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon as
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=728524
Petr Sabata psab...@redhat.com changed:
What|Removed |Added
perl-Pugs-Compiler-Rule has broken dependencies in the rawhide tree:
On x86_64:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
On i386:
perl-Pugs-Compiler-Rule-0.37-9.fc16.noarch requires
perl(:MODULE_COMPAT_5.12.3)
Please resolve this as soon
perl-Bio-Graphics has broken dependencies in the rawhide tree:
On x86_64:
perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig)
On i386:
perl-Bio-Graphics-2.25-1.fc17.noarch requires perl(Bio::DB::BigWig)
Please resolve this as soon as possible.
--
Fedora Extras
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=719874
Karsten Hopp kars...@redhat.com changed:
What|Removed |Added
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=719874
Karsten Hopp kars...@redhat.com changed:
What|Removed |Added
Summary of changes:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance (*)
(*) 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
Summary of changes:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance (*)
(*) 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
Summary of changes:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance (*)
(*) 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
Summary of changes:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance (*)
(*) 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
Summary of changes:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance (*)
(*) 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
The lightweight tag 'perl-Test-Mojibake-0.3-3.el4' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.el5' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.el6' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.fc14' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.fc15' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.fc16' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
The lightweight tag 'perl-Test-Mojibake-0.3-3.fc17' was created pointing to:
4d28970... BR/R: perl(Unicode::CheckUTF8) for improved performance
--
Fedora Extras Perl SIG
http://www.fedoraproject.org/wiki/Extras/SIGs/Perl
perl-devel mailing list
perl-devel@lists.fedoraproject.org
93 matches
Mail list logo
