Unbootable machine
Hello Peter & Jeremy, I've found an ordinary desktop PC (with Phoenix Award BIOS 6.00PG) that won't boot off a USB stick created by livecd-tools-024 with syslinux (tested both versions 3.75 and 3.81). The boot process drops to the "boot:" prompt with an error message: could not find kernel image: linux The same USB stick boots fine on any other computer I could find. Does it seem like a syslinux bug? And if turns out to be a known BIOS bug, is there a good workaround? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unbootable machine
On 06/02/09 07:10, H. Peter Anvin wrote: > Bernie Innocenti wrote: >> Ok, I wiped mbr and made fdisk create a new one: >> >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 64 heads, 62 sectors/track, 1011 cylinders > ^^ > > Equally weird. The only "standard" ones are 64 heads, 32 sectors and > 255 heads, 63 sectors. Shouldn't fdisk guess these values automagically? And, more importantly, who are we going to blame if it doesn't? ;-) -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unbootable machine
On 06/02/09 13:48, Bernie Innocenti wrote: > On 06/02/09 07:10, H. Peter Anvin wrote: >> Bernie Innocenti wrote: >>> Ok, I wiped mbr and made fdisk create a new one: >>> >>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>> 64 heads, 62 sectors/track, 1011 cylinders >> ^^ >> >> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >> 255 heads, 63 sectors. > > Shouldn't fdisk guess these values automagically? > And, more importantly, who are we going to blame if it doesn't? ;-) For the record, GNU parted gets it right: ber...@giskard:~$ sudo dd if=/dev/zero of=/dev/sdb ^C5017+0 records in 5017+0 records out 2568704 bytes (2.6 MB) copied, 1.63415 s, 1.6 MB/s 130!ber...@giskard:~$ sudo parted /dev/sdb GNU Parted 1.8.8 Using /dev/sdb Welcome to GNU Parted! Type 'help' to view a list of commands. (parted) mklabel New disk label type? msdos (parted) unit chs (parted) print Model: USB DISK 2.0 (scsi) Disk /dev/sdb: 249,220,34 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 249,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Type File system Flags (parted) mkpart File system type? [ext2]? fat32 Start? 0 End? 100% Warning: You requested a partition from 0,0,0 to 249,220,34. The closest location we can manage is 0,1,0 to 248,254,62. Is this still acceptable to you? Yes/No? y (parted) p Model: USB DISK 2.0 (scsi) Disk /dev/sdb: 249,220,34 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 249,255,63. Each cylinder is 8225kB. Partition Table: msdos Number Start End Type File system Flags 1 0,1,0 248,254,62 primary lba -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unbootable machine
On 06/02/09 07:10, H. Peter Anvin wrote: > Bernie Innocenti wrote: >> On 06/02/09 03:43, H. Peter Anvin wrote: >>> Bernie Innocenti wrote: >>>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>>> 221 heads, 2 sectors/track, 9081 cylinders >>> I don't know where fdisk, the Linux kernel, or whatever come up with >>> these kinds of geometries. They're almost universally non-bootable. >> >> Ok, I wiped mbr and made fdisk create a new one: >> >> Disk /dev/sdb: 2055 MB, 2055208960 bytes >> 64 heads, 62 sectors/track, 1011 cylinders > ^^ > > Equally weird. The only "standard" ones are 64 heads, 32 sectors and > 255 heads, 63 sectors. Indeed, repartitioning the USB stick with 32 sectors and 255 heads fixed boot for a previously unbootable computer. Thanks, Peter. I think we should document this tip in the Sugar on a Stick wiki page and perhaps change the Fedora livecd-iso-to-disk script to create the MBR with parted rather than fdisk. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Unbootable machine
On 06/04/09 20:51, H. Peter Anvin wrote: > Bernie Innocenti wrote: >>> >>> Equally weird. The only "standard" ones are 64 heads, 32 sectors and >>> 255 heads, 63 sectors. >> >> Indeed, repartitioning the USB stick with 32 sectors and 255 heads fixed >> boot for a previously unbootable computer. >> > > 32x255? That's an odd mix? Does 32x64 work on that machine, too? Sorry, I mistyped the numbers. It was really 255 heads, 63 sectors: (parted) p Model: LEXAR JD EXPRESSION (scsi) Disk /dev/sdb: 123,86,26 Sector size (logical/physical): 512B/512B BIOS cylinder,head,sector geometry: 123,255,63. Each cylinder is 8225kB. Partition Table: msdos -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Can we import dia 0.97 in rawhide?
It's been released here: http://projects.gnome.org/dia/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Can we import dia 0.97 in rawhide?
On Wed, 2009-07-08 at 11:36 -0700, Conrad Meyer wrote: > File a bug. Found one already filed here: https://bugzilla.redhat.com/show_bug.cgi?id=502870 -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > devtodo-0.1.20-3.fc12 I maintain this package in Fedora. Just wrote the author asking for a clarification on licensing. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: readline update?
On Thu, 2009-07-09 at 01:14 +0200, Bernie Innocenti wrote: > On Fri, 2009-07-03 at 12:27 +0200, Miroslav Lichvar wrote: > > devtodo-0.1.20-3.fc12 > > I maintain this package in Fedora. Just wrote the author asking for a > clarification on licensing. FYI, I got this reply: Forwarded Message From: Alec Thomas To: Bernie Innocenti Subject: Re: License clarification for devtodo Date: Thu, 9 Jul 2009 12:02:04 +1000 I haven't looked at the GPLv3 to determine whether I'd actually want to license devtodo under it, but I'll take a look when I get a chance. Unfortunately I'm going on holidays for a month, so likely won't be able to until mid-August or so. 2009/7/9 Bernie Innocenti : > Hello, > > I'm packaging devtodo in Fedora. We can't link it against readline 6 > because it is GPLv3 and devtodo appears to be GPLv2 only. > > Is that right? If your intention actually was to make devtodo GPLv2 or > later, could you please release an updated source package with this fact > explained explicitly? > > -- > // Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
Hello, > I'm running into a problem with Fedora 11 and OpenLDAP's slapd > instance (the same configuration that I've used for F8, F9, F10 and > now F11). > > After a day or two, of continuous usage, the slapd instance hangs with the > "too many open files" issue. I googled around a bit and found that some have > fixed the problem by adding the following line to slapd.conf: > > # Disconnect idle connections > idletimeout 60 > > This doesn't really seem to make a difference. When I do "lsof -u ldap", > I get the normal output of files in mem, followed by a ton of these: > > ... > ... > slapd 19221 ldap 37r REG 8,51235360 418680 /lib64/libnspr4.so > slapd 19221 ldap 38r REG 8,51235360 418680 /lib64/libnspr4.so > slapd 19221 ldap 39r REG 8,51235360 418680 /lib64/libnspr4.so > slapd 19221 ldap 40r REG 8,51235360 418680 /lib64/libnspr4.so > ... > ... > > that never seem to go away, and lead to the "too many open files" issue. > > Can anyone offer some assistance as to how to fix this issue? Thank you in > advance. -Anthony Did you eventually solve this issue? If not, is there a bug already filed in Bugzilla? I'm still seeing exactly the same on F11 with all updates installed as of today. I'd be tempted to point fingers at nss-softokn-freebl, as this is where the code to ope libnspr4.so actually lives. Upgrading openldap-servers and to rawhide has no effect. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
El Mon, 10-08-2009 a las 02:08 +0200, Bernie Innocenti escribió: > I'm still seeing exactly the same on F11 with all updates installed > as of today. I'd be tempted to point fingers at nss-softokn-freebl, > as this is where the code to ope libnspr4.so actually lives. > Upgrading openldap-servers and to rawhide has no effect. Disabling ldaps:/// makes the problem go away. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
El Mon, 10-08-2009 a las 02:15 +0200, Bernie Innocenti escribió: > El Mon, 10-08-2009 a las 02:08 +0200, Bernie Innocenti escribió: > > I'm still seeing exactly the same on F11 with all updates installed > > as of today. I'd be tempted to point fingers at nss-softokn-freebl, > > as this is where the code to ope libnspr4.so actually lives. > > Upgrading openldap-servers and to rawhide has no effect. > > Disabling ldaps:/// makes the problem go away. No, it doesn't. I just didn't wait long enough. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: enigmail for F-11's thunderbird ?
El Sat, 08-08-2009 a las 12:03 -0400, Mail Lists escribió: > On 08/08/2009 07:38 AM, Frank Murphy (Frankly3D) wrote: > > On 08/08/09 12:39, Gregory Hosler wrote: > >> Hi all, > >> > > > > Works fine for me. > > Did you get TB from Mozilla? > > > > I believe enigmail is setup fro the Fedora packaged version of TB, > > which is on TB 3 Beta2 > > > > I am using stock F11 tb and enigmail from rpmfusion on x64 - and it > does NOT work. It says 'not compatible'. Why is thunderbird-enigmail in rpfusion-free rather than fedora proper? Actually, why does rpmfusion-free even exist? A cheeky question, admittedly, but I'm honestly curious. > Since the mozilla builds do not provide x64 (which is a shame 64 bit > are basically the baseline now with core 2) and the plugins are not 64 > bit I am not using them - but if you use the 32 bit mozilla tb and > enigmail nightly from mozilla - they do work. And here's another thing I've been wondering for years: why doesn't Mozilla provide Linux x86_64 builds? It should probably be asked on one of their lists, though. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
Ping? This bug is pretty nasty: we have to restart slapd 2 or 3 times a day :-/ El Mon, 10-08-2009 a las 02:08 +0200, Bernie Innocenti escribió: > Hello, > > > I'm running into a problem with Fedora 11 and OpenLDAP's slapd > > instance (the same configuration that I've used for F8, F9, F10 and > > now F11). > > > > After a day or two, of continuous usage, the slapd instance hangs with the > > "too many open files" issue. I googled around a bit and found that some > > have > > fixed the problem by adding the following line to slapd.conf: > > > > # Disconnect idle connections > > idletimeout 60 > > > > This doesn't really seem to make a difference. When I do "lsof -u ldap", > > I get the normal output of files in mem, followed by a ton of these: > > > > ... > > ... > > slapd 19221 ldap 37r REG 8,51235360 418680 /lib64/libnspr4.so > > slapd 19221 ldap 38r REG 8,51235360 418680 /lib64/libnspr4.so > > slapd 19221 ldap 39r REG 8,51235360 418680 /lib64/libnspr4.so > > slapd 19221 ldap 40r REG 8,51235360 418680 /lib64/libnspr4.so > > ... > > ... > > > > that never seem to go away, and lead to the "too many open files" issue. > > > > Can anyone offer some assistance as to how to fix this issue? Thank you in > > advance. -Anthony > > Did you eventually solve this issue? If not, is there a bug > already filed in Bugzilla? > > I'm still seeing exactly the same on F11 with all updates installed > as of today. I'd be tempted to point fingers at nss-softokn-freebl, > as this is where the code to ope libnspr4.so actually lives. > Upgrading openldap-servers and to rawhide has no effect. > > -- >// Bernie Innocenti - http://codewiz.org/ > \X/ Sugar Labs - http://sugarlabs.org/ > > -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
El Thu, 13-08-2009 a las 07:12 +0200, Bernie Innocenti escribió:
> Ping?
>
> This bug is pretty nasty: we have to restart slapd
> 2 or 3 times a day :-/
Ok, I think I'm starting to see the light here, but perhaps
it's just because it's already dawn.
nss-3.12.3.99.3/mozilla/security/nss/lib/freebl/stubs.c
dlopen()s nspr4.so like so:
-8<--8<--8<--8<--8<-
#define freebl_getLibrary(libName) \
dlopen (libName, RTLD_LAZY|RTLD_NOLOAD)
#define freebl_releaseLibrary(lib) \
if (lib) dlclose(lib)
#endif
extern SECStatus
FREEBL_InitStubs()
{
SECStatus rv = SECSuccess;
#ifdef FREEBL_NO_WEAK
void *nspr = NULL;
void *nssutil = NULL;
/* NSPR should be first */
if (!ptr_PR_DestroyLock) {
nspr = freebl_getLibrary(nsprLibName);
if (!nspr) {
return SECFailure;
}
rv = freebl_InitNSPR(nspr);
if (rv != SECSuccess) {
freebl_releaseLibrary(nspr);
return rv;
}
}
/* now load NSSUTIL */
if (!ptr_SECITEM_ZfreeItem_Util) {
nssutil= freebl_getLibrary(nssutilLibName);
if (!nssutil) {
return SECFailure;
}
rv = freebl_InitNSSUtil(nssutil);
if (rv != SECSuccess) {
freebl_releaseLibrary(nssutil);
return rv;
}
}
#endif
return rv;
}
-8<--8<--8<--8<--8<-
There's no corresponding place in the code to call dlclose().
If slapd enters this multiple times (perhaps from multiple threads),
it might indeed leak file descriptors.
It remains to be determined what codepath in openldap does this.
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Fedora 11 slapd "too many open files": /lib64/libnspr4.so
El Thu, 13-08-2009 a las 07:56 +0200, Bernie Innocenti escribió:
> El Thu, 13-08-2009 a las 07:12 +0200, Bernie Innocenti escribió:
> > Ping?
> >
> > This bug is pretty nasty: we have to restart slapd
> > 2 or 3 times a day :-/
>
> Ok, I think I'm starting to see the light here, but perhaps
> it's just because it's already dawn.
>
> nss-3.12.3.99.3/mozilla/security/nss/lib/freebl/stubs.c
> dlopen()s nspr4.so like so:
>
> -8<--8<--8<--8<--8<-
> #define freebl_getLibrary(libName) \
> dlopen (libName, RTLD_LAZY|RTLD_NOLOAD)
>
> #define freebl_releaseLibrary(lib) \
> if (lib) dlclose(lib)
>
> #endif
>
> extern SECStatus
> FREEBL_InitStubs()
> {
> SECStatus rv = SECSuccess;
> #ifdef FREEBL_NO_WEAK
> void *nspr = NULL;
> void *nssutil = NULL;
>
> /* NSPR should be first */
> if (!ptr_PR_DestroyLock) {
> nspr = freebl_getLibrary(nsprLibName);
> if (!nspr) {
> return SECFailure;
> }
> rv = freebl_InitNSPR(nspr);
> if (rv != SECSuccess) {
> freebl_releaseLibrary(nspr);
> return rv;
> }
> }
> /* now load NSSUTIL */
> if (!ptr_SECITEM_ZfreeItem_Util) {
> nssutil= freebl_getLibrary(nssutilLibName);
> if (!nssutil) {
> return SECFailure;
> }
> rv = freebl_InitNSSUtil(nssutil);
> if (rv != SECSuccess) {
> freebl_releaseLibrary(nssutil);
> return rv;
> }
> }
> #endif
>
> return rv;
> }
> -8<--8<--8<--8<--8<-
>
> There's no corresponding place in the code to call dlclose().
> If slapd enters this multiple times (perhaps from multiple threads),
> it might indeed leak file descriptors.
>
> It remains to be determined what codepath in openldap does this.
Looks like the above code is being by this Fedora-specific patch carried
by the nss package:
-8<--8<--8<--8<--8<-
diff -rupN nss-3.12.3.99.3-orig/mozilla/security/nss/lib/freebl/stubs.c
nss-3.12.3.99.3/mozilla/security/nss/lib/freebl/stubs.c
--- ./mozilla/security/nss/lib/freebl/stubs.c 2009-03-28 19:21:50.0
-0700
+++ ./mozilla/security/nss/lib/freebl/stubs.c 2009-06-08 20:37:20.0
-0700
@@ -558,8 +558,8 @@ FREEBL_InitStubs()
return SECFailure;
}
rv = freebl_InitNSPR(nspr);
- freebl_releaseLibrary(nspr);
if (rv != SECSuccess) {
+ freebl_releaseLibrary(nspr);
return rv;
}
}
@@ -570,8 +570,8 @@ FREEBL_InitStubs()
return SECFailure;
}
rv = freebl_InitNSSUtil(nssutil);
- freebl_releaseLibrary(nssutil);
if (rv != SECSuccess) {
+ freebl_releaseLibrary(nssutil);
return rv;
}
}
-8<--8<--8<--8<--8<-
The patch was motivated by this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=502133
--
// Bernie Innocenti - http://codewiz.org/
\X/ Sugar Labs - http://sugarlabs.org/
--
fedora-devel-list mailing list
fedora-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] Unbootable machine
El Sat, 29-08-2009 a las 15:17 +0200, Jonas Smedegaard escribió: > BTW, are all these details about USB booting being collected somewhere > on a wiki page? it would be great if someone could expand this paragraph: http://wiki.sugarlabs.org/go/Soas#Boot This page is not even linked from it: http://wiki.sugarlabs.org/go/Sugar_on_a_Stick/USB_format A few months ago, I got this useful piece of information which makes a lot of previously unbootable machines work: - Mensaje reenviado De: H. Peter Anvin Para: Bernie Innocenti Cc: sysli...@zytor.com, Jeremy Katz , Development discussions related to Fedora Core , Sugar Devel Asunto: Re: Unbootable machine Fecha: Mon, 01 Jun 2009 22:10:37 -0700 Bernie Innocenti wrote: > On 06/02/09 03:43, H. Peter Anvin wrote: >> Bernie Innocenti wrote: >>> Disk /dev/sdb: 2055 MB, 2055208960 bytes >>> 221 heads, 2 sectors/track, 9081 cylinders >> I don't know where fdisk, the Linux kernel, or whatever come up with >> these kinds of geometries. They're almost universally non-bootable. > > Ok, I wiped mbr and made fdisk create a new one: > > Disk /dev/sdb: 2055 MB, 2055208960 bytes > 64 heads, 62 sectors/track, 1011 cylinders ^^ Equally weird. The only "standard" ones are 64 heads, 32 sectors and 255 heads, 63 sectors. -hpa -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] Unbootable machine
El Sat, 29-08-2009 a las 10:25 -0400, Luke Faraone escribió: > > Well, the USB format idea was left unimplemented as we (I) couldn't > get it working, but we should probably take a look at makebootfat to > achieve the same goals. Or just use parted instead of fdisk to wipe the MBR and create it from scratch. It does the right thing on the USB sticks I tried. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
alsa support in sidplay
Hello Linus,
since when we culled OSS support in Fedora's kernel, sidplay
could not delight our ears with the three celestial, synth
voices of the SID.
If you like this patch, I'll go on and commit myself using my
überpackager superpowers. I'm also planning to submit the
autoconf changes upstream.
diff -u -p -r1.6 sidplay.spec
--- sidplay.spec11 May 2009 20:10:35 - 1.6
+++ sidplay.spec8 Sep 2009 04:13:27 -
@@ -3,7 +3,7 @@
Name: sidplay
Version: 2.0.9
-Release: 7%{?dist}
+Release: 8%{?dist}
Summary: A command-line tool for playing back SID files
URL: http://sidplay2.sourceforge.net/
Group: Applications/Multimedia
@@ -12,6 +12,8 @@
# http://packages.debian.org/unstable/oldlibs/sidplay
Patch0:sidplay_2.0.9-5.diff.gz
Patch1:gcc440.patch
+Patch2:sidplay-alsa.patch
+Patch3:sidplay-autohell-fixes.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
License: GPL
BuildRequires: libsidplay-devel
@@ -35,9 +37,12 @@
%setup -q
%patch0 -p1
%patch1 -p1
+%patch2 -p1
+%patch3 -p1
%build
-%configure --with-sidbuilders=%{_libdir}/sidplay/builders
+ACLOCAL='aclocal -I unix' autoreconf -v --force --install
+%configure --with-sidbuilders=%{_libdir}/sidplay/builders --with-alsa
make %{?_smp_mflags}
%install
@@ -54,6 +59,11 @@
%{_bindir}/*
%changelog
+* Mon Sep 07 2009 Bernie Innocenti 2.0.9-7
+- Add sidplay-alsa.patch, stolen from Gentoo
+- Add sidplay-autohell-fixes.patch, rolled in house
+- Rock!
+
* Mon May 11 2009 Linus Walleij 2.0.9-6
- Located a suspect GCC 4.4.0 rebuild bug.
>From http://bugs.gentoo.org/98769
diff -Nrup sidplay-2.0.9.orig/configure.ac sidplay-2.0.9/configure.ac
--- sidplay-2.0.9.orig/configure.ac 2009-09-06 00:26:21.370889171 -0400
+++ sidplay-2.0.9/configure.ac 2009-09-06 00:26:38.631866724 -0400
@@ -24,6 +24,8 @@ AC_CHECK_HEADERS(sys/ioctl.h linux/sound
sys/soundcard.h soundcard.h sys/audio.h sun/audioio.h sun/dbriio.h sys/audioio.h \
audio.h dmedia/audio.h)
+AC_ARG_WITH(alsa,[ --with-alsa Use ALSA library for sound],[WANT_ALSA=$withval],[WANT_ALSA=no])
+
AH_TOP(
[/* Define supported audio driver */
#undef HAVE_HARDSID
@@ -60,9 +62,17 @@ case "$host" in
AC_MSG_RESULT(irix)
AC_CHECK_LIB(audio, main, [AUDIO_LDADD=-laudio AC_SUBST(AUDIO_LDADD)])
;;
-*linux*) AC_DEFINE(HAVE_OSS)
-audiodrv_libadd="./audio/oss/liboss.a"
-AC_MSG_RESULT(oss)
+*linux*)
+if test "$WANT_ALSA" = "yes" ; then
+ AC_DEFINE(HAVE_ALSA)
+ audiodrv_libadd="./audio/alsa/libalsa.a"
+ AC_MSG_RESULT(alsa)
+ AC_CHECK_LIB(asound, main, [AUDIO_LDFLAGS=-lasound AC_SUBST(AUDIO_LDFLAGS)])
+ else
+ AC_DEFINE(HAVE_OSS)
+ audiodrv_libadd="./audio/oss/liboss.a"
+ AC_MSG_RESULT(oss)
+ fi
;;
*netbsd*) AC_DEFINE(HAVE_OSS)
audiodrv_libadd="./audio/oss/liboss.a"
diff -Nrup sidplay-2.0.9.orig/src/audio/alsa/audiodrv.cpp sidplay-2.0.9/src/audio/alsa/audiodrv.cpp
--- sidplay-2.0.9.orig/src/audio/alsa/audiodrv.cpp 2009-09-06 00:26:21.372869292 -0400
+++ sidplay-2.0.9/src/audio/alsa/audiodrv.cpp 2009-09-06 00:26:38.633866542 -0400
@@ -2,6 +2,9 @@
// Advanced Linux Sound Architecture (ALSA) specific audio driver interface.
// --
/***
+ * 2005-07-12: Heikki Orsila
+ * Fixed use of obsolete parts of ALSA API
+ *
* $Log: audiodrv.cpp,v $
* Revision 1.7 2002/03/04 19:07:48 s_a_white
* Fix C++ use of nothrow.
@@ -31,6 +34,7 @@
#include "audiodrv.h"
#ifdef HAVE_ALSA
+#include
#include
#ifdef HAVE_EXCEPTIONS
# include
@@ -57,88 +61,86 @@ void Audio_ALSA::outOfOrder ()
void *Audio_ALSA::open (AudioConfig &cfg, const char *)
{
AudioConfig tmpCfg;
-int mask, wantedFormat, format;
-int rtn;
-int card = -1, dev = 0;
-
-if (_audioHandle != NULL)
-{
+snd_pcm_uframes_t buffer_frames;
+snd_pcm_hw_params_t *hw_params;
+
+// Transfer input parameters to this object.
+// May later be replaced with driver defaults.
+tmpCfg = cfg;
+unsigned int rate = tmpCfg.frequency;
+
+if (_audioHandle != NULL) {
_errorString = "ERROR: Device already in use";
return NULL;
}
-if ((rtn = snd_pcm_open_preferred (&_audioHandle, &card, &dev, SND_PCM_OPEN_PLAYBACK)))
-{
+if (snd_pcm_open (&_audioHandle, "default", SND_PCM_STREAM_PLAYBACK, 0)) {
_errorString = "ERROR: Could not open audio device.";
goto open_error;
}
-
-// Transfer input parameters to this object.
-// May later be replaced with driver
Re: alsa support in sidplay
El Tue, 08-09-2009 a las 21:55 +0200, Linus Walleij escribió: > > If you like this patch, I'll go on and commit myself using my > > überpackager superpowers. I'm also planning to submit the > > autoconf changes upstream. > > That's great, but you mailed off into fedora-devel-list and > the package "sidplay2" is in RPMfusion. But if you're a > superpackager in RPMfusion too then go ahead and do it! Oops, I knew it was in RPMFusion, but forgot about that after one day of debugging! (the Gentoo patch was actually broken). No, I have no RPMFusion account at all. Please, go on and commit the patch for me if you ack it! -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
sugar-pippy dependencies
Hello, the sugar-pippy rpm in Fedora depends on pygame, which is used by some of the examples. So far, so good, but pygame in turn depends on numpy, a 7.7MB package which a lot of huge dependencies such as atlas (11MB), libgfortran (1MB), blas (700KB) and python-nose (1MB). The rest of Sugar is now free of numpy, so it would be good if we could get rid of it completely. One quick solution would be splitting the problematic examples to a sugar-pippy-examples-extra package. Another possibility -- probably the cleanest -- would be splitting the optional classes surfarray and sndarray to a subpackage of pygame. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
El Tue, 29-09-2009 a las 12:36 +, Aleksey Lim escribió: > pygame and numpy are parts of Sugar Platform[1], at least for 0.84, > so, the right question is should these pakcages be a part of SP-0.86 > I guess +1 for both, since we have honey activities that are depend on > these packages. In Sugar shell 0.82, the only thing that numpy was providing was a bit matrix. In 0.82, we replaced it with faster and lighter C code in sugar-base, and it was a big performance win. I suspect the #1 usecase for numpy is to compensate for lack of good array support in Python. Questions: 1) are there lighter-weight alternatives for the most popular uses of numpy? 1) how many of the existing activities actually depend on numpy? 2) would it be hard to remove this dependency from them? 3) Should we define a policy for deprecating components of the Sugar Platform in new revisions? All evolving standards need to find a balance between new features with old feature removal to avoid unbounded bloat. 4) Even if numpy is going to stay around for the Sugar Platform, could we remove it from Pippy and other core activities to save resources and allow shipping lighter weight live distros? -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: [Sugar-devel] sugar-pippy dependencies
El Tue, 29-09-2009 a las 16:25 -0400, Benjamin M. Schwartz escribió: > Bernie Innocenti wrote: > > 1) are there lighter-weight alternatives for the most popular uses of > > numpy? > > No. It has no competition, and is used by virtually every program that > uses python and performs array manipulation. I think it would probably be > part of the python standard library except for political issues (now > mostly resolved). It's not used as much as you think: 1!ber...@giskard:~$ LANG=C rpm -e numpy error: Failed dependencies: numpy is needed by (installed) pygame-1.8.1-7.fc12.x86_64 ber...@giskard:~$ rpm -qa | grep python | wc -l 93 It's also one of the worst startup time offenders I've ever seen in Python: with hot caches, it takes 300ms on a fast computer (~2 seconds on an XO). A lot longer if you have to actually fetch it from disk along with its unique dependencies. > > 2) would it be hard to remove this dependency from them? > > Yes. Numpy provides high-speed math for python. high-speed *advanced* math functions. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Booting Fedora live USB on MacBookPro
Hello, I'm creating an EFI bootable USB image on my rawhide system with this command-line: ./livecd-iso-to-disk.sh --format --efi --overlay-size-mb 400 \ --delete-home --extra-kernel-args selinux=0 ./soas04.iso /dev/sdb1 The resulting USB stick boots fine on a black MacBook, but not on a silver MacBook Pro. The bootable stick does not even show up in the list of boot devices. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
Re: Booting Fedora live USB on MacBookPro
El Tue, 10-11-2009 a las 15:31 -0500, Caroline Meeks escribió: > Are you sure you macbook pro is capable of booting linux? I was > experimenting at a Apple Store and found that the White Macbooks there > were not capable of booting Linux from a CD, let alone Sugar from a > Stick. However the Silver Macbook pros booted both fine. White > macbooks at the GPA have the same issue. Older white macbooks at the > Lilla Fredrick boot fine. So things can be very odd with Macs. Next Saturday I'll bring a few boot CDs of Fedora and Ubuntu to see if I can manage to make them boot on those silver Mac Book Pros. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ -- fedora-devel-list mailing list fedora-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-list
