Hi,
I request removal of vast from Debian unstable for the following
reasons:
* FTBFS since 2021
* Not part of bookworm or trixie
* No maintainer upload since 2021
* Low popcon (2)
* No reverse dependencies
* Requires changes for the /usr-move transition
As the original packager,
Hi Andreas,
after routine-update dh_missing failed due to compat level 13 which
defaults to fail if some files are not installed.
Yep, encountered that in other places as well when updating a few (old!)
things.
This made me aware that upstream in principle installs a test suite
we could use
Hi Guillem,
[RFP]
I'll try to do this during this week or next one, but if someone
would like to package this right ahead, I can speed this up.
Cool. If my old packaging helps in any way, feel free to steal anything
from it! [0]
[...]
I'm also CCing Sascha who might be interested (given the
Hi all,
Upgrading txtorcon to the latest version (23.11.0) should fix this
problem, it does not happen there for me.
I have imported the new upstream version and updated the packaging [1]
after adjusting the watchfile, which indeed fixes this FTBFS.
Would it be OK to push to git and
Package: wnpp
Severity: wishlist
Owner: debian-...@lists.debian.org
X-Debbugs-Cc: debian-de...@lists.debian.org
* Package name: python-awkward
Version : 2.6.1
Upstream Contact: Jim Pivarski
* URL : https://github.com/scikit-hep/awkward
* License : BSD-3-clause
Hi,
https://buildd.debian.org/status/fetch.php?pkg=seqan-needle=amd64=1.0.2%2Bds-2=1707394988=0
2: [ RUN ] insert.ibfmin
2: unknown file: Failure
2: C++ exception with description "std::bad_alloc" thrown in the test body.
2:
2: [ FAILED ] insert.ibfmin (0 ms)
[...]
2: [ FAILED ] 1
Hi,
apt-cache policy dpdk-dev
dpdk-dev:
Installed: 23.11-1
Candidate: 23.11-1
Version table:
*** 23.11-1 500
500 http://deb.debian.org/debian unstable/main riscv64 Packages
100 /var/lib/dpkg/status
riscv64 is not a release architecture, so it is not in bullseye.
On 2/2/24 16:14, Alexandra N. Kossovsky wrote:
On 02/02/2024 17:19, Sascha Steinbiss wrote:
Will look into adding DPDK support in the binaries on platforms that
support it on Debian (i.e. amd64, arm64, i386, ppc64el).
and riscv64, please.
Unfortunately, riscv64 does not have a dpdk-dev
Hi,
thanks for the notification.
Suricata can work with DPDK, but this feature is not enabled in the
Debian package. Could you enable it, please?
True. I assumed DPDK and the other methods (like AF_PACKET/AF_XDP) were
mutually exclusive, but looks like they are not! Will look into adding
Hi all,
golang-github-twstrike-gotk3adapter was introduced to build coyim, which is
already removed in 2021, see #994195.
FYI, as the person who introduced that package I very much agree it can
and should be removed if nothing else depends on it besides coyim. A lot
has changed with these
tags 1039931 + fixed pending
thanks
Hi Adrian,
thanks for letting me know.
[...]
debian/control:Homepage: https://www.suricata-ids.org/
This location does no longer exist, the new location is
https://oisf.net/
Actually, that's the organization that runs the project -- Suricata's
new
Hi Salvatore,
(re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856649)
Can we just close this bug? This has been addressed for years, and I am not
sure we need to keep these open forever.
Can you pin point the upstream version where this was fixed?
Sure, you did so yourself in your
Hi,
(re: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=856649)
Can we just close this bug? This has been addressed for years, and I am
not sure we need to keep these open forever.
Thanks and best regards
Sascha
OpenPGP_signature
Description: OpenPGP digital signature
Can we just close this bug? This has been fixed for years, and AFAICS no
CVE has ever been assigned.
Thanks and best regards
Sascha
OpenPGP_signature
Description: OpenPGP digital signature
Hi Hamish,
thanks for the reminder.
The default configuration still seems to be broken.
The provided suricata.yaml refers to /etc/suricata/rules/suricata.rules
as the rules file, but none is provided.
suricata-update writes rules to /var/lib/suricata, so even after running
Hi Martin,
[...]
This is mentioned in
https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely
a "timing issue". Not sure if it's fixed upstream. >
Could it make sense to also patch the tests to include the delay that is
mentioned in the GitHub issue comments?
I've tried
Hi all,
[...]
This is mentioned in
https://github.com/magic-wormhole/magic-wormhole/issues/458 as likely
a "timing issue". Not sure if it's fixed upstream. >
Could it make sense to also patch the tests to include the delay that is
mentioned in the GitHub issue comments?
Cheers
Sascha
Hi Nilesh,
On 20 December 2021 9:17:40 pm IST, Sascha Steinbiss wrote:
TLDR: I have prepared a package to cover as much of Arrow as is possible
with what we have in Debian, dependency-wise. There is still a review of
d/copyright missing, and some bundled code might need some extra love
Hi again,
[...]
So it looks like metaeuk is not found -- is this even packaged? Did I do
something wrong (note: busco 5.4.4 from unstable)?
Quick update: filed an ITP for it [0] and also started packaging [1].
Cheers
Sascha
[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029432
[1]
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
X-Debbugs-Cc: debian-de...@lists.debian.org, debian-...@lists.debian.org
* Package name: metaeuk
Version : 6-a5d39d9
Upstream Author : Eli Levy Karin and co-authors
* URL : https://github.com/soedinglab/metaeuk
Hi all,
We might still download one of them at autopkgtest time but I am not sure
that's a good idea. Any comments?
BTW datasets are regularly downloaded anyway by the busco tool when
specifying a lineage on the command line. So if that's the way it's
usually done with the installed
Hi,
I'm at the Debian Med sprint and currently taking a look at various
things to take care of.
[...]
To have BUSCO lineages in the archive their licensing details have to
be clarified as the data does not contain any explicit statements.
The website [0] states that
The BUSCO datasets
Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: 1012...@bugs.debian.org
Hi,
recently added autopkgtests showed that pktanon does not work correctly
on s390x, while it builds there. This might be due to endianness issues.
Reported to upstream, but in order to keep the package in testing I
forwarded 1012382 https://github.com/KIT-Telematics/pktanon/issues/8
tags 1012382 upstream
thanks
Hi,
Your package has an autopkgtest, great. However, it fails on s390x. I
have attached the relevant piece of the log [1]. I'd like to note that
s390x is big-endian. Maybe the check for the
tags 967603 wontfix
thanks
Hi smcv,
[...]
This package has Build-Depends on GTK 2 (libgtk2.0-dev), or produces
binary packages with a Depends on GTK 2.
Unfortunately, LTRsift is currently unmaintained (by me, I am also
upstream). My career has moved into a different direction and it does
not
Hi Sudip,
suricata FTBFS with libbpf 1.0.0 (available in experimental).
This is the first error from the build log:
util-ebpf.c: In function 'EBPFLoadFile':
util-ebpf.c:375:17: error: implicit declaration of function
'bpf_program__set_socket_filter'; did you mean 'bpf_program__set_log_level'?
tags 1018370 upstream
forwarded 1018370 https://github.com/gnome-keysign/gnome-keysign/issues/115
thanks
fixed 1013801 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6
reassign 1013818 golang-github-satta-ifplugo
fixed 1013818 golang-github-satta-ifplugo/0.0~git20200508.ca679be-6
thanks
Setting these bugs to fixed.
* golang-github-satta-ifplugo is ready for gopsutil v3.
* slinkwatch does
Hi Paul,
thanks for letting me know!
I noticed that there were several runs that took 2:47 (our timeout
time), while successful runs more in the order of minutes. This
started to happen recently.
This is likely related to #1012629 [1] (also see #1012804 [2]), a hang
issue that was in fact
Hi Shengjing!
Even better :) I will undo my change then as well as soon as a new
version hits the archive.
Thanks
Sascha
On 24.06.22 16:18, Shengjing Zhu wrote:
Hi,
golang-github-satta-ifplugo (0.0~git20200508.ca679be-4) unstable;
urgency=medium
.
* Adjust import path for
Hi,
this issue seems to be the one I fixed upstream a while ago in:
https://github.com/OISF/suricata/pull/7350
Looks like this just wasn't added as a patch to the packaging yet. Maybe
adding fixes the build on the other machine. Will add the patch soon and
keep an eye on the build status
severity 1010771 normal
thanks
Hi Tim,
I just noticed you also included your suricata.yaml configuration file
in your bug report. I think I found the cause of your problem.
Let's take a look at a problematic rule:
9/5/2022 -- 14:20:21 - -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] -
error
Hi,
[...]
9/5/2022 -- 14:20:21 - -- [ERRCODE: SC_ERR_INVALID_SIGNATURE(39)] -
Complete IP space negated. Rule address range is NIL. Probably have a !any or
an address range that supplies a NULL address range
This seems to indicate that in the rule below, the expression
Package: ftp.debian.org
Severity: normal
As the maintainer for pktanon, I would like to have old arm binary
packages removed from unstable and testing. They are bult but do not
work on these architectures due to alignment problems. See [0].
I have already removed the architectures with my latest
Hi,
Do you think we should wait for this to be fixed? As I said before I (just
from my practical point of view) would be in favor of just removing the
problematic architectures.
I have no opinion on this. But if you want the package to be releasable,
you will need to change it so that it is
Hi Steve,
Many thanks for reproducing this and for offering a the detailed
explanation. I would be happy to forward your findings to upstream
(however, my previous issues/PRs on upstream's GitHub have gone
unanswered). For the time being, I must admit I unfortunately do not
have the time to
Hi Nilesh,
[…]
> Would it be possible to add a hint to ignore arm64 autopkgtest suite?
BTW I think this is possible already in the autopkgtest definition [1] by
adding an Architecture: section and leaving out arm64 in the list of archs you
list in there — if that is what you mean.
Cheers
Hi Andreas,
thanks for your quick reply!
On 19.02.22 22:17, Andreas Beckmann wrote:
> On 19/02/2022 20.13, Sascha Steinbiss wrote:
>> 79 | #error The version of CUB in your include path is not compatible
>> with this release of Thrust. CUB is now included in the CUDA Too
Hi all,
greetings from the Debian Med Sprint 2021!
[...]
> /usr/bin/nvcc -M -D__CUDACC__
> /build/relion-cuda-3.1.0/src/acc/cuda/cuda_projector_plan.cu -o
>
forwarded 1004998 https://github.com/tox-dev/py-filelock/issues/133
thanks
> the packaging makes it look like it is version 0.0.0. We have the path
> /usr/lib/python3/dist-packages/filelock-0.0.0.egg-info, the file
> PKG-INFO says "Version: 0.0.0", etc.
Ah, upstream now uses setuptools-scm to
Hi Nobuhiro,
[...]
> Python3.10 has been introduced in Ubuntu, and as part of the rebuild
> of packages against 3.10 I noticed that pygattlib misbuilds, linking
> both the python3.9 and python3.10 extensions against the same version
> of libboost_python instead of linking each against the
severity 1001981 normal
thanks
FTR: The original reporter confirmed that removing the Python modules in
/usr/local got onioncircuits to start again. So lowering severity as
this is likely not a packaging bug breaking onioncircuits for everyone.
S.
On 23.12.21 12:58, Sascha Steinbiss wrote:
>
Hi Richard,
thanks for your report. Let's see what I can do.
> clicking then launcher results in no visible action.
This is just in bullseye? Unfortunately I can't reproduce this,
onioncircuits opens fine for me.
> Starting from shell
> results in this:
>
> rz@rz-debian:~$ onioncircuits
>
Hi,
just for the record in this RFP and to move this a bit into the
spotlight: I have moved my packaging repository for Apache Arrow to the
Debian Science project in Salsa [1]. See the corresponding thread in the
Debian Med mailing list for more context [2].
TLDR: I have prepared a package to
Hi Paul,
sorry for the delay in replying, I was quite busy and now I have some
free time over the holidays to follow up.
>> I am puzzled. The recent upload only changed the watchfile and updated
>> Standards-Version, compat level etc -- packaging things. Nothing touched
>> the code or build
Hi,
> I have uploaded fmtlib/8 to experimental, and plan to start this transition.
>
> You package FTBFS with fmtlib/8, it has been fixed in version 2021.08.26.
> Please package the new version or backport the relevant commits.
Unfortunately never versions than the one currently in testing
Hi Roberto,
thanks for the quick response!
> I cannot attend to this at the moment, so I give you my blessing to
> proceed with the NMU.
Thanks, will do that and upload soon.
Cheers
Sascha
.
+ * Incorporate patch from upstream to fix build on newer GCC versions.
+(Closes: #997248)
+
+ -- Sascha Steinbiss Mon, 22 Nov 2021 13:01:43 +0100
+
mysql++ (3.2.5-2) unstable; urgency=medium
* Update to Standards-Version 4.5.0 (no changes)
diff -Nru mysql++-3.2.5/debian/patches
Package: golang-github-pierrec-lz4
Severity: wishlist
Dear Maintainer,
it looks like upstream has made the v4 branch the new default and some
updates of my Go packages have started importing
github.com/pierrec/lz4/v4, e.g. gocql. It would be useful to have this version
packaged.
Thanks and best
Hi Matthew,
thanks for letting us know.
> Your package still depends on the old, obsolete PCRE3[0] libraries
> (i.e. libpcre3-dev). This has been end of life for a while now, and
> upstream do not intend to fix any further bugs in it. Accordingly, I
> would like to remove the pcre3 libraries
Hi Paul,
> With a recent upload of pktanon the autopkgtest of pktanon fails in
> testing on armhf when that autopkgtest is run with the binary packages
> of pktanon from unstable.
[...]
> Currently this regression is blocking the migration to testing [1]. Can
> you please investigate the
Hi,
[...]
>> I would also like to have a new version in unstable but as I said I
>> never tested if the rdeps still properly work with the new version. I
>> just expected trouble when upgrading due to the API change that was
>> mentioned in the upstream changelog.
>
> We rebuilt the rdeps again
Hi,
> > There is even 1.x.x available now, which broke API :( [1]
>
> Is this problem still a thing?
> I have rebuilt the rdependencies locally, but I haven't been able to
> reproduce this.
I just read in the upstream changelog that the API is different, not
tried it with a newer package. See
Hi Sebastian,
>>> coyim is not in bookworm. Did you want request removal from unstable?
>>
>> Correct. Just wanting to clean up my packages as at least coyim would
>> surely just be accumulating bug reports from now :)
>
> Removals from unstable are handled by the FTP team. Reassigning.
Oh, I
Hi Sebastian,
[...]
>> Coyim has not made it into buster and bullseye and I as the maintainer do not
>> intend to invest more work into it. A RFA has been without response since
>> January 2021 [1].
>>
>> Hence I suggest to remove it and, once it is gone, also get rid of the
>> obsolete
>>
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: rm
Please remove coyim. It has an RC bug [0] that will require various new
dependencies and transitive dependencies, as upstream moved repositories and
requires new versions. Some dependencies also
Hi,
I think this is done now. With YARA 4.1.2 and
golang-github-hillu-go-yara 4.1.0 now in unstable, the build works again
as the build-time tests complete fine.
@Hilko any other comments?
Cheers
Sascha
Hi,
Please feel free to remove it for now, unless someone wants to take over.
Ack. Given that noone stepped up for about a year now, I'll go ahead and file
a removal request.
Fine with me!
Cheers
Sascha
tags 991270 - moreinfo
thanks
Hi Graham,
[...]
> Please go ahead and upload to unstable, then remove the moreinfo tag
> once it has built.
Done. 6.0.1-3 is now built in unstable on all of the official archs that
the previous version was built on.
Cheers
Sascha
OpenPGP_signature
Description:
; urgency=medium
+
+ * Address CVE-2021-35063 by backporting upstream fix.
+Closes: #990835
+
+ -- Sascha Steinbiss Mon, 19 Jul 2021 13:26:22 +0200
+
suricata (1:6.0.1-2) unstable; urgency=medium
* Also specify explicit separate '-latomic' reference on mipsel.
diff -Nru suricata-6.0.1
Hi Yutaka and Andreas,
thanks for bringing this to our attention. I'll take a look.
Best regards
Sascha
On 21.04.21 08:51, Andreas Tille wrote:
> Hi Yutaka,
>
> thanks for your verbose explanation. I think we'll do nothing in
> current freeze time. But once freeze is over we can deal with
> I will file a ticket to change the override soon.
See #985816 [1]
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985816
Package: ftp.debian.org
Severity: normal
This is in response to bug #931477 [1] dealing with libhtp being
priority extra despite having set the Priority field in d/control years
ago. Please change/remove the override to make libhtp compliant with the
current policy and establish libhtp2 as
Ahh, I think I see the issue now. There is an override that forces
libhtp2 to be extra, in [1]. I think it will take a ftp.debian.org
ticket to change it, there's nothing I can do in a simple upload. In the
package itself the optional definition has already been done years ago.
I will file a
Hi,
If you are wondering why there haven't been any updates lately, I
am sad to announce that current versions of datatables.js does not
build anymore with the old version of closure-compiler in Debian.
>>>
>>> Looks like it does not really need to use closure-compiler, so I
>>>
Hi again,
> However, I noticed that uglifyjs complains about the same line
> closure-compiler did:
>
> JS compressing dataTables.bulma.js
> Parse error at /tmp/jquery-datatables.23860.03SeC/dataTables.bulma.js:170,5
> let nav = $(' aria-label="pagination">
> ^
>
Hi Jonas,
great, thanks for your quick reply and the patch.
>> If you are wondering why there haven't been any updates lately, I am
>> sad to announce that current versions of datatables.js does not build
>> anymore with the old version of closure-compiler in Debian.
>
> Looks like it does
Source: datatables.js
Severity: normal
If you are wondering why there haven't been any updates lately, I am sad
to announce that
current versions of datatables.js does not build anymore with the old
version of
closure-compiler in Debian. So far (up to 1.10.21) I managed to keep it
building
but
I assume this bug is obsolete, right? We already have 3.6.5 in testing
and I do not see these warnings anymore in the i386 build logs.
Cheers
Sascha
I assume this bug is obsolete, right? We already have 3.6.5 in testing
and I do not see these warnings anymore in the i386 build logs.
Cheers
Sascha
Hi,
>>> Should we tag this 'upstream'?
>>
>> Ah, good finding! Yes, I believe it would make sense to tag it
>> upstream.
>
> Probably. However, what about providing it for 64bit architectures
> only? I mean the practical relevance for 32 bit architectures is
> very limited and I consider it
Hi,
> The bug system works by email, so I am forwarding this for filing there.
> I'll also mark the bug fixed in a certain version because it looks like
> the ploteig script disappeared at that point.
Can this bug be closed then? I just checked the latest version (which is
even in buster) and
Hi,
> While investigating FTBFS of `kleborate' on i386 and armhf, I
> found out that `mash' seemed to output inconsistent results
> depending on the underlying CPU architecture it is running on.
[...]
> Since the output obtained on amd64 is considered appropriate by
> `kleborate' test suite, I
Package: wnpp
Severity: normal
I would like to put the peframe package up for adoption.
PEframe is a tool to perform static analysis on Portable Executable (PE)
malware and malicious MS Office documents.
I myself am not longer a peframe user and with increasing work load
recently I can not find
Hi all,
[..]> I just discovered that rekall is no longer maintained at the upstream
> level so I'm wondering if we should not just remove the package.
>
> Hilko, Sascha, what do you think?
Just bringing this up again... I would be in favour of removing it
completely. Would be happy to file a RM
Package: ftp.debian.org
Severity: normal
Please remove the existing old (< 2020.12.16-4) packages for vast on
non-amd64 architectures from unstable. I am the maintainer of that
package.
The code builds but will not work in a stable fashion. I have made upstream
aware of this but they do not see
Package: wnpp
Severity: normal
I would like to put the coyim package up for adoption.
CoyIM is a XMPP (Jabber) chat client with built-in Tor support and
privacy/security features.
I myself am not longer a CoyIM user and with increasing work load
recently I can not find the time to incorporate
Package: rustc
Version: 1.41.1+dfsg1-1~deb10u1
Severity: normal
Dear Maintainer,
while trying to build the new 6.0.1 version of Suricata [1] with the
current Rust toolchain in buster, I noticed that one of the Rust
components in this project [2] fails to build. This can be reproduced on
buster
Hi,
> * Package name : golang-github-godbus-dbus
> Version : 5.0.3-1
I believe this is already in Debian, via golang-dbus [1]
Cheers
Sascha
[1] https://packages.debian.org/source/sid/golang-dbus
Hi everyone,
[...]
> I just discovered that rekall is no longer maintained at the upstream
> level so I'm wondering if we should not just remove the package.
>
> Hilko, Sascha, what do you think?
I would be fine with removing it as at least I don't have much interest
in it any more anyway. It
Hi all,
> Version 0.11.2 is available.
There is even 1.x.x available now, which broke API :( [1]
Should we introduce a new source package, python-pika1, to reflect that
and preserve the old API for the existing reverse deps:
$ apt-rdepends -r python3-pika
Reading package lists... Done
Building
Source: actor-framework
Severity: wishlist
Dear Maintainer,
in order to build VAST
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=970505)
for buster, I would like to request a backport of version 0.17.6. If you
are not interested in doing it, I'd also be happy to upload such a
backport.
Hi Kingsley,
Thanks for reporting this. I did some research and I assume this is referring
to upstream ticket https://trac.torproject.org/projects/tor/ticket/32552, which
seems to suggest that this deals with some issue touching Python 3.8+ and stem
1.7.x.
[…]
> The main reason I'm writing is
Hi,
has anyone taken any action here already? Some of my packages are
affected by this as well.
Cheers
Sascha
reassign 971154 golang-go
thanks
Hi Lucas,
Thanks for reporting this.
[…]
>> ok github.com/DCSO/fever/input 15.229s
>> # github.com/DCSO/fever/processing [github.com/DCSO/fever/processing.test]
>> compile: loop
To me, this looks like a possible Go regression, though. The above seems to
Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss
* Package name: vast
Version : 2020.08.28
Upstream Author : Tenzir GmbH
* URL : https://github.com/tenzir/vast
* License : BSD-3-clause
Programming Lang: C++
Description : network telemetry
Hi all,
>> you once wrote that test. Do you have any idea how to fix it?
>
> Since this is just a warning, it might be sufficient to simply add
>
> Restrictions: allow-stderr
>
> That would make sure that printing a warning to stderr does not cause
> the test to fail. I will test this later
Hi all,
> you once wrote that test. Do you have any idea how to fix it?
Since this is just a warning, it might be sufficient to simply add
Restrictions: allow-stderr
That would make sure that printing a warning to stderr does not cause
the test to fail. I will test this later and fix it if
Source: flatbuffers
Severity: wishlist
Dear Maintainer,
I would like to request a buster backport of flatbuffers.
Thanks and best regards
Sascha
Hi Moritz,
>> Just an update: Python 3 compatibility is indeed introduced in the latest
>> upstream version, however, that version also adds some new dependencies that
>> would need to be packaged and pass NEW. For example, python-virustotal-api,
>> which has been in NEW for quite some time. I
Package: wnpp
Severity: wishlist
* Package name: apache-arrow
Version : 1.0.1
Upstream Author : The Apache Software Foundation
* URL : https://arrow.apache.org
* License : Apache 2.0
Programming Lang: C, C++, Java, Go, Python, ...
Description :
Hi Andreas,
thanks for your email!
[Test failures]
[...]
>>> --
>>> Ran 356 tests in 57.387s
>>>
>>> FAILED (SKIP=2, errors=6)
>>> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
>>>
Package: ftp.debian.org
Severity: normal
Please remove the old version of the fever binary package from testing
for the mipsel architecture.
Due to #960674, it currently does not build on mipsel as there is a
deeper problem with the Go compiler on this architecture. Please see the
corresponding
Hi,
first of all thanks for putting some energy into this issue!
> FTR, after giving back golang-1.14 mipsel several times, it's finally
> built, by a longson builder.
> So I guess it only occurs on octeon. Since the porterbox eller is also
> octeon, it also can't build any go program.
So what
Package: golang-go
Version: 2:1.14~1
Severity: important
Dear Maintainer,
the current go binary crashes on mipsel when running non-trivial calls
(a trivial call would be like 'go version', which succeeds) with the message
'fatal error: gc_trigger underflow'. Here's an example from the mipsel
Hi.
> During a rebuild of all packages in sid, your package failed to build
> on amd64.
This is easily fixed by updating to the latest upstream version (1.1.17).
@Hilko: OK with you? I have already prepared the update as need this for
stenographer to migrate. Gopacket as a dependency has been
reassign 957811 golang-github-satta-ifplugo
thanks
On 17.04.20 13:11, Matthias Klose wrote:
> Package: src:slinkwatch
> Version: 1.1-2
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-10
>
[...]
> # github.com/satta/ifplugo
> /usr/bin/ld:
>
fixed 951181 1:5.0.2-1
thanks
Hi Adam,
>> When you talk about bug metadata, are you just referring to a missing
>> 'fixed' tag for #951181 along the lines of:
>>
>>fixed 951181 1:5.0.2-1
>>
>> If so, I would be happy to provide that.
>
> Yes, exactly that. Sorry if it seems insignificant,
Hi Adam,
thanks for taking a look at my proposed update.
[...]
>> Upstream has merged this patch already [1] and it has been included
>> in the current version in unstable (5.0.2) [2] which the original
>> patch author backported to 4.1.2 to allow fixing it in buster as
>> well.
>>
>> The
Hi Timo,
[...]
> I would appreciate if you could consider adding this patch to the suricata
> package in the current stable release (buster) as the inabilitiy to drop root
> privileges may have severe security implications and the patch itself is
> trivial.
Thanks for taking the time to think of
1 - 100 of 482 matches
Mail list logo
