Re: Yubikey single-factor authentication disabled

[Juan Orti Alcaine]

2013/3/7 Clive Hills 

> 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

[Petr Pisar]

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

[Petr Pisar]

commit 0e21b1f7ef329458d0e8ca8aa30ba6e17e481455
Author: Petr Písař 
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  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)

[Jan Kratochvil]

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:
 <1><62c6>: Abbrev Number: 58 (DW_TAG_subprogram)
<62c7>   DW_AT_name: (indirect string, offset: 0x3eb4): 
setprocattrcon
<62d2>   DW_AT_inline  : 1  (inlined)
 <1><6791>: 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)

[Mark Wielaard]

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:
>  <1><62c6>: Abbrev Number: 58 (DW_TAG_subprogram)
> <62c7>   DW_AT_name: (indirect string, offset: 0x3eb4): 
> setprocattrcon
> <62d2>   DW_AT_inline  : 1  (inlined)
>  <1><6791>: 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

[Jaroslav Reznik]

- Original Message -
> On Wed, Mar 6, 2013 at 7:15 PM, Adam Williamson 
> 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

[Jitka Plesnikova]

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)

[Richard W.M. Jones]

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:
> >  <1><62c6>: Abbrev Number: 58 (DW_TAG_subprogram)
> > <62c7>   DW_AT_name: (indirect string, offset: 0x3eb4): 
> > setprocattrcon
> > <62d2>   DW_AT_inline  : 1  (inlined)
> >  <1><6791>: 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=, 
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)

[Richard W.M. Jones]

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=, 
> 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

[Vít Ondruch]

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

[Kay Sievers]

On Wed, Mar 6, 2013 at 5:28 PM,   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  part of 
> pp 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

[Vít Ondruch]

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)

[Jan Kratochvil]

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=, 
attr=attr@entry=0x77bd11f6 "sockcreate", pid=0) at procattr.c:274
#3  0x77bc2ddc in setsockcreatecon (c=) 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

 <2><37e>: Abbrev Number: 21 (DW_TAG_GNU_call_site)
<37f>   DW_AT_low_pc  : 0x400818
<387>   DW_AT_abstract_origin: <0x515>
 <1><515>: 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

[Mark Bidewell]

On Wed, Mar 6, 2013 at 10:03 PM, Adam Williamson wrote:

> 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/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

[Darryl L. Pierce]

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 
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

[Darryl L. Pierce]

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 
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)

[Mark Wielaard]

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=, 
> attr=attr@entry=0x77bd11f6 "sockcreate", pid=0) at procattr.c:274
> #3  0x77bc2ddc in setsockcreatecon (c=) 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)

[Jan Kratochvil]

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)

[Richard W.M. Jones]

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=, 
> > attr=attr@entry=0x77bd11f6 "sockcreate", pid=0) at procattr.c:274
> > #3  0x77bc2ddc in setsockcreatecon (c=) 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

[James Laska]

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

[Vít Ondruch]

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

[Richard W.M. Jones]

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

[Petr Lautrbach]

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 , Red Hat, Inc.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fwd: problem with extended attributes

[Reindl Harald]

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 
Antwort an: Community support for Fedora users 
Organisation: the lounge interactive design
An: Mailing-List fedora-users 

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

[Tim Flink]

---
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

[Kevin Fenzi]

On Thu, 7 Mar 2013 07:09:13 +
Clive Hills  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

[Kevin Fenzi]

On Wed, 06 Mar 2013 21:07:45 -0800
Adam Williamson  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

[Jan Zelený]

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

[Toshio Kuratomi]

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

[Chris Adams]

Once upon a time, Toshio Kuratomi  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 
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

[Chris Wright]

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?

[Stephan Bergmann]

Building LibreOffice for x86_64 starting to fail in an odd way recently, 
, 
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?

[Jon Ciesla]

On Thu, Mar 7, 2013 at 1:28 PM, Stephan Bergmann wrote:

> Building LibreOffice for x86_64 starting to fail in an odd way recently, <
> http://koji.fedoraproject.**org/koji/getfile?taskID=**
> 5091173&name=build.log&offset=**-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/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

[Nicolas Mailhot]

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"

[Sandro Mani]

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 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?

[Stephan Bergmann]

On 03/07/2013 08:31 PM, Jon Ciesla wrote:

On Thu, Mar 7, 2013 at 1:28 PM, Stephan Bergmann mailto:sberg...@redhat.com>> wrote:

Building LibreOffice for x86_64 starting to fail in an odd way
recently,

>,
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, 
 " 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

[James Laska]

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"

[Michael Schwendt]

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  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

[Emmanuel Seyman]

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.

[Emmanuel Seyman]

commit ed5c6653106508d7247fa475538377f7578b2559
Author: Emmanuel Seyman 
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  - 0.10-3
+- Change perl(Carp) from a BR to a R
+
+* Tue Mar 05 2013 Emmanuel Seyman  - 0.10-2
+- Take into account comments of review (#916670)
+
+* Thu Feb 28 2013 Emmanuel Seyman  - 0.10-1
+- Update to 0.10
+
+* Mon Aug 13 2012 Emmanuel Seyman  - 0.09-1
+- Update to 0.09
+
+* Mon Jul 30 2012 Emmanuel Seyman  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"

[Sandro Mani]

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  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"

[Michael Schwendt]

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  >> 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"

[Sandro Mani]

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  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

[Adam Williamson]

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

[Adam Williamson]

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

[Rahul Sundaram]

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

[Rahul Sundaram]

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

[Rahul Sundaram]

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"

[Yanko Kaneti]

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

[Michael Schwendt]

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

[inode0]

On Thu, Mar 7, 2013 at 5:17 PM, Rahul Sundaram  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

[Sérgio Basto]

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?

[Kevin Fenzi]

I see all the various desktop envs install the 'dial-up' group, which
has: 

  ppp
  isdn4k-utils
  linux-atm
  lrzsz
  minicom
  ModemManager
  rp-pppoe
  wvdial
  efax
  pptp
  statserial

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?

[Kenneth Marcy]

On 3/7/2013 8:50 PM, Kevin Fenzi wrote:

I see all the various desktop envs install the 'dial-up' group, which
has:

   ppp
   isdn4k-utils
   linux-atm
   lrzsz
   minicom
   ModemManager
   rp-pppoe
   wvdial
   efax
   pptp
   statserial

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

[Rahul Sundaram]

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