file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric
constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: note: in expansion of macro '_Int'
36 | typedef enum { _Int, _Text, _Float, _DateType, _Key, _Tag }
AceType
On 2024-09-16, at 15:18:27 +0200, Andreas Tille wrote:
> Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> > Try this patch.
>
> Works.
>
> Thanks a lot for the quick help
A quick follow-up now I have more time. The definition of `struct
input_event` in /usr/include/linux/input.h
Hi Jeremy,
Am Mon, Sep 16, 2024 at 12:23:36PM +0100 schrieb Jeremy Sowden:
> Try this patch.
Works.
Thanks a lot for the quick help
Andreas.
--
https://fam-tille.de
On 2024-09-16, at 12:32:59 +0200, Andreas Tille wrote:
> Control: tags -1 help
> Control: tags -1 confirmed
> Thanks
>
> Hi,
>
> since input-utils showed up as Bug of the Day[1] I worked down the list
> of bugs including upgrading to latest upstream. Unfortunately the FTBFS
> for several 32bit a
Control: tags -1 help
Control: tags -1 confirmed
Thanks
Hi,
since input-utils showed up as Bug of the Day[1] I worked down the list
of bugs including upgrading to latest upstream. Unfortunately the FTBFS
for several 32bit architectures (not only armhf) remains[2].
Since I have no experience wit
missing declaration issues (which luckily did
not were connected to GTK) but I'm now stumbling upon:
...
In file included from disknew.c:85:
../whooks/systags.h:57:15: error: expected identifier before numeric constant
57 | #define _Int 24
| ^~
../wh/acetypes.h:36:16: no
Hi Jeremy,
Am Sat, Apr 13, 2024 at 10:46:17PM +0100 schrieb Jeremy Sowden:
>
> The one after this looks like a GTK problem, and that's the point at
> which I bow out.
Thanks a lot for your help so far. Your patches are pushed to Git.
Kind regards
Andreas.
--
https://fam-tille.de
; > by
> > some issue that cython seems to miss adding some
> >#include
> > but I have no idea how to accomplish this. The Salsa CI build log[1] says:
> >
> > ...
> > y.tab.c: In function 'yyparse':
> > y.tab.c:1409:16: error: implicit
dea how to accomplish this. The Salsa CI build log[1] says:
>
> ...
> y.tab.c: In function 'yyparse':
> y.tab.c:1409:16: error: implicit declaration of function 'yylex'
> [-Werror=implicit-function-declaration]
> y.tab.c:2185:7: error: implicit declarati
':
y.tab.c:1409:16: error: implicit declaration of function 'yylex'
[-Werror=implicit-function-declaration]
y.tab.c:2185:7: error: implicit declaration of function 'yyerror'; did you mean
'YYerror'? [-Werror=implicit-function-declaration]
In file included from a
Do yu know If we have a Debian bug, so I can refer to this bug in mine ?
I prefer to not hide the problem and wait u til mesa is fixed (if this is not
too long).
Do you have a idea of when this issue should be integrated into Debian mesa ?
On Tue, 12 Mar 2024 09:50:51 +0100 (CET)
PICCA Frederic-Emmanuel
wrote:
> Hello, I am affected by this error in the autopkgtest of silx[1]
>
> 487s autopkgtest [22:01:24]: test gui: [---
> 489s MESA: error: ZINK: vkCreateInstance failed
> (VK_ERROR_INCOMPATIB
Hello, I am affected by this error in the autopkgtest of silx[1]
487s autopkgtest [22:01:24]: test gui: [---
489s MESA: error: ZINK: vkCreateInstance failed (VK_ERROR_INCOMPATIBLE_DRIVER)
489s glx: failed to create drisw screen
489s failed to load driver: zink
493s autopkgtest
86_64'
None of this has anything to do with your actual lintian error, as you have
worked out :-)
Wookey
--
Principal hats: Debian, Wookware, ARM
http://wookware.org/
signature.asc
Description: PGP signature
Thank you, that seems to have resolved it. I changed it to arch:any and
multiarch:same.
On 11/11/2023 20:10, Andrey Rakhmatullin wrote:
On Sat, Nov 11, 2023 at 07:36:07PM +0530, Shriram Ravindranathan wrote:
dpkg-deb: building package 'libmagicenum-dev' in
'../libmagicenum-dev_0.9.3-1_all.deb
On Sat, Nov 11, 2023 at 07:36:07PM +0530, Shriram Ravindranathan wrote:
> dpkg-deb: building package 'libmagicenum-dev' in
> '../libmagicenum-dev_0.9.3-1_all.deb'.
[...]
> E: libmagicenum-dev: triplet-dir-and-architecture-mismatch is for arm64
> instead of all [usr/lib/aarch64-linux-gnu/]
So you
Hi Shriram,
debian/control file has a field "architecture". By default it's set to "any".
Try setting it to "all"
On November 11, 2023 7:46:05 PM GMT+05:30, Shriram Ravindranathan
wrote:
>I just realized that I misread the error message. My apologies. It
I just realized that I misread the error message. My apologies. It seems
to be expecting all instead of arm64. So how might I build it for all?
On 11/11/23 7:36 pm, Shriram Ravindranathan wrote:
Dear Mentors,
I am trying to build a multiarch package (ITP #1055706) for debian on
a raspberry
Dear Mentors,
I am trying to build a multiarch package (ITP #1055706) for debian on a
raspberry pi. The package builds fine, however, there is a lintian error
like so:
*Output from *debuild*:*
dpkg-deb: building package 'libmagicenum-dev' in
'../libmagicenum-dev_0.9.3-1_
On Tue, Oct 10, 2023 at 09:07:16PM +0100, Oyindamola Olatunji wrote:
> Hello everyone,
>
> I am trying to update the mmlib package to upstream 1.4.2, however, I keep
> getting this salsa build error log with sphinx.
>
> https://salsa.debian.org/med-team/mmlib/-/jobs/4787422#12
Hello everyone,
I am trying to update the mmlib package to upstream 1.4.2, however, I keep
getting this salsa build error log with sphinx.
https://salsa.debian.org/med-team/mmlib/-/jobs/4787422#1219
The sphinx documentation builds locally.
I look forward to hearing from you.
Thanks
On Fri, Aug 25, 2023 at 06:29:34PM +0200, Niels Thykier wrote:
> Nilesh Patra:
> > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
> > > [...]
> >
> > I had figured out this already, but conffile.lex.c does not exist in the
> > project, it is generated as a part of the lexer output.
On 2023-08-25, at 18:29:34 +0200, Niels Thykier wrote:
> Nilesh Patra:
> > On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
> > > [...]
> >
> > I had figured out this already, but conffile.lex.c does not exist in the
> > project, it is generated as a part of the lexer output. In part
Nilesh Patra:
On Fri, Aug 25, 2023 at 05:17:47PM +0200, Niels Thykier wrote:
[...]
I had figured out this already, but conffile.lex.c does not exist in the
project, it is generated as a part of the lexer output. In particular:
Ok, apologies it was not clear to me from your opening email, wh
ev
> > > > Version: 0.2-6
> > > > Severity: serious
> > > > > In file included from conffile.lex.c:242:
> > > > > ../../lib/stdio.h:64:3: error: #error "Please include config.h first."
> > > > > 64 | #error "P
Niels Thykier:
[...]
Hi,
[...]
I believe that this is stdio.h is generated by the embedded gnulib copy
and that is as far as I am willing to debug that rabbit hole. Based on
the error, I assume gnulib's generated stdio.h requires the project
specific "config.h" to
Nilesh Patra:
On 25 August 2023 1:47:26 pm IST, Nilesh Patra wrote:
On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum wrote:
Source: eegdev
Version: 0.2-6
Severity: serious
In file included from conffile.lex.c:242:
../../lib/stdio.h:64:3: error: #error "Please include config.h
On 25 August 2023 1:47:26 pm IST, Nilesh Patra wrote:
>On Wed, 26 Jul 2023 21:52:17 +0200 Lucas Nussbaum wrote:
>> Source: eegdev
>> Version: 0.2-6
>> Severity: serious
>> > In file included from conffile.lex.c:242:
>> > ../../lib/stdio.h:64:3: error
On Mon, Jul 10, 2023 at 05:11:39PM +0200, José Luis Blanco-Claraco wrote:
> Thanks a lot, Andrey, for the time analyzing the problems here, and
> for the clarifications. I thought libpython was like "libc" for
> python...
It is, but as extensions are loadable plugins, they are fine with symbols
bei
Thanks a lot, Andrey, for the time analyzing the problems here, and
for the clarifications. I thought libpython was like "libc" for
python...
So the main issue seems to be dh_python3 not recognizing the package
as "python"...
I attach the list of files and directories of the latest package
version
On Mon, Jul 10, 2023 at 11:22:05AM +0200, José Luis Blanco-Claraco wrote:
> On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> > No, as it says "phyton3".
> > (I would also expect that using appropriate substvars here is better than
> > writing deps manually)
>
> I know, and added ${py
On Mon, 10 Jul 2023 01:19:38 -0700, JOSE LUIS BLANCO CLARACO wrote:
> I attach the output of "dpkg -I" for the final binary package, where
> the "Depends: python3" is visible,
Copied from the attached file:
Depends: phyton3
phyton3 != python3
:)
Cheers,
gregor
--
.''`. https://info.co
On Mon, Jul 10, 2023 at 11:09 AM Andrey Rakhmatullin wrote:
> No, as it says "phyton3".
> (I would also expect that using appropriate substvars here is better than
> writing deps manually)
I know, and added ${python3:Depends} and ${shlibs:Depends}, but
"dh-python" seems not to add any substvars,
On Mon, Jul 10, 2023 at 11:02 AM gregor herrmann wrote:
> phyton3 != python3
> :)
hahaha, I knew more eyeballs would be helpful!
Thanks a lot, Gregor, that solves the mystery :-)
On Mon, Jul 10, 2023 at 01:19:38AM -0700, JOSE LUIS BLANCO CLARACO wrote:
> [2]. I attach the output of "dpkg -I" for the final binary package, where
> the "Depends: python3" is visible
No, as it says "phyton3".
(I would also expect that using appropriate substvars here is better than
writing deps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Hi all,
I'm adding a new python3 package as part of a larger C++ package [1], which
builds using a rather standard dh + cmake procedure, then builds a python3
package from a pybind11 wrapper.
The problem I have found is that lintian keeps complaini
Hello,
I have a problem with the lintian error "no-code-sections" in the
package libhx.
No matter if I set the parameters
export DEB_CFLAGS_MAINT_APPEND = -flto=auto -ffat-lto-objects
or not the error message remains.
Can someone look over this?
The readelf output se
L.S.
I have a simple program, created by an official Debian tool (fasm).
If I put it into a debian archive I get (among others complaints)
E: lina: unstripped-binary-or-object usr/bin/lina
I'm perfectly willing to strip lina
~/PROJECT/ciforths/ciforth$ strip lina
strip: error: the input
Hello,on my package libHX[1] I get always the lintian error:
E: libhx-dev: no-code-sections [usr/lib/x86_64-linux-gnu/libHX_rtcheck.a]
1. As described in bug #977596 [2],
export DEB_CFLAGS_MAINT_APPEND = -flto=auto -ffat-lto-objects
was included.
This did not result in any change in size
On Mon, 11 Jul 2022 23:57:21 +0500
Andrey Rahmatullin wrote:
> Are you sure converting that file is useful and won't break the software for
> the
> use cases when this file is used?
You're right it breaks program menus[0]. Once I handle to use iconv properly I
see it ...
On Mon, 11 Jul 2022 2
On Mon, Jul 11, 2022 at 11:57:21PM +0500, Andrey Rahmatullin wrote:
> Your input and output file is the same. Looks like iconv crashes with
> SIGBUS in this case, instead of just silently truncating the file or
> something like that, as many other tools would do in this case. If you
> really want t
vert the file, you need to output the result to a
different file and then move it to the old location.
> make[1]: *** [debian/rules:23: override_dh_auto_install] Error del bus
Please run your commands with LANG=C if you intend to show the output when
asking for help.
--
WBR, wRAR
signature.asc
Description: PGP signature
Dear mentors,
I'm working on importing a new upstream version for scid package and I want to
get rid of "national-encoding" lintian warning.
I'm trying to use iconv to convert problematic encondings to UTF-8 but I always
get an error, no matter where I put instructions (over
Dear Nicholas D Steeves,
Thank you very much for your email.
Now, the problem has been solved.
I contacted the support of mentors.debian.net
and I learned that my account was deleted somehow.
He suggested that I create a new account,
and the new account works perfectly.
Thank you very much for y
Hello Makoto Yamashita,
Makoto Yamashita writes:
> Dear whom it may concern,
>
> Thank you very much for reading my email.
> I am a maintainer of the SDPA package and I am trying to
> upload a modified file, but I received the following mail.
>
> Unable to verify file sdpa_7.3.16+dfsg-1_a
On Sat, Jul 02, 2022 at 07:53:40PM +0900, Makoto Yamashita wrote:
> Dear whom it may concern,
>
> Thank you very much for reading my email.
> I am a maintainer of the SDPA package and I am trying to
> upload a modified file, but I received the following mail.
Upload where?
--
WBR, wRAR
signatu
fix it and re-upload. Thanks,
I am trying to search for information related to this message.
However, I cannot find any good information to resolve this issue.
If there is some info, could you please share it with me?
(I made my PGP key almost 10 years ago.
This may affect the above error
Control: tags -1 help
Hi,
I tried to fix the issue via a patch[1] that should ensure
AM_INIT_AUTOMAKE is called only once. Unfortunately that patch
resulted in:
dh_autoreconf
configure.ac:303: error: AM_INIT_AUTOMAKE expanded multiple times
/usr/share/aclocal-1.16/init.m4:29
John Scott writes:
> binutils/libiberty/configure: line 2911: syntax error near unexpected token
> `PLUGIN_OPTION'
> binutils/libiberty/configure: line 2911: `GCC_PLUGIN_OPTION(PLUGIN_OPTION)'
>
> This seems bizarre. Why would autoreconf produce a script with a synta
cache ./config.cache
checking whether to enable maintainer-specific portions of Makefiles... no
...
checking for x86_64-linux-gnu-ranlib... ranlib --plugin
/usr/lib/gcc/x86_64-linux-gnu/11/liblto_plugin.so
binutils/libiberty/configure: line 2911: syntax error near unexpected token
`PLUGIN_OPTION'
ecurity', '-g',
'-Wall', '-MMD', '../../test.c', '-c',
'-o/<>/bin/.conf_check_0af4100b5fe46e1d39544ff43f971742/testbuild/default/test.c.1.o',
'-Wdate-time', '-D_FORTIFY_SOURCE=2']
yes
ERROR: Mismatch between --bui
On Fri, Jul 02, 2021 at 01:26:01AM -0400, Sergio Durigan Junior wrote:
> On Thursday, July 01 2021, Geert Stappers wrote:
>
> > Invoking sbuild with just 'sbuild' gives me:
> >
> > $ sbuild
> > dh clean --with python3 --buildsystem=pybuild
> >
On Thursday, July 01 2021, Geert Stappers wrote:
> Invoking sbuild with just 'sbuild' gives me:
>
> $ sbuild
> dh clean --with python3 --buildsystem=pybuild
> dh: error: unable to load addon python3: Can't locate
> Debian/Debhelper/Sequence/python3.
-compat (= 13),
dh-python,
python3-all,
python3-setuptools,
Invoking sbuild with just 'sbuild' gives me:
$ sbuild
dh clean --with python3 --buildsystem=pybuild
dh: error: unable to load addon python3: Can't locate
Debian/Deb
On Tue, May 4, 2021 at 7:48 PM Stephen Sinclair wrote:
>
> In any case, I was not so much asking for help building/reproducing,
> as I was asking what I can do other than to reply to the bug, which
> seems not to be eliciting a response, to either avoid or delay the
> auto-removal process. Is aut
Thanks for the responses and attempts to build!
Yes, it takes quite a bit of memory unfortunately, due to some very
large auto-generated swig wrappers combined with some complicated
boost usage.
In any case, I was not so much asking for help building/reproducing,
as I was asking what I can do othe
I used a trivial jail with chroot. I can't reproduce the issue.
Regards,
Eriberto
Em qui., 29 de abr. de 2021 às 18:30, Tobias Frost escreveu:
>
> On Thu, Apr 29, 2021 at 05:25:28PM +0200, Stephen Sinclair wrote:
> > Hi Mentors,
> >
> > My package siconos currently has a bug filed [1] and has
On Thu, Apr 29, 2021 at 05:25:28PM +0200, Stephen Sinclair wrote:
> Hi Mentors,
>
> My package siconos currently has a bug filed [1] and has been marked
> for autoremoval from testing.
> The problem is that I cannot reproduce it. The failure is on a test
> that depends on another package, so I
Hi Stephen,
On Thu, Apr 29, 2021 at 5:26 PM Stephen Sinclair wrote:
>
> Hi Mentors,
>
> My package siconos currently has a bug filed [1] and has been marked
> for autoremoval from testing.
>
> The problem is that I cannot reproduce it.
Did you build the package in a clean environment? Against on
Hi Mentors,
My package siconos currently has a bug filed [1] and has been marked
for autoremoval from testing.
The problem is that I cannot reproduce it. The failure is on a test
that depends on another package, so I am wondering if there was just a
glitch here? I have replied to the bug report
On Fri, Dec 18, 2020 at 11:47:53PM +, Jeremy Sowden wrote:
> If you haven't got this sorted yet, try the attached patch. It also
> corrects the SONAME of shasta.so. It does mean there's an RPATH in the
> executable, however.
> ...
Thanks a lot
Andreas.
--
http://fam-tille.de
On 2020-12-18, at 15:32:01 +0100, Andreas Tille wrote:
> I tried no override_dh_shlibdeps in shasta debian/rules, which has
> lead to:
>
> dpkg-shlibdeps: error: cannot find library
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so
> needed by debian/shasta/u
has lead
> > > to:
> > >
> > > dpkg-shlibdeps: error: cannot find library
> > > /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so
> > > needed by debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi:
> > >'
On Fri, Dec 18, 2020 at 07:37:12PM +0500, Andrey Rahmatullin wrote:
> On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> > I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> > to:
> >
> > dpkg-shlibdeps: error: cannot find library
On Fri, Dec 18, 2020 at 03:32:01PM +0100, Andreas Tille wrote:
> Hi,
>
> I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
> to:
>
> dpkg-shlibdeps: error: cannot find library
> /usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so neede
Hi,
I tried no override_dh_shlibdeps in shasta debian/rules, which has lead
to:
dpkg-shlibdeps: error: cannot find library
/usr/lib/python3/dist-packages/shasta.cpython-39-x86_64-linux-gnu.so needed by
debian/shasta/usr/bin/shasta (ELF format: 'elf64-x86-64' abi:
'0
Here is a patch based on this :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Tested on a power machine (where the build failed) and it seems to work.
F.
Description: Fix parallel build
This happened here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976906
Soluti
Here is a patch based on this :
https://www.gnu.org/software/automake/manual/html_node/Yacc-and-Lex.html
Tested on a power machine (where the build failed) and it seems to work.
F.
Description: Fix parallel build
This happened here : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976906
Soluti
On 10/12/20 at 18:20 +0100, Andreas Tille wrote:
> Hi Mathieu,
>
> On Thu, Dec 10, 2020 at 11:10:17AM +0100, Mathieu Malaterre wrote:
> > "make -j160"
> >
> > that would be my guess :)
>
> This sounds pretty likely, thought. Thanks for the hint.
Hi,
I tried building with SMT off (so the machi
Hi Mathieu,
On Thu, Dec 10, 2020 at 11:10:17AM +0100, Mathieu Malaterre wrote:
> "make -j160"
>
> that would be my guess :)
This sounds pretty likely, thought. Thanks for the hint.
> remove parallel from the dh option, and try again (fixes symptoms)
To cure the real issue rather than the symp
IC -DPIC -o .libs/libpll_la-hardware.o
> > > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time
> > > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC
> > > -g -c random.c -fPIC -DPIC -o .libs/libpll_la-random.o
> > > libtool:
e
> > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O3 -fPIC
> > -g -c random.c -fPIC -DPIC -o .libs/libpll_la-random.o
> > libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -Wdate-time
> > -D_FORTIFY_SOURCE=2 -Wall -Wsign-compare -D_GNU_SOURCE -std=c99 -O
sinstance(self.f.get('test_softlink', getlink=True),
> SoftLink))
> AssertionError: False is not true
>
> --
> Ran 748 tests in 3.146s
>
> FAILED (failures=2, skipped=3, expected failures=1)
> E: pybuild pybuild:352: test: plugin distutils failed with: exit code=1: cd
&
On Tue, Dec 01, 2020 at 09:08:23PM +0100, Andreas Tille wrote:
> Control: tags -1 pending
>
> Hi,
>
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions. Thus I've set
>
>Rules-Requires-Root: yes
There is no "Rules-Requires-Root: yes", see the Policy.
--
Andreas Tille:
> Control: tags -1 pending
>
> Hi,
>
> upstream of fis-gtm package[1] confirmed that the build needs some root
> permissions. Thus I've set
>
>Rules-Requires-Root: yes
>
> When trying to build with pbuilder I get:
>
>dh_tes
Control: tags -1 pending
Hi,
upstream of fis-gtm package[1] confirmed that the build needs some root
permissions. Thus I've set
Rules-Requires-Root: yes
When trying to build with pbuilder I get:
dh_testroot
dh_testroot: error: Package needs targeted root but builder has not provi
On Sat, Sep 26, 2020 at 7:32 AM Geert Stappers wrote:
. . .
>
> Found a total of 26 reverse build-depend(s) for libgit2-dev.
Thanks Geert.
One more question, I'm currently helping with the library transition
for libgit2-dev, the above 26 reverse build-depends are all only from
main. Do I also nee
On Fri, Sep 25, 2020 at 11:24:39PM -0400, Tong Sun wrote:
> Hi,
>
> I'm getting "character 0-1: RFC 822 error" from build-rdeps:
And maybe others also ...
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> $ build-rdeps libgit2-dev
&
Hi,
I'm getting "character 0-1: RFC 822 error" from build-rdeps:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
$ build-rdeps libgit2-dev
Reverse Build-depends in main:
------
Fatal error in module common/format822.ml:
character 0-1: RF
gram_grammar_inst.o
> > stan/lang/grammars/semantic_actions_def.o
> > stan/lang/grammars/statement_2_grammar_inst.o
> > stan/lang/grammars/statement_grammar_inst.o
> > stan/lang/grammars/term_grammar_inst.o
> > stan/lang/grammars/whitespace_grammar_inst.o /usr/lib/x86
Hi Paul,
On Wed, Sep 23, 2020 at 07:57:09AM +, Paul Wise wrote:
> It looks like r-base-core is duplicating standard C types and defining
> them incorrectly. If you edit /usr/share/R/include/Rinterface.h to
> remove uintptr_t, does the build succeed?
It turned out that this problem has gone.
On Wed, Sep 23, 2020 at 7:40 AM Andreas Tille wrote:
> unfortunately upstream has not yet responded to this mail. My guess is
> that this is a general gcc-10 issue.
>
> Any hint how to solve this?
It looks like r-base-core is duplicating standard C types and defining
them incorrectly. If you edi
lib/gcc/i686-linux-gnu/10/include/stdint.h:9,
> > from HelperFunctions.h:139,
> > from R_wrapper.c:35:
> > /usr/include/stdint.h:96:23: error: conflicting types for ‘uintptr_t’
> >96 | typedef unsigned int uintptr_t;
> > |
On Thursday, August 13 2020, Ángel wrote:
> On 2020-08-13 at 12:47 -0700, A. Lewenberg wrote:
>> I am trying to suppress some lintian errors in my package build. I see
>> this error when running lintian:
>> --
>> E: stanford-spdb source: source-is-missing
>
On Thu, Aug 13, 2020 at 12:47:16PM -0700, A. Lewenberg wrote:
> I am trying to suppress some lintian errors in my package build. I see this
> error when running lintian:
> --
> E: stanford-spdb source: source-is-missing
> usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.
On 2020-08-13 at 12:47 -0700, A. Lewenberg wrote:
> I am trying to suppress some lintian errors in my package build. I see
> this error when running lintian:
> --
> E: stanford-spdb source: source-is-missing
> usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js
> (.
Hi A. Lewenberg,
Em qui., 13 de ago. de 2020 às 17:49, A. Lewenberg
escreveu:
>
> I am trying to suppress some lintian errors in my package build. I see
> this error when running lintian:
> --
> E: stanford-spdb source: source-is-missing
> usr/share/spdb/vendor/assets/javascrip
I am trying to suppress some lintian errors in my package build. I see
this error when running lintian:
--
E: stanford-spdb source: source-is-missing
usr/share/spdb/vendor/assets/javascripts/bootstrap-4.4.1.min.js
--
I attempt to override this by adding to debian/lintian-overrides the line
Hi Rebecca,
On Sat, Jun 13, 2020 at 3:09 AM Rebecca N. Palmer
wrote:
>
> > ccache: error: Failed to create directory
> > /sbuild-nonexistent/.ccache/tmp: Permission denied
>
> You are using a build tool which expects a writable home directory,
> which does not necessaril
ccache: error: Failed to create directory
/sbuild-nonexistent/.ccache/tmp: Permission denied
You are using a build tool which expects a writable home directory,
which does not necessarily exist in build chroots.
Setting debhelper compat to 13 may help:
https://sources.debian.org/src
Hello all,
I hope you are doing well. I have a question about building with sbuild.
I was trying to build a .dsc file but I get a failed build error, on the other
hand with pbuilder all works fine. I'm attaching the message error,
appreciate any help. Thanks.
Option c_args is: ['-
On Sun, May 10, 2020 at 08:56:50PM +0200, Andreas Tille wrote:
>...
> On Sun, May 10, 2020 at 11:19:27AM +0300, Adrian Bunk wrote:
> > What does fix the problem is disabling OpenMP.
> > I suspect OpenMP is somehow broken in gcc >= 8 on mipsel.
>
> I wonder how we could keep this finding to other p
Hi Adrian,
On Mon, May 11, 2020 at 10:04:24AM +0300, Adrian Bunk wrote:
> A bug buried somewhere in the Debian bts would not change anything.
Probably that's correct.
> What would have to happen would be a Debian MIPS porter debugging
> this problem and then submitting a minimal testcase to gcc
On Sun, May 10, 2020 at 2:57 PM Andreas Tille wrote:
>
> ...
> > --- clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300
> > +++ clustalo-1.2.4/debian/rules 2020-04-14 12:19:44.0 +0300
> > @@ -9,6 +9,11 @@
> > %:
> > dh $@
> >
> > +ifneq (,$(filter $(DEB_HOST
On Sun, May 10, 2020 at 03:51:28PM -0400, Jeffrey Walton wrote:
> > I've now uploaded now with this patch closing the bug - but as I tried to
> > express I'd sleep a bit better if this issue would be recorded somewhere
> > else than in a closed bug.
>
> Maybe GCC? I believe the component is libgom
Hi Adrian,
thanks a lot for your investigation.
On Sun, May 10, 2020 at 11:19:27AM +0300, Adrian Bunk wrote:
> What does fix the problem is disabling OpenMP.
> I suspect OpenMP is somehow broken in gcc >= 8 on mipsel.
I wonder how we could keep this finding to other packages. I bet it
would not
Hi,
I tried to narrow down what broke clustalo on mipsel.
The test from 1.2.4-5 passes with the binary in buster,
but not when rebuilding it in buster.
gcc versions:
7: works
8: broken
9: broken
10: broken
clustalo in buster was built with gcc 7, a rebuild with the gcc 8 now in
buster would
On Fri, May 1, 2020 at 3:05 AM Jeffrey Walton wrote:
>
> On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote:
> >
> > ...
> > ==13209== Process terminating with default action of signal 10 (SIGBUS)
> > ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
> > ==13209==by 0x119410: Alignme
On Fri, May 1, 2020 at 2:14 AM Andreas Tille wrote:
>
> ...
> ==13209== Process terminating with default action of signal 10 (SIGBUS)
> ==13209==at 0x12D5CC: PairDistances (pair_dist.c:346)
> ==13209==by 0x119410: AlignmentOrder (clustal-omega.c:835)
> ==13209==by 0x11A6C4: Align (clu
king the bus error. Of
> course this doesn’t fix the underlying problem(s), but it looks as if
> debugging this to its root cause is going to result in the Debian package
> carrying a lot of invasive dquilt patches on top of upstream. OTOH I don’t
> know the performance requirements o
1 - 100 of 1093 matches
Mail list logo
