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 min
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 t
-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 attach
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 on
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 wrote:
> Control: tags -1 - moreinfo
> Control: tags -1 confirm
g this bug 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 currentl
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 pmud
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 implementatio
ool
suddenly stopped 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.
wrote:
> Xubuntu 12.04 shipped by defaul
,
Michael Schmitz
On Wed, Nov 26, 2014 at 12:04 PM, Herminio Hernandez, Jr.
wrote:
> No problem any way I can help
>
> On Tue, Nov 25, 2014 at 5:01 PM, Michael Schmitz
> wrote:
>>
>> Hi Herminio,
>>
>> thanks, that device tree demonstrates substantial differe
rnels ...
Thanks for your help!
Regards,
Michael Schmitz
On Wed, Nov 26, 2014 at 11:30 AM, Herminio Hernandez, Jr.
wrote:
> sorry no attachment
>
> On Tue, Nov 25, 2014 at 4:30 PM, Herminio Hernandez, Jr.
> wrote:
>>
>> try this
>>
>> On Tue, Nov 25, 2
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.
wrote:
> did youget
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.
wrote:
> I found a work around I was able to
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.
wrote:
> Here you go!
>
> On Tue, Nov 25,
ly 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.
wrote:
> Also why would the kernel see my buil
r up 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
> wrote:
>>
>> Herminio,
>>
>> your keyboard and trackpad appear to be USB devices, inst
.
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
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 s
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 g
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 between
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 gparte
ther I can get a recent version from debian-ports. Not a
priority 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
> To: sub...@bugs.debian.org
> Sub
> Petr Stehlik dixit:
>
> ># cat /proc/hardware
> >Model: ARAnyM <--- output of
>
> 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.
> S
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 Afterburner
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 pa
> 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.
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 powerp
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 use
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, whic
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 disa
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
> diffe
ry, if its current maintainer
> > agrees.
>
> 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 A
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
> > 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 CONFIG_PMAC_BACK
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]
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:
> ...
> ope
> > > 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 ...
>
> 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
>
> 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 actuall
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
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 suc
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 autobuilde
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 repor
> 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
>
> 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 so
> > 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
> > 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.
> > 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 sarg
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 test
> 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 uplo
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 UN
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
i
> 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 sh
+ ChangeLog 2005-07-19 12:33:44.0 +0200
@@ -1,3 +1,11 @@
+2005-07-19 Michael Schmitz <[EMAIL PROTECTED]>
+
+ Long overdue m68k cleanup.
+ * linux/syscallent.h: remove m68k declarations.
+ * linux/m68k/syscallent.h: new file, fixed up declarations
+ to m
> 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 exact
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.
W
> 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 (
> 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 sys
> > > 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
> > > 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.
> > > 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.
> > 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 a
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
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, stoppin
> 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
+
[EMAIL PROTECTED]
[EMAIL PROTECTED] (Debian stuff)
+
On Thu, 12 May 2005, Jeff Green wrote:
> With crucial help from Be
> 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 bec
> 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 D
> > 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
> Hi,
>
> Here is the output of lsprop /proc/device-tree
>
> name "device-tree"
> model"Power Macintosh"
> compatible "AAPL,e407"
>"MacRISC"
>
> /proc/device-tree/[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
> > 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,
> > 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
> 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) ?
Michae
> 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
> Correct me if I am wrong: the problem is caused by a dangling link in
> the alternatives system that refers to an uninstalled package. dpkg
Nope - even after removing that dangling link, bison does not properly
install a new link.
> knows that byacc is not installed, so in principle update-alt
> > 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 p
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
> > 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
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
> fo
Package: kinoplus
Version: 0.3.3-3
Severity: important
Tag: patch
Due to a typo in the ImageMagick overlay code (startwidth used for
startheight in calculation of height change), the overlay height shrinks
even when startgeometry==endgeometry is set in the dialog.
Trivial patch attached.
> > Why? Because we don't know how MockOS will react to a partition _type_ set
>
> I don't know any MockOS, please provide real examples.
s/MockOS/MacOS/g
> > to anything but Apple_Bootstrap, Apple_HFS, Apple_UNIX_SVR2 or Apple_Free.
> > If you're sure (or just reasonably confident) Linux_LVM wil
> > > Parted converts flags to funky partition type names, i think. Not idea,
> > > but it
> > > works, like said, i think parted is inherently broken on this, but there
> > > is
> > > not much we can do at this time.
> >
> > They might have done this following a comment of mine (my memory id fu
93 matches
Mail list logo
