Hi,
(Sorry, overlooked your email.)
Am 2019-08-12 21:31, schrieb Thomas Lange:
I think we cannot fix it in this way.
gpg --export 2BF8D9FE074BCDE4 may not work, if the key is not already
downloaded and available for gpg. I also do not want to force to
install the package debian-keyring on the f
Package: fai-server
Version: 5.8.4
Severity: grave
Tags: security, buster
Dear Maintainer,
fai-server installs /etc/fai/apt/sources.list with the following entry
by default:
deb [trusted=yes] http://fai-project.org/download buster koeln
This is problematic, as the [trusted=yes] part will tell
On 09/30/2017 09:10 PM, Sean Whitton wrote:
> On Sun, Oct 01 2017, Pirate Praveen wrote:
>> Packaging of rollup is stuck [1] and I can make progress with gitlab
>> package with node-d3-color in contrib. Quite a lot of work can happen
>> even with gitlab in contrib, like making sure everything is co
Hi Andreas,
On 09/26/2017 10:08 PM, Andreas Tille wrote:
> I need to admit I have no idea why
>
>fseeko() on reference file: Invalid argument
>
> is happening on some architectures.
According to the manpage of fseek(), which is identical to fseeko()
apart from the offset data type:
ERRORS
On 09/26/2017 10:06 PM, Andreas Tille wrote:
>> ...
>> In file included from bgzip.c:56:0:
>> bgzip.c: In function 'gzi_index_dump':
>> ../io_lib/os.h:127:10: error: invalid operands to binary & (have 'uint64_t *
>> {aka long long unsigned int *}' and 'long long int')
>> (((x & 0x
Hi Andreas,
On 09/18/2017 01:54 PM, Andreas Tille wrote:
> Strangely enough on i386 the build fails with
>
>/usr/bin/ld: cannot find -lhdf5
>
> which I do not understand as well ...
You add the following to the linker flags:
-L/usr/lib/$(shell dpkg-architecture -qDEB_TARGET_GNU_TYPE)/hdf5/
Hi Andreas,
On 08/26/2017 10:08 PM, Andreas Tille wrote:
> I moved disulfinder to Git[1] and tried to track down this issue with my
> limited C++ knowledge but failed. The issue is
>
> ...
> make[3]: Entering directory '/build/disulfinder-1.2.11/disulfind/src'
> g++ -Wdate-time -D_FORTIFY_SOURCE
Am 2017-07-26 09:55, schrieb Tobias Doerffel:
May I ask what you changed? Because if it's something that could
be interesting to other users this might be added to the package
in general. Also, as I'm upstream for it, I'm always a bit curios what
use cases people have for the package.
The use
Control: tags -1 + stretch
Yes, I'll do that. Since you're reporting this from Stretch: are you
using this package on Stretch systems?
If so, I'd also ask the release team if they'd consider a stable
update of the package for the next point release of Stretch (9.2).
Yes we use Stretch here ev
On 02/04/2017 11:25 PM, Christian Seiler wrote:
> That said: I just tried this in a VM, and systemd appears to be
> quite broken if you try to start a Type=dbus unit when DBus is
> installed, but not properly configured. And while that is not
> normally the case, I couldn't ge
On 02/04/2017 10:09 PM, Muri Nicanor wrote:
> i just found a bug (#854192) in the installation procedure of usbguard:
> when i install usbguard on a minimal stretch system, the installation
> stalls and never ends successfully. apparently it has something to do
> with dbus being a dependency of usb
On 01/26/2017 10:17 PM, Thorsten Glaser wrote:
> Christian Seiler dixit:
>> -g, and generate a backtrace? That might already help me to figure
>> out what's going on...
>
> Recursive calls; the SIGBUS is likely a stack underflow.
So it looked at this yesterday evening
On 01/26/2017 09:27 PM, Thorsten Glaser wrote:
>> Christian Seiler dixit:
>
>>> Could you do me a favor, if you're on the porterbox anyway?
>>
>> … that’s a lengthy process, but I’ll do anyway…
>
> Surprise!
Yay for nondeterminism...
> (sid_arm64-d
On 01/26/2017 08:35 PM, Thorsten Glaser wrote:
> Christian Seiler dixit:
>
>> Unfortunately I still haven't heard back from Front Desk about
>> a porterbox account (I'm a DM) for arm64, and I really can't
>> reproduce the issue in qemu on my system and I do
Control: retitle -1 dietlibc: arm64: tst-calloc.c -lpthread fails with Bus error
Control: found -1 dietlibc/0.34~cvs20160508-1~exp3
Unfortunately I still haven't heard back from Front Desk about
a porterbox account (I'm a DM) for arm64, and I really can't
reproduce the issue in qemu on my system a
Control: tags -1 + confirmed
On 01/14/2017 02:30 PM, Adrian Bunk wrote:
> Source: dietlibc
> Version: 0.34~cvs20160606-4
> Severity: serious
>
> https://buildd.debian.org/status/fetch.php?pkg=dietlibc&arch=arm64&ver=0.34~cvs20160606-4&stamp=1483685322
>
> ...
> test/stdlib/testrand.c :
Control: tags -1 + pending
On 01/05/2017 12:17 PM, Christian Seiler wrote:
>> The correct solution is to change the name of the function to
>> __libc_waitpid in __waitpid.c and to define a weak alias for
>> waitpid there. I'm already working on this (saw your initial email
Control: retitle -1 dietlibc: libpthread overrides __errno_location even with
TLS enabled
I've now tracked this down: libpthread apparently overrode
__errno_location to point it to td->errno, where td is POSIX
thread descriptor. This is just plain wrong, because errno is
now a (TLS) variable, whi
Control: clone -1 -2
Control: retitle -2 Various regressions in unit tests when linking against
-lpthread
On 01/05/2017 12:17 PM, Christian Seiler wrote:
> The correct solution is to change the name of the function to
> __libc_waitpid in __waitpid.c and to define a weak alias for
> wait
Control: retitle -1 dietlibc: waitpid broken w/ -lpthread on s390, s390x,
mips64, ia64
Control: tags -1 + confirmed
Control: tags -1 - patch
Thanks for reassigning this.
On 01/05/2017 11:48 AM, latinovic wrote:
> Both archs (s390x and mips64el) do not support waitpid, wait4 is used instead.
> (h
On 12/15/2016 03:03 PM, Dirk Eddelbuettel wrote:
>
> On 15 December 2016 at 14:42, Christian Seiler wrote:
> | On 12/15/2016 02:37 PM, Dirk Eddelbuettel wrote:
> | > On 15 December 2016 at 14:26, Andreas Tille wrote:
> | > | Sorry, but I have no idea how since I'm tota
On 12/15/2016 02:37 PM, Dirk Eddelbuettel wrote:
> On 15 December 2016 at 14:26, Andreas Tille wrote:
> | Sorry, but I have no idea how since I'm totally clueless currently and
> | upstream also did not yet responded to this after the initial idea that
> | it might be some ape related issue was not
Hi,
On 12/14/2016 04:16 PM, Dirk Eddelbuettel wrote:
> One quick thought: does it die in _compilation_ which we have seen with other
> (C++-heavy) packages?
No, g++ works fine here. (The C++ file itself is trivial if you
look at it.)
Current package in Debian:
http://sources.debian.net/src/r-cra
Hi Andreas,
On 12/14/2016 03:59 PM, Andreas Tille wrote:
> thanks a lot for your extensive analysis about of the stack problem. I
> admit I have no idea why this large stack is needed on those
> architectures with stable kernel. I also have no idea why everything
> went fine with treescape versi
Hi again,
On 12/14/2016 03:00 PM, Christian Seiler wrote:
> If I had to guess what was going on in the backtrace, I'd suspect
> an infinite recursion in R code, which translates to infinite
> recursion of the underlying C code. But I'm really not sure here.
Interestingly enoug
Hi Andreas,
On 12/14/2016 11:47 AM, Christian Seiler wrote:
> On 12/14/2016 08:50 AM, Christian Seiler wrote:
>> I'm going to try an i386 build in a VM running a stable kernel
>> and see if that does indeed change things and if I can reproduce
>> the problem. Should th
Hi Andreas,
On 12/14/2016 08:50 AM, Christian Seiler wrote:
> I'm going to try an i386 build in a VM running a stable kernel
> and see if that does indeed change things and if I can reproduce
> the problem. Should that not be the issue though then I really
> can't repro
Hi Andreas,
On 12/14/2016 08:10 AM, Andreas Tille wrote:
> On Wed, Dec 14, 2016 at 12:32:24AM +0100, Christian Seiler wrote:
>> On 11/02/2016 05:20 PM, Andreas Tille wrote:
>>
>> Hmm, was going to take a shot at debugging your segfault, but I
>>
Control: retitle -1 soapdenovo2: FTBFS with parallel builds (dpkg-buildpackage
-J$n, $n > 1)
On 12/08/2016 09:17 PM, Andreas Tille wrote:
> On Thu, Dec 08, 2016 at 02:11:07PM +0500, Andrey Rahmatullin wrote:
>> On Thu, Dec 08, 2016 at 09:58:37AM +0100, Andreas Tille wrote:
>>> it seems there are
On 12/06/2016 11:45 PM, James Cowgill wrote:
> Hi,
>
> On 06/12/16 22:34, Christian Seiler wrote:
>> On 12/06/2016 11:22 PM, James Cowgill wrote:
>>> The version number should be the version number immediately before the
>>> one where the dpkg-maintscript stuff i
On 12/06/2016 11:22 PM, James Cowgill wrote:
> Hi,
>
> On 06/12/16 21:36, Andreas Tille wrote:
>> On Tue, Dec 06, 2016 at 07:06:39PM +0100, Andreas Beckmann wrote:
>>> Package: r-cran-rcurl
>>> Version: 1.95-4.8-1
>>> Severity: serious
>>> User: debian...@lists.debian.org
>>> Usertags: piuparts
>>
Control: tags -1 + confirmed
Hi,
Am 27. November 2016 06:23:25 MEZ, schrieb James Braid :
>Package: tiny-initramfs
>Version: 0.1-2
>Severity: critical
>
>Recent Debian kernels (4.8.x) have disabled support for legacy vsyscall
>emulation. [...]
>This causes problems with tiny-initramfs as the ini
Hi Thorsten,
Am 25. Oktober 2016 22:54:47 MESZ, schrieb Thorsten Glaser :
>Christian Seiler dixit:
>
>>Yes, I fully intend to fix that - which is why I tagged the bug
>>report "confirmed" when it was first reported, even while it
>>was still of lower severit
On 10/22/2016 01:00 AM, Thorsten Glaser wrote:
> Bálint Réczey dixit:
>
>> AFAIK the linux package is the only problematic package were the
>> maintainer refused to disable PIE from packaging scripts.
>
> So, how are you supposed to do that now, instead of filtering
> -fPIE from CFLAGS and -pie f
Control: tags -1 + pending
On 08/13/2016 10:22 PM, Cyril Brulebois wrote:
> Christian Seiler (2016-08-13):
>> So I'd probably want to do the following:
>>
>> Step 1: build open-iscsi twice, once with libmount patched
>> out (closing this bug)
>>
Package: open-iscsi-udeb
Version: 2.0.873+git0.3b4b4500-8
Severity: serious
Justification: installs with iSCSI rootfs unbootable by default
Tags: confirmed jessie
This was reported on debian-user, and I've been able to reproduce
that in a local test environment in a VM.
https://lists.debian.org/d
On 08/15/2016 12:43 PM, Gudjon I. Gudjonsson wrote:
> This fails to compile with the following message:
>
> make[2]: Entering directory '/home/gudjon/nb/pyqwt3d/
> pyqwt3d-0.1.7~cvs20090625/build/py2.7-qt4/configure/OpenGL_Qt4'
> g++ -c -g -O2 -fstack-protector-strong -Wformat -Werror=format-secur
Control: tags -1 + confirmed
(Cc'ing util-linux and selinux maintainers.)
On 08/13/2016 07:08 PM, Cyril Brulebois wrote:
> partman-iscsi and open-iscsi-udeb are no longer installable since the
> latter now depends on libmount1-udeb, which was dropped in 2014 (see
> https://bugs.debian.org/723168)
Control: block 832299 by 827806
On 07/25/2016 02:02 PM, Andreas Tille wrote:
> Format: "jpg" not recognized. Use one of: canon cmap cmapx cmapx_np dot eps
> fig gd gd2 gv imap imap_np ismap pdf pic plain plain-ext png pov ps ps2 svg
> svgz tk vml vmlz x11 xdot xdot1.2 xdot1.4 xlib
> ' returned n
Control: tags -1 + upstream
On Mon, 4 Jul 2016 09:36:08 +0200
=?UTF-8?B?TMOhc3psw7MgQsO2c3rDtnJtw6lueWkgKEdDUyk=?= wrote:
> On Sun, Jul 3, 2016 at 1:46 PM, Christian Kastner wrote:
> > On 2016-07-03 12:30, László Böszörményi (GCS) wrote:
> >> In that clean chroot, may you rebuild -13 from
On 07/24/2016 05:35 PM, Andreas Beckmann wrote:
> On 2016-07-24 17:10, Christian Seiler wrote:
>> Thinking about this again: since this package uses debconf
>> anyway, it's probably much easier to just ask the user whether
>> to delete auth_key or not in -server's po
ut other programs will now
hopefully also work.)
Regards,
Christian
Description: Make MAIN__ a weak symbol
Make MAIN__ a weak symbol, to make sure that non-f2c binaries can link
against libraries created by it. Also make main() a weak symbol, just
in case, because we really don't want to ov
On 05/19/2016 02:52 PM, Christoph Anton Mitterer wrote:
>> PS: I dislike CSDs too (which is why I maintain this package), but
>> could you please not use language such as "crap"? Thanks!
> [...]
This is getting _way_ off track. I just asked nicely because I
do think the word crosses a line. I don'
Control: tags -1 + fixed-upstream
This bug is now fixed upstream:
https://github.com/PCMan/gtk3-nocsd/commit/e9a1e5bf186f2d650ef724b3861d337b7270a400
Regards,
Christian
Package: open-iscsi
Version: 2.0.873+git0.3b4b4500-10
Severity: serious
I'm opening this RC bug so that open-iscsi doesn't migrate to testing,
for two reasons:
- we need to make a followup upload to fix the systemd WantedBy=
target, and because of #797108 the old symlinks don't get removed.
Am 2015-03-20 06:25, schrieb Michael Biebl:
You can probably trigger this by putting 12 modules into
/etc/modules-load.d. Each one will generate a message for the
journal
and after the 11th the service will hang. Jupp, just tried it,
deadlocks. Will, kind-of, because after ~15s it will somehow
Am 2015-03-16 13:51, schrieb Michael Biebl:
It would be great, if Mateusz can confirm that this patch [1] does
indeed fix his issue.
Mateusz, if you are not versed in compiling packages yourself and you
would prefer if we provided you with a test package, please let us
know.
I can also provide
Am 2015-03-03 16:26, schrieb Michael Biebl:
I did a couple more reboots and did indeed run into the problem, that
systemd-sysctl.service was started after syslog.socket, so I got the
"missed XXX messages" again.
Adding the After=systemd-sysctl.service ordering to syslog.socket
fixed
that. In [1]
Am 2015-03-03 15:33, schrieb Michael Biebl:
Am 02.03.2015 um 15:42 schrieb Christian Seiler:
- SOLUTION (mostly the same as before, but SendBuffer is set on a
different unit and a Condition is added to the service):
1. Increase max_dgram_qlen to a reasonable value. The easiest
I did some more tests on this and there is one key thing that I
misunderstood: SO_SNDBUF of the socket that is used to send the
datagrams is used as a limit in the kernel, not of the socket syslog
uses to receive them.
I actually tried setting SendBuffer=1 and ReceiveBuffer=1 on
syslog.socket (to
Small correction to my previous observations:
Am 2015-02-25 18:59, schrieb Christian Seiler:
- SendBuffer=8M will increase the max size of a single log message
that may be sent via this socket (8M is probably at bit much)
Actually that's not true. I've misread the kernel source
Am 2015-02-26 00:04, schrieb Michael Biebl:
Also: I'm not looking for a solution that solves this for any
possible amount of log messages, but I do think that the current
limit doesn't provide enough of a safety zone that one would like
to rely on.
If we can make the journald -> syslog forwardi
Am 2015-02-25 23:26, schrieb Michael Biebl:
If you need that kind of throughput, using the imjournal module might
possibly be the better choice (would need some testing, how mature
imjournal is). Unfortunately, it's not really possible to ship a
default
rsyslog configuration, which uses imjourna
Control: tags -1 - moreinfo
Am 2015-02-25 21:27, schrieb Michael Biebl:
Am 25.02.2015 um 18:59 schrieb Christian Seiler:
Control: severity -1 serious
Thoughts?
Those missing syslog messages (only) happen when systemd flushes the
initial boot kernel/messages to the syslog socket, right
Hi Martin,
(bugtracker CC changed to -quiet to not spam other people)
Note that I consider "grave" quite inflated, severity normal or
important would be more appropriate IMHO.
According to the descriptions reportbug gave me, it was the lowest
severity that fit IMHO, since I would consider not
ay, since it also does the same thing if
the process has already exited).
.
With this patch, journald will no longer silently discard messages
that are supposed to be sent to syslog in these situations.
Author: Christian Seiler
---
This patch header follows DEP-3: http://dep.debia
> Confirmed that this bug is fixed with the following packages:
>
> ii cgmanager 0.33-2 amd64
> Central cgroup manager daemon
> ii linux-image-3.17-1-amd643.17-1~exp1 amd64
> Linux 3.17 for 64-bit PCs
> ii syst
57 matches
Mail list logo
