Re: Yubikey single-factor authentication disabled
2013/3/7 Clive Hills discordia...@gmail.com I suppose I have to bite and ask why yubikey is regarded as single-factor? I guess it isn't something I know as well as something I have? Spot's poll is interesting - I see SecureID hard tokens leading the hard tokens featured (7am UTC Thursday) but how does an individual buy one? Clive I'm using the two factor authentication at Google with the Google Authentication app[1] and it's very handy. I think It can be used in your own projects [1] https://play.google.com/store/apps/details?id=com.google.android.apps.authenticator2 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File utf8-all-0.010.tar.gz uploaded to lookaside cache by ppisar
A file has been added to the lookaside cache for perl-utf8-all: 159ac1b5f6b4a8daae35fcf4fed2f794 utf8-all-0.010.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-utf8-all] Import
commit 0e21b1f7ef329458d0e8ca8aa30ba6e17e481455
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 7 09:10:50 2013 +0100
Import
.gitignore |1 +
perl-utf8-all.spec | 69
sources|1 +
3 files changed, 71 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..0189d4d 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/utf8-all-0.010.tar.gz
diff --git a/perl-utf8-all.spec b/perl-utf8-all.spec
new file mode 100644
index 000..952f2ac
--- /dev/null
+++ b/perl-utf8-all.spec
@@ -0,0 +1,69 @@
+Name: perl-utf8-all
+Version:0.010
+Release:1%{?dist}
+Summary:Turn on Unicode everywhere
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/utf8-all/
+Source0:
http://www.cpan.org/authors/id/D/DO/DOHERTY/utf8-all-%{version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl
+BuildRequires: perl(strict)
+BuildRequires: perl(warnings)
+BuildRequires: perl(Module::Build) = 0.3601
+# Run-time:
+BuildRequires: perl(charnames)
+BuildRequires: perl(Dist::CheckConflicts) = 0.02
+BuildRequires: perl(Encode)
+BuildRequires: perl(feature)
+BuildRequires: perl(Import::Into)
+BuildRequires: perl(open)
+BuildRequires: perl(parent)
+BuildRequires: perl(utf8)
+# Tests:
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(locale)
+BuildRequires: perl(PerlIO)
+BuildRequires: perl(Test::Fatal)
+BuildRequires: perl(Test::More) = 0.96
+BuildRequires: perl(Test::Warn)
+BuildRequires: perl(version) = 0.77
+# Optional tests:
+BuildRequires: perl(autodie) = 2.12
+BuildRequires: perl(Test::Script) = 1.05
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+Requires: perl(Dist::CheckConflicts) = 0.02
+Conflicts: perl(autodie) = 2.11
+
+%description
+Pragma utf8 allows you to write your Perl encoded in UTF-8. That means UTF-8
+strings, variable names, and regular expressions. utf8::all goes further, and
+makes @ARGV encoded in UTF-8, and file handles are opened with UTF-8 encoding
+turned on by default (including STDIN, STDOUT, STDERR), and character names
+are imported so \N{...} sequences can be used to compile Unicode characters
+based on names. If you don't want UTF-8 for a particular file handle, you'll
+have to set binmode $filehandle.
+
+%prep
+%setup -q -n utf8-all-%{version}
+
+%build
+perl Build.PL installdirs=vendor
+./Build
+
+%install
+./Build install destdir=$RPM_BUILD_ROOT create_packlist=0
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+./Build test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Feb 14 2013 Petr Pisar ppi...@redhat.com 0.010-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..29769d1 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+159ac1b5f6b4a8daae35fcf4fed2f794 utf8-all-0.010.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: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote: On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote: [...] ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) [...] It looks like you will have to use the setprocattrcon[.constprop] function name in your suppression file. I am not exactly sure how the linker ends up pointing directly to that one for setsockcreatecon (), but it apparently is. And so valgrind will only know it by that name. Symbol table '.symtab' contains 770 entries: Num:Value Size TypeBind Vis Ndx Name 70: 999062 FUNCLOCAL DEFAULT 11 setprocattrcon.constprop.2 Contents of the .debug_info section: 162c6: Abbrev Number: 58 (DW_TAG_subprogram) 62c7 DW_AT_name: (indirect string, offset: 0x3eb4): setprocattrcon 62d2 DW_AT_inline : 1 (inlined) 16791: Abbrev Number: 40 (DW_TAG_subprogram) 6792 DW_AT_abstract_origin: 0x62c6 6794 DW_AT_low_pc : 0x9990 679c DW_AT_high_pc : 62 Valgrind apparently used the ELF symbol name. But in DWARF there is the real function name (and it is even marked as 'inlined' - although it is a standalone function). GDB also knows the real name from DWARF: (gdb) disas 'setprocattrcon.constprop.2' Dump of assembler code for function setprocattrcon: 0x9990 +0: push %rbx [...] 0x99cd +61:retq End of assembler dump. So it is possible to fix it in Valgrind. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, 2013-03-07 at 09:42 +0100, Jan Kratochvil wrote: On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote: On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote: [...] ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) [...] It looks like you will have to use the setprocattrcon[.constprop] function name in your suppression file. I am not exactly sure how the linker ends up pointing directly to that one for setsockcreatecon (), but it apparently is. And so valgrind will only know it by that name. Symbol table '.symtab' contains 770 entries: Num:Value Size TypeBind Vis Ndx Name 70: 999062 FUNCLOCAL DEFAULT 11 setprocattrcon.constprop.2 Contents of the .debug_info section: 162c6: Abbrev Number: 58 (DW_TAG_subprogram) 62c7 DW_AT_name: (indirect string, offset: 0x3eb4): setprocattrcon 62d2 DW_AT_inline : 1 (inlined) 16791: Abbrev Number: 40 (DW_TAG_subprogram) 6792 DW_AT_abstract_origin: 0x62c6 6794 DW_AT_low_pc : 0x9990 679c DW_AT_high_pc : 62 Valgrind apparently used the ELF symbol name. But in DWARF there is the real function name (and it is even marked as 'inlined' - although it is a standalone function). GDB also knows the real name from DWARF: (gdb) disas 'setprocattrcon.constprop.2' Dump of assembler code for function setprocattrcon: 0x9990 +0: push %rbx [...] 0x99cd +61: retq End of assembler dump. So it is possible to fix it in Valgrind. Aha, thanks. Yes using DWARF might help getting more user friendly/recognizable names. Though note that the name we were really looking for was setsockcreatecon, since that is what was called from main. I think that one is doing a tail-call to setprocattrcon.constprop.2 so might not easily be available in the backtrace. If you compile and run Richard's reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and break at the strdup call, can you get a backtrace from gdb with setsockcreatecon in it? Also using DWARF .debug_info will only work if it is available. By default valgrind doesn't require DWARF, it uses only the symbol table. I can look in extending valgrind to use the DWARF info when available for matching suppressions, but that might mean a suppression only works when the debuginfo is installed (and it might make valgrind even slower). Cheers, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
- Original Message - On Wed, Mar 6, 2013 at 7:15 PM, Adam Williamson awill...@redhat.com wrote: On 06/03/13 04:39 AM, Dan Mashal wrote: Took libindicator too. Is this deprecated upstream? No, there are commits right up to late Feb in launchpad. But then I don't immediately see that you'd want it for MATE purposes (or really any other Fedora purposes); it's a Unity thing. I packaged and used to own it for my aborted plan to try and package Unity, and it's orphaned because I don't want it any more. I don't think it has any dependencies in Fedora, and I think it's pretty useless if you're not running Unity. bamf is in a similar position, but at least _something_ - gnome-pie, whatever that is - requires it. So it might actually be more useful for someone to pick that up. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel I don't know what gnome-pie / bamf are and what they do. Gnome maintainers, you may want to take those? Well, I'm the maintainer of bamf-qt, same reason as Adam's - my try to package Unity-2d before they decided to get rid of QML based one and now, finally, decided to go back to the QML path ;-). So we will see if we could continue with the effort with Unity-next. And we can always revive it later in case we will need it. R. Dan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File version-0.9902.tar.gz uploaded to lookaside cache by jplesnik
A file has been added to the lookaside cache for perl-version: edb0ac88be8bed3e370ce12e74261998 version-0.9902.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: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, Mar 07, 2013 at 10:10:56AM +0100, Mark Wielaard wrote:
On Thu, 2013-03-07 at 09:42 +0100, Jan Kratochvil wrote:
On Wed, 06 Mar 2013 16:13:47 +0100, Mark Wielaard wrote:
On Wed, 2013-03-06 at 14:38 +, Richard W.M. Jones wrote:
[...]
==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6
==11843==at 0x4A06409: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==11843==by 0x38EAC861F9: strdup (strdup.c:42)
==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3
(procattr.c:241)
==11843==by 0x38EC8099B7: setprocattrcon.constprop.2
(procattr.c:274)
==11843==by 0x400955: main (in /tmp/test)
[...]
It looks like you will have to use the setprocattrcon[.constprop]
function name in your suppression file. I am not exactly sure how the
linker ends up pointing directly to that one for setsockcreatecon (),
but it apparently is. And so valgrind will only know it by that name.
Symbol table '.symtab' contains 770 entries:
Num:Value Size TypeBind Vis Ndx Name
70: 999062 FUNCLOCAL DEFAULT 11
setprocattrcon.constprop.2
Contents of the .debug_info section:
162c6: Abbrev Number: 58 (DW_TAG_subprogram)
62c7 DW_AT_name: (indirect string, offset: 0x3eb4):
setprocattrcon
62d2 DW_AT_inline : 1 (inlined)
16791: Abbrev Number: 40 (DW_TAG_subprogram)
6792 DW_AT_abstract_origin: 0x62c6
6794 DW_AT_low_pc : 0x9990
679c DW_AT_high_pc : 62
Valgrind apparently used the ELF symbol name. But in DWARF there is the
real
function name (and it is even marked as 'inlined' - although it is a
standalone
function).
GDB also knows the real name from DWARF:
(gdb) disas 'setprocattrcon.constprop.2'
Dump of assembler code for function setprocattrcon:
0x9990 +0: push %rbx
[...]
0x99cd +61:retq
End of assembler dump.
So it is possible to fix it in Valgrind.
Aha, thanks. Yes using DWARF might help getting more user
friendly/recognizable names.
Though note that the name we were really looking for was
setsockcreatecon, since that is what was called from main. I think that
one is doing a tail-call to setprocattrcon.constprop.2 so might not
easily be available in the backtrace. If you compile and run Richard's
reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and
break at the strdup call, can you get a backtrace from gdb with
setsockcreatecon in it?
The answer seems to be no. This is on a very up to date Rawhide:
Breakpoint 2, __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
40 {
(gdb) bt
#0 __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
#1 0x0038ec8097ca in setprocattrcon_raw (
context=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023,
attr=attr@entry=0x38ec8181f6 sockcreate, pid=0) at procattr.c:241
#2 0x0038ec8099b8 in setprocattrcon (context=optimized out,
attr=0x38ec8181f6 sockcreate, pid=0) at procattr.c:274
#3 0x00400956 in main () at test.c:33
Also using DWARF .debug_info will only work if it is available. By
default valgrind doesn't require DWARF, it uses only the symbol table. I
can look in extending valgrind to use the DWARF info when available for
matching suppressions, but that might mean a suppression only works when
the debuginfo is installed (and it might make valgrind even slower).
Actually we found that our suppressions only work properly when we're
careful to install debuginfo packages. Otherwise some of the patterns
don't match and we get false positives.
Here's our suppressions file FWIW:
https://github.com/libguestfs/libguestfs/blob/master/valgrind-suppressions
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, Mar 07, 2013 at 10:55:58AM +, Richard W.M. Jones wrote:
The answer seems to be no. This is on a very up to date Rawhide:
Breakpoint 2, __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
40 {
(gdb) bt
#0 __GI___strdup (
s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023)
at strdup.c:40
#1 0x0038ec8097ca in setprocattrcon_raw (
context=0x6021e0
unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023,
attr=attr@entry=0x38ec8181f6 sockcreate, pid=0) at procattr.c:241
#2 0x0038ec8099b8 in setprocattrcon (context=optimized out,
attr=0x38ec8181f6 sockcreate, pid=0) at procattr.c:274
#3 0x00400956 in main () at test.c:33
Note: libselinux-debuginfo-2.1.13-6.fc19.x86_64 is installed.
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
rubygem-fast_gettext license change
Hi all, I have updated rubygem-fast_gettext to 0.7.0 version in rawhide and it changed license from Public Domain to MIT. Please note that there are also some bit licensed under the same terms as Ruby. Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names
On Wed, Mar 6, 2013 at 5:28 PM, narendr...@dell.com wrote: -Original Message- From: devel-boun...@lists.fedoraproject.org [mailto:devel- boun...@lists.fedoraproject.org] On Behalf Of Michal Schmidt Sent: Tuesday, March 05, 2013 10:22 PM To: devel@lists.fedoraproject.org Subject: Re: Proposed F19 Feature: systemd/udev Predictable Network Interface Names On 03/04/2013 04:01 PM, Matt Domsch wrote: drivers/net/ethernet/sfc/siena.c: efx-net_dev-dev_id = EFX_OWORD_FIELD(reg, FRF_CZ_CS_PORT_NUM) - 1; I think sfc does not really *need* to set dev_id. Yes, these are multi-port cards, but the ports are on distinct PCI functions. I think setting of 'dev_id' by drivers/devices used in enterprise server environment will be beneficial, not just for devices in which multiple ports share a single PCI d/b/d/f(1 PCI d/b/d/f - 2 ports), also for multiport devices with 1 PCI d/b/d/f - 1 Port mapping. The following scenarios demonstrate the requirement/usefulness - 1. As the dev_id would indicate the physical port number used by a netdevice and will be available to user space via sysfs, tools such as NetworkManager could use the information to implement intelligent/smarter bonding of netdevices. For example, when bonding netdevices coming from NIC partitions (or SR-IOV VFs) which use the same physical port, in fault tolerance mode for example, NM could inform the user that the netdevices being enslaved map to/use the same physical port and bonding them may not have desired effect. Dev_id would provide such information in a generic way. 2. biosdevname could possibly use 'dev_id' to determine the port part of pslotpport eliminating the need to determine/enumerate port number as pointed out here. Using dev_id in the kernel for static and predictable per-device properties is fine, sure. Using dev_id with per-driver-global internal counters, or anything else that depends on any sort of probing or loading order is not; the range of dev_id must be local to every instance than can be separated and which the driver handles. Otherwise, I would not be surprised if the creativity of people would introduce new artificial and unpredictable enumerations in the kernel with that facility. :) Kay -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
rubygem-pg licesne change
Hi all, I have updated rubygem-pg to 0.14.0 version in rawhide and it is now shipped under the same terms as Ruby, i.e. BSD or Ruby licenses and some bits are distributed under PostgreSQL license Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote: ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' [...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote: Though note that the name we were really looking for was setsockcreatecon, since that is what was called from main. I think that one is doing a tail-call to setprocattrcon.constprop.2 so might not easily be available in the backtrace. If you compile and run Richard's reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and break at the strdup call, can you get a backtrace from gdb with setsockcreatecon in it? Yes: (gdb) bt #0 __GI___strdup (s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40 #1 0x77bc27ca in setprocattrcon_raw (context=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241 #2 0x77bc29b8 in setprocattrcon (context=optimized out, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274 #3 0x77bc2ddc in setsockcreatecon (c=optimized out) at procattr.c:320 #4 0x00400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffe130: rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7781ab75 tail call frame, caller of frame at 0x7fffe130 ^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffe130 But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2 237e: Abbrev Number: 21 (DW_TAG_GNU_call_site) 37f DW_AT_low_pc : 0x400818 387 DW_AT_abstract_origin: 0x515 1515: Abbrev Number: 24 (DW_TAG_subprogram) 516 DW_AT_name: (indirect string, offset: 0x11): setsockcreatecon 520 DW_AT_declaration : 1 Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Wed, Mar 6, 2013 at 10:03 PM, Adam Williamson awill...@redhat.comwrote: So just a couple of notes on the proposal: It's phrased in very technical terms here - probably a wise choice - but I think it's worth noting one of the angles we took in discussing it in person at FUDCon is that it has the potential to contribute to the more general idea of making Fedora more flexible in terms of what we can build and release. It has the effect of giving us a defined 'core' of functionality on top of which we could build various things. It would only be one piece of a larger puzzle here - things like better image building tools and Formulas are part of the same puzzle - but it's an element I was quite interested in. Also, I recall the in-person discussions making it clearer that this plan is pretty strongly dependent on automated testing. This has been discussed somewhat in the follow-ups, but to make sure it's very clear, my reading of the proposal is that it would require substantially more sophisticated and reliable tests than we currently have in AutoQA, and we'd need development resources - either RH paid, or volunteer - to build AutoQA up to the point where it could support this plan without causing unnecessary disruption. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel Are there any records of these FUDCon discussions? Creating defined core of functionality seems like it could solve several problems. I would be curious as to what ideas we proposed on that. -- Mark Bidewell http://www.linkedin.com/in/markbidewell -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Mon, Mar 04, 2013 at 01:20:22PM -0500, Bill Nottingham wrote: Package rubygem-acts-as-list (orphan) I've taken this one. Anybody want to co-maintain? Package spicebird (orphan) -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.multiply.com/ What do you care what people think, Mr. Feynman? pgptvdt6mDSe9.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Thu, Mar 07, 2013 at 07:50:59AM -0500, Darryl L. Pierce wrote: On Mon, Mar 04, 2013 at 01:20:22PM -0500, Bill Nottingham wrote: Package rubygem-acts-as-list (orphan) I've taken this one. Anybody want to co-maintain? Package spicebird (orphan) Second thought, I've decided against this. Upstream appears to be dead so this likely can just go away. -- Darryl L. Pierce mcpie...@gmail.com http://mcpierce.multiply.com/ What do you care what people think, Mr. Feynman? pgpB5ToB4Ymvt.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote: On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote: ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' [...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote: Though note that the name we were really looking for was setsockcreatecon, since that is what was called from main. I think that one is doing a tail-call to setprocattrcon.constprop.2 so might not easily be available in the backtrace. If you compile and run Richard's reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and break at the strdup call, can you get a backtrace from gdb with setsockcreatecon in it? Yes: (gdb) bt #0 __GI___strdup (s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40 #1 0x77bc27ca in setprocattrcon_raw (context=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241 #2 0x77bc29b8 in setprocattrcon (context=optimized out, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274 #3 0x77bc2ddc in setsockcreatecon (c=optimized out) at procattr.c:320 #4 0x00400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffe130: rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7781ab75 tail call frame, caller of frame at 0x7fffe130 ^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffe130 But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2 O, very nice! It is kind of funny that gcc generates better/fuller debuginfo with higher optimizations these days. Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if people install debuginfo anyway to get better backtraces and/or symbol resolution it might make sense to teach valgrind about it. Thanks, Mark -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, 07 Mar 2013 14:20:40 +0100, Mark Wielaard wrote: It is kind of funny that gcc generates better/fuller debuginfo with higher optimizations these days. There is even -Og for debugging as the best of -O0 and -O2 but I do not have much practical experience with it yet. Jan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Testing valgrind in rawhide (separate valgrind-debuginfo package)
On Thu, Mar 07, 2013 at 02:20:40PM +0100, Mark Wielaard wrote: On Thu, 2013-03-07 at 13:42 +0100, Jan Kratochvil wrote: On Wed, 06 Mar 2013 15:38:54 +0100, Richard W.M. Jones wrote: ==11843== 56 bytes in 1 blocks are definitely lost in loss record 6 of 6 ==11843==at 0x4A06409: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==11843==by 0x38EAC861F9: strdup (strdup.c:42) ==11843==by 0x38EC8097C9: setprocattrcon_raw.constprop.3 (procattr.c:241) ==11843==by 0x38EC8099B7: setprocattrcon.constprop.2 (procattr.c:274) ==11843==by 0x400955: main (in /tmp/test) The symbol we're actually calling is 'setsockcreatecon'. It's not a macro. There is no public function called 'setprocattrcon' [...] On Thu, 07 Mar 2013 10:10:56 +0100, Mark Wielaard wrote: Though note that the name we were really looking for was setsockcreatecon, since that is what was called from main. I think that one is doing a tail-call to setprocattrcon.constprop.2 so might not easily be available in the backtrace. If you compile and run Richard's reproducer from https://bugzilla.redhat.com/show_bug.cgi?id=918572 and break at the strdup call, can you get a backtrace from gdb with setsockcreatecon in it? Yes: (gdb) bt #0 __GI___strdup (s=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023) at strdup.c:40 #1 0x77bc27ca in setprocattrcon_raw (context=0x6021e0 unconfined_u:unconfined_r:svirt_socket_t:s0-s0:c0.c1023, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:241 #2 0x77bc29b8 in setprocattrcon (context=optimized out, attr=attr@entry=0x77bd11f6 sockcreate, pid=0) at procattr.c:274 #3 0x77bc2ddc in setsockcreatecon (c=optimized out) at procattr.c:320 #4 0x00400818 in main () at constprop.c:33 (gdb) info frame 3 Stack frame at 0x7fffe130: rip = 0x77bc2ddc in setsockcreatecon (procattr.c:320); saved rip 0x7781ab75 tail call frame, caller of frame at 0x7fffe130 ^^^ source language c. Arglist at unknown address. Locals at unknown address, Previous frame's sp is 0x7fffe130 But one has to compile the main program with -O2 -g so that it has the needed call site debug information: gcc -Wall constprop.c -o constprop -lselinux -g -O2 O, very nice! It is kind of funny that gcc generates better/fuller debuginfo with higher optimizations these days. Currently valgrind doesn't handle DW_TAG_GNU_call_site at all. But if people install debuginfo anyway to get better backtraces and/or symbol resolution it might make sense to teach valgrind about it. I can also confirm that with -O2 the correct symbol is shown in the gdb stack trace on Rawhide. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://people.redhat.com/~rjones/virt-top -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mediawiki 1.20.2 has landed
On Wed, 2013-03-06 at 21:08 -0600, Michael Cronenworth wrote: On 03/06/2013 10:41 AM, James Laska wrote: * Fedora 18 * mediawiki-validator - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086055 * mediawiki-semantic - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086060 These packages seemed to work fine on my mediawiki. I have not used this extension before but I enabled it and the Special pages appeared with no visible errors. Thanks for the feedback. Once I finish tests on my end, I'll push packages out to updates-testing. Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
Dne 7.3.2013 14:10, Darryl L. Pierce napsal(a): On Thu, Mar 07, 2013 at 07:50:59AM -0500, Darryl L. Pierce wrote: On Mon, Mar 04, 2013 at 01:20:22PM -0500, Bill Nottingham wrote: Package rubygem-acts-as-list (orphan) I've taken this one. Anybody want to co-maintain? Package spicebird (orphan) Second thought, I've decided against this. Upstream appears to be dead so this likely can just go away. Heh, also I was thinking for 5 minutes if I should pick it up, but my conclusion was the same as your ;) Vít -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: rawhide report: 20130307 changes
On Thu, Mar 07, 2013 at 02:10:08PM +, Fedora Rawhide Report wrote: [kdebase3] kdebase3-pim-ioslaves-3.5.10-21.fc18.x86_64 requires libsasl2.so.2()(64bit) [kdevelop-python] kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0 kdevelop-python-1.4.1-2.fc19.x86_64 requires libpython2.7-kdevelop.so.1.0()(64bit) [libgda] 1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit) [libguestfs] 1:libguestfs-1.21.17-1.fc19.i686 requires libsasl2.so.2 1:libguestfs-1.21.17-1.fc19.i686 requires /usr/lib/sasl2/libsasldb.so.2 1:libguestfs-1.21.17-1.fc19.i686 requires /usr/lib/sasl2/libanonymous.so.2 1:libguestfs-1.21.17-1.fc19.x86_64 requires libsasl2.so.2()(64bit) 1:libguestfs-1.21.17-1.fc19.x86_64 requires /usr/lib64/sasl2/libsasldb.so.2 1:libguestfs-1.21.17-1.fc19.x86_64 requires /usr/lib64/sasl2/libanonymous.so.2 [and more ...] Unintentional soname bump in cyrus-sasl-lib? Looking at the package it seems that the soname has gone from .2 to .3, even though the package version did not change significantly (2.1.26-5 - 2.1.26-6). 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
Re: rawhide report: 20130307 changes
On 7.3.2013 16:00, Richard W.M. Jones wrote: On Thu, Mar 07, 2013 at 02:10:08PM +, Fedora Rawhide Report wrote: [kdebase3] kdebase3-pim-ioslaves-3.5.10-21.fc18.x86_64 requires libsasl2.so.2()(64bit) [kdevelop-python] kdevelop-python-1.4.1-2.fc19.i686 requires libpython2.7-kdevelop.so.1.0 kdevelop-python-1.4.1-2.fc19.x86_64 requires libpython2.7-kdevelop.so.1.0()(64bit) [libgda] 1:libgda-tools-5.1.1-4.fc19.x86_64 requires libgraph.so.5()(64bit) [libguestfs] 1:libguestfs-1.21.17-1.fc19.i686 requires libsasl2.so.2 1:libguestfs-1.21.17-1.fc19.i686 requires /usr/lib/sasl2/libsasldb.so.2 1:libguestfs-1.21.17-1.fc19.i686 requires /usr/lib/sasl2/libanonymous.so.2 1:libguestfs-1.21.17-1.fc19.x86_64 requires libsasl2.so.2()(64bit) 1:libguestfs-1.21.17-1.fc19.x86_64 requires /usr/lib64/sasl2/libsasldb.so.2 1:libguestfs-1.21.17-1.fc19.x86_64 requires /usr/lib64/sasl2/libanonymous.so.2 [and more ...] Unintentional soname bump in cyrus-sasl-lib? Looking at the package it seems that the soname has gone from .2 to .3, even though the package version did not change significantly (2.1.26-5 - 2.1.26-6). No, it's intentional, see [1]. There were a transition period when cyrus-sasl-lib carried both libsasl2.so.2 and libsasl2.so.3 but some packages weren't rebuilt during f19 mass rebuild for some reason so they still require libsasl2.so.2. [1] http://lists.fedoraproject.org/pipermail/devel/2013-January/176599.html Petr -- Petr Lautrbach plaut...@redhat.com, Red Hat, Inc. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Fwd: problem with extended attributes
hi possibly better suited to the devel-list setfattr does not work here on F17/F18 with the latest kernels which is a huge problem with netatalk, especially if you try to build and get working netatalk-3.0.x the machines are booted with selinux=0 at the kernel-line but this should and must not be the reason to break support of extended attributes F17: attr-2.4.46-5.fc17.x86_64 / 3.7.10-101.fc17.x86_64 F18: attr-2.4.46-7.fc18.x86_64 / 3.8.2-201.fc18.x86_64 Original-Nachricht Betreff: problem with extended attributes Datum: Wed, 06 Mar 2013 15:36:24 +0100 Von: Reindl Harald h.rei...@thelounge.net Antwort an: Community support for Fedora users us...@lists.fedoraproject.org Organisation: the lounge interactive design An: Mailing-List fedora-users us...@lists.fedoraproject.org anybody an idea? [root@fileserver:~]$ setfattr -n harry -v test /mnt/storage/test setfattr: /mnt/storage/test: Operation not supported [root@fileserver:~]$ tune2fs -l /dev/mapper/StorageVolume-StorageVolumeLogical tune2fs 1.42.3 (14-May-2012) Filesystem volume name: /mnt/storage Last mounted on: /mnt/storage Filesystem UUID: 0e3b09c7-c488-486f-97b8-013e8d01037c Filesystem magic number: 0xEF53 Filesystem revision #:1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize Filesystem flags: signed_directory_hash Default mount options:journal_data_writeback user_xattr acl -- Reindl Harald the lounge interactive design GmbH A-1060 Vienna, Hofmühlgasse 17 CTO / CISO / Software-Development p: +43 (1) 595 3999 33, m: +43 (676) 40 221 40 icq: 154546673, http://www.thelounge.net/ http://www.thelounge.net/signature.asc.what.htm signature.asc Description: OpenPGP digital signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Review Request 16: Initial Packaging Work
--- This is an automatically generated e-mail. To reply, visit: http://reviewboard-tflink.rhcloud.com/r/16/ --- Review request for blockerbugs. Bugs: 337 https://fedorahosted.org/fedora-qa/ticket/337 Repository: blockerbugs Description --- Initial packaging work and reworking all the various cli scripts into a single module to make it more packaging friendly Diffs - update_blockers.sh d5229ea9b54119608e73cabcabbaaf4d99248876 sync_db.py 3489434c9cd6dc4f67ad82f61b171f94c4d65793 setup.py b4a51dc9c4bb9dadbd5ada286b8ddd5448811886 run_cli.py PRE-CREATION initialize.py eb3c3e160e66f5f044e20f53ff79994820fd4a7e init_db.sh 540dcb1f4baff9d7d0cad0dc75d67a4d6f3c3a98 docs/source/installation.rst PRE-CREATION docs/source/index.rst PRE-CREATION docs/source/development.rst PRE-CREATION docs/source/conf.py PRE-CREATION docs/Makefile PRE-CREATION doc/source/installation.rst 41319a6c345987bf50663ae4ff88068aed81334c doc/source/index.rst f07f013268aaa01cec780efec6e320c6cb267339 doc/source/development.rst 35b1b34a6b81d8d35e91fb11d32b35dc5d8269a9 doc/source/conf.py fc14e55effbd22e0c2b4fef5c7a395d16f0a5f70 doc/Makefile 8c16a97606680359188461c22ef48777b5ee9ee0 blockerbugs/cli.py PRE-CREATION blockerbugs/__init__.py 9030c04ee244ce21439075be9c446a83c05ed9ae blockerbugs.spec PRE-CREATION alembic.ini 848a3873008f231b03c12c4bcfe6d7367527f8fc Diff: http://reviewboard-tflink.rhcloud.com/r/16/diff/ Testing --- I've done a bunch of local testing and have a staging instance set up in the cloud: https://209.132.184.164/blockerbugs/ Thanks, Tim Flink ___ qa-devel mailing list qa-de...@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/qa-devel
Re: Yubikey single-factor authentication disabled
On Thu, 7 Mar 2013 07:09:13 + Clive Hills discordia...@gmail.com wrote: I suppose I have to bite and ask why yubikey is regarded as single-factor? I guess it isn't something I know as well as something I have? The way we had yubikeys deployed before (and what this thread is talking about) was single factor. You needed only your login/account name and the yubikey to login. While your login is indeed something you know it's not something that _only_ you know, it's something that anyone can trivially find out. The something you know in 2 factor auth has to be a secret only you know. ;) We are currently using yubikeys in a real 2 factor way in Fedora infrastructure, but thats something only folks with shell access and sudo access see right now. They have to enter password + yubikey (or google authenticator code) to sudo. We do hope to roll out more uses for 2 factor to web applications or other places, but we have not yet had time to do so. Also, I want to make sure when we do it's not a burden to contributors. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Wed, 06 Mar 2013 21:07:45 -0800 Adam Williamson awill...@redhat.com wrote: Sure. Note however that we don't currently run autoqa on rawhide builds and that was at least the initial target for this. ;) Um. I think we do? I see results from rpmguard (and other tests) for builds with 'fc19' in them at http://autoqa.fedoraproject.org/resultsdb/frontend , right now. Ah right, rpmguard is opt-in right now and does run against rawhide packages. ;) Thanks. kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 5. 3. 2013 at 18:50:45, Colin Walters wrote: On Tue, 2013-03-05 at 16:58 -0500, Bill Nottingham wrote: We don't ship in a way that easily allows this though, now. Admittedly, this is due to the sheer *amount* of stuff involved in just maintaining single versions of things, and how much that would jump if we started having multiple versions available all the time. To be clear, I am not suggesting multiple versions. The suggestion is that the old version of mesa overrides the new version and the tests (and users) get it. I think what Bill meant was to keep older versions of package in repos, as Debian distros do. It's not necessary to keep them locally. Having multiple versions in repos would solve the issue, as you would always have the option to install any of the older ones. However your proposal for old version explicitly overriding new version isn't just a problem of tooling. It's a problem of understanding the entire package release timeline. If you want an old package to override the new package, you will of course need to somehow specify that the new version of the package obsoletes all the old ones except the reversion while the new-new version obsoletes all of them, including the reversion. Diificult to comprehend? Now imagine implementing and actually using it as maintainer ;-) Also, you still have to put this information into the old package somehow, i.e. rebuild it. If you don't do that, you will miss a piece of the timeline. Much easier to bump epoch or release IMO. In this model where version numbers are merely descriptive, other things would have to change to use the build serial and not the ENVR, since the ENVR is now merely descriptive. For example, from systemd.spec: Obsoletes: upstart 1.2-7 The 1.2-7 is an ENVR, obviously. But if you think about it, the relationship of systemd and upstart here has *nothing* to do with the upstream version of 1.2, nor the fact that it was the 7th build. That 1.2-7 is capturing a *point in time* in Fedora (the combination of packages of systemd and upstart), and a point in time is exactly what a build serial is. Let's consider that EVR is an abstraction of point in time. Version marks point in time for upstream, release marks point in time for Fedora release. In that case all you need to do is update the point in time to more recent value, i.e. bump the release, right? I don't see anything complicated here, that's what release numbers are for. Thanks Jan signature.asc Description: This is a digitally signed message part. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora openid provider (fas-openid) in service
On Wed, Mar 06, 2013 at 07:21:49PM -0800, Adam Williamson wrote: On 06/03/13 06:41 AM, Stephen Gallagher wrote: I encountered an issue recently with pypi.org, where it was treating http://sgallagh.id.fedoraproject.org and https://sgallagh.id.fedoraproject.org as separate accounts (up to a point where they were causing tracebacks because they shared the same email address). So lesson learned: always drop the protocol prefix. The Verge does the same...the lesson I chose to learn was just to always use https, though. Note -- I made the same decision but I found out from puiterwijk that that should be raising an error in the relying party (the website asking that you auth with fedora's openid). The reason? We don't have SSL certificates for all possible [username].id.fedoraproject.org domains. In practice I never encountered a site that worked with our http:// identities but not our https:// identities. Makes you wonder about quality of implementations a bit -Toshio pgp8WUKigwflC.pgp Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: New Fedora openid provider (fas-openid) in service
Once upon a time, Toshio Kuratomi a.bad...@gmail.com said: Note -- I made the same decision but I found out from puiterwijk that that should be raising an error in the relying party (the website asking that you auth with fedora's openid). The reason? We don't have SSL certificates for all possible [username].id.fedoraproject.org domains. https://[username].id.fp.o uses a wildcard SSL cert for *.fp.o, but in SSL wildcard matching, a * does not match a .. This means that id.fp.o is matched with *.fp.o, but [username].id.fp.o is not. There would have to be an SSL cert for *.id.fp.o, which would mean DNS for *.id.fp.o couldn't CNAME to wildcard.fp.o, or the wildcard.fp.o server and all SSL-using clients trying to access *.id.fp.o would have to support TLS SNI. -- Chris Adams cmad...@hiwaay.net Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
asciidoc ownership
I orhpaned asciidoc, although I expect Stanislav to pick it up. Thank you Stanislav. thanks, -chris -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Problem in rawhide with ld and weak symbols?
Building LibreOffice for x86_64 starting to fail in an odd way recently, http://koji.fedoraproject.org/koji/getfile?taskID=5091173name=build.logoffset=-4000, I stripped that down to what I would assume is a newly introduced bug in how ld resolves weak references? Given a test.s of .text .globl main .type main, @function main: .quad x .weakref x,__pthread_key_create gcc test.s builds fine, while gcc test.s -lcom_err, i.e., including a reference to some .so that in turn needs libpthread, fails with /usr/bin/ld: /tmp/cckAPSW1.o: undefined reference to symbol '__pthread_key_create@@GLIBC_2.2.5' /usr/bin/ld: note: '__pthread_key_create@@GLIBC_2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status The same works fine in F-18. The failing ld is GNU ld version 2.23.52.0.1-4.fc19 20130226. Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem in rawhide with ld and weak symbols?
On Thu, Mar 7, 2013 at 1:28 PM, Stephan Bergmann sberg...@redhat.comwrote: Building LibreOffice for x86_64 starting to fail in an odd way recently, http://koji.fedoraproject.**org/koji/getfile?taskID=** 5091173name=build.logoffset=**-4000http://koji.fedoraproject.org/koji/getfile?taskID=5091173name=build.logoffset=-4000, I stripped that down to what I would assume is a newly introduced bug in how ld resolves weak references? Given a test.s of .text .globl main .type main, @function main: .quad x .weakref x,__pthread_key_create gcc test.s builds fine, while gcc test.s -lcom_err, i.e., including a reference to some .so that in turn needs libpthread, fails with /usr/bin/ld: /tmp/cckAPSW1.o: undefined reference to symbol '__pthread_key_create@@GLIBC_**2.2.5' /usr/bin/ld: note: '__pthread_key_create@@GLIBC_**2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status The same works fine in F-18. The failing ld is GNU ld version 2.23.52.0.1-4.fc19 20130226. I ran into this with kismet, adding an '-lpthread' at the right spot fixed it. I think it just got stricter again. -J Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.**org/mailman/listinfo/develhttps://admin.fedoraproject.org/mailman/listinfo/devel -- http://cecinestpasunefromage.wordpress.com/ in your fear, seek only peace in your fear, seek only love -d. bowie -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
Le Jeu 7 mars 2013 17:27, Jan Zelený a écrit : Also, you still have to put this information into the old package somehow, i.e. rebuild it. If you don't do that, you will miss a piece of the timeline. Much easier to bump epoch or release IMO. You may possibly work around this problem by keeping old builds for some time and adding a way to temporary override timeline at the repo metadata level (not at the package level). I suspect this could work at a small scale, but would wreak havoc in dep resolution if used more than a couple of days on packages with deep descendant trees. Even with --skip-broken yum is not able to resolve all conflicts in koji repos now, without adding such possibilities to the mix. And that is assuming all the administrative details (who sets the overrides, when, with what tools, how to deal with conflicting requests) could be worked out sanely. While seductive the idea seems about as safe as attempting to reverse direction on a highway. The more traffic (repo churn) there is the less likely you'll end up in one piece. Regards, -- Nicolas Mailhot -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
yum = 3.4.3-70: yum check reports X has installed obsoletes Y
Hi, Starting approx one week ago, yum check all returns messages such as fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes redhat-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes gnome-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-release-19-0.2.noarch has installed obsoletes redhat-release: fedora-release-19-0.2.noarch [ etc, 29 in total ] It started with yum-3.4.3-70.fc19. Is this a bug in yum = 3.4.3-70, or is this a problem with my rpm db? Both yum erase and rpm -e reported installed obsolete package tell me that the indicated package is not installed. Thanks, Sandro -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Problem in rawhide with ld and weak symbols?
On 03/07/2013 08:31 PM, Jon Ciesla wrote: On Thu, Mar 7, 2013 at 1:28 PM, Stephan Bergmann sberg...@redhat.com mailto:sberg...@redhat.com wrote: Building LibreOffice for x86_64 starting to fail in an odd way recently, http://koji.fedoraproject.__org/koji/getfile?taskID=__5091173name=build.logoffset=__-4000 http://koji.fedoraproject.org/koji/getfile?taskID=5091173name=build.logoffset=-4000, I stripped that down to what I would assume is a newly introduced bug in how ld resolves weak references? Given a test.s of .text .globl main .type main, @function main: .quad x .weakref x,__pthread_key_create gcc test.s builds fine, while gcc test.s -lcom_err, i.e., including a reference to some .so that in turn needs libpthread, fails with /usr/bin/ld: /tmp/cckAPSW1.o: undefined reference to symbol '__pthread_key_create@@GLIBC___2.2.5' /usr/bin/ld: note: '__pthread_key_create@@GLIBC___2.2.5' is defined in DSO /lib64/libpthread.so.0 so try adding it to the linker command line /lib64/libpthread.so.0: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status The same works fine in F-18. The failing ld is GNU ld version 2.23.52.0.1-4.fc19 20130226. I ran into this with kismet, adding an '-lpthread' at the right spot fixed it. I think it just got stricter again. Just see this is a known problem already, https://bugzilla.redhat.com/show_bug.cgi?id=918003 New ld broke handling of undefined weak symbols (and adding an '-lpthread' at the right spot just works around the symptoms). Stephan -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Mediawiki 1.20.2 has landed
On Wed, 2013-03-06 at 21:08 -0600, Michael Cronenworth wrote: On 03/06/2013 10:41 AM, James Laska wrote: * Fedora 18 * mediawiki-validator - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086055 * mediawiki-semantic - http://koji.fedoraproject.org/koji/taskinfo?taskID=5086060 These packages seemed to work fine on my mediawiki. I have not used this extension before but I enabled it and the Special pages appeared with no visible errors. For your karma pleasure ... https://admin.fedoraproject.org/updates/mediawiki-validator-0.5.1-1.fc18,mediawiki-semantic-1.8.0.4-2.fc18 Thanks, James signature.asc Description: This is a digitally signed message part -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On Thu, 07 Mar 2013 21:08:08 +0100, Sandro Mani wrote: Hi, Starting approx one week ago, yum check all returns messages such as fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes redhat-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes gnome-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-release-19-0.2.noarch has installed obsoletes redhat-release: fedora-release-19-0.2.noarch [ etc, 29 in total ] It started with yum-3.4.3-70.fc19. Is this a bug in yum = 3.4.3-70, or is this a problem with my rpm db? Both yum erase and rpm -e reported installed obsolete package tell me that the indicated package is not installed. You misread the output. It tells which Obsoletes tags are found in packages. For example: $ rpm --query --obsoletes fedora-logos redhat-logos gnome-logos It doesn't ask you to uninstall anything. ;) -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.11 0.12 0.16 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
File URI-Escape-XS-0.10.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-URI-Escape-XS: 23453334534498de37a758de3b077793 URI-Escape-XS-0.10.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-URI-Escape-XS] Initial import.
commit ed5c6653106508d7247fa475538377f7578b2559
Author: Emmanuel Seyman emman...@seyman.fr
Date: Thu Mar 7 21:24:24 2013 +0100
Initial import.
.gitignore |1 +
perl-URI-Escape-XS.spec | 65 +++
sources |1 +
3 files changed, 67 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..3111afa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/URI-Escape-XS-0.10.tar.gz
diff --git a/perl-URI-Escape-XS.spec b/perl-URI-Escape-XS.spec
new file mode 100644
index 000..b34ebb7
--- /dev/null
+++ b/perl-URI-Escape-XS.spec
@@ -0,0 +1,65 @@
+Name: perl-URI-Escape-XS
+Version:0.10
+Release:3%{?dist}
+Summary:Drop-In replacement for URI::Escape
+License:GPL+ or Artistic
+
+URL:http://search.cpan.org/dist/URI-Escape-XS/
+Source0:
http://www.cpan.org/authors/id/D/DA/DANKOGAI/URI-Escape-XS-%{version}.tar.gz
+
+BuildRequires: perl(base)
+BuildRequires: perl(Encode)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Carp)
+
+%{?perl_default_filter}
+
+%description
+This is a drop-in replacement for the URI::Escape module. Since it
+uses XS, it is really fast except for uri_escape(noop).
+
+%prep
+%setup -q -n URI-Escape-XS-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorarch}/auto/URI*
+%{perl_vendorarch}/URI*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-3
+- Change perl(Carp) from a BR to a R
+
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-2
+- Take into account comments of review (#916670)
+
+* Thu Feb 28 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-1
+- Update to 0.10
+
+* Mon Aug 13 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.09-1
+- Update to 0.09
+
+* Mon Jul 30 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.08-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..23caf82 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+23453334534498de37a758de3b077793 URI-Escape-XS-0.10.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: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On 07.03.2013 21:24, Michael Schwendt wrote: On Thu, 07 Mar 2013 21:08:08 +0100, Sandro Mani wrote: Hi, Starting approx one week ago, yum check all returns messages such as fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes redhat-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-logos-19.0.0-1.fc19.noarch has installed obsoletes gnome-logos: fedora-logos-19.0.0-1.fc19.noarch fedora-release-19-0.2.noarch has installed obsoletes redhat-release: fedora-release-19-0.2.noarch [ etc, 29 in total ] It started with yum-3.4.3-70.fc19. Is this a bug in yum = 3.4.3-70, or is this a problem with my rpm db? Both yum erase and rpm -e reported installed obsolete package tell me that the indicated package is not installed. You misread the output. It tells which Obsoletes tags are found in packages. For example: $ rpm --query --obsoletes fedora-logos redhat-logos gnome-logos It doesn't ask you to uninstall anything. ;) Uhm, ok, but why is this something yum suddenly wants to report? -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On Thu, 07 Mar 2013 21:36:12 +0100, Sandro Mani wrote:
It started with yum-3.4.3-70.fc19. Is this a bug in yum = 3.4.3-70, or
is this a problem with my rpm db? Both yum erase and rpm -e reported
installed obsolete package tell me that the indicated package is not
installed.
You misread the output. It tells which Obsoletes tags are found in
packages. For example:
$ rpm --query --obsoletes fedora-logos
redhat-logos
gnome-logos
It doesn't ask you to uninstall anything. ;)
Uhm, ok, but why is this something yum suddenly wants to report?
The Yum changelog is not detailed enough to tell, but rpmsack.py considers
these as problems. I think normal installing/updating with Yum also
prints those warnings. As a guess, it could be these are all for strange
Obsoletes/Provides pairs that aren't specific enough, or confusing, or lacking
versions. Such as:
rpcbind-0.2.0-21.fc19.x86_64 has installed obsoletes portmap = ('0', '4.0',
'65.3'): rpcbind-0.2.0-21.fc19.x86_64
$ rpm -q --obsoletes rpcbind|grep port
portmap = 4.0-65.3
$ rpm -q --provides rpcbind|grep port
portmap = 0.2.0-21.fc19
In other words, it obsoletes itself due to the versions that are specified.
--
Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64
loadavg: 0.15 0.18 0.14
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On 07.03.2013 22:03, Michael Schwendt wrote:
On Thu, 07 Mar 2013 21:36:12 +0100, Sandro Mani wrote:
It started with yum-3.4.3-70.fc19. Is this a bug in yum = 3.4.3-70, or
is this a problem with my rpm db? Both yum erase and rpm -e reported
installed obsolete package tell me that the indicated package is not
installed.
You misread the output. It tells which Obsoletes tags are found in
packages. For example:
$ rpm --query --obsoletes fedora-logos
redhat-logos
gnome-logos
It doesn't ask you to uninstall anything. ;)
Uhm, ok, but why is this something yum suddenly wants to report?
The Yum changelog is not detailed enough to tell, but rpmsack.py considers
these as problems. I think normal installing/updating with Yum also
prints those warnings. As a guess, it could be these are all for strange
Obsoletes/Provides pairs that aren't specific enough, or confusing, or lacking
versions. Such as:
rpcbind-0.2.0-21.fc19.x86_64 has installed obsoletes portmap = ('0', '4.0',
'65.3'): rpcbind-0.2.0-21.fc19.x86_64
$ rpm -q --obsoletes rpcbind|grep port
portmap = 4.0-65.3
$ rpm -q --provides rpcbind|grep port
portmap = 0.2.0-21.fc19
In other words, it obsoletes itself due to the versions that are specified.
You are right, i.e. these ones from fedora-logos are clearly ambiguous:
[...]
Obsoletes: redhat-logos
Obsoletes: gnome-logos
Provides: redhat-logos = %{version}-%{release}
Provides: gnome-logos = %{version}-%{release}
[...]
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On Thu, 2013-03-07 at 04:44 -0500, Jaroslav Reznik wrote: Well, I'm the maintainer of bamf-qt, same reason as Adam's - my try to package Unity-2d before they decided to get rid of QML based one and now, finally, decided to go back to the QML path ;-). So we will see if we could continue with the effort with Unity-next. And we can always revive it later in case we will need it. Eh. Given that Canonical now appear to be building Ubuntu OS, I have very little interest in trying to package Unity any more. I expect news sites will catch this, so I won't express myself any more forcefully than that. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Thu, 2013-03-07 at 07:48 -0500, Mark Bidewell wrote: Are there any records of these FUDCon discussions? Creating defined core of functionality seems like it could solve several problems. I would be curious as to what ideas we proposed on that. I don't know for sure, but I'm not aware of any, sadly. A lot of the discussion happened in a big free-for-all that ensued from the flaming wreckage of spot's talk on a proposed new release cycle (not spot's fault, but the discussion of his proposal very rapidly mutated into a wide-ranging, 'what do we want to change in Fedora?' discussion that lasted for a few hours.) I don't think anyone was recording at that point. I think some people wrote blog posts about it, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
On 03/06/2013 06:06 AM, Michael Schwendt wrote: And rest assured, dropping very old obsoletes isn't controversial in general. That's my opinion. What's controversial is how to do it. It ought not be done with just a clean up spec to follow current guidelines entry. Point at a commit where you've dropped Obsoletes, and one could take a look. It would be a good habit to document dropped Obsoletes in a %changelog comment, for example. Agreed but I just get a general feeling that some package maintainers don't really want others touching their packages. I haven't stopped doing the changes ( I don't commit daily but whenever I can run through a bunch of mock builds first) but I am going to be confining my changes to more obvious and clear issues and package maintainers can deal with the rest however they see fit and that would leave less room for complaints. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [ACTION REQUIRED] Retiring packages for Fedora 19 - March 4 update
On 03/07/2013 05:13 PM, Adam Williamson wrote: Eh. Given that Canonical now appear to be building Ubuntu OS, I have very little interest in trying to package Unity any more. I don't think it would make sense to package any of the bits individually unless you buy into their whole roadmap which includes a number of tightly integrated components and that probably will have patches across the stack. Since they are targeting the mobile/tablet world, it seems the Google model is the one they have adopted which admittedly has worked out great for Google but I don't think Canonical has the same muscle to flex. We will know in a few years how successful their chosen path is. This is a watershed moment for them. Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On 03/07/2013 05:16 PM, Adam Williamson wrote: I don't know for sure, but I'm not aware of any, sadly. A lot of the discussion happened in a big free-for-all that ensued from the flaming wreckage of spot's talk on a proposed new release cycle (not spot's fault, but the discussion of his proposal very rapidly mutated into a wide-ranging, 'what do we want to change in Fedora?' discussion that lasted for a few hours.) I don't think anyone was recording at that point. I think some people wrote blog posts about it, though. Unfortunately, this leaves people who haven't attended the FUDCon disconnected from the discussions and you only get very distilled impressions. Recording conversations like this is fairly important Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: yum = 3.4.3-70: yum check reports X has installed obsoletes Y
On Thu, 2013-03-07 at 22:03 +0100, Michael Schwendt wrote: The Yum changelog is not detailed enough to tell, If I may. The handling of both this and the bundled presto^Wdeltrarpm new yum ..features on the part of the current yum developers is disappointing. I am trying to find the devel mail that informs us about these obviously visible changes to a core Fedora tool and I can't find them -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [emelfm2] remove vendor tag from desktop file. https://fedorahosted.org/fpc/ticket/247
On Thu, 07 Mar 2013 17:56:32 -0500, Rahul Sundaram wrote: Agreed but I just get a general feeling that some package maintainers don't really want others touching their packages. Some don't like it that another name appears in their %changelog. Some even overwrite/revert changes with their next commit, because either they don't pay attention to the commit notification mails or they force into git their spec file working-copies and don't care what somebody else may have committed. (no examples available, but it has happened within fedora cvs and git) Pkgdb shows a provenpackager - group members can commit? checkbox. For which packages is this box unchecked? In general, http://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages is a good start. If touching packages also included doing version upgrades at random times without taking care of a package in general, it would/could get less funny and [much] more difficult. There are some, who would like permission to mess with the package collection as they see fit and not be responsible for the touched packages otherwise. I haven't stopped doing the changes ( I don't commit daily but whenever I can run through a bunch of mock builds first) but I am going to be confining my changes to more obvious and clear issues and package maintainers can deal with the rest however they see fit and that would leave less room for complaints. Happy to hear that. I'm sure the people who get rid of the desktop vendor prefix in hundreds of packages will receive a honorary mention occasionally. -- Fedora release 19 (Rawhide) - Linux 3.9.0-0.rc0.git15.1.fc19.x86_64 loadavg: 0.87 0.74 0.46 -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: RFC: Fedora revamp proposal
On Thu, Mar 7, 2013 at 5:17 PM, Rahul Sundaram methe...@gmail.com wrote: On 03/07/2013 05:16 PM, Adam Williamson wrote: I don't know for sure, but I'm not aware of any, sadly. A lot of the discussion happened in a big free-for-all that ensued from the flaming wreckage of spot's talk on a proposed new release cycle (not spot's fault, but the discussion of his proposal very rapidly mutated into a wide-ranging, 'what do we want to change in Fedora?' discussion that lasted for a few hours.) I don't think anyone was recording at that point. I think some people wrote blog posts about it, though. Unfortunately, this leaves people who haven't attended the FUDCon disconnected from the discussions and you only get very distilled impressions. Recording conversations like this is fairly important Notes were collected at the end and this thread began with I believe a fair representation of the outcome of the discussion and it was signed off on by the list of people included in the original post to which I am happy to add my name as someone who was present for most of the discussion. Of course it was fully expected there would be extensive discussion here about the idea. John -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Maintainers wanted for packages from 2013-02-27 FESCo Meeting
On Sáb, 2013-03-02 at 10:26 +0100, Michael Scherer wrote: Le vendredi 01 mars 2013 à 00:24 +, Sérgio Basto a écrit : Hi, I also use clamav as daemon and I use fedora package, recently I upgrade the box, that use clamav, to Fedora 17. I had to do a new clamd.service based on what exist, so here it is /usr/lib/systemd/system/clamd.service : [Unit] Description = clamav server (clamd) daemon After = syslog.target nss-lookup.target network.target Before= spamassassin.service [Service] Type = simple ExecStart = /usr/sbin/clamd -c /etc/clamd.conf --nofork=yes Restart = on-failure PrivateTmp = true [Install] WantedBy=multi-user.target given that clamav is a security sensitive package ( ie, we feed it with all kind of crap coming from network ), wouldn't it be interesting to investigate using : - PrivateNetwork=yes afaik, clamav use socket to communicate, so this could help to mitigate exploit that download from the network, or just a attacker using a exploit to attack a inside ressource. - LimitNPROC=1 not sure if clamav is multiprocess when run as daemon, should be checked too. This would permit to mitigate some exploits, ie, not able to fork/exec would block let's spawn a shell bound to port XXX. - DeviceAllow= and just allow /dev/null or /dev/zero I guess. the reasoning are on the page of systemd http://0pointer.de/blog/projects/security.html , in short, if someone using code injection to attack a device for local privileges escalation from clamav, this would mitigate some exploit. - CapabilityBoundingSet=~CAP_SYS_PTRACE , and maybe more stringent restriction, again, this requires some tests. This one is harder to setup since we need lots of runtime tests, and since clamav is not running as root, I am not sure this bring much, when compared to the work it may requires. While some of theses are surely already blocked by selinux, some people unfortunately tend to disable it, so we should think about defence in depth. And if that work fine, we can start to apply this idea to others daemons as well. Hi, some ideas, If you do a re-review of the package I can help you on review, please CC directly to me . I have a server with qmail and Fedora 17 based on qmailrocks and now just http://qmail.jms1.net/patches/combined-details.shtml Clamav package works with it without patches :) I'm thinking document it, my email server solution but don't had much time, also now that qmail is public domain, it use and integrated a few packages of Fedora. About what you wrote: Don't understand the concern on so must security, I use it under a router so this port are close to exterior and in side my LAN don't see a problem to have a tcp port, neither have completely untrusted email. Best regards, -- Sérgio M. B. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
dial-up comps group?
I see all the various desktop envs install the 'dial-up' group, which has: packagereq type=mandatoryppp/packagereq packagereq type=defaultisdn4k-utils/packagereq packagereq type=defaultlinux-atm/packagereq packagereq type=defaultlrzsz/packagereq packagereq type=defaultminicom/packagereq packagereq type=defaultModemManager/packagereq packagereq type=defaultrp-pppoe/packagereq packagereq type=defaultwvdial/packagereq packagereq type=optionalefax/packagereq packagereq type=optionalpptp/packagereq packagereq type=optionalstatserial/packagereq I can see people perhaps using ModemManager (when they have some kind of mobile broadband or the like), but do we need to install the rest of that stuff on every desktop anymore? kevin signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: dial-up comps group?
On 3/7/2013 8:50 PM, Kevin Fenzi wrote: I see all the various desktop envs install the 'dial-up' group, which has: packagereq type=mandatoryppp/packagereq packagereq type=defaultisdn4k-utils/packagereq packagereq type=defaultlinux-atm/packagereq packagereq type=defaultlrzsz/packagereq packagereq type=defaultminicom/packagereq packagereq type=defaultModemManager/packagereq packagereq type=defaultrp-pppoe/packagereq packagereq type=defaultwvdial/packagereq packagereq type=optionalefax/packagereq packagereq type=optionalpptp/packagereq packagereq type=optionalstatserial/packagereq I can see people perhaps using ModemManager (when they have some kind of mobile broadband or the like), but do we need to install the rest of that stuff on every desktop anymore? kevin In a word, yes. The digital divide between urban and rural still exists, which means that broadband availability is significantly less in rural areas, leaving dial-up the only financially feasible alternative for many households. This situation is exacerbated in physically large countries that lack strong national policy for high speed, high capacity Internet availability, so continued installation of what might be considered geriatric, if not actually primitive, technology continues to be necessary. Ken -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: MariaDB replacing MySQL
On 03/06/2013 08:44 AM, Miloslav Trmač wrote: File conflicts within the server packages might still be a concern, I don't know. Per the decision quoted above, FESCo would prefer the maintainers of the two servers to agree on a solution. If the maintainers don't reach a solution or if one of them finds the current proposal unsatisfactory, file a ticket at https://fedorahosted.org/fesco/ Rahul -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
[pkgdb] perl-CPANPLUS ownership changed
Package perl-CPANPLUS in Fedora devel is now owned by ppisar To make changes to this package see: https://admin.fedoraproject.org/pkgdb/acls/name/perl-CPANPLUS -- 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-CPANPLUS] Reincarnate already died package
commit 2c6fbd3f34b3bc4fa01d3e38eb182cef9b2b1e40
Author: Petr Písař ppi...@redhat.com
Date: Thu Mar 7 09:31:02 2013 +0100
Reincarnate already died package
.gitignore |1 +
dead.package |1 -
perl-CPANPLUS.spec | 104
sources|1 +
4 files changed, 106 insertions(+), 1 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index fa16006..31f7a51 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
CPANPLUS-0.84.tar.gz
+/CPANPLUS-0.9134.tar.gz
diff --git a/perl-CPANPLUS.spec b/perl-CPANPLUS.spec
new file mode 100644
index 000..9297a5d
--- /dev/null
+++ b/perl-CPANPLUS.spec
@@ -0,0 +1,104 @@
+%global cpan_version 0.9134
+Name: perl-CPANPLUS
+# Keep 2-digit major varion to compete with perl.spec for history
+Version:%(echo '%{cpan_version}' | sed 's/\(\...\)/\1./')
+Release:1%{?dist}
+Summary:Ameliorated interface to the Comprehensive Perl Archive Network
+License:GPL+ or Artistic
+Group: Development/Libraries
+URL:http://search.cpan.org/dist/CPANPLUS/
+Source0:
http://www.cpan.org/authors/id/B/BI/BINGOS/CPANPLUS-%{cpan_version}.tar.gz
+BuildArch: noarch
+BuildRequires: perl(Config)
+BuildRequires: perl(constant)
+BuildRequires: perl(File::Copy)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(Getopt::Long)
+BuildRequires: perl(inc::Module::Install)
+BuildRequires: perl(lib)
+BuildRequires: perl(Locale::Maketext::Simple)
+BuildRequires: perl(Module::Loaded)
+# Run-time:
+BuildRequires: perl(Archive::Extract)
+BuildRequires: perl(base)
+BuildRequires: perl(Carp)
+BuildRequires: perl(Cwd)
+BuildRequires: perl(Data::Dumper)
+BuildRequires: perl(DBD::SQLite)
+BuildRequires: perl(DBIx::Simple)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(IPC::Cmd)
+BuildRequires: perl(File::Basename)
+BuildRequires: perl(File::Fetch)
+BuildRequires: perl(File::Find)
+BuildRequires: perl(File::Glob)
+BuildRequires: perl(FileHandle)
+BuildRequires: perl(File::Path)
+BuildRequires: perl(File::Spec::Unix)
+BuildRequires: perl(File::stat)
+BuildRequires: perl(File::Temp)
+BuildRequires: perl(Log::Message)
+BuildRequires: perl(Module::Load)
+BuildRequires: perl(Module::Load::Conditional)
+BuildRequires: perl(Object::Accessor)
+BuildRequires: perl(overload)
+BuildRequires: perl(Package::Constants)
+BuildRequires: perl(Params::Check)
+BuildRequires: perl(Parse::CPAN::Meta)
+BuildRequires: perl(strict)
+BuildRequires: perl(Term::ReadLine)
+BuildRequires: perl(Term::UI)
+BuildRequires: perl(Tie::Hash)
+BuildRequires: perl(Time::Local)
+BuildRequires: perl(vars)
+BuildRequires: perl(version)
+BuildRequires: perl(warnings)
+# Tests:
+BuildRequires: perl(Test::More)
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
+# lib/CPANPLUS/Internals.pm:465
+Requires: perl(File::Glob)
+# lib/CPANPLUS/Internals/Utils.pm:68
+Requires: perl(File::Path)
+# lib/CPANPLUS/Internals/Utils.pm:323
+Requires: perl(File::stat)
+# bin/cpanp-boxed:10
+Requires: perl(FindBin)
+
+%global __requires_exclude
%{?__requires_exclude:%__requires_exclude|}^perl\\((Your::Module::Here|Test)\\)
+
+%description
+The CPANPLUS library is an API to the CPAN mirrors and a collection of
+interactive shells, command line programs, etc., that use this API.
+
+%prep
+%setup -q -n CPANPLUS-%{cpan_version}
+# Remove bundled modules
+rm -rf inc
+sed -i -e '/^inc\//d' MANIFEST
+# Fix shebangs
+sed -i -e '1i#!%{__perl}' bin/cpanp-run-perl
+
+%build
+perl Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc ChangeLog README
+%{_bindir}/*
+%{perl_vendorlib}/*
+%{_mandir}/man1/*
+%{_mandir}/man3/*
+
+%changelog
+* Thu Jan 24 2013 Petr Pisar ppi...@redhat.com 0.91.34-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
new file mode 100644
index 000..8f4123a
--- /dev/null
+++ b/sources
@@ -0,0 +1 @@
+df932be2b5fc533a6e82180fef0f436e CPANPLUS-0.9134.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 918921] New: perl-version-0.9902 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=918921 Bug ID: 918921 Summary: perl-version-0.9902 is available Product: Fedora Version: rawhide Component: perl-version Keywords: FutureFeature, Triaged Severity: unspecified Priority: unspecified Reporter: upstream-release-monitor...@fedoraproject.org Latest upstream release: 0.9902 Current version in Fedora Rawhide: 0.99.01 URL: http://search.cpan.org/dist/version/ 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=JHofVANW59a=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 918921] perl-version-0.9902 is available
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=918921 Jitka Plesnikova jples...@redhat.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||jples...@redhat.com Assignee|mmasl...@redhat.com |jples...@redhat.com -- 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=3cI6ho4zFIa=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-version] (2 commits) ...Merge branch 'master' of ssh://pkgs.fedoraproject.org/perl-version
Summary of changes: 97dad9c... 0.9902 bump ac67155... Merge branch 'master' of ssh://pkgs.fedoraproject.org/perl- -- 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-version: 1/2] 0.9902 bump
commit 97dad9c00c07ae85ac537a57c2d8b9b5277e4beb
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Mar 7 10:47:15 2013 +0100
0.9902 bump
.gitignore|1 +
perl-version.spec | 12 +++-
sources |2 +-
3 files changed, 9 insertions(+), 6 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 1a07576..480b6e5 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,3 +1,4 @@
version-0.88.tar.gz
/version-0.99.tar.gz
/version-0.9901.tar.gz
+/version-0.9902.tar.gz
diff --git a/perl-version.spec b/perl-version.spec
index e8b2e93..c5eb528 100644
--- a/perl-version.spec
+++ b/perl-version.spec
@@ -1,7 +1,7 @@
Name: perl-version
Epoch: 3
-Version:0.99.01
-%define module_version 0.9901
+Version:0.99.02
+%define module_version 0.9902
Release:1%{?dist}
Summary:Perl extension for Version Objects
License:GPL+ or Artistic
@@ -18,7 +18,7 @@ BuildRequires: perl(File::Temp) = 0.13
BuildRequires: perl(lib)
BuildRequires: perl(Test::More) = 0.45
BuildRequires: perl(Test::Harness)
-Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(:MODULE_COMPAT_%(eval `perl -V:version`; echo $version))
%{?perl_default_filter}
# version::vxs is private module (see bug #633775)
@@ -36,14 +36,13 @@ strongly urged to set 0.77 as a minimum in your code.
%setup -q -n version-%{module_version}
%build
-%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+perl Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
make %{?_smp_mflags}
%install
make pure_install DESTDIR=$RPM_BUILD_ROOT
find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
-find $RPM_BUILD_ROOT -depth -type d -exec rmdir {} \; 2/dev/null
%{_fixperms} $RPM_BUILD_ROOT/*
%check
@@ -61,6 +60,9 @@ make test
%{_mandir}/man3/version::Internals.3pm*
%changelog
+* Thu Mar 7 2013 Jitka Plesnikova jples...@redhat.com - 3:0.99.02-1
+- 0.9902 bump
+
* Mon Sep 17 2012 Jitka Plesnikova jples...@redhat.com - 3:0.99.01-1
- 0.9901 bump
diff --git a/sources b/sources
index 4c2c609..c912787 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-bf5e487e24a8991d09c01e56a247424f version-0.9901.tar.gz
+edb0ac88be8bed3e370ce12e74261998 version-0.9902.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-version: 2/2] Merge branch 'master' of ssh://pkgs.fedoraproject.org/perl-version
commit ac67155741d0a518ecef3cb499ca133f48da9b1d
Merge: 97dad9c fdba821
Author: Jitka Plesnikova jples...@redhat.com
Date: Thu Mar 7 10:48:53 2013 +0100
Merge branch 'master' of ssh://pkgs.fedoraproject.org/perl-version
Conflicts:
perl-version.spec
perl-version.spec |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
---
diff --cc perl-version.spec
index c5eb528,0becd29..0c49981
--- a/perl-version.spec
+++ b/perl-version.spec
@@@ -60,9 -61,9 +60,12 @@@ make tes
%{_mandir}/man3/version::Internals.3pm*
%changelog
+* Thu Mar 7 2013 Jitka Plesnikova jples...@redhat.com - 3:0.99.02-1
+- 0.9902 bump
+
+ * Thu Feb 14 2013 Fedora Release Engineering
rel-...@lists.fedoraproject.org - 3:0.99.01-2
+ - Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
+
* Mon Sep 17 2012 Jitka Plesnikova jples...@redhat.com - 3:0.99.01-1
- 0.9901 bump
--
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 919030] New: perl-Glib-Object-Introspection seems to have a big-endian problem, self tests fail on s390* and ppc*
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=919030 Bug ID: 919030 Summary: perl-Glib-Object-Introspection seems to have a big-endian problem, self tests fail on s390* and ppc* Product: Fedora Version: rawhide Component: perl-Glib-Object-Introspection Severity: high Priority: medium Reporter: kars...@redhat.com Description of problem: # Failed test at t/00-basic-types.t line 15. # got: '-1' # expected: '-127' # Failed test at t/00-basic-types.t line 16. # got: '0' # expected: '255' # Failed test at t/00-basic-types.t line 17. # got: '-1' # expected: '-32767' # Failed test at t/00-basic-types.t line 18. # got: '0' # expected: '65535' # Looks like you failed 4 tests of 34. t/00-basic-types.t Dubious, test returned 4 (wstat 1024, 0x400) Failed 4/34 subtests # Failed test at t/arg-checks.t line 11. # got: '-1' # expected: '-127' # Failed test at t/arg-checks.t line 21. # got: '0' # expected: '127' # Looks like you failed 2 tests of 5. t/arg-checks.t Dubious, test returned 2 (wstat 512, 0x200) Version-Release number of selected component (if applicable): perl-Glib-Object-Introspection-0.015-1.fc19 How reproducible: always Steps to Reproduce: 1. ppc-koji build --scratch f19 perl-Glib-Object-Introspection-0.015-1.fc19.src.rpm 2. 3. Actual results: http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=973021 Expected results: Additional info: -- 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=YIO2oILrQBa=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-Math-Clipper
perl-Math-Clipper has broken dependencies in the rawhide tree: On x86_64: perl-Math-Clipper-1.17-3.fc19.x86_64 requires libpolyclipping.so.5()(64bit) On i386: perl-Math-Clipper-1.17-3.fc19.i686 requires libpolyclipping.so.5 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
File HTML-TableExtract-2.11.tar.gz uploaded to lookaside cache by psabata
A file has been added to the lookaside cache for perl-HTML-TableExtract: ac1b8fa092d53931a9f3fdbba330f5b0 HTML-TableExtract-2.11.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-HTML-TableExtract] 2.11 bump, fixing build
commit 4e583d02d5f05366a27a7e11a8cacd260235cd2b
Author: Petr Šabata con...@redhat.com
Date: Thu Mar 7 16:41:41 2013 +0100
2.11 bump, fixing build
.gitignore |1 +
perl-HTML-TableExtract.spec | 37 -
sources |2 +-
3 files changed, 26 insertions(+), 14 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index 3b92133..edbcb94 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1 +1,2 @@
HTML-TableExtract-2.10.tar.gz
+/HTML-TableExtract-2.11.tar.gz
diff --git a/perl-HTML-TableExtract.spec b/perl-HTML-TableExtract.spec
index ff74cd6..75593c2 100644
--- a/perl-HTML-TableExtract.spec
+++ b/perl-HTML-TableExtract.spec
@@ -1,15 +1,29 @@
Name: perl-HTML-TableExtract
-Version:2.10
-Release: 14%{?dist}
+Version:2.11
+Release: 1%{?dist}
Summary:A Perl module for extracting content in HTML tables
Group: Development/Libraries
License:GPL+ or Artistic
URL: http://www.mojotoad.com/sisk/projects/HTML-TableExtract/
Source0:
http://search.cpan.org/CPAN/authors/id/M/MS/MSISK/HTML-TableExtract-%{version}.tar.gz
-BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch: noarch
Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
-BuildRequires: perl(HTML::TreeBuilder) perl(Test::Pod)
perl(Test::Pod::Coverage)
+BuildRequires: perl
+BuildRequires: perl(Carp)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(File::Spec)
+BuildRequires: perl(FindBin)
+BuildRequires: perl(HTML::ElementTable)
+BuildRequires: perl(HTML::Entities)
+BuildRequires: perl(HTML::Parser)
+BuildRequires: perl(HTML::TreeBuilder)
+BuildRequires: perl(lib)
+BuildRequires: perl(strict)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(vars)
%description
HTML::TableExtract is a module that simplifies the extraction of
@@ -27,27 +41,24 @@ documentation for details.
make %{?_smp_mflags}
%install
-rm -rf $RPM_BUILD_ROOT
-make pure_install PERL_INSTALL_ROOT=$RPM_BUILD_ROOT
+make pure_install DESTDIR=$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/*
%check
make test
-%clean
-rm -rf $RPM_BUILD_ROOT
-
-
%files
-%defattr(-,root,root,-)
%doc Changes README
%{perl_vendorlib}/HTML/
%{_mandir}/man3/*.3*
-
%changelog
+* Wed Mar 06 2013 Petr Šabata con...@redhat.com - 2.11-1
+- 2.11 build
+- Minor spec cleanup
+- Fix the build by correcting BRs
+
* Thu Feb 14 2013 Fedora Release Engineering rel-...@lists.fedoraproject.org
- 2.10-14
- Rebuilt for https://fedoraproject.org/wiki/Fedora_19_Mass_Rebuild
diff --git a/sources b/sources
index 73dfcc0..fb748af 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-e6e355f6049dc57706e719c5ce61ff39 HTML-TableExtract-2.10.tar.gz
+ac1b8fa092d53931a9f3fdbba330f5b0 HTML-TableExtract-2.11.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 914285] perl-HTML-TableExtract: FTBFS in rawhide
Product: Fedora https://bugzilla.redhat.com/show_bug.cgi?id=914285 Petr Šabata psab...@redhat.com changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-HTML-TableExtract-2.11 ||-1.fc19 Resolution|--- |RAWHIDE Last Closed||2013-03-07 10:48:07 -- 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=pDYwARtx24a=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
File ElasticSearch-SearchBuilder-0.18.tar.gz uploaded to lookaside cache by eseyman
A file has been added to the lookaside cache for perl-ElasticSearch-SearchBuilder: 5269021cbda741c334d1e0dfef7e1d45 ElasticSearch-SearchBuilder-0.18.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-ElasticSearch-SearchBuilder] Initial import.
commit ab36633aa3af5e2f6cd97a9a77e50e5af4c05ef3
Author: Emmanuel Seyman emman...@seyman.fr
Date: Thu Mar 7 20:04:59 2013 +0100
Initial import.
.gitignore|1 +
perl-ElasticSearch-SearchBuilder.spec | 69 +
sources |1 +
3 files changed, 71 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..982aa0c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/ElasticSearch-SearchBuilder-0.18.tar.gz
diff --git a/perl-ElasticSearch-SearchBuilder.spec
b/perl-ElasticSearch-SearchBuilder.spec
new file mode 100644
index 000..47ae9a1
--- /dev/null
+++ b/perl-ElasticSearch-SearchBuilder.spec
@@ -0,0 +1,69 @@
+Name: perl-ElasticSearch-SearchBuilder
+Version:0.18
+Release:2%{?dist}
+Summary:Perlish compact query language for ElasticSearch
+License:GPL+ or Artistic
+
+URL:http://search.cpan.org/dist/ElasticSearch-SearchBuilder/
+Source0:
http://www.cpan.org/authors/id/D/DR/DRTECH/ElasticSearch-SearchBuilder-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::Dump)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Test::Differences)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+The Query DSL for ElasticSearch (see Query DSL), which is used to write
+queries and filters, is simple but verbose, which can make it difficult to
+write and understand large queries.
+
+%prep
+%setup -q -n ElasticSearch-SearchBuilder-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.18-2
+- Take into accounts package review comments (#916677)
+
+* Sun Jan 27 2013 Emmanuel Seyman emman...@seyman.fr - 0.18-1
+- Update to 0.18
+
+* Sat Nov 17 2012 Emmanuel Seyman emman...@seyman.fr - 0.17-1
+- Update to 0.17
+
+* Thu Nov 01 2012 Emmanuel Seyman emman...@seyman.fr - 0.16-1
+- Update to 0.16
+
+* Sun Oct 21 2012 Emmanuel Seyman emman...@seyman.fr - 0.15-1
+- Update to 0.15
+
+* Mon Jul 30 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.14-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..2611f76 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+5269021cbda741c334d1e0dfef7e1d45 ElasticSearch-SearchBuilder-0.18.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-ElasticSearch-SearchBuilder/f18] Initial import.
commit eaa4fbfd7eee0880f0546a7f880497279195d184
Author: Emmanuel Seyman emman...@seyman.fr
Date: Thu Mar 7 20:42:51 2013 +0100
Initial import.
.gitignore|1 +
perl-ElasticSearch-SearchBuilder.spec | 69 +
sources |1 +
3 files changed, 71 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..982aa0c 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/ElasticSearch-SearchBuilder-0.18.tar.gz
diff --git a/perl-ElasticSearch-SearchBuilder.spec
b/perl-ElasticSearch-SearchBuilder.spec
new file mode 100644
index 000..47ae9a1
--- /dev/null
+++ b/perl-ElasticSearch-SearchBuilder.spec
@@ -0,0 +1,69 @@
+Name: perl-ElasticSearch-SearchBuilder
+Version:0.18
+Release:2%{?dist}
+Summary:Perlish compact query language for ElasticSearch
+License:GPL+ or Artistic
+
+URL:http://search.cpan.org/dist/ElasticSearch-SearchBuilder/
+Source0:
http://www.cpan.org/authors/id/D/DR/DRTECH/ElasticSearch-SearchBuilder-%{version}.tar.gz
+
+BuildArch: noarch
+BuildRequires: perl(Carp)
+BuildRequires: perl(Data::Dump)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Scalar::Util)
+BuildRequires: perl(Test::Deep)
+BuildRequires: perl(Test::Differences)
+BuildRequires: perl(Test::Exception)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+
+%{?perl_default_filter}
+
+%description
+The Query DSL for ElasticSearch (see Query DSL), which is used to write
+queries and filters, is simple but verbose, which can make it difficult to
+write and understand large queries.
+
+%prep
+%setup -q -n ElasticSearch-SearchBuilder-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes LICENSE README
+%{perl_vendorlib}/*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.18-2
+- Take into accounts package review comments (#916677)
+
+* Sun Jan 27 2013 Emmanuel Seyman emman...@seyman.fr - 0.18-1
+- Update to 0.18
+
+* Sat Nov 17 2012 Emmanuel Seyman emman...@seyman.fr - 0.17-1
+- Update to 0.17
+
+* Thu Nov 01 2012 Emmanuel Seyman emman...@seyman.fr - 0.16-1
+- Update to 0.16
+
+* Sun Oct 21 2012 Emmanuel Seyman emman...@seyman.fr - 0.15-1
+- Update to 0.15
+
+* Mon Jul 30 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.14-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..2611f76 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+5269021cbda741c334d1e0dfef7e1d45 ElasticSearch-SearchBuilder-0.18.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 YAML-Syck-1.24.tar.gz uploaded to lookaside cache by pghmcfc
A file has been added to the lookaside cache for perl-YAML-Syck: 075fd0e5bcd4c67aa27788568b5f5b8b YAML-Syck-1.24.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-YAML-Syck] Update to 1.24
commit dbae81332e46a59fc2a86c6c08c8ec534d5f360e
Author: Paul Howarth p...@city-fan.org
Date: Thu Mar 7 21:59:33 2013 +
Update to 1.24
- New upstream release 1.24
- Implement $JSON::Syck::MaxDepth
- Prevent failure when the same object is seen twice during Dump
- Prevent YAML from being influnced by the previous change
- MinGW64 compatibility (CPAN RT#78363)
perl-YAML-Syck.spec |9 -
sources |2 +-
2 files changed, 9 insertions(+), 2 deletions(-)
---
diff --git a/perl-YAML-Syck.spec b/perl-YAML-Syck.spec
index be62be3..dc41b3b 100644
--- a/perl-YAML-Syck.spec
+++ b/perl-YAML-Syck.spec
@@ -1,5 +1,5 @@
Name: perl-YAML-Syck
-Version:1.23
+Version:1.24
Release:1%{?dist}
Summary:Fast, lightweight YAML loader and dumper
License:BSD and MIT
@@ -67,6 +67,13 @@ rm -rf $RPM_BUILD_ROOT
%{_mandir}/man3/YAML::Syck.3pm*
%changelog
+* Thu Mar 7 2013 Paul Howarth p...@city-fan.org 1.24-1
+- Update to 1.24
+ - Implement $JSON::Syck::MaxDepth
+ - Prevent failure when the same object is seen twice during Dump
+ - Prevent YAML from being influnced by the previous change
+ - MinGW64 compatibility (CPAN RT#78363)
+
* Wed Feb 27 2013 Paul Howarth p...@city-fan.org 1.23-1
- Update to 1.23
- Synchronize JSON::Syck with YAML::Syck version number
diff --git a/sources b/sources
index 417d75e..76ec6bd 100644
--- a/sources
+++ b/sources
@@ -1 +1 @@
-902ca96c2f4e9bf818b06e1ed4d89c00 YAML-Syck-1.23.tar.gz
+075fd0e5bcd4c67aa27788568b5f5b8b YAML-Syck-1.24.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-YAML-Syck] Created tag perl-YAML-Syck-1.24-1.fc19
The lightweight tag 'perl-YAML-Syck-1.24-1.fc19' was created pointing to: dbae813... Update to 1.24 -- 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-URI-Escape-XS/f18] Initial import.
commit a5997950d1a444e0cdef4694f398d4176bb366d2
Author: Emmanuel Seyman emman...@seyman.fr
Date: Thu Mar 7 23:49:18 2013 +0100
Initial import.
.gitignore |1 +
perl-URI-Escape-XS.spec | 65 +++
sources |1 +
3 files changed, 67 insertions(+), 0 deletions(-)
---
diff --git a/.gitignore b/.gitignore
index e69de29..3111afa 100644
--- a/.gitignore
+++ b/.gitignore
@@ -0,0 +1 @@
+/URI-Escape-XS-0.10.tar.gz
diff --git a/perl-URI-Escape-XS.spec b/perl-URI-Escape-XS.spec
new file mode 100644
index 000..b34ebb7
--- /dev/null
+++ b/perl-URI-Escape-XS.spec
@@ -0,0 +1,65 @@
+Name: perl-URI-Escape-XS
+Version:0.10
+Release:3%{?dist}
+Summary:Drop-In replacement for URI::Escape
+License:GPL+ or Artistic
+
+URL:http://search.cpan.org/dist/URI-Escape-XS/
+Source0:
http://www.cpan.org/authors/id/D/DA/DANKOGAI/URI-Escape-XS-%{version}.tar.gz
+
+BuildRequires: perl(base)
+BuildRequires: perl(Encode)
+BuildRequires: perl(Exporter)
+BuildRequires: perl(ExtUtils::MakeMaker)
+BuildRequires: perl(Test::More)
+BuildRequires: perl(Test::Pod)
+BuildRequires: perl(Test::Pod::Coverage)
+BuildRequires: perl(XSLoader)
+Requires: perl(:MODULE_COMPAT_%(eval `%{__perl} -V:version`; echo
$version))
+Requires: perl(Carp)
+
+%{?perl_default_filter}
+
+%description
+This is a drop-in replacement for the URI::Escape module. Since it
+uses XS, it is really fast except for uri_escape(noop).
+
+%prep
+%setup -q -n URI-Escape-XS-%{version}
+
+%build
+%{__perl} Makefile.PL INSTALLDIRS=vendor OPTIMIZE=$RPM_OPT_FLAGS
+make %{?_smp_mflags}
+
+%install
+make pure_install DESTDIR=$RPM_BUILD_ROOT
+
+find $RPM_BUILD_ROOT -type f -name .packlist -exec rm -f {} \;
+find $RPM_BUILD_ROOT -type f -name '*.bs' -size 0 -exec rm -f {} \;
+
+%{_fixperms} $RPM_BUILD_ROOT/*
+
+%check
+make test
+
+%files
+%doc Changes README
+%{perl_vendorarch}/auto/URI*
+%{perl_vendorarch}/URI*
+%{_mandir}/man3/*
+
+%changelog
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-3
+- Change perl(Carp) from a BR to a R
+
+* Tue Mar 05 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-2
+- Take into account comments of review (#916670)
+
+* Thu Feb 28 2013 Emmanuel Seyman emman...@seyman.fr - 0.10-1
+- Update to 0.10
+
+* Mon Aug 13 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr - 0.09-1
+- Update to 0.09
+
+* Mon Jul 30 2012 Emmanuel Seyman emmanuel.sey...@club-internet.fr 0.08-1
+- Specfile autogenerated by cpanspec 1.78.
diff --git a/sources b/sources
index e69de29..23caf82 100644
--- a/sources
+++ b/sources
@@ -0,0 +1 @@
+23453334534498de37a758de3b077793 URI-Escape-XS-0.10.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
