Bug#913189: [Pkg-tcltk-devel] Bug#913189: /usr/bin/tclsh8.6: `file delete' can produce EFAULT
Hi! Just to be clear: The manpage of [file delete] states that > Trying to delete a non-existent file is not considered an error. see https://www.tcl.tk/man/tcl8.6/TclCmd/file.htm#M12 or, the Wiki states that > If pathname is a non-existent file, nothing is done and it is not an error. see https://wiki.tcl-lang.org/page/file+delete ... so your expectation is that this behaviour also applies to this EFAULT instance? If so (I agree), you might consider opening a ticket at https://core.tcl.tk/tcl/login?g=/tcl/tktnew This can also be (re-)produced under macOs, FWIW: $ rm -rf d $ mkdir d $ cd d $ rm -rf ../d $ env - pwd pwd: .: No such file or directory $ tclsh8.6 % pwd error getting working directory name: no such file or directory % file delete spong error deleting "spong": bad address in system call argument % exit Stefan
Bug#856961: [Pkg-tcltk-devel] Bug#856961: nsf: can't find package xotcl::serializer
Hi Héctor, Thx for reporting. I prepared 2.1.0-4 plus an autopkgtest to prevent such troubles in the future. Upload is requested. All the best, Stefan > After reinstalling again, the duplicity is gone, most probably a local > issue. > > The issue with "package req xotcl::serializer" persists, though. > > Kind regards, > Héctor > > > > ___ > Pkg-tcltk-devel mailing list > pkg-tcltk-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-tcltk-devel > -- Institute for Information Systems and New Media WU Vienna, Austria Welthandelsplatz 1, Building D2, A-1020 Vienna stefan.sober...@wu.ac.at http://nm.wu.ac.at/en/sobernig t. +43-1-31336-4878 f. +43-1-31336-90-4878
Bug#840155: [Pkg-tcltk-devel] Bug#840155: xotcl: please make the build reproducible
Hi Chris! >> Would you consider applying this patch and uploading? > > Friendly ping on this :) I prepared an package revision incl. a variant of the patch, and already asked for upload. Sry for the long'ish delay. Stefan
Bug#840155: [Pkg-tcltk-devel] Bug#840155: xotcl: please make the build reproducible
My apologies:
> ...
> foreach {f fb} [lsort $fileList] {
> ...
The correct patch is:
...
foreach {f fb} [lsort -stride 2 $fileList] {
...
(assuming it is correct to assume Tcl 8.6 to be the default build-dep).
Stefan
Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible
> is it in svn it is at the tip of the svn trunk. thank you! //stefan
Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible
Hi Chris, > ie. src:nfs is currently reproducible on all our platform/dist combinations. > Hope that helps. :) Thank you, this is re-assuring! Stefan
Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible
Hi all, >> But then I discovered that due to the >> > still unfixed #821962 xotcl is already on the list of to be removed >> > packages. >> > Since I use neither xotcl nor aolserver I would currently refrain >> > from trying to support unmaintained packages further. But I'm putting >> > Stefan on CC in case he missed the mailinglist mails. > I am happy to play my part (xotcl). I prepared a package revision to account for https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797543. @Sven: Can I kind askly you to check and upload the revised xotcl package? All the best, Stefan
Bug#797543: [Pkg-tcltk-devel] Bug#797543: xotcl: please make the build reproducible
Hi Chris, Hi Sven, Thanks for re-entering me into the loop. I am afraid, I don't know why, but I have never received any mailing list emails. Just checked my archive. I would have acted earlier (I am not checking the PTS sites regularly, should have probably.) >> There hasn't seem to be any update on this bug in 348 days, in which >> time the Reproducible Builds effort has come on a long way. :) >> >> Would you consider applying this patch and uploading? > > Since I once upon a time sponsored the upload of xotcl I just > considered doing a NMU. > But then I discovered that due to the > still unfixed #821962 xotcl is already on the list of to be removed > packages. > Since I use neither xotcl nor aolserver I would currently refrain > from trying to support unmaintained packages further. But I'm putting > Stefan on CC in case he missed the mailinglist mails. I am happy to play my part (xotcl). As for 821962, Sergei Golovan replied to the aolserver list that he would take care of it? Frankie has not been very responsive as AOLServer maintainer for the last two years. As for xotcl: XOTcl continues playing some role (will be maintained), but will be phased out for NSF/XOTcl 2 over time. But I prefer to see the xotcl debian package alive. Ad "Reproducible Builds": Has the RB toolchain been tested on https://packages.qa.debian.org/n/nsf.html successfully? Do we need to take care of anything? All the best, Stefan
Bug#793845: nsf: FTBFS on Linux due to test suite errors
Thx for this help! Did you test on the very same buildd/porterbox which reports the issue: hasse.debian.org; or any other armhf/mipsel box? I don't have access to the autobuilders, on which logins are restricted to their actual maintainers. Rather, my test builds were on harris.debian.org (armhf) and eder.debian.org (mipsel). On debian-admin I was told that abel.debian.org has the same hardware as hasse.debian.org, and is a porterbox. It will take some time till I can sign up and get sponsoring for a guest account there, any chance that you can give it a try on abel.debian.org and report back (maybe including a core dump)? Thank you for considering it. Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793845: nsf: FTBFS on Linux due to test suite errors
Thx for this help! Did you test on the very same buildd/porterbox which reports the issue: hasse.debian.org; or any other armhf/mipsel box? I don't have access to the autobuilders, on which logins are restricted to their actual maintainers. Rather, my test builds were on harris.debian.org (armhf) and eder.debian.org (mipsel). On debian-admin I was told that abel.debian.org has the same hardware as hasse.debian.org, and is a porterbox. It will take some time till I can sign up and get sponsoring for a guest account there, any chance that you can give it a try on abel.debian.org and report back (maybe including a core dump)? Thank you for considering it. 2.0.0-2 builds successfully for armhf/mipsel on boxes other than hasse?! https://buildd.debian.org/status/package.php?p=nsfsuite=unstable And there is no change to 2.0.0-2 other than disabling the HTTP tests. I would still appreciate it if you could test on abel. Thx. //stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793845: nsf: FTBFS on Linux due to test suite errors
Hi Aaron! How can I best simulate the environment at the buildd box? Is there a chance to obtain a core dump from the buildd box, alternatively? I'm not aware of a way to get core dumps off of autobuilders, though perhaps if you asked their maintainers nicely, they might be able to help you out. I tried building the package on a physical porterbox of each architecture, but wasn't able to reproduce the error on either, so I'm not sure why the automatic builds failed. Thx for this help! Did you test on the very same buildd/porterbox which reports the issue: hasse.debian.org; or any other armhf/mipsel box? Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793845: nsf: FTBFS on Linux due to test suite errors
Builds of nsf on Linux architectures failed with test suite errors, of two types. (There was also a kFreeBSD failure, which I'll report separately.) On armhf and mipsel, the linearization test segfaults when done: We will certainly look at these a.s.a.p. I tried to reproduce the issue, but sadly I failed in doing so. In my (emulated) armhf environment, building the package succeeds. Details on my build environment (QEMU-powered Debian sid ARMHF guest on Ubuntu host): # cat /etc/debian_version stretch/sid # uname -a Linux debian-armhf 3.2.0-4-vexpress #1 SMP Debian 3.2.51-1 armv7l GNU/Linux # apt-show-versions build-essential debhelper tcllib gcc tcl tcl-dev tcl8.6 build-essential:armhf/sid 11.7 uptodate debhelper:all/sid 9.20150628 uptodate gcc:armhf/sid 4:4.9.2-4 uptodate tcl:armhf/sid 8.6.0+8 uptodate tcl-dev:armhf/sid 8.6.0+8 uptodate tcl8.6:armhf/sid 8.6.4+dfsg-2 uptodate tcllib:all/sid 1.17-dfsg-1 uptodate What I did: apt-get source nsf apt-get build-dep nsf cd nsf-2.0.0 dpkg-buildpackage -us -uc gives me -rw-r--r-- 1 root root 303662 Jul 30 11:49 ../nsf_2.0.0-1_armhf.deb -rw-r--r-- 1 root root 25394 Jul 30 11:49 ../nsf-dev_2.0.0-1_armhf.deb -rw-r--r-- 1 root root 20870 Jul 30 11:49 ../nsf-shells_2.0.0-1_all.deb How can I best simulate the environment at the buildd box? Is there a chance to obtain a core dump from the buildd box, alternatively? Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793845: nsf: FTBFS on Linux due to test suite errors
Hi Aaron! Thx for reporting, I had already noticed the failing builds. Builds of nsf on Linux architectures failed with test suite errors, of two types. (There was also a kFreeBSD failure, which I'll report separately.) On armhf and mipsel, the linearization test segfaults when done: We will certainly look at these a.s.a.p. On the remaining Linux architectures, the http test times out, perhaps due to idiosyncracies of buildd network configuration: !!!::req1 (2): Connection refused by host 'localhost' port '8086' error flushing sock949f8a8: socket is not connected!!! xocomm/test.001: incorrect result for 'Trying to load image logo-100.jpg ... ', expected: '1', got 0 Mmmh. I tested in my build environments in various configurations (amd64, i386). the connection tests suceed. How can I learn more about these buildd limitations you hinted at? Are certain ports locked down etc.? If I cannot ship around those limitations, what is the authoritative approach then: disable these network I/O tests? Cheers, Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793845: nsf: FTBFS on Linux due to test suite errors
On the remaining Linux architectures, the http test times out, perhaps due to idiosyncracies of buildd network configuration: !!!::req1 (2): Connection refused by host 'localhost' port '8086' error flushing sock949f8a8: socket is not connected!!! xocomm/test.001: incorrect result for 'Trying to load image logo-100.jpg ... ', expected: '1', got 0 Mmmh. I tested in my build environments in various configurations (amd64, i386). the connection tests suceed. How can I learn more about these buildd limitations you hinted at? Are certain ports locked down etc.? If I cannot ship around those limitations, what is the authoritative approach then: disable these network I/O tests? https://wiki.debian.org/buildd says one should not rely on any network (interface) being available, so (conditionally) disabling those tests is the way to go? Stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766486: ITP: nsf -- The Next Scripting Framework (for short: NSF) is an infrastructure for creating object-oriented scripting languages based on Tcl. See http://next-scripting.org/.
Package: wnpp Severity: wishlist Owner: Stefan Sobernig stefan.sober...@wu.ac.at * Package name: nsf Version : 2.0b6 Upstream Author : Stefan Sobernig stefan.sober...@wu.ac.at * URL : http://next-scripting.org/ * License : MIT Programming Lang: C, Tcl Description : The Next Scripting Framework (for short: NSF) is an infrastructure for creating object-oriented scripting languages based on Tcl. See http://next-scripting.org/. The Next Scripting Framework (for short: NSF) is an infrastructure for creating object-oriented scripting languages based on Tcl. This package provides two ready-made object-orientated extensions for Tcl based on NSF: Next Scripting Language (NX, pronounced next) and Extended Object Tcl version 2 (XOTcl2, pronounced exotickle). NSF and the two languages are direct successors of XOTcl (http://www.xotcl.org/), which is actively maintained as a Debian package (jointly with the Debian Tcl/Tk packaging team). NSF/NX, NSF/XOTcl2 and applications written using them are deployed in and along with production-grade software systems, such as Learn@WU (http://learn.wu.ac.at/), OpenACS (http://openacs.org/), and AOLServer/NaviServer. I plan to maintain the NSF Debian package inside the Debian Tcl/Tk packaging team. In this context, I am already responsible for two other packages. See https://qa.debian.org/developer.php?login=stefan.sobernig%40wu-wien.ac.at. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651969: [Pkg-tcltk-devel] request for upload / XOTcl 1.6.7 upstream release
Sven, I refrain from uploading that right now, in case you can come up with something more appropriate. Sven, I refrain from uploading that right now, in case you can come up with something more appropriate. I was desperately looking for the quirk in the source package, only to find out in the end that the upstream tarball itself contained the built artifact (actually, a couple of *.o and the one *.so): % debian/rules get-orig-source % tar -tzf xotcl_1.6.7.orig.tar.gz | fgrep .so - xotcl-1.6.7/library/store/XOTclSdbm/libxotclsdbm1.2.so Grmpf. I rebuilt our distribution archive, now % debian/rules get-orig-source ... delivers a clean upstream distribution there should not be any need for patching the source package as such. Thx, anyways, for your quick fix suggestion. I can't explain to myself how they ended up in the release tarball, I need to check back with my colleagues. Could you upload again, please, so the new orig tarball is picked up? Sorry for the inconvenience, Thx //stefan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#651969: [Pkg-tcltk-devel] request for upload / XOTcl 1.6.7 upstream release
Sven, Thx for taking of uploading! Uploaded but it FTBFS. Yes, there are several .o and .so files left over by the build system. Until that's fixed I could offer a very quick and ugly workaround (attached). I refrain from uploading that right now, in case you can come up with something more appropriate. Interesting. I am a little puzzled why these build artifacts remain in the first place; and why this poses a problem for this upload, for the first time (provided that I haven't missed the obvious). mh. //s -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#560950: --with-expat=sys will be fully supported in upcoming upstream release (1.6.6)
Alex, Moritz, Moritz is actually right, your --with-expat=sys is a mere placebo treatment. this flag has just been added to the xotcl build system in response to the debian security bulletins. the upcoming 1.6.6 release provides support for shared expat. i hope that the upstream release will be show up soon, i will then push it into debian asap! Stefan -- Institute for Information Systems and New Media Vienna University of Economics and Business Augasse 2-6, A-1090 Vienna `- http://nm.wu.ac.at/en/sobernig `- stefan.sober...@wu.ac.at `- s...@thinkersfoot.net `- +43-1-31336-4878 [phone] `- +43-1-31336-746 [fax] -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#467502: ITP: xotcl -- Extended Object Tcl (XOTcl) is an object-oriented scripting language based on Tcl
Package: wnpp Severity: wishlist Owner: Stefan Sobernig [EMAIL PROTECTED] * Package name: xotcl Version : 1.6.0+ Upstream Author : Gustaf Neumann [EMAIL PROTECTED], Uwe Zdun [EMAIL PROTECTED] * URL : http://www.xotcl.org/ * License : BSD Programming Lang: Tcl Description : Extended Object Tcl (XOTcl) is an object-oriented scripting language based on Tcl Extended Object Tcl (for short: XOTcl, pronounced exotickle) is an object-oriented scripting language based on Tcl. It was originally designed for providing language support for design patterns and provides novel constructs such as filters or transitive mixin classes. The language is designed for empowering rather than constraining system developers. The basic object model is highly influenced by CLOS. Learn more at http://www.xotcl.org. -- System Information: Debian Release: 4.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18-5-686 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
