The later versions of Nuitka with less problems didn't make it to unstable
yet, they would only give an error. However, I
expect to make an upload in the next 2 weeks that will then close this bug.
Yours,
Kay
Hello Lucas,
I have seen this on my side as well, but it was inconsequential, probably
because I still have Python2 installed, but of course, that is bad. The
relevant code should be this:
BUILD_ONLY_PYTHON3 := $(shell [ `lsb_release -r -s | sed -e s/unstable/11/
-e s/testing/11/ -e s/buildd-//
Hello Adrian,
thanks for your effort. As you probably know, my interest is to provide
Debian packages for old distributions too. However, I think I will follow
this, and remove the burden from Debian folk, and work in the future with
an approach, where I will generate the control file based on
Hello,
I am readying said release right now. Future releases will be faster
though, promised. I got blocked as an upstream by a push to make Nuitka do
real optimization, but will release more often again. Sorry for the delays.
But in my defence, Nuitka uploads were blocked for months due to
Hello,
this is not explained in the FAQ, but the way I have done it is like this
(in build-depends, removed irrelevant parts):
python (>= 2.6.6-2) | base-files (>= 11),
python-all-dbg (>= 2.6.6-2) | base-files (>= 11),
python-all-dev (>= 2.6.6-2) |
Hello,
Nuitka is very much ported to Python3 for a long time. I have done the
changes to the packaging, which remove Python2 dependencies for Bullseye
and Sid, but I wanted to keep the packaging working for Wheezy and higher,
so this took more time.
Nuitka has been not building due to rst2pdf
Hello Adrian,
> +simpleFunction21: FAILED 125836 125872 leaked 36
The reference counting in 3.7.0 was broken, as reported in
https://bugs.python.org/issue34042 which is reported fixed.
For current releases, I have had disabled it for 3.7.0 therefore, and
couldn't see what 3.7.1 will be. These
Hello there,
I noticed that this also affected my pbuilder instances. Assuming a file
system corruption when the existing image started to fail with "segfault in
method http", I then discovered that debootstrap of wheezy won't work, and
crash in mysterious ways.
The vsyscall=emulate kernel
Package: hplip
Version: 3.16.3+repack0-1
Severity: important
Dear Maintainer,
at some point in the past, my printer stopped working entirely. Previously
already, likely because of upgrades, or so I assumed, the existing printer
would no longer print, a new one added with a re-run of hp-setup,
Package: snmpd
Version: 5.7.3+dfsg-1.3
Severity: normal
Dear Maintainer,
I just installed "snmpd" from testing, and did systemctl status
snmpd.service
which gives lines like this:
/etc/snmp/snmpd.conf: line 145: Warning: Unknown token: defaultMonitors.
/etc/snmp/snmpd.conf: line 147: Warning:
Hello,
I tried 2.7.8 and it does not happen, and I tried hg branch 2.7 and it
does, obviously that is an issue of Nuitka, that Nuitka will face more
widespread, once 2.7.9 gets released.
However, check out this:
[ /opt/python27_hg/bin/python
Python 2.7.8+ (2.7:e6c7a5a94a1d, Sep 16 2014,
Hello,
this is about a behaviour change of Python:
-Exec with None as tuple args did update locals: 1
+Exec with None as tuple args did update locals: 0
Normally, exec only used to copy back to locals, if it was given no
argument, and using locals() in a read only fashion, when it's given
in the name.
Best regards,
Kay Hayen
Hello Scott,
Am 13.06.2014 17:00, schrieb Scott Kitterman:
Package: nuitka
Version: 0.5.1+ds-1
Severity: normal
As far as I can tell, nuitka doesn't compile any python3 code, so the
build-dep on python3-all-dev is unneeded. python3-all is sufficient. We use
build-deps on the python -dev
Hello,
I think if you change python3-all-dev to python3-all you'll still be able to
run your tests, won't you?
That won't provide Python.h, will it? It is only in the python*-dev
packages AFAIK.
Nuitka generates C++ code that depends on that include file.
Yours,
Kay
--
To UNSUBSCRIBE,
Package: python-reportlab
Version: 3.0~a1-1
Severity: normal
Dear Maintainer,
* What led up to the situation?
I was building my package nuitka, and update, which works fine in
my testing environment, but fails in chroot with unstable.
* What exactly did you do (or not do) that was
Package: pylint
Version: 1.1.0-1
Severity: normal
Dear Maintainer,
upgrading to PyLint, and using a script to check my files, this was
using --include-ids for enhanced parsing, which now fails according
to changes described in changelog.gz, but when I looked at the man
page, it still describes
version of Nuitka to be released soon will address the issue by
treating =2.7.6 the same as 2.7.5+.
Best regards,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello,
turns out, that CPython3 defines the module init function PyMODINIT_FUNC
as follows:
extern C PyObject *
on the other hand, visibility attributes are supposed to be defined
before the actual type, but since it's a define, one can't really get in
between.
I would content, that
of the attribute is at fault,
because with Python2, this gives T:
extern C void __attribute__(( visibility( default ))) initMini( void );
extern C void __attribute__(( visibility( default ))) initMini( void )
But that needs further research (over the weekend). Will keep you updated.
Thanks,
Kay Hayen
Am
Hello Jakub,
In fact there is NUITKA_SKIP_TESTS=1 that I have been using, and I am
going to support the Debian standard instead. I have just added support
for it and it will be in the next release.
In the mean time, you can use the old way if you wish to.
Yours,
Kay
--
To UNSUBSCRIBE,
Hello Jakub,
what I didn't know is that only the g++ package provides the g++
binary, and that the g++-4.6 doesn't. I wonder why my minimal Debian
chroot used for building has it.
What I noticed is this apt-get remove g++ wants to remove
build-essential package. So a adding dependency on
to Python and use the tempfile
module, which allows me to be better at it.
So, this bug will be addressed in the upcoming upstream release too.
Best regards,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas
in a
deterministic way? It probably is just that somebody or something hates
it when not all choices are valid.
Best regards,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello Lucas,
As to deterministic, are you implying that the choice is not made in
a deterministic way? It probably is just that somebody or something
hates it when not all choices are valid.
If you use alternative build-deps, two builds of the same package at
the same time might produce
Hello Lucas,
Am 23.03.2012 10:27, schrieb Lucas Nussbaum:
So it's much easier to fix that problem in your package, for example by
build-depending on B | A.
I totally agree and prepare an upload with this for my sponsor Yaroslav
Halchenko at the next opportunity.
Yours,
Kay Hayen
this bug.
Yours,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Hello Yaroslav,
thanks for reporting the bug.
manpage has odd formatting in
--recurse-to=MODULE/PACKAGE
Recurse to that module, or if a package, to the whole package.
Can be
given multiple
times.Default empty.
Thanks corrected. This was
Hello,
this is to let you know that I just an uploaded an improved package to
mentors.debian.net that addresses this bug:
http://mentors.debian.net/debian/pool/main/n/nuitka/nuitka_0.3.18.1+ds-1.dsc
Note that I changed the upstream version numbering for hotfixes, what
normally was a
The package, meanwhile 0.3.17pre2 is available as a package from here:
http://mentors.debian.net/package/nuitka
Regards,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Package: wnpp
Severity: wishlist
Owner: Kay Hayen kayha...@gmx.de
* Package name: nuitka
Version : 0.3.15
Upstream Author : Name kayha...@gmx.de
* URL : http://nuitka.net/
* License : GPLv3, uses BSD parts.
Programming Lang: Python, C++, Assembler
Hello,
this is just to confirm that ftp.debian.org is also affected. I didn't yet
find a workaround that makes apt-get ignore signatures. Is there one?
Yours,
Kay Hayen
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
Hello Ludovic,
You are absolutely right.
Puting the -static only after -largs probably only affects the final
command build by gnatlink, but not enough besides that. Puting it
outside -largs fixed the issue. I can (now) see how of course passing -static
to ld will not be enough.
So I guess
be
wiser though to remove the need for lib*-4.3.a files entirely.
Workaround is to create the symbolic links by hand.
Best regards,
Kay Hayen
-- System Information:
Debian Release: 5.0
APT prefers testing
APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.27 (SMP w/2
Hello,
I also noted the following:
# locate libgnat | egrep '.a$'
/usr/lib/gcc/x86_64-linux-gnu/4.3/rts-native/adalib/libgnat.a
/usr/lib/gcc/x86_64-linux-gnu/4.3/rts-sjlj/adalib/libgnat-4.3.a
/usr/lib/gcc/x86_64-linux-gnu/4.3/rts-sjlj/adalib/libgnat.a
Hello Ludovic,
Kay Hayen writes:
We are compiling software not necessarily with the system default
compiler, but based on PATH. For that purpose we figure out the
adalib directory of the used compiler, and link against libgnat.so
from there.
Are you trying to set the LD_LIBRARY_PATH
/libgnat-4.3.so -
libgnat-4.3.so.1
-rw-r--r-- 1 root root 5625476 14. Jun 12:40
/usr/lib/gcc/x86_64-linux-gnu/4.3/rts-native/adalib/libgnat.a
For manually compiled gcc installations there is a libgnat.so in that directory.
Thanks in advance,
Kay Hayen
-- System Information:
Debian Release: lenny
37 matches
Mail list logo
