Hello Stuart,
Nuitka supports 3.12 for a while now, and will support 3.13 at release
time. We will be able to keep it this way. I think I messed up with my
sponsor such that currently the stable package didn't make it through my
automatic checks, but I think it should be good to go I will check t
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 the
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 broken
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) | bas
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 fai
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 no
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 parame
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, wou
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: Un
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, 08:49:1
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
" is missing in the name.
Best regards,
Kay Hayen
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,
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 pack
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 effec
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
new 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 CP
fault" ))) 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 07.06.2013 02:10, schrieb Jakub Wilk:
Package: nuitka
Version: 0.4.3+ds-1
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,
hat in "/var/tmp" in any portable
way in shell script.
I will probably port the two scripts 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 UNSUBSCR
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 depend
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
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 diffe
u 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.
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
-dbg (>= 2.6.6-2), python-all-dev (>= 2.6.6-2),
rst2pdf (>= 0.14-2), scons (>= 2.0.0), base-files (<< 6.0) |
python3-all-dev (>= 3.2), base-files (<< 6.0) | python3-all-dbg (>= 3.2)
I am assuming a bug in an underlying package and ask to reassign 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,
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 "0.3.18
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 comin
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
* Package name: nuitka
Version : 0.3.15
Upstream Author : Name
* URL : http://nuitka.net/
* License : GPLv3, uses BSD parts.
Programming Lang: Python, C++, Assembler
Description : Nuitka is a fully
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". T
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 gue
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
/usr/lib/gcc-snapshot/lib/gcc/x86_64-linux-
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.2
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.
&g
lib/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:
38 matches
Mail list logo
