Can you please submit the patches in the BTS so that the maintainer of
those packages can upload a new version?
#560114 brltty: FTBFS on kfreebsd-* with 8.x kernel headers
#561076 hal: FTBFS on kfreebsd-* with 8.x kernel headers
#561078 freeglut: FTBFS on kfreebsd-* with 8.x kernel headers
Petr
Petr Salinger a écrit :
>> Petr Salinger (09/12/2009):
>>> I will check also freeglut.
>> Ping? Release managers are getting interested in what's holding up
>> freeglut and hal˙˙ (Asked & answered on the IRC channel.)
>
> For both brltty and freeglut is needed
>
> 1) upload kfreebsd-kernel-heade
Petr Salinger (09/12/2009):
I will check also freeglut.
Ping? Release managers are getting interested in what's holding up
freeglut and hal˙˙ (Asked & answered on the IRC channel.)
For both brltty and freeglut is needed
1) upload kfreebsd-kernel-headers from our current SVN
2a) one line ch
Petr Salinger (09/12/2009):
> I will check also freeglut.
Ping? Release managers are getting interested in what's holding up
freeglut and hal… (Asked & answered on the IRC channel.)
Mraw,
KiBi.
signature.asc
Description: Digital signature
Petr Salinger (09/12/2009):
> It might be sufficient just to add b-d on libusb2-dev, which is
> currently in NEW.
Okay, I've opened #560241 accordingly. I might build freebsd-libs
locally later on and see how it goes, and update the bugreport.
Mraw,
KiBi.
signature.asc
Description: Digital sig
There's smartmontools now too:
https://buildd.debian.org/status/package.php?suite=unstable&p=smartmontools
That sounds related to USB changes˙˙ Log excerpt:
| g++ -DHAVE_C| ONFIG_H -I. -DBUILD_INFO='"(local build)"'
-DSMARTMONTOOLS_SYSCONFDIR='"/etc"' -g -O2 -Wall -W -fno-strict-aliasing
Cyril Brulebois (09/12/2009):
> * brltty: I've just opened #560114, I believe it's also due to this
> USB API change. It's needed to get brltty in testing ASAP for some
> d-i alpha release, so I've suggested removing kfreebsd-* binaries
> for now.
There's smartmontools now too:
https://bu
An alternative option is to install the old /dev/bus/usb in
/dev/legacy/bus/usb, as it seems to be on 8.0 installations (haven't
upgrade my plain FreeBSD machine yet). Then a single line change fixes
our problems.
From my POV, only the "/dev/legacy/bus/usb" is fine.
As we advertise __FreeBSD_ke
Petr Salinger (03/12/2009):
> [ list of affected packages ]
* brltty: I've just opened #560114, I believe it's also due to this
USB API change. It's needed to get brltty in testing ASAP for some
d-i alpha release, so I've suggested removing kfreebsd-* binaries
for now.
Mraw,
KiBi.
signat
On Fri, Dec 04, 2009 at 12:39:02PM +0100, Petr Salinger wrote:
> >>* freeglut
> >> It is possible to disable USB scan of joystick by hack bellow.
> >>
> >>I would prefer to stay on headers based on 8.0.
>
> >As most of the problem are concentrated on the USB stack, what about
> >switching back to
* freeglut
It is possible to disable USB scan of joystick by hack bellow.
I would prefer to stay on headers based on 8.0.
As most of the problem are concentrated on the USB stack, what about
switching back to 7.2 headers only for /dev/bus/usb? There is a
compatibility layer in the kernel, an
On Thu, Dec 03, 2009 at 01:09:40PM +0100, Petr Salinger wrote:
> * freeglut
> It is possible to disable USB scan of joystick by hack bellow.
>
> I would prefer to stay on headers based on 8.0.
>
As most of the problem are concentrated on the USB stack, what about
switching back to 7.2 headers on
On Fri, Dec 04, 2009 at 12:30:53AM +0100, Aurelien Jarno wrote:
> On Thu, Dec 03, 2009 at 01:09:40PM +0100, Petr Salinger wrote:
> If we want to go for this solution, we have to scan the archive for
> usage of this header file, and fix them by submitting a patch.
> >>>
> With the hop
On Thu, Dec 03, 2009 at 01:09:40PM +0100, Petr Salinger wrote:
If we want to go for this solution, we have to scan the archive for
usage of this header file, and fix them by submitting a patch.
>>>
With the hope it won't come in a middle of a transition.
>>>
>>> Speaking of which, we
If we want to go for this solution, we have to scan the archive for
usage of this header file, and fix them by submitting a patch.
With the hope it won't come in a middle of a transition.
Speaking of which, we probably shouldn't be trying too long with
kfreebsd 8.0 unless we have a plan and a
If we want to go for this solution, we have to scan the archive for
usage of this header file, and fix them by submitting a patch.
With the hope it won't come in a middle of a transition.
Speaking of which, we probably shouldn't be trying too long with
kfreebsd 8.0 unless we have a plan and a
Aurelien Jarno (02/12/2009):
> If we want to go for this solution, we have to scan the archive for
> usage of this header file, and fix them by submitting a patch.
> With the hope it won't come in a middle of a transition.
Speaking of which, we probably shouldn't be trying too long with
kfreebsd
Petr Salinger a écrit :
>> The new kfreebsd-kernel-headers version 0.44 is based on kFreeBSD 8.0.
>> This new kernel version introduce a new USB stack with a totally
>> different API.
>>
>> This breaks the build of at least freeglut, libsdl1.2, hal and qemu, but
>> probably a lot more. While the lo
The new kfreebsd-kernel-headers version 0.44 is based on kFreeBSD 8.0.
This new kernel version introduce a new USB stack with a totally
different API.
This breaks the build of at least freeglut, libsdl1.2, hal and qemu, but
probably a lot more. While the long term solution is to add support for
t
Hi all,
The new kfreebsd-kernel-headers version 0.44 is based on kFreeBSD 8.0.
This new kernel version introduce a new USB stack with a totally
different API.
This breaks the build of at least freeglut, libsdl1.2, hal and qemu, but
probably a lot more. While the long term solution is to add suppo
20 matches
Mail list logo
