Hi,
> Steven Chamberlain <ste...@pyro.eu.org> writes:
> > Could someone with access to the hurd-i386 or kfreebsd porter boxes
> > try the attached patch please?
Christoph Egger wrote:
> Start 284: RunCMake.Configure
> 284/371 Te
Hi,
> Steven Chamberlain <ste...@pyro.eu.org> writes:
> > Could someone with access to the hurd-i386 or kfreebsd porter boxes
> > try the attached patch please?
Christoph Egger wrote:
> Start 284: RunCMake.Configure
> 284/371 Te
Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?
Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:
$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tes
Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?
Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:
$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tes
Steven Chamberlain wrote:
> Could someone with access to the hurd-i386 or kfreebsd porter boxes
> try the attached patch please?
Here's how to run that test on its own, verbosely, in an already-built
Debian build tree:
$ Build/bin/cmake "-DCMAKE_MODULE_PATH=Tes
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Te
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Te
Hi,
Andreas Beckmann wrote:
> 292 - RunCMake.Configure (Failed)
Could someone with access to the hurd-i386 or kfreebsd porter boxes
try the attached patch please?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/Tests/RunCMake/Configure/RunCMakeTest.cmake
+++ b/Te
have sub-second
file timestamps. At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.
> 292 - RunCMake.Configure (Failed)
I didn't look at that other test failure yet...
Regards,
--
Steven Chamberlain
ste...@pyro.eu.or
have sub-second
file timestamps. At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.
> 292 - RunCMake.Configure (Failed)
I didn't look at that other test failure yet...
Regards,
--
Steven Chamberlain
ste...@pyro.eu.or
have sub-second
file timestamps. At least with this patch applied I didn't see any
regression, and on UFS... I feel lucky that this will fix it.
> 292 - RunCMake.Configure (Failed)
I didn't look at that other test failure yet...
Regards,
--
Steven Chamberlain
ste...@pyro.eu.or
USB plugin on non-Linux arches.
A patch is attached for this. I've tested it builds again on
kfreebsd-amd64 with this; maybe it fixes hurd also?
Thanks,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/rules.orig 2016-03-13 07:31:31.0 +
+++ debian/rules 2016-04-05 23:46:41.519210
USB plugin on non-Linux arches.
A patch is attached for this. I've tested it builds again on
kfreebsd-amd64 with this; maybe it fixes hurd also?
Thanks,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/rules.orig 2016-03-13 07:31:31.0 +
+++ debian/rules 2016-04-05 23:46:41.519210
icy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 22:00:19 +0100
From: Steven Chamberlain <ste...@pyro.eu.
icy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 22:00:19 +0100
From: Steven Chamberlain <ste...@pyro.eu.
')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 21:37:17 +0100
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: distrho: support GNU platforms othe
')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 21:37:17 +0100
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: distrho: support GNU platforms othe
')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Date: Tue, 05 Apr 2016 21:37:17 +0100
From: Steven Chamberlain <ste...@pyro.eu.org>
Subject: distrho: support GNU platforms othe
Package: src:openocd
Version: 0.9.0-1
Severity: important
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi!
openocd stopped building on kfreebsd when it was switched to
libusb-1.0 API. This can be easily fixed though, as kfreebsd has a
libusb2-dev that Provides:
Package: src:openocd
Version: 0.9.0-1
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi!
openocd stopped building on kfreebsd when it was switched to
libusb-1.0 API. This can be easily fixed though, as kfreebsd has a
libusb2-dev that Provides:
s,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: xscreensaver
Version: 5.34-1
Severity: grave
Tags: upstream
Hi,
The upstream maintainer of xscreensaver has explicitly asked Debian
to stop shipping it, which is a shame of course:
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
It *is* still a free
Package: xscreensaver
Version: 5.34-1
Severity: grave
Tags: upstream
Hi,
The upstream maintainer of xscreensaver has explicitly asked Debian
to stop shipping it, which is a shame of course:
https://www.jwz.org/blog/2016/04/i-would-like-debian-to-stop-shipping-xscreensaver/
It *is* still a free
s of reverse-deps
in the archive, and then get back to you.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Architecture: source kfreebsd-amd64 all
Version: 10.3~svn296998-2
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-...@lists.debian.org>
Changed-By: Steven Chamberlain <ste...@pyro.eu.org>
Description:
acpi-modules-10.3-0-486-di - ACPI support modules
Architecture: source kfreebsd-amd64 all
Version: 10.3~svn296998-2
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-...@lists.debian.org>
Changed-By: Steven Chamberlain <ste...@pyro.eu.org>
Description:
acpi-modules-10.3-0-486-di - ACPI support modules
should work, but probably needs some manual setup
with ifconfig and/or wpa_supplicant.
These are all good questions and probably should go in the Wiki FAQ...
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Christoph Egger wrote:
> Steven Chamberlain <ste...@pyro.eu.org> writes:
> > I guess the switch from Clang->GCC means some zlib code is now being
> > inlined into zfs.ko. An override is suitable here.
>
> Guessed so jep. Don't feel too bad about "embedded copi
ur changes are the same as my r5978 commit, it does seem to work.
I guess the switch from Clang->GCC means some zlib code is now being
inlined into zfs.ko. An override is suitable here.
FWIW kfreebsd 10.3 was working fine today on my Thinkpad, even with the
10.0 userland of jessie-kfreebsd.
Regar
need non-free firmware.
Swapping them for free-software compatible ones is often worth doing.
Otherwise you may only be able to run GNU/kFreeBSD as a virtualised
guest on top of Linux+non-free drivers.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
feedback in that thread for potential issues; YMMV
and perhaps it will work better or worse for you. Feedback is welcome,
since we may soon be ready to build the official images.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: haskell-http2
Version: 1.5.3-2
Severity: serious
X-Debbugs-Cc: debian-...@lists.debian.org
Hi,
Wookey wrote:
> +++ Steven Chamberlain [2016-04-01 10:31 +0100]:
> > Currently haskell-http2 FTBFS on only armel:
> > https://buildd.debian.org/status/package.php?p=haskell
Package: haskell-http2
Version: 1.5.3-2
Severity: serious
X-Debbugs-Cc: debian-...@lists.debian.org
Hi,
Wookey wrote:
> +++ Steven Chamberlain [2016-04-01 10:31 +0100]:
> > Currently haskell-http2 FTBFS on only armel:
> > https://buildd.debian.org/status/package.php?p=haskell
Package: haskell-http2
Version: 1.5.3-2
Severity: serious
X-Debbugs-Cc: debian-arm@lists.debian.org
Hi,
Wookey wrote:
> +++ Steven Chamberlain [2016-04-01 10:31 +0100]:
> > Currently haskell-http2 FTBFS on only armel:
> > https://buildd.debian.org/status/package.php?p=haskell
e the control file with `debian/rules control`. I
think the upload must include binaries because of NEW queue
restrictions.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:kfreebsd-10
Version: 10.3~svn296998-1
Severity: normal
Hi,
When compiled with GCC (rather than upstream default compiler Clang),
WITH_SSP (Stack Smashing Protection), kfreebsd-10 panics on boot.
The panic is in taskqueue_start_threads, just before it would start
zfskern I think.
Package: src:kfreebsd-10
Version: 10.3~svn296998-1
Severity: normal
Hi,
When compiled with GCC (rather than upstream default compiler Clang),
WITH_SSP (Stack Smashing Protection), kfreebsd-10 panics on boot.
The panic is in taskqueue_start_threads, just before it would start
zfskern I think.
Steven Chamberlain wrote:
> To better handle this long-term, you may want to change from a
> whitelist to a blacklist, as it would be a shorter list now:
Attached is a patch doing that. It's the most maintainable way I can
think of handling this.
Thanks,
Regards,
--
Steven Chamberla
Steven Chamberlain wrote:
> To better handle this long-term, you may want to change from a
> whitelist to a blacklist, as it would be a shorter list now:
Attached is a patch doing that. It's the most maintainable way I can
think of handling this.
Thanks,
Regards,
--
Steven Chamberla
arches. That way they stay BD-Uninstallable until luajit is ported or
the porters specifically ask to make haskell-hslua build without luajit.
I think that's more maintainable long-term.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Steven Chamberlain wrote:
> Please could you _keep_ it as a luajit arch, as in the attached patch.
Oops, attached.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/control.orig 2016-01-21 08:05:29.0 +
+++ debian/control 2016-04-01 10:44:43.357267872 +0100
@@ -10,7 +1
Steven Chamberlain wrote:
> Please could you _keep_ it as a luajit arch, as in the attached patch.
Oops, attached.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- debian/control.orig 2016-01-21 08:05:29.0 +
+++ debian/control 2016-04-01 10:44:43.357267872 +0100
@@ -10,7 +1
Package: haskell-hslua
Version: 0.4.1-7
Tags: patch
Followup-For: Bug #811554
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
debian/rules and debian/control are out of sync with respect to
kfreebsd-amd64.
Please could you _keep_ it as a luajit arch, as in the attached patch.
Because
Package: haskell-hslua
Version: 0.4.1-7
Tags: patch
Followup-For: Bug #811554
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
debian/rules and debian/control are out of sync with respect to
kfreebsd-amd64.
Please could you _keep_ it as a luajit arch, as in the attached patch.
Because
Package: haskell-hslua
Version: 0.4.1-7
Tags: patch
Followup-For: Bug #811554
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
debian/rules and debian/control are out of sync with respect to
kfreebsd-amd64.
Please could you _keep_ it as a luajit arch, as in the attached patch.
Because
://tests.reproducible-builds.org/rbuild/unstable/armhf/haskell-http2_1.5.3-2.rbuild.log
Therefore, please could it be given back for another build attempt?
gb haskell-http2_1.5.3-2 . armel
Thanks!
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
notfound 819319 apcupsd/3.14.12-1.2
close 819319
thanks
Carsten Leonhardt wrote:
> My understanding is that apcupsd is BD-Uninstallable because of bug
> #810982 net-snmp: FTBFS on kfreebsd10
You were right, as it has built now on kfreebsd. Thanks, and sorry!
Regards,
--
Steven Chamberla
an.org/status/fetch.php?pkg=net-snmp=kfreebsd-amd64=5.7.3%2Bdfsg-1.2=1459377666
> make[1]: pkg-config: Command not found
> make[1]: pkg-config: Command not found
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Steinar H. Gunderson wrote:
> On Wed, Mar 30, 2016 at 11:57:50PM +0100, Steven Chamberlain wrote:
> > The debian/control file wasn't actually updated with my patch?
>
> Urrrg, double-messup. I hadn't saved the file, it seems. I'm on a bad streak.
Don't worry! Seems we've all made
Steinar H. Gunderson wrote:
> I don't have a kFreeBSD system to test this with. I assume you can do the
> upload yourself if needed, though?
I'm only a DM, so I would need a sponsor for this in any case.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff -Nru net-snmp-5.7.3+dfsg/
in.
Only kfreebsd needs it, to get flags for the libbsd overlay.
A diff is attached, if someone could please apply it... I've tested in
a clean sid chroot that I didn't miss any others.
Thanks a lot,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
diff --git a/debian/control b/debian/control
index
les
* pkg-net-snmp/perl/SNMP/t/snmptest.cmd
* pkg-net-snmp/perl/TrapReceiver/const-c.inc
* pkg-net-snmp/perl/TrapReceiver/const-xs.inc
I've attached a diff against your NMU to fix both of these things.
After that, the client and server both work nicely for me, IPv6 too.
Thanks again,
Reg
Oh sorry, I've just noticed the comment:
Debian Bug Tracking System wrote:
> # unconfuse bts
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Hi Andreas,
Debian Bug Tracking System wrote:
> > notfixed 814631 1:1.7.8-1
> Bug #814631 {Done: Steven Chamberlain <ste...@pyro.eu.org>}
> [src:xserver-xorg-video-siliconmotion] xserver-xorg-video-siliconmotion:
> FTBFS: src/smi.h:224:5: error: unknown type name 'IOADDRES
Steven Chamberlain wrote:
> Carsten Leonhardt wrote:
> > Hm, but on kfreebsd the package libusb2-dev "Provides: libusb-1.0-0-dev",
> > isn't that enough?
>
> Uhhhm... maybe that works. Although, sbuild does have some quirks with
> its dependency handling, so
Control: block -1 by 810982
(putting the bug back into Cc: now)
Hi!
> Steven Chamberlain wrote:
> > The change to apcupsd Build-Depends is not right for kfreebsd. On
> > Linux, libusb 1.0 is provided by libusb-1.0-0-dev, whereas on kfreebsd
> > it is provided by libu
amlessly.
Thank you.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh link
amlessly.
Thank you.
-- System Information:
Debian Release: stretch/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: kfreebsd-amd64 (x86_64)
Kernel: kFreeBSD 10.1-0-amd64
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh link
Package: src:apcupsd
Version: 3.14.12-1.2
Severity: important
Tags: patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd
Hi,
The change to apcupsd Build-Depends is not right for kfreebsd. On
Linux, libusb 1.0 is provided by libusb-1.0-0-dev, whereas on kfreebsd
it is provided by
Package: src:apcupsd
Version: 3.14.12-1.2
Severity: important
Tags: patch
User: debian-...@lists.debian.org
Usertags: kfreebsd
Hi,
The change to apcupsd Build-Depends is not right for kfreebsd. On
Linux, libusb 1.0 is provided by libusb-1.0-0-dev, whereas on kfreebsd
it is provided by
Package: ftp.debian.org
Severity: important
Dear FTP Masters,
In order to release jessie-kfreebsd, the packages from
jessie-kfreebsd-proposed-updates must first be copied into that suite
(similar to a point release I think).
Please could that happen while p-u is frozen for the upcoming point
Package: ftp.debian.org
Severity: important
Dear FTP Masters,
In order to release jessie-kfreebsd, the packages from
jessie-kfreebsd-proposed-updates must first be copied into that suite
(similar to a point release I think).
Please could that happen while p-u is frozen for the upcoming point
Hi,
I'm curious if anyone has tried using a network filesystem in this kind
of setup. I would think, "diskless" boards sharing a NAS allows for
easier provisioning and probably cheaper storage by centralising it.
Though I don't know how that performs in practice?
Regards,
--
Steven C
Hi,
Steven Chamberlain wrote:
> We are running out of time, as wheezy security support ends in April, so
> we must release as soon as possible to give users time to upgrade.
>
> There is not much left to do however:
> * I need to upload GRUB2;
done
> * if we're sure de
tc/os-release"
2042 bash NAMI "/etc/inxi.conf"
2042 bash NAMI "/etc/inxi.conf"
So there is no sign of the bug here.
I think we can probably close the bug unless Adam can show a way to
reproduce it (maybe it can happen only in rare circumstances).
Rega
ork is still needed yet.
(Annoying that there are so many cheap boards that claim to be/do so
much and yet, are of little practical use if they can only boot a
vendor-supplied kernel).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signat
ork is still needed yet.
(Annoying that there are so many cheap boards that claim to be/do so
much and yet, are of little practical use if they can only boot a
vendor-supplied kernel).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Architecture: source all
Version: 10.3~svn296998-1
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-...@lists.debian.org>
Changed-By: Steven Chamberlain <ste...@pyro.eu.org>
Description:
acpi-modules-10.3-0-486-di - ACPI support modules (udeb)
acpi-mo
Architecture: source all
Version: 10.3~svn296998-1
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-...@lists.debian.org>
Changed-By: Steven Chamberlain <ste...@pyro.eu.org>
Description:
acpi-modules-10.3-0-486-di - ACPI support modules (udeb)
acpi-mo
h form.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/src/PacketDumperTuntap.cpp
+++ b/src/PacketDumperTuntap.cpp
@@ -98,7 +98,7 @@
/* * */
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
#define FREEBSD_TA
h form.
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
--- a/src/PacketDumperTuntap.cpp
+++ b/src/PacketDumperTuntap.cpp
@@ -98,7 +98,7 @@
/* * */
-#ifdef __FreeBSD__
+#if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
#define FREEBSD_TA
block 765846 by 810982
tags 765846 + patch
thanks
This bug is fixed by the patch in
https://bugs.debian.org/810982#15
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
tags 818777 + pending
thanks
Fix pending in SVN r5955, which will go into experimental first
and then sid within a few weeks.
Not really an issue anyway since Clang is used instead of GCC on the
arches that really exist at the moment.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
tags 818777 + pending
thanks
Fix pending in SVN r5955, which will go into experimental first
and then sid within a few weeks.
Not really an issue anyway since Clang is used instead of GCC on the
arches that really exist at the moment.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
freebsd-i386 build succeeded because we still have wrappers in
i386/ for backward compatibility, but the old paths are deprecated since
2003! amd64 doesn't have these wrappers as it didn't exist before then.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
* net-snmp
And these were all *buntu-specific (e.g. Mir) :
* libcolumbus
* lightdm
* gtk+3.0
* xorg-server
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
bian-bsd/2016/03/msg00084.html
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
fficient on Linux too.)
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
fficient on Linux too.)
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:kfreebsd-10
Version: 10.1~svn274115-4+kbsd8u2
Severity: grave
Tags: upstream patch
A local unprivileged user could trigger a kernel panic or DoS attack
on kfreebsd-amd64 via sysarch(2) sysctls:
https://security.freebsd.org/advisories/FreeBSD-SA-16:15.sysarch.asc
This affects
Control: tags -1 + pending
Thanks, applied in SVN r5945, meaning it should be in the next
kfreebsd-10 (10.3) package upload.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Control: tags -1 + pending
Thanks, applied in SVN r5945, meaning it should be in the next
kfreebsd-10 (10.3) package upload.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
p.s. where are the sources? Do you have an APT repo with those yet?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
not work
unless firwmares are downloaded to /lib/firmware/ by choice of the user.
I think Intel Wi-Fi, and maybe some other drivers support loading
firmware that way.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:kfreebsd-10
Version: 10.1~svn274115-4+kbsd8u2
Severity: important
Tags: security upstream
kfreebsd's Linux binary compatibility layer (linux.ko module) has a
programming error that could allow for privilege esclation to happen.
Although, this feature is not typically used by Debian
keep patches better documented in the changelog in future, so it is
clear what you fixed, mention bug numbers etc. or if it is just a
backport of some later package version from Debian.
p.s. is the Ubuntu trademark perhaps a concern for your project?
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
e root cause of this.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Control: block -1 by 815519
Steven Chamberlain wrote:
> Actually please hold off on that... the issue that led to pandoc
> removeal already has a patch in the BTS, though I forget which package
> was the root cause of this.
That was http://bugs.debian.org/815519 in haskell-mockery
e root cause of this.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
Package: src:kfreebsd-10
Version: 10.1~svn274115-4+kbsd8u2
Severity: grave
Tags: upstream patch
A local unprivileged user could trigger a kernel panic or DoS attack
on kfreebsd-amd64 via sysarch(2) sysctls:
https://security.freebsd.org/advisories/FreeBSD-SA-16:15.sysarch.asc
This affects
Control: block -1 by 815519
Steven Chamberlain wrote:
> Actually please hold off on that... the issue that led to pandoc
> removeal already has a patch in the BTS, though I forget which package
> was the root cause of this.
That was http://bugs.debian.org/815519 in haskell-mockery
Package: src:kfreebsd-10
Version: 10.1~svn274115-4+kbsd8u2
Severity: important
Tags: security upstream
kfreebsd's Linux binary compatibility layer (linux.ko module) has a
programming error that could allow for privilege esclation to happen.
Although, this feature is not typically used by Debian
But if Julien really decides to drop this package, I'm sure
a separate request could be filed later in that case?
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
freebsd-i386 build succeeded because we still have wrappers in
i386/ for backward compatibility, but the old paths are deprecated since
2003! amd64 doesn't have these wrappers as it didn't exist before then.
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
would be to release as soon as possible after the point
releases (2016-04-02).
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
g this for good.
I commented that the large memory allocation (and the original
CVE-2015-4491) might have been avoided by falling back to simpler
rescale methods when handling very large images:
https://bugzilla.gnome.org/show_bug.cgi?id=754387#c23
Regards,
--
Steven Chamberlain
ste...@pyro.eu.
g this for good.
I commented that the large memory allocation (and the original
CVE-2015-4491) might have been avoided by falling back to simpler
rescale methods when handling very large images:
https://bugzilla.gnome.org/show_bug.cgi?id=754387#c23
Regards,
--
Steven Chamberlain
ste...@pyro.eu.
Architecture: source all
Version: 10.3~svn296373-2
Distribution: experimental
Urgency: medium
Maintainer: GNU/kFreeBSD Maintainers <debian-...@lists.debian.org>
Changed-By: Steven Chamberlain <ste...@pyro.eu.org>
Description:
acpi-modules-10.3-0-486-di - ACPI support modules (udeb)
acpi-mo
Steven Chamberlain wrote:
> (I think this is causing the failure to install build-deps of
> kfreebsd-10 in experimental, and it might affect other packages).
Although on kfreebsd-amd64, where glibc is up-to-date in the buildd
chroots, there is still something odd happening:
|
could you update the kfreebsd-i386
chroots again now?
(I think this is causing the failure to install build-deps of
kfreebsd-10 in experimental, and it might affect other packages).
Thanks,
Regards,
--
Steven Chamberlain
ste...@pyro.eu.org
signature.asc
Description: Digital signature
501 - 600 of 5971 matches
Mail list logo
