date:20120313

Why we need redhat_lsb_trigger.c in redhat-lsb package?

2012-03-13 Thread Xibo Ning


Hi,
Do we really need a fineness c program to make symbol link? In 
redhat-lsb.spec, we can see:

gcc $RPM_OPT_FLAGS -Os -static -fno-stack-protector -o
redhat_lsb_trigger{.%{_target_cpu},.c} -DLSBSOVER='%{lsbsover}' \
  -DLDSO='%{ldso}' -DLSBLDSO='/%{_lib}/%{lsbldso}' -D_GNU_SOURCE
install -m 700 redhat_lsb_trigger.%{_target_cpu} \
  $RPM_BUILD_ROOT%{_sbindir}/redhat_lsb_trigger.%{_target_cpu}

%triggerpostun -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.%{_target_cpu} ]; then
  /usr/sbin/redhat_lsb_trigger.%{_target_cpu}
fi

And in redhat_lsb_trigger.c, the main function is as follows:

int main (int argc, char **argv)
{
/* redhat_lsb_trigger.c:428: warning: unused variable 'ret' */
/*  long ret; */
  INTERNAL_SYSCALL_DECL (err);
  char lsbsover[] = LSBSOVER;
  char *LSBVER, *p = lsbsover;
  while ((LSBVER = strtok (p,  \t)) != NULL)
{
  char buf[sizeof LSBLDSO + 1 + strlen (LSBVER)];
  p = buf;
  p = mempcpy (p, LSBLDSO, sizeof LSBLDSO - 1);
  *p++ = '.';
  strcpy (p, LSBVER);
  if (is_ia64 ())
INTERNAL_SYSCALL (symlink, err, 2, /emul/ia32-linux/lib/ 
LDSO, buf);

  else
INTERNAL_SYSCALL (symlink, err, 2, LDSO, buf);
  p = NULL;
}
  INTERNAL_SYSCALL (exit, err, 1, 0);
  return 110;
}

Why need we use a manually c program, not sln command? We can copy a 
copy of sln, so we can use it even when glibc is removed.


Why?

Thanks alot
xning
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Why we need redhat_lsb_trigger.c in redhat-lsb package?

2012-03-13 Thread Xibo Ning


On 03/13/2012 02:04 PM, Xibo Ning wrote:

Hi,
Do we really need a fineness c program to make symbol link? In
redhat-lsb.spec, we can see:
gcc $RPM_OPT_FLAGS -Os -static -fno-stack-protector -o
redhat_lsb_trigger{.%{_target_cpu},.c} -DLSBSOVER='%{lsbsover}' \
-DLDSO='%{ldso}' -DLSBLDSO='/%{_lib}/%{lsbldso}' -D_GNU_SOURCE
install -m 700 redhat_lsb_trigger.%{_target_cpu} \
$RPM_BUILD_ROOT%{_sbindir}/redhat_lsb_trigger.%{_target_cpu}

%triggerpostun -- glibc
if [ -x /usr/sbin/redhat_lsb_trigger.%{_target_cpu} ]; then
/usr/sbin/redhat_lsb_trigger.%{_target_cpu}
fi

And in redhat_lsb_trigger.c, the main function is as follows:

int main (int argc, char **argv)
{
/* redhat_lsb_trigger.c:428: warning: unused variable 'ret' */
/* long ret; */
INTERNAL_SYSCALL_DECL (err);
char lsbsover[] = LSBSOVER;
char *LSBVER, *p = lsbsover;
while ((LSBVER = strtok (p,  \t)) != NULL)
{
char buf[sizeof LSBLDSO + 1 + strlen (LSBVER)];
p = buf;
p = mempcpy (p, LSBLDSO, sizeof LSBLDSO - 1);
*p++ = '.';
strcpy (p, LSBVER);
if (is_ia64 ())
INTERNAL_SYSCALL (symlink, err, 2, /emul/ia32-linux/lib/ LDSO, buf);
else
INTERNAL_SYSCALL (symlink, err, 2, LDSO, buf);
p = NULL;
}
INTERNAL_SYSCALL (exit, err, 1, 0);
return 110;
}

Why need we use a manually c program, not sln command? We can copy a
copy of sln, so we can use it even when glibc is removed.

Why?

Thanks alot
xning


#ifdef __sparc__
register void *__thread_self __asm (g7);
#endif
#include unistd.h
#include string.h
#include fcntl.h
#include syscall.h

#if defined __i386__
# define INTERNAL_SYSCALL_DECL(err) do { } while (0)
# define INTERNAL_SYSCALL(name, err, nr, args...) \
  ({	  \
register unsigned int resultvar;	  \
asm volatile (			  \
movl %1, %%eax\n\t		  \
int $0x80\n\t			  \
: =a (resultvar)			  \
: i (__NR_##name) ASMFMT_##nr(args) : memory, cc);		  \
(int) resultvar; })
# define INTERNAL_SYSCALL_ERROR_P(val, err) \
  ((unsigned int) (val) = 0xf001u)
# define ASMFMT_0()
# define ASMFMT_1(arg1) \
	, b (arg1)
# define ASMFMT_2(arg1, arg2) \
	, b (arg1), c (arg2)
# define ASMFMT_3(arg1, arg2, arg3) \
	, b (arg1), c (arg2), d (arg3)
#elif defined __x86_64__
# define INTERNAL_SYSCALL_DECL(err) do { } while (0)
# define INTERNAL_SYSCALL_NCS(name, err, nr, args...) \
  ({	  \
unsigned long resultvar;		  \
LOAD_ARGS_##nr (args)		  \
LOAD_REGS_##nr			  \
asm volatile (			  \
syscall\n\t			  \
: =a (resultvar)			  \
: 0 (name) ASM_ARGS_##nr : memory, cc, r11, cx);		  \
(long) resultvar; })
# define INTERNAL_SYSCALL(name, err, nr, args...) \
  INTERNAL_SYSCALL_NCS (__NR_##name, err, nr, ##args)
# define INTERNAL_SYSCALL_ERROR_P(val, err) \
  ((unsigned long) (val) = -4095L)
# define LOAD_ARGS_0()
# define LOAD_REGS_0
# define ASM_ARGS_0
# define LOAD_ARGS_1(a1)\
  long int __arg1 = (long) (a1);			\
  LOAD_ARGS_0 ()
# define LOAD_REGS_1	\
  register long int _a1 asm (rdi) = __arg1;		\
  LOAD_REGS_0
# define ASM_ARGS_1	ASM_ARGS_0, r (_a1)
# define LOAD_ARGS_2(a1, a2)\
  long int __arg2 = (long) (a2);			\
  LOAD_ARGS_1 (a1)
# define LOAD_REGS_2	\
  register long int _a2 asm (rsi) = __arg2;		\
  LOAD_REGS_1
# define ASM_ARGS_2	ASM_ARGS_1, r (_a2)
# define LOAD_ARGS_3(a1, a2, a3)			\
  long int __arg3 = (long) (a3);			\
  LOAD_ARGS_2 (a1, a2)
# define LOAD_REGS_3	\
  register long int _a3 asm (rdx) = __arg3;		\
  LOAD_REGS_2
# define ASM_ARGS_3	ASM_ARGS_2, r (_a3)
#elif defined __powerpc__
# define INTERNAL_SYSCALL_DECL(err) long int err
# define INTERNAL_SYSCALL_NCS(name, err, nr, args...) \
  ({	\
register long int r0  __asm__ (r0);\
register long int r3  __asm__ (r3);\
register long int r4  __asm__ (r4);\
register long int r5  __asm__ (r5);\
register long int r6  __asm__ (r6);\
register long int r7  __asm__ (r7);\
register long int r8  __asm__ (r8);\
LOADARGS_##nr(name, args);		\
__asm__ __volatile__		\
  (sc\n\t\
   mfcr  %0\n\t			\
   : =r (r0),			\
 =r (r3), =r (r4), =r (r5),\
 =r (r6), =r (r7), =r (r8)\
   : ASM_INPUT_##nr			\
   : r9, r10, r11, r12,	\
 cr0, ctr, memory);	\
	  err = r0;  \
(int) r3;  \
  })
# define INTERNAL_SYSCALL(name, err, nr, args...)			\
  INTERNAL_SYSCALL_NCS (__NR_##name, err, nr, ##args)
# define INTERNAL_SYSCALL_ERROR_P(val, err) \
  ((void) (val), __builtin_expect ((err)  (1  28), 0))
# define LOADARGS_0(name, dummy) \
	r0 = name
# define LOADARGS_1(name, __arg1) \
	long int arg1 = (long int) (__arg1); \
	LOADARGS_0(name, 0); \
	r3 = arg1
# define LOADARGS_2(name, __arg1, __arg2) \
	long int arg2 = (long int) (__arg2); \
	LOADARGS_1(name, __arg1); \
	r4 = arg2
# define LOADARGS_3(name, __arg1, __arg2, __arg3) \
	long int arg3 = (long int) (__arg3); \
	LOADARGS_2(name, __arg1, __arg2); \

Help with Mock error

2012-03-13 Thread Amit Saha


Hello:

I am in the process of building my first package [1], and have got most 
of it sorted. 'rpmbuild -ba' executes successfully with the current SPEC 
file[3].


However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob: 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file 
passes successfully).



[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm
[3] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec



I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

--
http://echorand.me

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Alec Leamas


On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got 
most of it sorted. 'rpmbuild -ba' executes successfully with the 
current SPEC file[3].


However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob: 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file 
passes successfully).



[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm
[3] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec



I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin. To 
verify, run rpmbuild -bi your spec, and look into 
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing 
actually installs


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Alec Leamas


On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got 
most of it sorted. 'rpmbuild -ba' executes successfully with the 
current SPEC file[3].


However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob: 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file 
passes successfully).



[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm
[3] 
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec



I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin. 
To verify, run rpmbuild -bi your spec, and look into 
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing 
actually installs


Oops... that should be Look into 
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Amit Saha


Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file
passes successfully).


[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm
[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec


I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit


The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs


Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...


Just checked it. It places the 'picloud' binary in 
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .


-Amit

--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Possible to access Koji build directory?

2012-03-13 Thread Richard W.M. Jones


I suspect the answer is 'no', but is is possible to access or download
the build directory of a failed build, on the Fedora Koji servers?

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: Help with Mock error

2012-03-13 Thread Alec Leamas


On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file
passes successfully).


[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm 


[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec 




I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit


The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs


Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...


Just checked it. It places the 'picloud' binary in 
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .


-Amit

What a mess... I think I would run a  mock build with the  
--no-cleanup-after flag, and then a mock --shell. This way you should be 
able to see what's built in mock in a similar way to rpmbuild -bi.

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to access Koji build directory?

2012-03-13 Thread Jan Kratochvil

On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
 
 I suspect the answer is 'no', but is is possible to access or download
 the build directory of a failed build, on the Fedora Koji servers?

GDB (and GCC) tar and uuencode their testsuite results into build.log:
* Mon Jun 21 2004 Andrew Cagney cag...@redhat.com1.200400607.4
- Tar/uuencode both the .sum and .log test results.

It is a bit hack, providing back also other files besides rpms would be great
but in fact it works well enough this way.

Using then a simple extraction script build.log - files (*.{sum,log}):

http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master


Regards,
Jan
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-03-13 Thread Chris Murphy

On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:

 Yes. I'm mostly working on the netinst isos, and right now if you take 
 that and dd it onto a USB stick, then insert that and hold down alt on 
 boot, you'll get a Mac install. Unfortunately, alpha ended up getting 
 built with a grub that dies on any Macs that don't have built-in 
 ethernet, so you may have some problems with that. The alpha kernel also 
 has a bug that seems to trigger on Macs that results in incredible 
 slowness. But other than that! Fixed kernel is in the archive now, and 
 I've just commited a fix for the grub bug.

Fedora-17-Beta-TC1-x86_64-netinst.iso. I'm getting the same problems as with 
alpha ISO.


Burned to DVD
--
Macbook Pro 4,1 (2008)
Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot, 
EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu
EFI Boot= Boots Mac OS X


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI Boot
*2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD icon.

Windows=Boots CSM/BIOS mode successfully
EFI Boot= Grub prompt, no menu
*EFI Boot= Grub prompt, no menu



dd to USB stick
--
Macbook Pro 4,1 (2008)
Three additional USB icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.

EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine


Macbook Pro 8,2 (2011)
Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI Boot
*2nd icon is a custom Fedora logo icon, not generic USB icon.

EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force 
shutdown.
*EFI Boot= Grub prompt, no menu
EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must force 
shutdown.


Further, upon completion of CSM-BIOS installation, Fedora isn't bootable by 
default because a hybrid MBR hasn't been created, requiring manual post install 
work to make it bootable. Same situation as F16.
https://bugzilla.redhat.com/show_bug.cgi?id=746901


Chris Murphy
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Amit Saha


On 03/13/2012 07:48 PM, Alec Leamas wrote:

On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC file
passes successfully).


[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm

[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec



I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit


The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs


Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...


Just checked it. It places the 'picloud' binary in
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .

-Amit


What a mess... I think I would run a mock build with the
--no-cleanup-after flag, and then a mock --shell. This way you should be
able to see what's built in mock in a similar way to rpmbuild -bi.


I did that. I think I should expect to see 'picloud' in /usr/bin and the 
man pages in /usr/share/man/man1/ ? I don't see any of after i do mock 
--shell.


From the build.log, the last few lines are:

+ cp -pr doc README.txt CHANGELOG 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2

+ exit 0
RPM build errors:
File not found by glob: 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1


So, obviously something is wrong. What else I can look into?

Thanks!
-Amit








--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F16 problems with git

2012-03-13 Thread Michał Piotrowski

Hi,

I noticed recently a worrying git behavior. I often do something like that:
git fsck --full
git gc
git push origin master | backup of the entire tree in tar archive

'git fsck' or 'git gc' sometimes causes damage to the repository ie:

$ git fsck --full
error: packed 694728b9fe62ad667f051a109c389403ffa0cb29 from
.git/objects/pack/pack-a4bae2576b36116f1962a5496674ea921eebb6c5.pack
is corrupt

This time, however, after 'git fsck' rerun I don't get this error
message, but in other cases, the repository is corrupted. Has anyone
noticed similar problems with git on F16?

-- 
Best regards,
Michal

http://eventhorizon.pl/
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Possible to access Koji build directory?

2012-03-13 Thread Richard W.M. Jones

On Tue, Mar 13, 2012 at 10:00:59AM +0100, Jan Kratochvil wrote:
 On Tue, 13 Mar 2012 09:45:22 +0100, Richard W.M. Jones wrote:
  
  I suspect the answer is 'no', but is is possible to access or download
  the build directory of a failed build, on the Fedora Koji servers?
 
 GDB (and GCC) tar and uuencode their testsuite results into build.log:
 * Mon Jun 21 2004 Andrew Cagney cag...@redhat.com1.200400607.4
 - Tar/uuencode both the .sum and .log test results.
 
 It is a bit hack, providing back also other files besides rpms would be great
 but in fact it works well enough this way.
 
 Using then a simple extraction script build.log - files (*.{sum,log}):
   
 http://git.jankratochvil.net/?p=nethome.git;a=blob_plain;f=bin/gdbunpack;hb=master

Neat trick, thanks :-)

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 Xen guests.
http://et.redhat.com/~rjones/virt-p2v
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Alec Leamas


On 03/13/2012 10:10 AM, Amit Saha wrote:

On 03/13/2012 07:48 PM, Alec Leamas wrote:

On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC 
file

passes successfully).


[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm 



[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec 





I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit


The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs


Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...


Just checked it. It places the 'picloud' binary in
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .

-Amit


What a mess... I think I would run a mock build with the
--no-cleanup-after flag, and then a mock --shell. This way you should be
able to see what's built in mock in a similar way to rpmbuild -bi.


I did that. I think I should expect to see 'picloud' in /usr/bin and 
the man pages in /usr/share/man/man1/ ? I don't see any of after i do 
mock --shell.

Yes, they should be there.


From the build.log, the last few lines are:

+ cp -pr doc README.txt CHANGELOG 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2

+ exit 0
RPM build errors:
File not found by glob: 
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1


So, obviously something is wrong. What else I can look into?

Thanks!
-Amit


I guess our common understanding is that the %install has failed... 
sometimes, the installation paths are wrong. Have you looked into the 
complete /builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386 tree 
to see if the %install has placed in other places there?


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

F-17 Branched report: 20120313 changes

2012-03-13 Thread Branched Report

Compose started at Tue Mar 13 08:15:07 UTC 2012

Broken deps for x86_64
--
[HippoDraw]
HippoDraw-devel-1.21.3-2.fc17.i686 requires python-numarray
HippoDraw-devel-1.21.3-2.fc17.x86_64 requires python-numarray
HippoDraw-python-1.21.3-2.fc17.x86_64 requires python-numarray
[aeolus-conductor]
aeolus-conductor-0.4.0-2.fc17.noarch requires ruby(abi) = 0:1.8
[aeolus-configserver]
aeolus-configserver-0.4.1-5.fc17.noarch requires ruby-nokogiri
[alexandria]
alexandria-0.6.8-2.fc17.1.noarch requires ruby(abi) = 0:1.8
[amsn]
amsn-0.98.4-9.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit)
[aunit]
aunit-2010-3.fc16.i686 requires libgnat-4.6.so
aunit-2010-3.fc16.x86_64 requires libgnat-4.6.so()(64bit)
[catfish]
catfish-engines-0.3.2-4.fc17.1.noarch requires pinot
[comoonics-cdsl-py]
comoonics-cdsl-py-0.2-19.noarch requires comoonics-base-py
[comoonics-cluster-py]
comoonics-cluster-py-0.1-25.noarch requires comoonics-base-py
[contextkit]
contextkit-0.5.15-2.fc15.i686 requires libcdb.so.1
contextkit-0.5.15-2.fc15.x86_64 requires libcdb.so.1()(64bit)
[couchdb]
couchdb-1.0.3-2.fc16.x86_64 requires libicuuc.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicui18n.so.46()(64bit)
couchdb-1.0.3-2.fc16.x86_64 requires libicudata.so.46()(64bit)
[dh-make]
dh-make-0.55-4.fc17.noarch requires debhelper
[empathy]
empathy-3.3.5-3.fc17.x86_64 requires telepathy-butterfly
empathy-3.3.5-3.fc17.x86_64 requires libtelepathy-farsight.so.0()(64bit)
empathy-3.3.5-3.fc17.x86_64 requires libgstfarsight-0.10.so.0()(64bit)
[eruby]
eruby-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit)
eruby-libs-1.0.5-17.fc17.i686 requires ruby(abi) = 0:1.8
eruby-libs-1.0.5-17.fc17.i686 requires libruby.so.1.8
eruby-libs-1.0.5-17.fc17.x86_64 requires ruby(abi) = 0:1.8
eruby-libs-1.0.5-17.fc17.x86_64 requires libruby.so.1.8()(64bit)
[gajim]
gajim-0.15-0.4.beta4.fc17.noarch requires farsight2-python
[ganyremote]
ganyremote-5.13-2.fc17.noarch requires bluez-utils = 0:3.35
[gcc-python-plugin]
gcc-python2-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python2-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
gcc-python3-debug-plugin-0.9-1.fc17.x86_64 requires gcc = 
0:4.7.0-0.10.fc17
gcc-python3-plugin-0.9-1.fc17.x86_64 requires gcc = 0:4.7.0-0.10.fc17
[gdal]
gdal-ruby-1.7.3-12.fc17.x86_64 requires libruby.so.1.8()(64bit)
[gearmand]
gearmand-0.23-2.fc17.x86_64 requires libtcmalloc.so.0()(64bit)
gearmand-0.23-2.fc17.x86_64 requires libmemcached.so.8()(64bit)
gearmand-0.23-2.fc17.x86_64 requires 
libboost_program_options-mt.so.1.47.0()(64bit)
[genius]
genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit)
gnome-genius-1.0.12-2.fc15.x86_64 requires libgmp.so.3()(64bit)
[gnatcoll]
gnatcoll-2011-6.fc17.i686 requires libgnat-4.6.so
gnatcoll-2011-6.fc17.i686 requires libgnarl-4.6.so
gnatcoll-2011-6.fc17.x86_64 requires libgnat-4.6.so()(64bit)
gnatcoll-2011-6.fc17.x86_64 requires libgnarl-4.6.so()(64bit)
[gnome-phone-manager]
gnome-phone-manager-0.66-9.fc17.x86_64 requires 
libgnome-bluetooth.so.9()(64bit)
[gnome-user-share]
gnome-user-share-3.0.1-3.fc17.x86_64 requires 
libgnome-bluetooth.so.9()(64bit)
[gorm]
gorm-1.2.13-0.2.20110331.fc17.i686 requires libobjc.so.3
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-gui.so.0.20
gorm-1.2.13-0.2.20110331.fc17.i686 requires libgnustep-base.so.1.23
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires libobjc.so.3()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-gui.so.0.20()(64bit)
gorm-1.2.13-0.2.20110331.fc17.x86_64 requires 
libgnustep-base.so.1.23()(64bit)
[gphpedit]
gphpedit-0.9.95-0.2.20090209snap.fc15.x86_64 requires 
libgtkhtml-2.so.0()(64bit)
[gpsdrive]
gpsdrive-2.11-10.fc17.x86_64 requires libmapnik.so.0.7()(64bit)
gpsdrive-2.11-10.fc17.x86_64 requires 
libboost_thread-mt.so.1.47.0()(64bit)
gpsdrive-2.11-10.fc17.x86_64 requires 
libboost_system-mt.so.1.47.0()(64bit)
gpsdrive-2.11-10.fc17.x86_64 requires 
libboost_filesystem-mt.so.1.47.0()(64bit)
[gscribble]
gscribble-0.1.2-2.fc17.noarch requires gnome-python2-gtkhtml2
[i3]
i3-4.0.1-2.fc17.x86_64 requires libxcb-property.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-keysyms.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-icccm.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-event.so.1()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-aux.so.0()(64bit)
i3-4.0.1-2.fc17.x86_64 requires libxcb-atom.so.1()(64bit)
[kanyremote]

Re: Help with Mock error

2012-03-13 Thread Mathieu Bridon

On Tue, 2012-03-13 at 20:10 +1100, Amit Saha wrote:
 From the build.log, the last few lines are:
 
 + cp -pr doc README.txt CHANGELOG 
 /builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2
 + exit 0
 RPM build errors:
  File not found by glob: 
 /builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
 Child return code was: 1
 
 
 So, obviously something is wrong. What else I can look into?

You could paste the full build.log somewhere.


-- 
Mathieu


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Amit Saha

On 03/13/2012 09:17 PM, Alec Leamas wrote:

On 03/13/2012 10:10 AM, Amit Saha wrote:

On 03/13/2012 07:48 PM, Alec Leamas wrote:

On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC
file
passes successfully).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm

[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec

I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

The spec most likely doesn't put anything in $RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs

Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...

Just checked it. It places the 'picloud' binary in
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .

-Amit

What a mess... I think I would run a mock build with the
--no-cleanup-after flag, and then a mock --shell. This way you should be
able to see what's built in mock in a similar way to rpmbuild -bi.

I did that. I think I should expect to see 'picloud' in /usr/bin and
the man pages in /usr/share/man/man1/ ? I don't see any of after i do
mock --shell.

Yes, they should be there.

From the build.log, the last few lines are:

+ cp -pr doc README.txt CHANGELOG
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2

+ exit 0
RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

So, obviously something is wrong. What else I can look into?

Thanks!
-Amit

I guess our common understanding is that the %install has failed...
sometimes, the installation paths are wrong. Have you looked into the
complete /builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386 tree
to see if the %install has placed in other places there?

I see that the bash_completion file has been placed in
etc/bash_completion.d directory and the man page has also been copied in
usr/share/man/man1

So, the install step is obviously failing in mock.

Here is the complete build.log file: https://gist.github.com/2028090

Hope something can be identified.

Many thanks!
-Amit

--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Alec Leamas

On 03/13/2012 11:55 AM, Amit Saha wrote:

On 03/13/2012 09:17 PM, Alec Leamas wrote:

On 03/13/2012 10:10 AM, Amit Saha wrote:

On 03/13/2012 07:48 PM, Alec Leamas wrote:

On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC
file
passes successfully).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm

[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec

I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

The spec most likely doesn't put anything in
$RPM_BUILD_ROOT/usr/bin.

To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs

Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...

Just checked it. It places the 'picloud' binary in
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .

-Amit

What a mess... I think I would run a mock build with the
--no-cleanup-after flag, and then a mock --shell. This way you
should be

able to see what's built in mock in a similar way to rpmbuild -bi.

I did that. I think I should expect to see 'picloud' in /usr/bin and
the man pages in /usr/share/man/man1/ ? I don't see any of after i do
mock --shell.

Yes, they should be there.

From the build.log, the last few lines are:

+ cp -pr doc README.txt CHANGELOG
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2

+ exit 0
RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

So, obviously something is wrong. What else I can look into?

Thanks!
-Amit

I see that the bash_completion file has been placed in
etc/bash_completion.d directory and the man page has also been copied
in usr/share/man/man1

So, the install step is obviously failing in mock.

Here is the complete build.log file: https://gist.github.com/2028090

Hope something can be identified.

Many thanks!
-Amit

Basically, this beats me. An educated guess is that something in your
own environment makes %install work when using rpmbuild. I note there
are some warnings when running setup.py...

Hopefully, someone who knows this python stuff kan give you some advice
(that person is certainly not me, sorry :) )

--a
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Amit Saha

On 03/13/2012 10:45 PM, Alec Leamas wrote:

On 03/13/2012 11:55 AM, Amit Saha wrote:

On 03/13/2012 09:17 PM, Alec Leamas wrote:

On 03/13/2012 10:10 AM, Amit Saha wrote:

On 03/13/2012 07:48 PM, Alec Leamas wrote:

On 03/13/2012 08:58 AM, Amit Saha wrote:

Hello:

On 03/13/2012 06:50 PM, Alec Leamas wrote:

On 03/13/2012 08:43 AM, Alec Leamas wrote:

On 03/13/2012 07:21 AM, Amit Saha wrote:

Hello:

I am in the process of building my first package [1], and have got
most of it sorted. 'rpmbuild -ba' executes successfully with the
current SPEC file[3].

However, the SRPM [2] fails in Mock with the error:

RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*

Child return code was: 1

I am not sure why? (Having the incorrect %{_bindir}/ in the SPEC
file
passes successfully).

[1] https://bugzilla.redhat.com/show_bug.cgi?id=799810
[2]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud-2.4.2-3.fc16.src.rpm

[3]
http://amitksaha.fedorapeople.org/contribs/picloud_packaging/python-picloud.spec

I am probably missing something very basic here. Kindly suggest.

Thanks!
Amit

The spec most likely doesn't put anything in
$RPM_BUILD_ROOT/usr/bin.
To verify, run rpmbuild -bi your spec, and look into
~/rpmbuild/BUILD/python-picloud-2.4.2* to find out what the thing
actually installs

Oops... that should be Look into
~/rpmbuild/BUILDROOT/python-picloud-2.4.2* to find out...

Just checked it. It places the 'picloud' binary in
~/rpmbuild/BUILDROOT/python-picloud-2.4.2-3.fc16/usr/bin .

-Amit

What a mess... I think I would run a mock build with the
--no-cleanup-after flag, and then a mock --shell. This way you
should be
able to see what's built in mock in a similar way to rpmbuild -bi.

I did that. I think I should expect to see 'picloud' in /usr/bin and
the man pages in /usr/share/man/man1/ ? I don't see any of after i do
mock --shell.

Yes, they should be there.

From the build.log, the last few lines are:

+ cp -pr doc README.txt CHANGELOG
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/share/doc/python-picloud-2.4.2

+ exit 0
RPM build errors:
File not found by glob:
/builddir/build/BUILDROOT/python-picloud-2.4.2-3.fc16.i386/usr/bin/*
Child return code was: 1

So, obviously something is wrong. What else I can look into?

Thanks!
-Amit

I see that the bash_completion file has been placed in
etc/bash_completion.d directory and the man page has also been copied
in usr/share/man/man1

So, the install step is obviously failing in mock.

Here is the complete build.log file: https://gist.github.com/2028090

Hope something can be identified.

Many thanks!
-Amit

Basically, this beats me. An educated guess is that something in your
own environment makes %install work when using rpmbuild. I note there
are some warnings when running setup.py...

Yes, the setup.py attempts to do a direct copy of the man and the bash
completion files to /usr/share and /etc/ sub-dirs respectively. (I think
i will patch it in the SPEC to work around this).

Hopefully, someone who knows this python stuff kan give you some advice
(that person is certainly not me, sorry :) )

Thank you for looking into this. I hope somebody can help.

Best,
Amit

--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-03-13 Thread Andreas Tunek

Thanks for all your testing! It certainly seems like Fedora has quite a way
to go before it is possible to install on clean macs.

Have you done any testing using refit, or is this all with vanilla apple
efi?
On Mar 13, 2012 10:06 AM, Chris Murphy li...@colorremedies.com wrote:

 On Feb 28, 2012, at 12:53 PM, Matthew Garrett wrote:

  Yes. I'm mostly working on the netinst isos, and right now if you take
  that and dd it onto a USB stick, then insert that and hold down alt on
  boot, you'll get a Mac install. Unfortunately, alpha ended up getting
  built with a grub that dies on any Macs that don't have built-in
  ethernet, so you may have some problems with that. The alpha kernel also
  has a bug that seems to trigger on Macs that results in incredible
  slowness. But other than that! Fixed kernel is in the archive now, and
  I've just commited a fix for the grub bug.

 Fedora-17-Beta-TC1-x86_64-netinst.iso. I'm getting the same problems as
with alpha ISO.


 Burned to DVD
 --
 Macbook Pro 4,1 (2008)
 Four additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI
Boot, EFI Boot
 *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD
icon.

 Windows=Boots CSM/BIOS mode successfully
 EFI Boot= Grub prompt, no menu
 *EFI Boot= Grub prompt, no menu
 EFI Boot= Boots Mac OS X


 Macbook Pro 8,2 (2011)
 Three additional CD/DVD icon options labeled as: Windows, EFI Boot, EFI
Boot
 *2nd EFI Boot option has a custom Fedora logo icon, not generic CD/DVD
icon.

 Windows=Boots CSM/BIOS mode successfully
 EFI Boot= Grub prompt, no menu
 *EFI Boot= Grub prompt, no menu



 dd to USB stick
 --
 Macbook Pro 4,1 (2008)
 Three additional USB icon options labeled as: EFI Boot, EFI Boot, EFI Boot
 *2nd icon is a custom Fedora logo icon, not generic USB icon.

 EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine
 *EFI Boot= Grub prompt, no menu
 EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine


 Macbook Pro 8,2 (2011)
 Three additional CD/DVD icon options labeled as: EFI Boot, EFI Boot, EFI
Boot
 *2nd icon is a custom Fedora logo icon, not generic USB icon.

 EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must
force shutdown.
 *EFI Boot= Grub prompt, no menu
 EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must
force shutdown.


 Further, upon completion of CSM-BIOS installation, Fedora isn't bootable
by default because a hybrid MBR hasn't been created, requiring manual post
install work to make it bootable. Same situation as F16.
 https://bugzilla.redhat.com/show_bug.cgi?id=746901


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

Re: Help with Mock error

2012-03-13 Thread Mathieu Bridon

On Tue, 2012-03-13 at 22:48 +1100, Amit Saha wrote:
  Hopefully, someone who knows this python stuff kan give you some advice
  (that person is certainly not me, sorry :) )
 
 Thank you for looking into this. I hope somebody can help.

From your build.log:
--
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'entry_points'
  warnings.warn(msg)
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'install_requires'
  warnings.warn(msg)
--

Try adding BuildRequires: python-setuptools to your spec file.


-- 
Mathieu


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Notice: IPv6 breaking issues tentatively considered blocker for F17

2012-03-13 Thread Glen Turner

Hi,

I am the network engineer at Australia's Academic and Research Network
responsible for assisting the deployment of IPv6 across Australian
universities. Your posting was bought to my attention.

Your phrasing of the condition for blocking is pretty broad: there are
lots of ways to break IPv6, just as there are with IPv4, and just as
with IPv4 not all of them are significant enough to be blocking.

Can I suggest the following as a starting point:
 - failure in configuration of interface addresses with a link scope
address via stateless address autoconfiguration should block
 - failure in configuration of interface addresses with a global scope
via stateless address autoconfiguration should block
 - failure in configuration of interface addresses with a global scope
via manual configuration should block
 - failure in configuration of DNS forwarding via stateless DHCP6 should
block
 - failure in configuration of DNS forwarding via RAs should block
 - failure of connectivity of network ::1/128 (localhost) of all
services should block
 - failure of unicast or multicast connectivity of link local addressing
of allowed services should block
 - failure of unicast connectivity of global addressing of allowed
services should block
 - failure of connectivity of ICMP6 service for codes = 127 should
block

Non-stateless DHCP6 is primarily used by ISPs to configure customer
routers. Those routers present SLAAC to their downstream users.

Non-stateless DHCP6 is also used by enterprises who wish to parallel
their existing management of computers via IPv4 DHCP into IPv6. In my
view that is a poor network design choice, but there is no denying that
it is a choice made by some enterprise networks.

At this point in time you could deploy a IPv6 with manual configuration
and with SLAAC (with both stateless DHCP6 and RAs to configure DNS) and
make most people happy. The significance of the proportion of people
made unhappy may or may not be enough for a release blocking bug (as
opposed to simple lack of support for that IPv6 feature) -- that's
really your choice.

It also depends if statefull DHCP6 host configuration was supported in a
previous release, in that case a regression leads to such a complicated
scenario for network engineers and systems administrators that the bug
should be release blocking.

Cheers,
Glen

-- 
 Glen Turner http://www.gdt.id.au/~gdt/

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: How can we make F17 be able to boot on Macs (with or without reFit)

2012-03-13 Thread Matthew Garrett

On Tue, Mar 13, 2012 at 03:06:31AM -0600, Chris Murphy wrote:

 EFI Boot= Grub prompt, no menu

Can you type root and see what it says, followed by findiso and then 
root?

 EFI Boot= Grub menu, loads from stick for ~45 seconds then reboots machine

That'll be a kernel bug of some description...

 EFI Boot= Grub menu, loads from stick for ~6 seconds, then beeping, must 
 force shutdown.

This too. Can you try adding noefi to the kernel command line for 
both?

CSM boots aren't expected to work in the slightest.
-- 
Matthew Garrett | mj...@srcf.ucam.org
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: /etc/default in Fedora

2012-03-13 Thread James Antill

On Sat, 2012-03-10 at 18:20 +, Richard W.M. Jones wrote:
 'Course we could go further and rename /etc/httpd - /etc/apache (and
 rename the package, both matching Debian), which should have been done
 a long time ago.

 It used to be like that:

http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/ch-httpd.html#S2-HTTPD-V2-DIFF-RPM

...but upstream explicitly requested that we change it.

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Help with Mock error

2012-03-13 Thread Amit Saha


On 03/13/2012 11:10 PM, Mathieu Bridon wrote:

On Tue, 2012-03-13 at 22:48 +1100, Amit Saha wrote:

Hopefully, someone who knows this python stuff kan give you some advice
(that person is certainly not me, sorry :) )


Thank you for looking into this. I hope somebody can help.


 From your build.log:
--
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'entry_points'
   warnings.warn(msg)
/usr/lib/python2.7/distutils/dist.py:267: UserWarning: Unknown
distribution option: 'install_requires'
   warnings.warn(msg)
--

Try adding BuildRequires: python-setuptools to your spec file.




And it succeeds. Thanks a lot, Mathieu!

Best,
-Amit

--
http://echorand.me
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Non-free tarball checked in

2012-03-13 Thread Toshio Kuratomi

On Mon, Mar 12, 2012 at 12:21:52PM -0500, Jon Ciesla wrote:
 On Mon, Mar 12, 2012 at 12:17 PM, Mattia Verga mattia.ve...@tiscali.it 
 wrote:
 
  And what about for pre-built binary files contained in source that are not
  installed in the final rpm (ex. deleted in the %setup stage)? Should the
  source be purged from those?
 
 If the licensing is such that they can't be redistributed, yes.
 
And just to be clear for people who search the mailing list archives later:

* If the licensing is okay, the source tarball doesn't need to be repacked
  with those files excluded.
* The binaries (for a definition of binaries that includes code/executable
  content but not necessarily data) do need to be removed from the build
  environment in the %prep stage of the rpm build.

https://fedoraproject.org/wiki/Packaging:Guidelines#No_inclusion_of_pre-built_binaries_or_libraries

-Toshio


pgpb444lkazcA.pgp
Description: PGP signature
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: [Test-Announce] Test Day 2012-03-15: GNOME Shell and Extensions

2012-03-13 Thread Stephen Gallagher

On Mon, 2012-03-12 at 19:36 -0400, Matthias Clasen wrote:
 On Mon, 2012-03-12 at 11:07 -0400, Stephen Gallagher wrote:
 
  
  I know this should most likely be directed at upstream Gnome, but would
  it be possible to redesign extensions.gnome.org so that it's... usable?
  I mean, it's a list of extensions, ten to a page, ordered by popularity,
  name or number of downloads.
  
  Would it be so hard to add tags or categories of functionality? Right
  now, I have to read through fourteen pages (and growing!) to get any
  idea of whether an extension happens to provide a feature I might want.
  
  I like gnome-shell, and I'd like to tweak it a little bit to fit my
  needs better. But the extension website is so difficult to navigate that
  it's really a deterrent. It will only get worse as people continue to
  write new extensions (which, because of the default ordering of
  popularity will always show up in the later pages of the site first).
 
 Thanks for the feedback.
 
 We have recently added search to the website, and some other
 improvements may still land before we remove the 'alpha' label from it.
 
 If you want to report your problem in more detail, feel free to go to
 https://bugzilla.gnome.org/enter_bug.cgi?product=websitecomponent=extensions.gnome.org
 - or just walk by Jaspers desk.


Ask and ye shall receive:
https://bugzilla.gnome.org/show_bug.cgi?id=672008


signature.asc
Description: This is a digitally signed message part
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Weird koji/mock problem with libpng-devel

2012-03-13 Thread Richard Shaw

I'm trying to rebuild OpenImageIO for an updated dependency and I ran
into an issue. When I try to build it in koji or even on a local mock
build the build fails with a cmake error saying it couldn't find the
PNG library.

Looking in root.log in both cases shows that it was installed.

I did a mock --shell and then tried rpm -ql libpng-devel:

mock-chroot# rpm -ql libpng-devel
package libpng-devel is not installed

Intresting... root.log said it was installed.

Doing a mock --install libpng-devel a second time seems to fix it but
of course I can't do that on a koji build.

I also tried a straight mock --init, mock --install libpng-devel and
it works as expected, so this only appears to fail when it's getting
the BuildRequires: from the spec/srpm.

This is only happening on f16 as far as I can tell. Any ideas?

Thanks,
Richard
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

74 matches

Mail list logo