What arch did that happen on?
(Your system info lists amd64. pmud should not be built on that arch).
But more to the point - in the binary-arch rule, the snooze man page
is removed from the packaged files for the pmud-utils package, but not
for the pmud package, The symlink to apm.8 OTOH is only
Thorsten,
Am 16.10.2016 um 11:42 schrieb Thorsten Glaser:
> Michael Schmitz dixit:
>
>> Did you write the table on the host and then had to byte swap to get it
>> read in ARAnyM?
>>
>> Just checked - Atari byte order disk image files of IDE disks don't need
>
Hi Adrian,
Am 16.10.2016 um 08:32 schrieb John Paul Adrian Glaubitz:
> On 10/15/2016 09:15 PM, Michael Schmitz wrote:
>> good to see you managed to fix the libparted issues!
>
> Thanks. I just happened to be in the situation that I'm writing a guide
> how to set up a minimal
Adrian,
good to see you managed to fix the libparted issues!
Am 16.10.2016 um 02:53 schrieb John Paul Adrian Glaubitz:
> On 10/15/2016 03:11 PM, John Paul Adrian Glaubitz wrote:
>> I then tried the image on Aranym but to my disappointment, the kernel did
>> not recognize the partition table, so
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mathieu,
no need for Dan to test - I've managed to solve my X11 problems and
verify keyboard backlight works with this udev rules file.
Do you want me to submit a patch against the pbbuttonsd package?
Cheers,
Michael
Mathieu,
the attached
Mathieu,
the attached udev rules file will load the i2c-dev module at boot time.
I've copied it into /etc/udev on my system, and linked it as
../050_pbbuttonsd.rules
inside /etc/udev/rules.d as it's done for mouseemu.
Maybe Dan could test this solution - I can't get a stable X desktop
session
Control: tags -1 - moreinfo
Mathieu,
currently upgrading to the latest testing weekly build. I'll look into
what's required for udev to load the correct module.
Cheers,
Michael
On Sat, Aug 15, 2015 at 3:33 AM, Mathieu Malaterre ma...@debian.org wrote:
Control: tags -1 - moreinfo
Control:
report, after reassigning to that package.
Thank you.
Regards,
Michael Schmitz
Logan Rosen wrote:
Package: src:powerpc-utils
Version: 1.1.3-25
Severity: wishlist
Dear Maintainer,
Please update the packaging to the latest upstream release of powerpc-utils,
which is currently 1.1.3-25
On 09/01/15 20:50, Mathieu Malaterre wrote:
Control: severity -1 grave
See 774883#12 (Thanks Ben !)
The package has been non-functional for the last three releases. Do
not ship on jessie.
The apm_bios device workaround was only relevant for Xfree, its lack
does not affect functionality of
Mathieu,
I got your other two bug reports (powerpc-utils) but not that one. The
old address is dead, I've waited for some weak pretext to send out an
update for pmud. You have just given me that pretext :-)
Truth to be told - I had not tested pmud on a system with recent
devfsd/udev
working, after it had worked fine before. Now it
looks more likely that the 'trackpad' tool would not have worked for
you in Xubuntu either.
Regards,
Michael Schmitz
On Thu, Nov 27, 2014 at 4:42 AM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
Xubuntu 12.04 shipped by defaul
.
Regards,
Michael Schmitz
Package: powerpc-utils
Version: 1.1.3-25
Severity: normal
File: /sbin/trackpad
Tags: d-i
Dear Maintainer,
For some reason I am getting this error when I try to enable tap to click using
the trackpad command.
rican-linux@debian-ppc:~/Documents$ sudo trackpad tap
the contents of /proc/device-tree for me to compare
with what I have on my PowerBook?
Regards,
Michael Schmitz
On Tue, Nov 25, 2014 at 1:22 PM, Michael Schmitz schmitz...@gmail.com
wrote:
Herminio,
your keyboard and trackpad appear to be USB devices, instead of ADB
ones. My PowerBook (5,5) has
on
them being enumerated in the OF device tree. That might be the root
cause of your problem.
I'll check your device tree and see what I can find out.
Regards,
Michael Schmitz
On Wed, Nov 26, 2014 at 8:39 AM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
Also why would
Herminio,
that just contains a symbolic link - could you please tar up
/sys/firmware/devicetree/base/ now?
Assuming, of course, that directory exists ...
Regards,
Michael Schmitz
On Wed, Nov 26, 2014 at 10:04 AM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
Here you go
OK, that should help - I would still need your OF device tree to see
what the 3.x kernels' ADB driver should make of the ADB I/O requests
from trackpad.
Regards,
Michael Schmitz
On Wed, Nov 26, 2014 at 10:20 AM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
I found a work
Herminio,
I got one approx. 20 minutes ago which only contained a symbolic link
to /sys/firmware/devicetree/base - what I need is that
/sys/firmware/devicetree/base path packed up,
Thanks,
Michael Schmitz
On Wed, Nov 26, 2014 at 10:29 AM, Herminio Hernandez, Jr.
herminio.hernande
...
Thanks for your help!
Regards,
Michael Schmitz
On Wed, Nov 26, 2014 at 11:30 AM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
sorry no attachment
On Tue, Nov 25, 2014 at 4:30 PM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
try this
On Tue, Nov 25
,
Michael Schmitz
On Wed, Nov 26, 2014 at 12:04 PM, Herminio Hernandez, Jr.
herminio.hernande...@gmail.com wrote:
No problem any way I can help
On Tue, Nov 25, 2014 at 5:01 PM, Michael Schmitz schmitz...@gmail.com
wrote:
Hi Herminio,
thanks, that device tree demonstrates substantial
Hi,
sorry about the bounce - I had been assured mail forwarding would be
set up when the mailserver handling that address was retired.
Shall I prepare a source-only upload to correct the address?
Cheers,
Michael
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a
Adam,
I can add ppc64el, but someone else will need to compile it even on
powerpc - my toolchain is in a truly sorry state.
I could NMU-with-consent, or even add myself to Uploaders and co-
maintain, if you'd be okay with that?
I'd be absolutely OK with that.
Given the upload history,
I
Philip,
On 12/17/2013 2:17 PM, Thorsten Glaser wrote:
I thought so too, but it turns out that the Atari IDE interface is
literally wired “the wrong way”, so you do need to bswap the entire
disc – not just partition table or filesystem metadata – but also
user data – before exchanging it
John,
as long as libparted (or some other PC side kernel magic automagically
invoked by libparted - dm??) does take care of byte-swapping IDE data
on the fly, go for it. I had a quick glance at the code and could find
nothing to that effect.
Otherwise, your only option would be to run
though unless a m68k user complains (heh).
In the meantime - thanks for putting this one to rest.
Michael
Date: Wed, 6 Dec 2000 14:09:04 +0100 (CET)
From: Michael Schmitz schm...@mail.biophys.uni-duesseldorf.de
To: sub...@bugs.debian.org
Subject: fdutils bug: superformat doesn't work
Petr Stehlik dixit:
# cat /proc/hardware
Model: ARAnyM --- output of NF_NAME
That, again, would require a kernel that supports this.
And the kernel would have to be told by ARAnyM in some way - I'm not sure how
the AB040 part is recognized by the kernel.
Hi,
Are there additional characteristics while running inside ARAnyM (i.e. cat
/proc/modules)? The dmesg logfile might not be available for (unprivileged)
users and the dmesg kernel buffer might be scrolled off.
# cat /proc/hardware
Model: Atari Falcon (with Afterburner040)
Hi Paul,
Package: pmud
Version: 0.10-11
Tags: patch
Following an upgrade to squeeze, my PowerBook G4 began suspending
every time I unplugged the AC. I believe this is because
CRITICAL_VOLT defaults to 100,000 millivolts (100V) instead of
10,000 millivolts (10V). I'm using the patch
Package: mac-fdisk
Version: 0.1-15
Severity: serious
Tags: patch d-i
The udebs do not get a correct dependency on libc6-udeb, but instead
depend on the regular libc6 package. We've ignored this for previous
releases, but for Squeeze it's RC because of britney support for udebs.
Thanks
First off, thanks for the bug report, Rick! Fixed powerpc-utils uploaded.
On Wednesday 13 May 2009, Rick Thomas wrote:
Everything progressed normally until during the installation of the
base packages, it failed. According to the syslog file there was a
problem setting up the
Hi,
I'll have to let Christian answer for the licensing of
cts_amiga_info.tar.gz. The rest of the amiga icons are in the d-i
repo. If these have clear licensing (I'm pretty sure they do) then
we should probably move them there too.
As I recall they were created either by or for Christian to
Hi
(wow, fast reply!)
On Tue, Apr 08, 2008 at 04:47:26AM +0200, Michael Schmitz wrote:
Well, even though I still read and answer mail from Duesseldorf I am
physically based in Auckland, NZ now. So 4 am is 2pm for me :-)
Package: powerpc-utils
Version: 1.1.3-22
Severity: normal
Recent
Hi Helge,
Package: powerpc-utils
Version: 1.1.3-22
Severity: normal
Recent kernels seemed to have changed the behaviour of the fn keys. I
recently upgraded from 2.6.4.19 to 2.6.4.24 and now the F-keys have
their hot key behaviour by default and the normal behaviour only if
fn is pressed, which
Hi,
The error is from ld.so, so gdb won't help a lot here.
I'm on the move as we speak, so uploading a new version
may take a few more days.
That was almost a month ago. But the warning is still getting
printed. Any word on when it will be fixed?
Sorry, that bug had disappeared
Hi,
I can confirm this for ppc unstable, and for both 0.1-14 and 0.1-13:
but I'm not sure whether this is a mac-fdisk issue: because mac-fdisk
0.1-13 was released already September 2005, and I doubt it takes such
a long time until I realise such a bug. I'm running ppc unstable on 2
different
.
As a former maintainer of readseq I would like to clarify the situation
from my point of view:
4. I handed over the package to Michael Schmitz [EMAIL PROTECTED]
(Changelog entry took over from Andreas Tille 'cuz readseq is actually
in use at our site). I'm a little bit unsure
severity 408341 wishlist
thank you
Package: mac-fdisk
Version: mac-fdisk
Severity: important
Justification: fails to build from source
Per #202019 it's suggested I (end user) build this from source
if I want to use it on another arch. It seems to build ok,
and the binaries in the package
reassign 407671
thank you
Not sure this is the right one to reassign to, but it describes a problem
related to the same cause -missing legacy backight ioctl.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
severity 407671 wishlist
thanks
The kernel developers didn't remove the ancient backlight code and
installed IOC_GRAB_BACKLIGHT instead. With this ioctl a user space
daemon can switch off the kernel backlight keys code and get full
control over it. Unfortunately
close 407295
thank you
On Wed, 17 Jan 2007, Dmitry Ovechkin wrote:
Package: powerpc-utils
Version: 1.1.3-19
bootsched returns write returned -1 regardless of form of passed
parameters:
# bootsched -w 07:00
bootsched: write returned -1
at Jan 17, 15:29 strace shows:
...
open(/dev/adb,
IIRC kino will use the ffmpeg decoder if it is available, or used to
anyway. Solution is to investigate seeing how kino can use the ffmpeg
decoder.
That's been done - IIRC Guido Guenther provided ffmpeg enabled binaries at
http://honk.sigxcpu.org/linux-ppc/debian ...
cc:ed so he
I believe compiling stalin with gcc now requires a bit over 1GB.
i.e. gcc's VSS grows to a bit over 1GB. Ignoring any other concerns,
it didn't look like the arm and m68k buildds would be likely to handle
that very well.
However, if the buildd admins are willing to make sure that the
Package: rasmol
Version: 2.7.2.1.1-4
Severity: serious
rasmol is unuseable on amd64 (and perhaps other 64bit architectures) due
to using the wrong data type for writes to the frame buffer. This simple
patch fixes it:
--- src/rasmol.h.org2006-11-10 09:35:34.0 +0100
+++ src/rasmol.h
Thanks for the patch. However, I propose that the definition should be
in the Imakefile, where the other architecture specific definitions
are as well. Unfortunately I don't have access to a 64-bit machine at
the moment, could you test that the patch below actually works?
The patch actually
Package: apache2.2-common
Version: 2.2.3-1
Severity: serious
Prevents proper unattended installation of apache2.2-common:
Setting up apache2.2-common (2.2.3-1) ...
touch: cannot touch `/var/log/apache2/error.log': No such file or directory
touch: cannot touch `/var/log/apache2/access.log': No
It very much is - removing qt3-dev-tools and qt3-qtconfig fixed it for me
while upgrading a testing installation.
Michael
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Package: mac-fdisk
Version: 0.1-13
On the experimental Debian-PPC64
(http://debian-ppc64.alioth.debian.org/), mac-fdisk fails on
initialization.
What's the status of ppc64 anyway? I thought even Debian was going to
integrate 64 bit binaries into the regular powerpc architecture now?
Package: libkrb53
Version: 1.4.4~beta1-1
Severity: important
According to policy, the package version may only contain alphanumerics,
and '+', '-', '.' or ':'. The tilde in libkrb53_1.4.4~beta1-1 violates
this rule, and apt-get chokes on it (refuses to download with 'illegal or
malformed chars in
Package: pmud-utils
Version: 0.10-9
Severity: serious
Justification: Breaks installation of new X11/XOrg R7.0
Please install xmouse into /usr/bin, rather than /usr/X11R6/bin. The
current X in unstable has removed the /usr/X11R6/bin directory:
Yep; noticed that on the m68k autobuilders
On Sun, 26 Mar 2006, Simon McVittie wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Forwarding my follow-up to bug 356933: since this was reported on a
package which no longer exists, my follow-up went to the BTS but not
to debian-kernel.
Bug 358816 appears to be another report of
I mentioned a while back that I filed a request for a new mailinglist on
the lists.debian.org domain to replace this one. Apparently, that needs
seconds; so it'd be nice if I could get some people to second this.
Strongly seconded. Cord: the requested list should have been moved to d.o
long
So I think it's udev that is broken (version 0.074-2 from sid)
Could you report a bug to udev's maintainer?
I just upgraded to 0.074-3 and the problem seems to be fixed
[EMAIL PROTECTED]:~$ ls -l /dev/input/
total 0
crw-rw 1 root root 13, 64 2005-11-19 11:30 event0
crw-rw 1
I am the maintainer of input-utils. A user reported a problem (bug
#326149) on the powerpc architecture that I need some help
investigating, since I don't have a ppc machine.
Apparently on his system the event devices start at /dev/input/event1,
and there is no /dev/input/event0. Can someone
a 2.4 or maybe even a 2.6 kernel? One more hint that points to a kernel
problem...
Crest is running 2.4.31. All my buildds that failed with this error are
running a 2.2.x kernel.
Seems we have a likely suspect there. Maybe rebuilding xargs on a 2.2 box
helps?
Someone want to grab
powerpc-utils.postinst moves adjtime from /etc to /var/lib/hwclock.
/var is a seperate partition on my system and I've just noticed
hwclockfirst.sh complains about no such file while booting because
because the /etc/adjtime link points to nothing as /var is not mounted
yet.
I'm not sure if
Our automated buildd log filter[1] detected a problem[2] that will cause
your package to segfault on architectures where the size of a pointer is
greater than the size of an integer, such as ia64 (ppc64 is probably
more relevant here).
Thanks for reporting this; I'll fix it in my next upload.
reassign 326220 apt
Your system looks older than a testing from April 2005. libc6 version
2.2.5-11.8 is a libc6 from Woody, an Debian does not support direct
Woody - Etch upgrade.
So please reassign the bug to whatever seems appropriate. Not being able
to upgrade from woody to current
Well, apt or dpkg should have figured that out, and warned me off to not
attempt the upgrade, right? Yet another bug.
The system is booted using a floppy, I'm not sure I can even fit a 2.4 or
2.6 kernel on there. Either way, 'you should not try that' is not an
The 2.6.8 sarge kernel
So please reassign the bug to whatever seems appropriate. Not being able
to upgrade from woody to current testing/unstable is what I'd consider a
bug in its own right.
It's seems you are not aware that Sarge is out and is now the stable
I'm well aware of that, thank you very much.
Package: libc6
Version: 2.3.5-6
Severity: serious
Architecture: powerpc
Subject says it: while upgrading from a rather dated testing install
(around Apr. 05) with libc6 2.2.5-11.8 to current testing, a number of
things went wrong.
Most notably, upon unpacking libc6 2.3.5-6, the libc6 postinstall
It should be packaged on its own (it's in Marillat's repository, IIRC),
but certainly not in xbase-clients.
Why's that? xvinfo is also in xbase-clients.
Either way, it's not in the archive yet. I'd package it separately, just
don't want to step on anyone's toes.
Michael
--
To
Package: xbase-clients
Version: 4.3.0.dfsg.1-14
Severity: wishlist
Please add the xvattr tool
(http://freshmeat.net/projects/xvattr/?topic_id=100%2C125)
to xbase-clients. It's useful to tweak XV stuff at runtime without server
restart, for instance to get xine running on the external CRTC port
Package: powerpc-utils
Version: 1.1.3-15
Severity: normal
Hi,
Since long long time I booted MacOSX again and it turned the startup
chime on again, but I can't turn it off anymore. This worked with
Joerg Dorchain alerted me to the fact that the iBook G4 does not sync the
nvram on shutdown,
Please send a patch that creates a linux/m68k/syscallent.h with correct
contents, unless m68k really matches i386 exactly. Please also compose
ChangeLog entries in the canonical format you see there and send those
ahead of the patch.
Thanks for reminding me. m68k does not match i386 exactly,
This is just a new symptom of the fact that m68k support has been wrong for
a long time. It's using the syscall table that's right for i386, and they
are not the same any more. An m68k hacker needs to supply a current
syscall table for strace.
I've taken a look at it, and prepared a
This is just a new symptom of the fact that m68k support has been wrong for
a long time. It's using the syscall table that's right for i386, and they
are not the same any more. An m68k hacker needs to supply a current
syscall table for strace.
While the syscall table is indeed outdated (the
On Mon, 4 Jul 2005, Roland McGrath wrote:
This is just a new symptom of the fact that m68k support has been wrong for
a long time. It's using the syscall table that's right for i386, and they
are not the same any more. An m68k hacker needs to supply a current
syscall table for strace.
pbbuttonsd must be started after mouseemu for this to work, and #307068
Doesn't matter in my setup - I can start mouseemu manually way after
bootup and pbbuttonsd still receives its events.
i guess the fact my mouseemu configuration uses the fn makes a
difference here.
If pbbuttonsd
Line 232 of mouseemu.c:
register_inputhandler(fd, keyboard_handler, 1);
Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
the mouse register device call needs the same change to let pbbuttonsd
react to mouse moves).
I have tested this and after restarting
Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
the mouse register device call needs the same change to let pbbuttonsd
react to mouse moves).
I have tested this and after restarting both mouseemu and pbbuttonsd, i
got the pbbuttonsd keys back. This seems to
Change that 1 to 0 and key events are passed on to pbbuttonsd (I imagine
the mouse register device call needs the same change to let pbbuttonsd
react to mouse moves).
I have tested this and after restarting both mouseemu and pbbuttonsd, i
got the pbbuttonsd keys back. This seems to
Hi,
I can confirm this same behavior with an older version of pbbuttonsd
(0.6.3a). The problem only started after upgrading mouseemu from 0.12-1 to
0.15-2.
Order of starting mouseemu and pbbuttonsd does not matter. Starting
mouseemu 0.15-2 'steals' the function key events from pbbuttonsd,
Hi,
I found the reason for pbbuttonsd not getting any more key events:
mouseemu grabbing the device for exclusive use seems to prevent
other processes from receiving events ...
Line 232 of mouseemu.c:
register_inputhandler(fd, keyboard_handler, 1);
Change that 1 to 0 and key events are
Michael,
All I can say at this point is that it didn't work without specifying
the kernel argument. As far as 2.6.8 goes, it didn't work period. I
tried it with the kernel arg and it didn't work, but it did work with
2.6.12-rc4 and 2.6.11.8. However again, I did need to explicitly give
them
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Debian stuff)
+
On Thu, 12 May 2005, Jeff Green wrote:
With crucial help from
Package: powerpc-utils
Version: 1.1.3-14
Severity: important
Justification: fails to build from source
When I tried to build powerpc-utils in a sid chroot, it failed as
follows:
sgml2txt -man autoboot.sgml mv -f autoboot.man autoboot.8
Please install groff to use LinuxDoc DTD SGML
tag 308413 sarge
thanks
I tried to build -10 in a sarge chroot and it failed with a similar
error trying to build clock.sgml, so I've tagged this bug sarge. You
may want to contact the release managers about fixing this in sarge.
OK; I'd rather have them update sarge to -15 anyway because
offset 0 rc 16 buf.sig 90 buf.len 2 buf.name nvram
offset 32 rc 16 buf.sig 95 buf.len 62 buf.name system
offset 1024 rc 16 buf.sig 112 buf.len 193 buf.name common
offset 4112 rc 16 buf.sig 160 buf.len 82 buf.name APL,MacOS75
PRAM found at offset: 4112 1010
How is the startup volume
Hi,
Here is the output of lsprop /proc/device-tree
name device-tree
modelPower Macintosh
compatible AAPL,e407
MacRISC
/proc/device-tree/[EMAIL PROTECTED]/[EMAIL PROTECTED]/[EMAIL PROTECTED]:
That's oldworld (i.e., no yaboot) ?
Yes, that's oldworld.
I suspect there's a bug in the oldworld nvram kernel code - I've not been
able to find anything like the newworld nvram structures in a desktop G3
('Gossamer' model). Can you send the output of lsprop /proc/device-tree so
I can see
Please send the output of ps -afl with nvsetvol hanging.
mac:~# ps afl
4 0 614 1 9 0 4528 2688 wait4 Ss tty1 0:01 -bash
0 0 730 614 20 0 1452 292 - R+ tty1 4:23 \_
nvsetvol 4
Seems to be running - does top show nvsetvol eating up CPU
Seems to be running - does top show nvsetvol eating up CPU time?
top - 17:04:38 up 4 min, 2 users, load average: 1.04, 0.51, 0.20
Tasks: 40 total, 2 running, 38 sleeping, 0 stopped, 0 zombie
Cpu(s): 14.3% user, 48.0% system, 0.0% nice, 37.7% idle
Mem:100744k total,
Running nvsetvol with or without an argument doesn't do anything. It has
to be killed.
Please send the output of ps -afl with nvsetvol hanging.
I'm using a Performa 6400/200 and the internal speaker is working(at
least with mp3blaster).
That's oldworld (i.e., no yaboot) ?
Michael
On Fri, Mar 25, 2005 at 01:38:27AM +0100, Daniel Kobras wrote:
On Tue, Mar 22, 2005 at 08:36:01PM +, Paul Brossier wrote:
there is probably a better mean to do so though, ie checking what
type of conversion is needed according to libavcodec, but it does
effectively fixes the XV
2. If you think that bison should work even under this specific
breakage (after all the byacc link is obviously stale), you need to
fix dpkg instead of bison.
I strongly doubt it's dpkg's fault. After all, handling compatibility
problems of that sort is supposed to happen in
Package: bison
Version: 1.875d-1
Severity: serious
Synopsis: installation of bison does not properly install the yacc
alternatives symlinks - see below.
I think I ran into this a few months back. It had to do with
alternatives -- very odd.
Odd indeed. I found a stale yacc alternatives file
On Mon, Feb 14, 2005 at 05:41:26PM +0100, Michael Schmitz wrote:
I can confirm the XV problem is the same old problem that a patch had
been posted for in http://jira.schirmacher.de/jira-kino/browse/KINO-76.
I've added some #ifdef __BIG_ENDIAN__ around that, the following patch
should
Sorry for the late reply; I've been away from my Powerbook (or indeed,
the net) for the last weeks...
On Fri, Jan 07, 2005 at 06:37:52PM +0100, Michael Schmitz wrote:
Severity: serious
Can you please comment on why you think these bugs make kino unsuitable
for release; specifically, which
I suspect kino declares BE audio data to be LE in the DV export (or indeed
any) pipe. No idea what's the cause of the XV and mpeg2enc endianness
problems though.
The audio problems seem to be caused (at least) by big-endian length
fields in an otherwise little-endian WAV file. I'm not too
88 matches
Mail list logo
