Bug#1029448: alire in Debian; dependencies of the package
Stephane Carrez writes: > Alire does not directly use XML/Ada nor GNATPRJ. > These shared libraries are linked/used by libgnatcoll.so.21 and > libgnatprj.so.10. Ah, ok, in that case the dependencies are already handled i.e. the package libgnatcoll21 depends on libxmlada-* and libgnatprj10. So you don't need to do anything more. I'll try to upload. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
> Depends: libc6 (>= 2.34), libgcc-s1 (>= 3.0), libgnat-12 (>= 12.2.0), > libgnatcoll21 (>= 23.0.0), libxmlezout7 (>= 1.06.2) is at odds with > ciceron@theia:~/debian$ ldd /usr/bin/alr > linux-vdso.so.1 (0x7ffc36dca000) > libgnatcoll.so.21 => /lib/x86_64-linux-gnu/libgnatcoll.so.21 > (0x7f1508e0) > libxmlezout.so.7 => /lib/x86_64-linux-gnu/libxmlezout.so.7 > (0x7f150a71b000) > libgnarl-12.so => /lib/x86_64-linux-gnu/libgnarl-12.so > (0x7f150a6cf000) > libgnat-12.so => /lib/x86_64-linux-gnu/libgnat-12.so > (0x7f150880) > libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 > (0x7f150a6af000) > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f150861f000) > libgnatprj.so.10 => /lib/x86_64-linux-gnu/libgnatprj.so.10 > (0x7f1507c0) > libxmlada_schema.so.7 => /lib/x86_64-linux-gnu/libxmlada_schema.so.7 > (0x7f150a5d7000) > libxmlada_dom.so.8 => /lib/x86_64-linux-gnu/libxmlada_dom.so.8 > (0x7f15095de000) > libxmlada_sax.so.7 => /lib/x86_64-linux-gnu/libxmlada_sax.so.7 > (0x7f150958c000) > libxmlada_input.so.7 => /lib/x86_64-linux-gnu/libxmlada_input.so.7 > (0x7f150957d000) > libxmlada_unicode.so.7 => > /lib/x86_64-linux-gnu/libxmlada_unicode.so.7 (0x7f150780) > /lib64/ld-linux-x86-64.so.2 (0x7f150a741000) > libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f150949e000) You need to add libgnatprj10, libxmlada-schema7 etc. to the dependencies; preferably in an automated way. You're almost there, keep up the good work. Also, I've checked that no existing package provides a file named /usr/bin/alr, so you're good in that respect. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
Stephane Carrez writes: > By not depending on the GNAT compiler installed, you can use Alire with > several newer > or older compiler as you wish. This may be fine on operating systems that lack a package manager but this contradicts the Debian Ada Policy, which requires all Ada packages to depend on the same gnat compiler. Therefore, please package alire in such a way that the binary package depends on, and uses, the existing Debian packages i.e. gnat-12, libgnatcoll21 and libxmlezout7 at run-time, and build-depends and uses the corresponding -dev packages at compile time. -- Ludovic Brenta.
Bug#1029448: alire in Debian; dependencies of the package
Here is what I get with dpkg --info alire_1.2.1-2_amd64.deb after building it: new Debian package, version 2.0. size 3434464 bytes: control archive=1560 bytes. 476 bytes,13 lines control 2386 bytes,35 lines md5sums Package: alire Version: 1.2.1-2 Architecture: amd64 Maintainer: Stephane Carrez Installed-Size: 17740 Depends: libc6 (>= 2.35) Section: devel Priority: optional Homepage: https://github.com/alire-project Description: Ada package manager. A catalog of ready-to-use Ada libraries plus a command-line tool (`alr`) to obtain, build, and incorporate them into your own projects. It aims to fulfill a similar role to Rust's `cargo` or OCaml's `opam`. As you can see, it does not depend on libgnat-12 and does not even recommend gnat. This seems suspicious to me. Could you please check that the dependencies are generated correctly? -- Ludovic Brenta.
Bug#1029448: Debian package for Alire 1.2.1
OK, after a little struggling I managed to build the package (notably, g...@github.com:alire-project/alire.git requires permissions which I don't have, used https://github.com/alire-project/alire.git). During the build I noticed that alire pulls and recompiles several libraries it depends on. This violates Debian policy; a Debian package must never duplicate another. I notice gnatcoll and xmlezout among the dependencies that are already packaged for Debian. There may be others I didn't see. Therefore, please update the packaging of alire to build-depend on these existing packages and not to recompile them from source. I have filed bug #1029448 to track the introduction of alire into Debian. A Debian bug is also a dedicated, public mailing list: in this case, 1029...@bugs.debian.org. -- Ludovic Brenta.
Bug#1029448: ITP: alire -- Package manager for Ada sources
Package: wnpp Owner: Ludovic Brenta Severity: wishlist * Package name: alire Version : 1.2.1 Upstream Author : Alejandro R. Mosteo and others * URL or Web page : https://github.com/alire-project * License : GPLv3 Description : Package manager for Ada sources ALIRE: Ada LIbrary REpository. A catalog of ready-to-use Ada libraries plus a command-line tool (alr) to obtain, build, and incorporate them into your own projects. It aims to fulfill a similar role to Rust's cargo or OCaml's opam. This is a source package manager, in contrast to apt which is a binary package manager. -- Ludovic Brenta.
Bug#1029405: flightgear: crashes on receiving some real-time weather reports
Package: flightgear Version: 1:2020.3.16+dfsg-1+b2 Severity: important Forwarded: https://sourceforge.net/p/flightgear/codetickets/2765/ Tags: upstream fixed-upstream When real-time weather is enabled, some METAR strings received from the weather servers can cause fgfs to crash. A workaround is to disable real-time weather, an important feature of flightgear. This upstream commit fixes; it would be nice if it were backported before the freeze of bookworm. https://sourceforge.net/p/flightgear/flightgear/ci/86f82994bec00ecbe791b61530b229b22c7d51c8 Thank you! -- Ludovic Brenta.
Bug#1027065: Clarification
On bookworm (testing) I get:
$ gm2 --version
gm2 (Debian 12.2.0-10) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gm2 hello.mod
hello.mod:1:2: error: expecting one of: ‘IMPLEMENTATION’ ‘MODULE’ ‘DEFINITION’
1 | FROM StrIO IMPORT WriteString, WriteLn;
| ^~~~
hello.mod:1:2: error: compilation failed
Adding a first line, "MODULE hello;" makes the program legal but then I
get the same symptoms as in the original bug report.
Adding -fpim2 or -fpim3 to the compiler command line has no effect.
Adding -fiso silences the compiler even though StrIO is not an ISO
module. Therefore a complete workaround is:
$ cat hello.mod
MODULE hello;
FROM StrIO IMPORT WriteString, WriteLn;
BEGIN
WriteString('hello world');
WriteLn
END hello.
$ gm2 -fiso hello.mod -o hello
$ ./hello
hello world
It seems that libm2pim.so lacks some necessary functions which
libm2iso.so has.
--
Ludovic Brenta.
Bug#1015974: Should gnat-gps be removed?
severity 1015974 normal retitle 1015974 gnat-gps: new version available using python 3 thanks Upstream has finally migrated gnat-gps to python 3 but too late for Debian 11. We will package the new upstream version as part of the next Ada transition (to gnat-12 or gnat-13). In the mean time, this package will remain in unstable. -- Ludovic Brenta.
Bug#496905: RFH: gnat-gps -- integrated development environment for C and Ada
The packaging scripts have migrated to salsa: https://salsa.debian.org/debian/gnat-gps -- Ludovic Brenta.
Bug#970660: ghdl: Please migrate to gnat-10
Package: ghdl Severity: wishlist X-Debbugs-Cc: Ludovic Brenta Hello! As discussed on the debian-ada mailing list[1], we are migrating all packages containing Ada sources to gnat-10. It is likely that gnat-9 will be removed from Debian before the freeze (and the severity of this bug will then increase). Therefore, please update ghdl to build with gnat-10 and gcc-10-source. I have checked that the simple patch below results in a successful build: [1] https://lists.debian.org/debian-ada/2020/09/msg0.html diff --git a/debian/control b/debian/control index ea850c26..9e6082ee 100644 --- a/debian/control +++ b/debian/control @@ -4,8 +4,8 @@ Priority: optional Maintainer: Debian Electronics Team Uploaders: Andreas Bombe Build-Depends: debhelper (>= 11), - gnat-9, - gcc-9-source , + gnat-10, + gcc-10-source , libisl-dev (>= 0.14) , libmpc-dev (>= 1.0) , libmpfr-dev (>= 3.0.0-9~) , diff --git a/debian/rules b/debian/rules index 81ad8ac5..ad67d6b3 100755 --- a/debian/rules +++ b/debian/rules @@ -6,17 +6,17 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all,-format #export DH_VERBOSE = 1 +# These variables are used to find and unpack the gcc source +GCC_VER := 10 +GCC_DIR := /usr/src/gcc-$(GCC_VER) +GCC_TARBALL := $(notdir $(wildcard $(GCC_DIR)/gcc-*.tar.*)) + include /usr/share/dpkg/default.mk -include /usr/share/ada/debian_packaging-9.mk +include /usr/share/ada/debian_packaging-$(GCC_VER).mk # This variable is used in Makefile.in to adjust src/version.in export PKG_VERSION := $(DEB_VENDOR) $(DEB_VERSION) -# These variables are used to find and unpack the gcc source -GCC_DIR := /usr/src/gcc-9 -GCC_VER := 9 -GCC_TARBALL := $(notdir $(wildcard $(GCC_DIR)/gcc-*.tar.*)) - # Get parallel option to parallelize the gcc build specifically (Ada builds # are already parallelized by code included from debian_packaging-*.mk above). ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) -- Ludovic Brenta.
Bug#956606: ITP: libsdlada2 -- Ada binding to SDL2
Package: wnpp Owner: Ludovic Brenta Severity: wishlist * Package name: libsdlada2 Version : 2.4.0 Upstream Author : Luke A. Guest * URL or Web page : https://github.com/Lucretia/sdlada * License : zlib/libpng Description : Ada binding to SDL2 -- Ludovic Brenta.
Bug#950747: projectl: Projectl fails to run with current libgphobos76
severity 951294 important severity 951423 important merge 950747 951294 951423 thanks Hi Matthias, I thought you were going to make gcc-9 (and gnat-9, for Ada) the default in the medium term and migrate to gcc-10 only later. Maybe I misunderstood? Can you please clarify? Are binNMUs planned for all other packages affected? -- Ludovic Brenta.
Bug#951423: gunroar: symbol lookup error: gunroar: undefined symbol: _D4core4stdc5errno5errnoFNbNdNiNeZi
Come to think of it, the problem might also be that the package libphobos76 retained the soname of version 8 but changed the name mangling in version 9. -- Ludovic Brenta.
Bug#951423: gunroar: symbol lookup error: gunroar: undefined symbol: _D4core4stdc5errno5errnoFNbNdNiNeZi
86_64-linux-gnu/libXdmcp.so.6 (0x7f02655b7000) libXcursor.so.1 => /usr/lib/x86_64-linux-gnu/libXcursor.so.1 (0x7f02655aa000) libXinerama.so.1 => /usr/lib/x86_64-linux-gnu/libXinerama.so.1 (0x7f02655a5000) libXi.so.6 => /usr/lib/x86_64-linux-gnu/libXi.so.6 (0x7f0265395000) libXrandr.so.2 => /usr/lib/x86_64-linux-gnu/libXrandr.so.2 (0x7f026518a000) libXss.so.1 => /usr/lib/x86_64-linux-gnu/libXss.so.1 (0x7f0265183000) libXxf86vm.so.1 => /usr/lib/x86_64-linux-gnu/libXxf86vm.so.1 (0x7f0264f7d000) libwayland-egl.so.1 => /usr/lib/x86_64-linux-gnu/libwayland-egl.so.1 (0x7f0264f78000) libwayland-client.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-client.so.0 (0x7f0264f67000) libwayland-cursor.so.0 => /usr/lib/x86_64-linux-gnu/libwayland-cursor.so.0 (0x7f0264f5e000) libxkbcommon.so.0 => /usr/lib/x86_64-linux-gnu/libxkbcommon.so.0 (0x7f0264f1b000) libsndio.so.7.0 => /usr/lib/x86_64-linux-gnu/libsndio.so.7.0 (0x7f0264f07000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x7f0264e93000) libopus.so.0 => /usr/lib/x86_64-linux-gnu/libopus.so.0 (0x7f0264e38000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x7f0264d8d000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f0264d64000) liblz4.so.1 => /usr/lib/x86_64-linux-gnu/liblz4.so.1 (0x7f0264d4) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x7f0264c23000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7f0264c09000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7f0264bf1000) libbsd.so.0 => /usr/lib/x86_64-linux-gnu/libbsd.so.0 (0x7f0264bd7000) libXrender.so.1 => /usr/lib/x86_64-linux-gnu/libXrender.so.1 (0x7f02649cd000) libXfixes.so.3 => /usr/lib/x86_64-linux-gnu/libXfixes.so.3 (0x7f02647c5000) libffi.so.7 => /usr/lib/x86_64-linux-gnu/libffi.so.7 (0x7f02647b9000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x7f0264796000) -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.4.0-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages gunroar depends on: ii gunroar-data0.15.dfsg1-9 ii libc6 2.29-10 ii libgcc-s1 [libgcc1] 10-20200211-1 ii libgcc1 1:10-20200211-1 ii libgl1 1.3.0-7 ii libglu1-mesa [libglu1] 9.0.1-1 ii libgphobos76 9.2.1-28 ii libsdl-mixer1.2 1.2.12-16+b1 ii libsdl1.2debian 1.2.15+dfsg2-5 gunroar recommends no packages. gunroar suggests no packages. -- no debconf information -- Ludovic Brenta. The clients repurpose a glocalization.
Bug#950490: transition: gnat-9, Ada component of GCC-9
Nicolas Boulenguez writes: > When would a reupload to unstable be appropriate? I'd rather ask: what blocks the transition now? I see gcc-10 has already migrated to testing as of today, so perhaps uploading gnat-9 to unstable can be done immediately? -- Ludovic Brenta. Leadership strategies energize the market thinkers, relative to our peers.
Bug#928122: mesa-utils: DRI_PRIME ignored, integrated graphics processing unit always used
Package: mesa-utils Version: 8.4.0-1+b1 Severity: normal Hello, I have a high-end laptop from 2012 with an intel integrated graphics and a discrete Radeon card with 2 GB VRAM. This has been working perfectly well for years, i.e. I could select the discrete graphics card with DRI_PRIME=1. Yesterday however, DRI_PRIME stopped working after I cleaned up the internal fans of the CPU and discrete GPU (I do that once a year approximately) and rebooting (which booted a newer kernel and possibly a new Xorg server; I don't normally reboot more than once every two or three months). While I cannot yet rule out a hardware problem, I would like some guidance as to where to look for additional clues. All of xrandr, vga_switcheroo and radeontop see the discrete GPU. I am not sure which package to report this against; I've selected mesa-utils because glxinfo exposes the problem. Please feel free to reassign or tell me if I've done anything wrong. Here are the details that I have gathered so far. The problem is I can see no error message whatsoever that would explain why DRI_PRIME=1 does not select the discrete GPU. $ uname -a Linux samuel 4.19.0-4-amd64 #1 SMP Debian 4.19.28-2 (2019-03-15) x86_64 GNU/Linux $ lspci -v 00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09) Subsystem: CLEVO/KAPOK Computer 3rd Gen Core processor DRAM Controller Flags: bus master, fast devsel, latency 0 Capabilities: Kernel driver in use: ivb_uncore 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=01, subordinate=01, sec-latency=0 I/O behind bridge: e000-efff Memory behind bridge: f7b0-f7bf Prefetchable memory behind bridge: e000-efff Capabilities: Kernel driver in use: pcieport 00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: CLEVO/KAPOK Computer 3rd Gen Core processor Graphics Controller Flags: bus master, fast devsel, latency 0, IRQ 31 Memory at f740 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at f000 [size=64] [virtual] Expansion ROM at 000c [disabled] [size=128K] Capabilities: Kernel driver in use: i915 Kernel modules: i915 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) (prog-if 30 [XHCI]) Subsystem: CLEVO/KAPOK Computer 7 Series/C210 Series Chipset Family USB xHCI Host Controller Flags: bus master, medium devsel, latency 0, IRQ 29 Memory at f7c0 (64-bit, non-prefetchable) [size=64K] Capabilities: Kernel driver in use: xhci_hcd Kernel modules: xhci_pci 00:16.0 Communication controller: Intel Corporation 7 Series/C216 Chipset Family MEI Controller #1 (rev 04) Subsystem: CLEVO/KAPOK Computer 7 Series/C216 Chipset Family MEI Controller Flags: bus master, fast devsel, latency 0, IRQ 30 Memory at f7c1b000 (64-bit, non-prefetchable) [size=16] Capabilities: Kernel driver in use: mei_me Kernel modules: mei_me 00:1a.0 USB controller: Intel Corporation 7 Series/C216 Chipset Family USB Enhanced Host Controller #2 (rev 04) (prog-if 20 [EHCI]) Subsystem: CLEVO/KAPOK Computer 7 Series/C216 Chipset Family USB Enhanced Host Controller Flags: bus master, medium devsel, latency 0, IRQ 16 Memory at f7c18000 (32-bit, non-prefetchable) [size=1K] Capabilities: Kernel driver in use: ehci-pci Kernel modules: ehci_pci 00:1b.0 Audio device: Intel Corporation 7 Series/C216 Chipset Family High Definition Audio Controller (rev 04) Subsystem: CLEVO/KAPOK Computer 7 Series/C216 Chipset Family High Definition Audio Controller Flags: bus master, fast devsel, latency 0, IRQ 33 Memory at f7c1 (64-bit, non-prefetchable) [size=16K] Capabilities: Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel 00:1c.0 PCI bridge: Intel Corporation 7 Series/C216 Chipset Family PCI Express Root Port 1 (rev c4) (prog-if 00 [Normal decode]) Flags: bus master, fast devsel, latency 0, IRQ 16 Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 I/O behind bridge: 2000-2fff Memory behind bridge: cfb0-cfcf Prefetchable memory behind bridge: 00042f60-00042f7f Capabilities: Kernel driver in use: pcieport 00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4) (prog-if 00 [Normal decode])
Bug#913371: gnat-gps fails to build on 32-bit kernels, address space exhaustion.
I think this is the best way forward. -- Ludovic Brenta.
Bug#901121: turing: missing dependency on python3-matplotlib
Package: turing Version: 0.10~beta-1 Severity: serious Dear Maintainer, Launching turing on the command line yields: QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-lbrenta' NoneType: None Traceback (most recent call last): File "/usr/share/turing/src/main.py", line 86, in from forms import mainwindow File "/usr/share/turing/src/forms/mainwindow.py", line 15, in from matplotlib.axes import Axes ModuleNotFoundError: No module named 'matplotlib' Installing the package python3-matplotlib solves this problem. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages turing depends on: ii python3 3.6.5-3 ii python3-altgraph0.15~repack0-2 ii python3-autopep81.3.5-2 ii python3-cycler 0.10.0-1 ii python3-dateutil2.6.1-1 ii python3-docutils0.14+dfsg-3 ii python3-future 0.15.2-4 ii python3-jedi0.11.1-1 ii python3-kiwisolver 1.0.1-2 ii python3-macholib1.9+repack0-1 ii python3-numpy 1:1.14.3-2 ii python3-parso 0.1.1-1 ii python3-pefile 2017.11.5-2 ii python3-pep81.7.1-1 ii python3-pyflakes1.6.0-1 ii python3-pygments2.2.0+dfsg-1 ii python3-pyparsing 2.2.0+dfsg1-2 ii python3-pyqt5 5.10.1+dfsg-2 ii python3-tz 2018.4-1 turing recommends no packages. turing suggests no packages. -- no debconf information
Bug#897234: raspi3-firmware: please add support for Raspberry Pi 3 B+
package: raspi3-firmware version: 1.20180316-3 severity: wishlist According to [1] and my recent personal experience, the latest revision of the Raspberry Pi 3 B+ (revision 1.3) boots but does not bring eth0 or wlan0 up, making the device useless in a headless setting. To support the B+ completely, additional Device Tree Binary files are necessary too, possibly to be provided by the linux-image package; specifically the files /boot/firmware/bcm2708-rpi-b-plus.dtb and /boot/firmware/bcm2710-rpi-b-plus.dtb are missing from buster but present in [2]. The latest firware update upstream is dated 2018-04-18[3]. [1] https://www.raspberrypi.org/forums/viewtopic.php?f=28=58151 [2] https://github.com/raspberrypi/firmware/tree/master/boot [3] http://downloads.raspberrypi.org/raspbian/release_notes.txt -- Ludovic Brenta.
Bug#814978: gcc-5: gnat paths are wrong due to ada-gcc-name.diff
On Wed, 17 Feb 2016 11:50:04 +0100, Matthias Klose wrote: this might be a bad merge/update; Ludovic, Nicolas, could you have a look? GCC 6 likely has the same issue. Will do. -- Ludovic.
Bug#802838: ada: gnatgcc-5 and gnatmake symlinks
Matthias Klose <d...@debian.org> writes: > I've never understood why this link moved to the versioned gnat > package and didn't stay in the unversioned gnat package. So maybe we > changed that when preparing the ada cross compiler? > > The cross compiler builds shouldn't ship such unversioned links at > all. I very much would prefer to have these links in the unversioned > gnat package again. My first reaction is to agree wholeheartedly but one of Nicolas' greatest qualities is that he discusses and documents such changes beforehand: https://lists.debian.org/debian-ada/2014/04/msg0.html I think the problem he wanted to solve was to be able to build gnat-x.y with itself even during the transition period when gnat pointed to an earlier, or later, on nonexistent, gnat-x'.y'. Now I'm not sure how such a situation could arise, or how it could prevent building gnat-x.y. > Not sure about gnatmake and others. I'm not an gnat developer. If it > is possible that the versioned tools can be used on its own, then > again I would prefer to ship these in the gnat package. No, the "versioned" tools cannot be used on their own. We don't want to require users to type gnatmake-x.y instead of gnatmake; and there is a whole bunch of user-facing programs that call each other, too, like gnatls, gprbuild, etc. -- Ludovic Brenta.
Bug#785760: gnat-gps: Location view is not shown
LOS Stéphane wrote: Are you working on the bug or not ? In my spare time at home, yes. I have not made much progress yet because spare time is a _very_ scarce resource for me :/ If you are interested in investigating this bug, the first step is to aptitude install gnat-gps-dbg and the sources and run gps under gdb, then extract the stack trace of where the exceptions are being raised. Try to establish whether or not there is a link between the assertion failures and the later access check failures. If you want to recompile from source, apt-get source and dpkg-buildpackage are your friends. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785760: gnat-gps: Location view is not shown
Stéphane LOS wrote: Since some time now it does not appear anymore either on my Debian Sid or in Jessie. I think it was still working around beginning of April. I have tried to delete the .gps folder so that it gets recreated anew but that does not help. Maybe the file ~/.gps/gps.log (or a similar name) contains useful information about the reason for the problem? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785760: gnat-gps: Location view is not shown
I believe the bug is in GtkAda. In gtk-tree_model.ads, it declares: Signal_Row_Changed : constant Glib.Signal_Name := row_changed; Signal_Row_Inserted : constant Glib.Signal_Name := row_inserted; Signal_Row_Has_Child_Toggled : constant Glib.Signal_Name := row_has_child_toggled; Signal_Row_Deleted : constant Glib.Signal_Name := row_deleted; Signal_Rows_Reordered: constant Glib.Signal_Name := rows_reordered; but the log file contains: [BUILDER] 2/473 Project view changed, loading xref in memory (14:17:15.933) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 1/480 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.40) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 2/481 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.41) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 3/482 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.41) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 4/483 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.41) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 5/484 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.41) [UNEXPECTED_EXCEPTION.EXCEPTIONS] 6/485 Unexpected exception: Exception name: SYSTEM.ASSERTIONS.ASSERT_FAILURE _UNEXPECTED_EXCEPTION.EXCEPTIONS_ Message: Trying to connect to unknown signal (row_inserted) on type GtkAdaAbstractTreeModel (14:17:16.42) The correct name for the signal appears to be row-inserted (note: s/_/-/). The spelling with _ was probably accepted by earlier versions of GTK+ and now rejected since April. To be confirmed by patching and recompiling GtkAda and then recompiling gnat-gps. Alternatively, try downgrading libgtk+2.0 and see what happens. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785760: gnat-gps: Location view is not shown
On Wed, 20 May 2015 23:29:59 +0200, Stéphane LOS wrote: Although your observation makes perfectly sense, there must be a bug raising those exceptions and it should certainly be fixed, I think this is not related to the problem at hand. Those lines may lead to something closer : When I saw these lines I thought they might be a consequence of the signal problem. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769797: marked as done (gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2)
Neil Williams codeh...@debian.org writes: unless you tell me how the b-d gcc-4.9-source ( 4.9.2) is satisfied in unstable, please leave this issue open. That doesn't make sense. gnat-4.9 in unstable has build-dependencies which can be satisfied in unstable. gnat-4.9 in testing has build-dependencies which can be satisfied in testing. Why would the build-dependency gcc-4.9-source ( 4.9.2) in gnat-4.9 in *testing* be relevant when checked in unstable? Correct but I think Matthias' mail alludes to his freeze exception request (#774221) which, if and when granted, will break the build-dependency of gnat-4.9 in testing and require that gnat-4.9 also migrate from unstable to testing; I commented to that effect in the request. So, this bug is technically closed but might resurface in the near future. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774221: freeze exception for gcc-4.8, gcc-4.9, and gcc-defaults
Please note that if and when this freeze exception is granted, it will become necessary also to allow gnat-4.9 into testing because the version currently in testing (gnat-4.9/4.9.1-4) build-depends on gcc-4.9-source/4.9.1-* which will no longer be in testing. gnat-4.9/4.9.2-1 has been in unstable since 2014-11-19. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769797: gnat-4.9: FTBFS: Needs update for gcc-4.9-4.9.2
Matthias Klose writes: known. please wait for the gcc-4.9 4.9.2-2 upload before syncing. OK. Are you planning to request a freeze exception so that 4.9.2 goes into jessie? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767845: flightgear: Frequently crashes when using TerraSync
Package: flightgear Version: 3.0.0-3 Severity: grave Justification: makes TerraSync almost unusable This crash is due to #765855 which has just been fixed in libopenscenegraph100. However, even after upgrading libopenscenegraph100 to 3.2.1-5 the crashes still happen quite frequently, ruining many perfectly good flights (4 times in the past 24 hours for me alone and several people reported similar crashes). The frequency of the crashes appears to increase as new TerraSync data becomes available. According to comment #59, it is necessary to recompile flightgear and possibly simgear in order to benefit from the bug fix. Therefore please upload 3.0.0-4 :) -- Ludovic Brenta. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flightgear depends on: ii flightgear-data-all 3.0.0-1 ii freeglut3 2.8.1-2 ii libc6 2.19-12 ii libdbus-1-3 1.8.8-2 ii libgcc1 1:4.9.1-16 ii libgl1-mesa-glx [libgl1] 10.3.1-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgsm1 1.0.13-4 ii libice6 2:1.0.9-1 ii libjpeg62-turbo 1:1.3.1-8 ii libopenal11:1.15.1-5 ii libopenscenegraph100 3.2.1-5 ii libopenthreads20 3.2.1-5 ii libplib1 1.8.5-7 ii libpng12-01.2.50-2 ii libsimgearcore3.0.0 3.0.0-6 ii libsimgearscene3.0.0 3.0.0-6 ii libsm62:1.2.2-1 ii libspeex1 1.2~rc1.2-1 ii libspeexdsp1 1.2~rc1.2-1 ii libsqlite3-0 3.8.7-1 ii libstdc++64.9.1-16 ii libudev1 215-5+b1 ii libx11-6 2:1.6.2-3 ii libxext6 2:1.3.3-1 ii libxi62:1.7.4-1 ii libxmu6 2:1.1.2-1 ii zlib1g1:1.2.8.dfsg-2 flightgear recommends no packages. flightgear suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767845: flightgear: Frequently crashes when using TerraSync
Actually reproducible now with simply: fgfs --enable-terrasync I suggest that flightgear should tighten its build-dependency on libopenscenegraph100 (= 3.2.1-5). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765855: fixed in openscenegraph 3.2.1-5
-aircrafts3.0.0-1 allFlightGear Flight Simulator -- standard aircraft ii flightgear-data-all 3.0.0-1 allFlightGear Flight Simulator - virtual package ii flightgear-data-base 3.0.0-1 allFlightGear Flight Simulator -- base files ii flightgear-data-models 3.0.0-1 allFlightGear Flight Simulator -- standard models ii libopenscenegraph100:amd64 3.2.1-5 amd64 3D scene graph, shared libs ii libsimgearcore3.0.0:amd643.0.0-6 amd64 Simulator Construction Gear -- core library ii libsimgearcore3.0.0-dbg:amd643.0.0-6 amd64 debugging symbols for libsimgearcore ii libsimgearscene3.0.0:amd64 3.0.0-6 amd64 Simulator Construction Gear -- scene library ii libsimgearscene3.0.0-dbg:amd64 3.0.0-6 amd64 debugging symbols for libsimgearscene Is it necessary to recompile flightgear in order to benefit from the bug fix? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: flightgear: Occasional deadlock when processing key input
Markus Wanner writes: On 10/24/2014 11:47 PM, Rebecca N. Palmer wrote: If it is that, the attached should fix it, but since I've never had this problem myself I can't test it. Could you please try this patch? I'd like to get some indication that it actually fixes the issue, before asking for a freeze exception. Not until next weekend unfortunately, and then again I might not be able to compile everything needed and do the testing, for lack of available time. If you provide precompiled .deb packages on some web site, that would expedite the testing; I could do some on evenings. As this bug has only happened occasionally to me and I don't know what the trigger is, I cannot prove its absence even if I did the testing. Rebecca, do you think there is a way to trigger this bug with certainty? Even if that means modifying the sources to create an artificial trigger for the bug? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: [pkg-fgfs-crew] Bug#750939: flightgear: Occasional deadlock when processing key input
Rebecca N. Palmer wrote: With this, gdb --args fgfs --aircraft=b1900d --airport=NZNV and pressing 'v' a few times reliably triggers it, allowing me to confirm that the patch works. Wow that was more than I hoped for. Is there still a need for me to test Markus' package? Thanks both for everything! -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759038: gnat-4.9: gnat1 and libgnatvsn-dev versions differ
I tried my proposed patch but reverted it. The patch did not solve the problem because the problem was actually simpler; in asis, A4G.GNAT_Int.Tree_In_With_Version_Check would raise an exception whenever Gnatvsn.Gnat_Version_String did *not* contain an opening paren (. ASIS did not actually check that the Gnatvsn.Gnat_Version_String in the compiler (gnat1) was the same as that in libgnatvsn; instead it would try to compare only the date portion of the two strings, assuming this portion was between a ( and a -. Moreover, this was an optional check that the various GNAT tools enabled when they didn't have to. I fixed the problem in asis and uploaded yesterday. Therefore, the actual contents of the Gnatvsn.Gnat_Version_String does not really matter anymore. While I would have preferred simplicity and seeing only $(BASEVER), I made libgnatvsn use $(FULLVER) as well for consistency. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765855: flightgear: crashes on Invercargill, New Zealand
Package: flightgear
Version: 3.0.0-2+b1
Severity: normal
Steps to reproduce:
$ rm -r $HOME/.fgfs/TerraSync/Terrain/e160s50 # contains Invercargill, NZ
$ export OSG_LIBRARY_PATH=$(dirname $(dpkg -L libopenscenegraph100 | grep
libosg.so.3.2.1)) # see #763821
$ gdb fgfs
(gdb) run --enable-terrasync --airport=NZNV # Invercargill triggers the bug
[...]
ERROR: opening $HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688035.btg or
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688035.btg.gz for reading!
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688035.stg: Failed to load
OBJECT_BASE '$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688035.btg'
ERROR: opening $HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688019.btg or
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688019.btg.gz for reading!
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688019.stg: Failed to load
OBJECT_BASE '$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688019.btg'
ERROR: opening $HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688051.btg or
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688051.btg.gz for reading!
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688051.stg: Failed to load
OBJECT_BASE '$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688051.btg'
ERROR: opening $HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688011.btg or
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688011.btg.gz for reading!
$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688011.stg: Failed to load
OBJECT_BASE '$HOME/.fgfs/TerraSync/Terrain/e160s50/e167s47/5688011.btg'
[Thread 0x7fffe8eb0700 (LWP 18712) exited]
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) thread apply all bt full
Thread 15 (Thread 0x7fffc8b80700 (LWP 18727)):
#0 0x7746308f in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x74e77fee in OpenThreads::Condition::wait(OpenThreads::Mutex*) ()
from /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20
No symbol table info available.
#2 0x763de21c in osgDB::DatabasePager::DatabaseThread::run() () from
/usr/lib/x86_64-linux-gnu/libosgDB.so.100
No symbol table info available.
#3 0x74e77a28 in OpenThreads::ThreadPrivateActions::StartThread(void*)
() from /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20
No symbol table info available.
#4 0x7745f0a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5 0x71e3cc2d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Thread 14 (Thread 0x7fffca414700 (LWP 18726)):
#0 0x7746308f in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x74e77fee in OpenThreads::Condition::wait(OpenThreads::Mutex*) ()
from /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20
No symbol table info available.
#2 0x763de21c in osgDB::DatabasePager::DatabaseThread::run() () from
/usr/lib/x86_64-linux-gnu/libosgDB.so.100
No symbol table info available.
#3 0x74e77a28 in OpenThreads::ThreadPrivateActions::StartThread(void*)
() from /usr/lib/x86_64-linux-gnu/libOpenThreads.so.20
No symbol table info available.
#4 0x7745f0a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5 0x71e3cc2d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Thread 13 (Thread 0x7fffeedd9700 (LWP 18719)):
#0 0x7746308f in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#1 0x76bee2eb in pop (this=0x115bbd8) at
/build/simgear-cdeqyX/simgear-3.0.0/simgear/threads/SGQueue.hxx:228
No locals.
#2 LogStreamPrivate::run (this=0x115bbc0) at
/build/simgear-cdeqyX/simgear-3.0.0/simgear/debug/logstream.cxx:261
entry = {debugClass = SG_AI, debugPriority = SG_INFO, file = 0xda0400
/build/flightgear-f1VqEt/flightgear-3.0.0/src/Traffic/TrafficMgr.cxx, line =
564, message = }
#3 0x76cb76ba in SGThread::PrivateData::start_routine (data=optimized
out) at /build/simgear-cdeqyX/simgear-3.0.0/simgear/threads/SGThread.cxx:204
thread = optimized out
#4 0x7745f0a4 in start_thread () from
/lib/x86_64-linux-gnu/libpthread.so.0
No symbol table info available.
#5 0x71e3cc2d in clone () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
Thread 12 (Thread 0x7fffc9713700 (LWP 18718)):
#0 0x71e340ed in poll () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1 0x7fffc996ed26 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2
No symbol table info available.
#2 0x77baeda2 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
No symbol table info available.
#3 0x77ba79da in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1
No symbol table info available.
#4
Bug#765501: freeciv-gtk: should depend on, not recommend, gtk2-engines-pixbuf
Markus Koschany wrote: and why gtk2-engines-pixbuf is neither detected at build-time nor pulled in by other Gnome packages. I mentioned the kind of machine this runs on :) It is not powerful enough to support GNOME so I installed LXDE instead, and only the minimal number of packages. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759038: gnat-4.9: gnat1 and libgnatvsn-dev versions differ
I have committed a proposed change to gcc-base-version.diff as revision 7691. I will try to experiment with this and gnat-4.9 when I have time and will not upload before doko approves of this change. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765482: don't recommend just gdb-minimal
On Wed, 15 Oct 2014 15:56:05 +0200, Matthias Klose wrote: Package: gnat-gps Version: 5.3-4 don't recommend just gdb-minimal; there are myriads of gdb packages, that should be gdb-minimal | gdb, or just gdb. Of course you know about https://bugs.debian.org/659166 and have tested that today's gdb works inside of GPS, haven't you? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765482: don't recommend just gdb-minimal
Matthias Klose wrote: why would gdb-minimal work when gdb is not working? Because gdb does (at least, did in the past) strange things with its tty that defeated expect. gdb-minimal does nothing fancy and uses only stdin and stdout, not a tty. Perhaps there exists a command-line option to newer gdbs to disable this tty thing? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#765501: freeciv-gtk: should depend on, not recommend, gtk2-engines-pixbuf
Package: freeciv-gtk Version: 2.4.3-1 Severity: normal The GTK+2 version of the freeciv client will not work without gtk2-engines-pixbuf. Symptoms: the client hangs doing nothing, not refreshing its window and not responding to user input. The ~/.xsession-errors file contains: Gtk-WARNING **: Unable to locate theme engine in module_path: pixmap which is the only clue I had about a possible cause. This happened on my 8-yer-old son's laptop, which is a 13-year-old Apple iBook where I installed Debian Jessie (testing) and configured apt *not* to install recommended packages by default. Therefore the Recommends: gtk2-engines-pixbuf should be strenghened to Depends:. There is no explanation in #677891 why the maintainer chose Recommends: when upstream said Depends: was necessary; hence this new bug report. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759038: Bug#765467: asis-programs: Version mismatch between GNAT 4.9.1 vs. ASIS 4.9
affects 759038 asis-programs block 765467 by 759038 thanks I have traced #765467 to a discrepancy between debian/patches/ada-libgnatvsn.diff and debian/patches/gcc-base-version.diff, which are patches applied to both gcc-4.9 and gnat-4.9. gcc-base-version.diff changes src/gcc/Makefile.in so that it builds version.o with the flag -DBASEVER=$(FULLVER_s) (where FULLVER_s has the value 4.9.1 and is introduced by this patch; upstream uses only BASEVER_s). This is a recent change introduced for #759038. ada-libgnatvsn.diff rebuilds version.o with -fPIC, so it can be included into libgnatvsn.so.4.9, and passes -DBASEVER=$(BASEVER_s), like upstream does. But the value of BASEVER_s is 4.9, not 4.9.1. Consequently: /usr/bin/gcc-4.9, linked statically with version.o, emits 4.9.1 /usr/bin/gnatpp, linked dynamically with version.o from libgnatvsn4.9, expects 4.9. I think the change made for #759038 should be reverted; as Matthias said, we should use 4.9 consistently, not 4.9.1. I disagree with Nicolas when he says that gcc -dumpversion should report 4.9.1; it should report 4.9 instead because Debian only ever uses the tip of the gcc-4_9-branch plus patches, and never exactly 4.9.1. Furthermore, 4.9.2 is looming on the horizon and will not change the format of ASIS tree files, so 4.9 is really the version that should be in the tree files. Assuming this change is reverted, gnat1 will still emit 4.9.1 into the tree files; this is the real issue. Linking gnat1 dynamically against libgnatvsn.so.4.9 might be desirable but seems like a lot of work, and also means that ada-libgnatvsn.diff would become even more intrusive than it already is (and it is not upstreamable without a lot more work because upstream supports many more cross-compiler configurations than we do ATM). In theory, gnat1 is linked statically with version.o, so emits whatever is configured into version.o. Why gnat1 would emit 4.9.1 as reported in #759038 escapes me ATM. gcc-base-version.diff was introduced back in 2011 to change the directories where various pieces of GCC are installed, e.g. /usr/lib/gcc/$(target)/4.6.1 to /usr/lib/gcc/$(target)/4.6 (changing BASEVER from 4.6.1 to 4.6). At the same time, this patch introduced FULLVER (value: 4.6.1). I am not sure why FULLVER is needed at all nowadays. Why not remove FULLVER altogether? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756383: adacgi: missing license in debian/copyright
Please fix this minor problem before the freeze of Debian... -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756385: adasockets: missing license in debian/copyright
Please fix this minor problem before the freeze of testing... -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763727: gprbuild: gprconfig segfaults on kfreebsd-i386, causes other packages to FTBFS
I have a kfreebsd-i386 virtual box on my laptop and I can confirm that Nicolas' latest patch [https://bugs.debian.org/763727#25] reproduces the same symptoms as in my message [https://bugs.debian.org/763727#10]. That is, he solved the handling of exceptions in a different way (not raising the exceptions while retaining the meaningful non-numeric default attribute values) but the problems with GNAT.Expect are still there. If you are interested in setting up a virtual box: aptitude install virtualbox-qt virtualbox-dkms. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763727: gprbuild: gprconfig segfaults on kfreebsd-i386, causes other packages to FTBFS
Strangely I am unable to reproduce either of the bugs in gprbuild, namely the mishandling of exceptions and the exception inside GNAT.Expect. The following program runs successfully on kfreebsd-i386. This suggests that something really fishy is going on in the way GNAT compiles gprbuild but not in a normal program. I see that some of the executables in gprbuild use tasking but gprconfig does not. I suspect this may cause trouble: some of the compilation units in gprconfig might use tasking (or cause some tasking initialization to take place at elaboration) while the main program does not. I will try to change debian/rules so that each executable gets built in its own directory and report back. with Ada.Exceptions; with Ada.Text_IO; with GNAT.Expect; with GNAT.OS_Lib; use GNAT.OS_Lib; procedure Hello is The_Arguments : GNAT.OS_Lib.Argument_List := (1 = new String'(gcc), 2 = new String'(-dumpversion)); Status : aliased Integer; The_Output : constant String := GNAT.Expect.Get_Command_Output (Command = gcc, Arguments = The_Arguments, Input = , Status = Status'Access, Err_To_Out = False); begin Ada.Text_IO.Put_Line (Executing ./hello...); Ada.Text_IO.Put_Line (Output: The_Output ; status: Integer'Image (Status)); Status := Integer'Value (hello); exception when E : others = Ada.Text_IO.Put_Line (Exception handled successfully: Ada.Exceptions.Exception_Information (E)); end Hello; $ gnatmake -g -O2 hello; ./hello gcc-4.9 -c -g -O2 hello.adb gnatbind -x hello.ali gnatlink hello.ali -g -O2 Executing ./hello... Output: 4.9.1; status: 0 Exception handled successfully: Exception name: CONSTRAINT_ERROR Message: bad input for 'Value: hello -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763727: gprbuild: gprconfig segfaults on kfreebsd-i386, causes other packages to FTBFS
D'oh. The problem is caused not by raising or handling exceptions but by storing the exception traceback in the exception occurrence, as specified by passing -E to gnatbind. If I bind hello.adb with -E I can reproduce the storage_error in GNAT.Expect. As I don't see any reason why gprbuild would need exception tracebacks for normal operation, I'll disable them. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763727: gprbuild: gprconfig segfaults on kfreebsd-i386, causes other packages to FTBFS
The Constraint_Error is triggered when parsing the following node in gprbuild's compilers.xml: compiler_description nameGCC-28/name executablegcc/executable version externalgcc -v/external grep regexp=^gcc \S+ (\S+) group=1/grep must_match2\.8\./must_match /version languagesC/languages target externalgcc -dumpmachine/external grep regexp=[^\r\n]+/grep /target /compiler_description which is the first node where executable lacks a prefix=1 attribute. There are other executable nodes lacking the prefix attribute. On amd64, gprconfig raises the same constraint_error but handles it and does not report anything. Therefore this bug is a compiler bug similar but not identical to #666106 (which is reported to occur only in the presence of tasks). I have found more instances of this bug in other places, which I have corrected on org.debian.gprbuild. But now I've hit another wall, an exception with this backtrace: #0 0x0815ce93 in __gnat_backtrace () #1 0x081529c0 in system.traceback.call_chain () #2 0x08108bbb in ada.exceptions.call_chain () #3 0x08108fab in ada.exceptions.complete_occurrence () #4 0x08108fc8 in ada.exceptions.complete_and_propagate_occurrence () #5 0x08109018 in __gnat_raise_exception () #6 0x08132e19 in gnat.expect.expect () #7 0x08132f38 in gnat.expect.expect () #8 0x08132fc0 in gnat.expect.expect () #9 0x0813489e in gnat.expect.get_command_output () #10 0x080e5f55 in gprconfig.knowledge.get_external_value (attribute=..., value=..., comp=..., split_into_words=false, merge_same_dirs=false, processed_value=...) at /home/lbrenta/gprbuild-2014/src/gprconfig-knowledge.adb:1774 #11 0x080e9e7e in gprconfig.knowledge.foreach_language_runtime (iterator=..., base=..., name=30258, executable=30342, directory=..., prefix=3, from_extra_dir=false, on_target=24, descr=..., path_order=2, continue=true) at /home/lbrenta/gprbuild-2014/src/gprconfig-knowledge.adb:2094 #12 0x080efa4c in gprconfig.knowledge.foreach_compiler_in_dir (iterator=..., base=..., directory=..., from_extra_dir=false, on_target=24, path_order=2, continue=true) at /home/lbrenta/gprbuild-2014/src/gprconfig-knowledge.adb:2592 #13 0x080f11b3 in gprconfig.knowledge.foreach_compiler_in_path (iterator=..., base=..., on_target=24, extra_dirs=...) at /home/lbrenta/gprbuild-2014/src/gprconfig-knowledge.adb:2805 #14 0x0807ada1 in gprconfig.main () at /home/lbrenta/gprbuild-2014/src/gprconfig-main.adb:490 and the command to run is gcc -dumpversion. Having reached the end of my available time for today, I'll leave it at that for now. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763727: gprbuild: gprconfig segfaults on kfreebsd-i386, causes other packages to FTBFS
Source: gprbuild Severity: important Hello, here are the symptoms visible in the buildd log of libgnatcoll on kfreebsd-i386, which I could reproduce in a virtual box: gprbuild -v -j4 -R -v -eS -XADAFLAGS=-g -O2 -fstack-protector-strong -XCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security -XCPPFLAGS=-D_FORTIFY_SOURCE=2 -XLDFLAGS\ =-Wl,-z,relro -Wl,--as-needed -Wl,-z,defs -XGNATCOLL_VERSION=1.6 -XGNATCOLL_PYTHON_VERSION=1.6 -XGNATCOLL_ICONV_VERSION=1.6 -XGNATCOLL_SQLITE_VERSION=1.6 -XGNATCOLL_READLINE_VERSION=1.6 -XG\ NATCOLL_GMP_VERSION=1.6 -XGNATCOLL_GTK_VERSION=1.6 -XLIBRARY_TYPE=static -Pgnatcoll_build -p GPRBUILD 2014 (unknown) (i586-kfreebsd-gnu) Copyright (C) 2004-2014, Free Software Foundation, Inc. gprconfig --batch -o /home/lbrenta/libgnatcoll-1.6gpl2014/src/obj/auto.cgpr --target=x86-freebsd --config=c,, --config=ada,, gprbuild: could not create /home/lbrenta/libgnatcoll-1.6gpl2014/src/obj/auto.cgpr Note how gprbuild passes --target=x86-freebsd to gprconfig. I believe this option is incorrect, it should be --target=i586-kfreebsd-gnu instead. Furthermore, gprconfig segfaults immediately even without any options specified: $ gdb $(which gprconfig) Current directory is /usr/bin/ GNU gdb (Debian 7.7.1+dfsg-3) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as i486-kfreebsd-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from /usr/bin/gprconfig...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/gprconfig [tcsetpgrp failed in terminal_inferior: Inappropriate ioctl for device] [tcsetpgrp failed in terminal_inferior: Operation not permitted] [tcsetpgrp failed in terminal_inferior: Operation not permitted] [tcsetpgrp failed in terminal_inferior: Operation not permitted] Program received signal SIGSEGV, Segmentation fault. 0x08142453 in __gnat_backtrace () (gdb) bt #0 0x08142453 in __gnat_backtrace () #1 0x08137f80 in system.traceback.call_chain () #2 0x080eeb4b in ada.exceptions.call_chain () #3 0x080eef3b in ada.exceptions.complete_occurrence () #4 0x080eef58 in ada.exceptions.complete_and_propagate_occurrence () #5 0x080eefa8 in __gnat_raise_exception () #6 0x08139ca1 in system.val_util.bad_value () #7 0x08138986 in system.val_int.scan_integer () #8 0x081389b5 in system.val_int.value_integer () #9 0x080d5437 in ?? () #10 0x080dffd2 in ?? () #11 0x0807b51f in ?? () #12 0x08077d88 in ?? () #13 0x28c89a63 in __libc_start_main (main=0x8077d30, argc=1, argv=0xbfbfd764, init=0x81459b0, fini=0x8145a20, rtld_fini=0x281bb3b0 _dl_fini, stack_end=0xbfbfd75c) at libc-start.c:287 #14 0x08077dea in ?? () (gdb) The segfault happens even when passing --target=i586-kfreebsd-gnu to gprconfig. This bug affects libgnatcoll on kfreebsd-i386, which FTBFS as a result. This in turn prevents gnat-gps from building. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Emilio Pozuelo Monfort po...@debian.org writes: On 21/09/14 02:31, Ludovic Brenta wrote: Nicolas Boulenguez nico...@debian.org writes: A bootstrap issue will remain: building a new gnat-4.9 package installing these symlinks requires a working compiler. I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I bootstrapped it on a kfreebsd-i386 virtual machine in which I created the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the bootstrap compiler. Since this is a policy violation (official packages must be built on real hardware, not on virtual machines) I intend to upload -3 to have it rebuilt on kfreebsd-i386 with -2. Which part of policy is that? Heh, I can't find it back. I thought I remembered this rule from years ago. Maybe I am mistaken. Maybe the package I just uploaded is perfectly fine after all. Or, maybe it is a rule imposed by DSA on porter machines. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
Nicolas Boulenguez nico...@debian.org writes: A bootstrap issue will remain: building a new gnat-4.9 package installing these symlinks requires a working compiler. I am now uploading gnat-4.9 4.9.1-2 which solves this problem. I bootstrapped it on a kfreebsd-i386 virtual machine in which I created the symlinks manually, so that gnat-4.9 4.9.1-1 worked again as the bootstrap compiler. Since this is a policy violation (official packages must be built on real hardware, not on virtual machines) I intend to upload -3 to have it rebuilt on kfreebsd-i386 with -2. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759407: gnat-4.9: gnat1 not found on kfreebsd-i386
reassign 759407 src:gcc-4.9 thanks Hello, Svante is correct on one point: some version of gcc-4.9 broke gnat-4.9 on kfreebsd-i386 at least. Proof: on August 11, gnat-4.9 (=4.9.1-1) worked perfectly well when combined with gcc-4.9 (exact version unspecified): https://buildd.debian.org/status/fetch.php?pkg=libtemplates-parserarch=kfreebsd-i386ver=11.8.2014-3stamp=1407787293 The symptoms appeared later, still with gnat-4.9 (=4.9.1-1) but with a later gcc-4.9; not a snapshot. On August 24: https://buildd.debian.org/status/fetch.php?pkg=gnat-gpsarch=kfreebsd-i386ver=5.3-3stamp=1408919003 Between these two dates (August 11 and August 24), there were no uploads of gnat-4.9 but there were some uploads of gcc-4.9, therefore gcc-4.9 must have broken something, possibly in the target triplet or directory where it looks for gnat1. Possibly, this bug has already been fixed by the last change in this upload: gcc-4.9 (4.9.1-11) unstable; urgency=medium * Update to SVN 20140830 (r214759) from the gcc-4_9-branch. * Update cross installation patches for the branch. * Use the base version (4.9) when accessing files in gcc_lib_dir. -- Matthias Klose d...@debian.org Sat, 30 Aug 2014 22:05:47 +0200 I'll try to check this (on kfreebsd-i386) over the weekend. This particular bug is for kfreebsd-i386 only. hurd-i386 has similar symptoms on different dates (for example, the build of gnat-gps (=5.3-3) succeeded on hurd-i386 when it failed on kfreebsd-i386). I propose to use #761248 (severity important) to track the issue on hurd-i386, if it is different. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760077: flightgear-data-aircrafts: SenecaII: timed updates receive the total elapsed time, not delta time since last update
Package: flightgear-data-aircrafts
Version: 3.0.0-1
Severity: normal
The bug is pretty obvious in SenecaII.nas, the patch below should be
self-explanatory.
--
Revision: a1938d7b46898441959a01cf7a9fc145cc724d29
Parent: 881d90681de950215bc0154cdc2d7207b044df2e
Author: Ludovic Brenta
Date: 2014-08-31T17:29:30
Branch: org.flightgear.aircraft.SenecaII
Changelog:
* Bug fix: pass the delta time since last update, not total elapsed time, to
updaters.
Changes against parent 881d90681de950215bc0154cdc2d7207b044df2e
patched Nasal/SenecaII.nas
--- Nasal/SenecaII.nas bb1eae50e10da5dfe78bdc80a25ff1bbaafc746a
+++ Nasal/SenecaII.nas 0787b6637818bae913fa8eb8862ad7a46dcde591
@@ -19,10 +19,11 @@ var timedUpdate = func {
var timeNode = props.globals.getNode( /sim/time/elapsed-sec, 1 );
var lastRun = timeNode.getValue();
var timedUpdate = func {
- var dt = timeNode.getValue() - lastRun;
+ var now = timeNode.getValue();
foreach( var n; updateClients ) {
-n.update( dt );
+n.update(now - lastRun);
}
+ lastRun = now;
settimer( timedUpdate, 0 );
};
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (1, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760081: flightgear-data-aircrafts: SenecaII: extra-long-range fuel tanks in the engine nacelles
Package: flightgear-data-aircrafts
Version: 3.0.0-1
Severity: wishlist
Tags: patch
https://answers.yahoo.com/question/index?qid=20060818093900AABI7C4
The Seneca can be modified to carry more fuel, however the Seneca
already has a terrible useful load capability. The engine-nacelle fuel
tanks offered by Tom's Aircraft (STC SA2205SW, originally by Nayak
Aviation) are auxiliary tanks and fuel must be transferred into the
mains to be used, a process which takes just over an hour for their
entire 30-gallon capacity. However, there are no gauges or indicators
whatsoever of fuel level or fuel transfer. So the only possible way to
know whether the fuel transferred or not is to watch the aircraft's
factory fuel gauges and determine, after an hour of flight where you've
added 30 gallons and burned 22-24, whether it looks like the gauges
indicate roughly 3-4 gallons more per side than they indicated an hour
before.
The attached patch implements said optional tanks. Additionally, it
corrects the max weight in the front and aft baggage holds to 100 pounds
each (instead of 200).
In Equipment Fuel and Payload, you can watch the nacelle tanks
slowly[1] empty themselves into the main tanks during flight. There is
no other way to know how much fuel remains in these tanks, just like in
reality.
Also, note that these tanks occupy space that was formerly available for
cargo in reality, but was never implemented in FlightGear. And
obviously, filling these tanks must be at the expense of payload. Like
in most aircraft, one cannot take max fuel and max payload at the same
time; it's a tradeoff.
The fuel in these tanks increases the range of the SenecaII from 800 to
970 nmi (approximately; actual range depends on payload, wind and how
well you fly...).
--
Revision: 4de47308fec1a8d3354ed0e0846f4574a40bbb71
Parent: a1938d7b46898441959a01cf7a9fc145cc724d29
Author: Ludovic Brenta
Date: 2014-08-31T17:43:00
Branch: org.flightgear.aircraft.SenecaII
Changelog:
* Add extra-long-range fuel tanks in the engine nacelles.
Changes against parent a1938d7b46898441959a01cf7a9fc145cc724d29
patched Nasal/SenecaII.nas
patched SenecaII-base.xml
patched SenecaII-jsbsim.xml
--- Nasal/SenecaII.nas 0787b6637818bae913fa8eb8862ad7a46dcde591
+++ Nasal/SenecaII.nas dd7b9f90bb5f27bfdaf6c0bcb895710d95a10de1
@@ -27,12 +27,17 @@ var timedUpdate = func {
settimer( timedUpdate, 0 );
};
+var tanks = [];
+
var seneca_init = func {
props.globals.initNode( autopilot/CENTURYIII/controls/mode, 2, INT );
props.globals.initNode( autopilot/CENTURYIII/controls/manual-trim, 0, INT );
props.globals.initNode( autopilot/CENTURYIII/controls/disconnect, 0, BOOL );
ki266.new(0);
+ foreach( var n; props.globals.getNode(/consumables/fuel).getChildren(tank) ) {
+append(tanks, FuelTank.new (n));
+ }
updateClients = [];
foreach( var n; props.globals.getNode(/systems/fuel).getChildren( fuel-pump ) ) {
append( updateClients, FuelPump.new( n ) );
@@ -154,14 +159,12 @@ var FuelTank = {};
var FuelTank = {};
-FuelTank.new = func(nr) {
+FuelTank.new = func(base) {
var obj = {};
obj.parents = [FuelTank];
- obj.baseN = props.globals.getNode( /consumables/fuel/tank[ ~ nr ~ ], 1 );
- obj.emptyN = obj.baseN.initNode(empty, 0, BOOL );
- obj.capacityN = obj.baseN.initNode(capacity-gal_us, 0.0 );
- obj.contentN = obj.baseN.initNode(level-gal_us, 0.0 );
-
+ obj.emptyN = base.initNode(empty, 0, BOOL );
+ obj.capacityN = base.initNode(capacity-gal_us, 0.0 );
+ obj.contentN = base.initNode(level-gal_us, 0.0 );
return obj;
};
@@ -194,11 +197,7 @@ FuelPump.new = func(base) {
}
obj.serviceableNode = base.initNode( serviceable, 1, BOOL );
obj.sourceTankNode = base.initNode( source-tank, -1, INT );
-
- obj.tanks = [];
- append( obj.tanks, FuelTank.new( 0 ) );
- append( obj.tanks, FuelTank.new( 1 ) );
- obj.destinationTank = FuelTank.new( base.getNode(destination-tank).getValue() );
+ obj.destinationTankNode = base.initNode(destination-tank, -1, INT);
obj.fuel_flow_gphNode = base.getNode( fuel-flow-gph, 1 );
return obj;
};
@@ -210,11 +209,15 @@ FuelPump.update = func(dt) {
!me.serviceableNode.getValue() and return;
var sourceTank = me.sourceTankNode.getValue();
- if(sourceTank == nil or sourceTank 0 or sourceTank = size(me.tanks) ) return
+ if (sourceTank == nil or sourceTank 0 or sourceTank = size(tanks)) return;
- #if source is empty, go away
- me.tanks[sourceTank].empty() and return;
+ var destinationTank = me.destinationTankNode.getValue();
+ if (destinationTank == nil or destinationTank 0 or destinationTank = size (tanks))
+return;
+
+ if (tanks[sourceTank].empty()) return;
+
# compute fuel flow
var flow_gph = me.fuel_flow_gphNode.getValue();
@@ -223,19 +226,19 @@ FuelPump.update = func(dt) {
var transfer_fuel
Bug#760082: flightgear-data-aircrafts: SenecaII: default field of vision is too narrow
Package: flightgear-data-aircrafts Version: 3.0.0-1 Severity: wishlist Tags: patch The human field of vision is normally 180 degrees, with the middle 90 degrees being precise and peripheral vision making up the remainder. The SenecaII uses a 50 degree field of vision by default which makes the cockpit occupy too much real estate on the screen (for me). Also this field of vision hides the exhaust gas temperature gauges, which I monitor constantly during climb. This patch corrects these problems: Revision: 881d90681de950215bc0154cdc2d7207b044df2e Parent: 1ed6e148865ad2802ac55d051a2e33119d4eb6ac Author: Ludovic Brenta Date: 2014-08-26T01:40:45 Branch: org.flightgear.aircraft.SenecaII Changelog: * Change the default field of vision from 50° to 66°. (This makes the left EGT gauge visible in the cockpit). Changes against parent 1ed6e148865ad2802ac55d051a2e33119d4eb6ac patched SenecaII-base.xml --- SenecaII-base.xml 52338a9418791ea3e158828de0018c94b76cd568 +++ SenecaII-base.xml f31d886b1561c549339182f8777619a31d9c2da2 @@ -90,7 +90,7 @@ view n=0 internaltrue/internal config -default-field-of-view-deg type=double50/default-field-of-view-deg +default-field-of-view-deg type=double66/default-field-of-view-deg x-offset-m type=double-0.358/x-offset-m y-offset-m type=double1.75/y-offset-m z-offset-m type=double-0.3/z-offset-m @@ -110,7 +110,7 @@ from-model type=booltrue/from-model from-model-idx type=int0/from-model-idx ground-level-nearplane-m type=double0.01/ground-level-nearplane-m -default-field-of-view-deg type=double50/default-field-of-view-deg +default-field-of-view-deg type=double66/default-field-of-view-deg pitch-offset-deg-15/pitch-offset-deg heading-offset-deg80/heading-offset-deg x-offset-m type=double-0.25/x-offset-m @@ -126,7 +126,7 @@ from-model type=booltrue/from-model from-model-idx type=int0/from-model-idx ground-level-nearplane-m type=double0.01/ground-level-nearplane-m -default-field-of-view-deg type=double50/default-field-of-view-deg +default-field-of-view-deg type=double66/default-field-of-view-deg pitch-offset-deg-15/pitch-offset-deg heading-offset-deg-80/heading-offset-deg x-offset-m type=double0.25/x-offset-m @@ -142,7 +142,7 @@ from-model type=booltrue/from-model from-model-idx type=int0/from-model-idx ground-level-nearplane-m type=double0.01/ground-level-nearplane-m -default-field-of-view-deg type=double50/default-field-of-view-deg +default-field-of-view-deg type=double66/default-field-of-view-deg pitch-offset-deg-15/pitch-offset-deg x-offset-m type=double0.358/x-offset-m y-offset-m type=double1.75/y-offset-m -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#760083: flightgear-data-aircrafts: SenecaII: exterior lighting
Package: flightgear-data-aircrafts Version: 3.0.0-1 Severity: wishlist Tags: patch Revision: 1ed6e148865ad2802ac55d051a2e33119d4eb6ac Parent: 30e7eb3517c778ac6f6012e4f5bfd39721a2317b Author: Ludovic Brenta Date: 2014-08-25T02:36:13 Branch: org.flightgear.aircraft.SenecaII Changelog: * Make landing lights work. They do not illuminate anything, yet, i.e. they don't emit a light cone. Changes against parent 30e7eb3517c778ac6f6012e4f5bfd39721a2317b patched Models/SenecaII.xml --- Models/SenecaII.xml 50f2fa5f1f0275bc083ea0a68acccd8c5e40ada9 +++ Models/SenecaII.xml 3ac8dfc614de8d67f0c86ea870345620d0ca9df2 @@ -1575,6 +1575,17 @@ /animation animation + typematerial/type + object-nameLandingLight/object-name + emission +red1/red +green1/green +blue1/blue +factor-prop/controls/lighting/landing-lights/factor-prop + /emission +/animation + +animation typenoshadow/type object-nameTaxiLandingLight/object-name /animation @@ -1603,6 +1614,17 @@ /axis /animation +animation + typematerial/type + object-nameTaxiLight/object-name + emission +red1/red +green1/green +blue1/blue +factor-prop/controls/lighting/taxi-light/factor-prop + /emission +/animation + !-- nose gear from Roberto Inzerillo -- animation typerotate/type -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#757178: fgrun: does not export environment variables to fgfs
Package: fgrun
Version: 3.0.0-1
Severity: normal
I have a laptop with hybrid graphics (Intel integrated and ATI Radeon
discrete) and I have finally taken the time to enable the discrete
graphics for FlightGear. In a shell:
$ xrandr --listproviders
Providers: number : 2
Provider 0: id: 0x80 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs:
3 outputs: 8 associated providers: 1 name:Intel
Provider 1: id: 0x55 cap: 0xf, Source Output, Sink Output, Source Offload, Sink
Offload crtcs: 6 outputs: 0 associated providers: 1 name:radeon
$ xrandr --setprovideroffloadsink radeon Intel
$ DRI_PRIME=1 fgfs --enable-fullscreen
This works with a compositing window manager such as xfvwm4 (not
ratpoison, unfortunately). (The next version of mesa should make this
work also in non-fullscreen and with non-compositing window managers).
Now I would like to do the same thing from fgrun. In the last page, I
click Advanced then Environment then New then I type DRI_PRIME=1
then OK.
When I then click Run, fgrun fails to pass the environment variable to
fgfs, resulting it its still using the Intel integrated graphics. The
workaround is to call DRI_PRIME=1 fgrun from a command line but then
the 3D Preview on page 2 does not work because it is not fullscreen.
Browsing the sources of fgrun on gitorious, I have traced this to the
following buggy piece of code near run_posix.cxx:119:
// export any environment variables.
int iVal;
prefs.get( env-count, iVal, 0 );
for (int i = 1; i = iVal; ++i)
{
buf[0] = 0;
prefs.get( Fl_Preferences::Name(env-var-%d, i),
buf, , buflen-1 );
char* s = strdup( buf );
putenv( s );
free( s );
}
The use of putenv(3) is buggy because its man page says: In particular,
this string becomes part of the environment; changing it later will
change the environment. (Thus, it is an error is to call putenv() with
an automatic variable as the argument, then return from the calling
function while string is still part of the environment.).
fgrun passes the string to the environment and then deallocates it.
The man page of setenv(3) says: This function makes copies of the
strings pointed to by name and value (by contrast with putenv(3)).
Therefore, fgrun should call setenv(3), not putenv(3).
Here is a suggested patch but note that I have not even tried to compile
it.
--- /tmp/run_posix.cxx.old 2014-08-06 03:13:53.351947269 +0200
+++ /tmp/run_posix.cxx 2014-08-06 03:25:49.983116275 +0200
@@ -124,9 +124,16 @@
buf[0] = 0;
prefs.get( Fl_Preferences::Name(env-var-%d, i),
buf, , buflen-1 );
- char* s = strdup( buf );
- putenv( s );
-free( s );
+const char* equals = strchr(buf, '=');
+if (equals == NULL) { /* environment variable name without a
value; unset it. */
+ unsetenv(buf);
+}
+else { /* value exists */
+ *equals = '\0'; /* replace '=' with a new terminator; the value
follows. */
+ setenv(/* name: */ buf,
+ /* value: */ equals + 1,
+ /* overwrite: */ TRUE);
+}
}
vectorstring argv;
argv.push_back( arg0 );
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (1, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages fgrun depends on:
ii libc6 2.19-7
ii libfltk-forms1.3 1.3.2-6
ii libfltk-gl1.3 1.3.2-6
ii libfltk-images1.3 1.3.2-6
ii libfltk1.31.3.2-6
ii libgcc1 1:4.9.1-1
ii libopenscenegraph99 3.2.0~rc1-5.1
ii libopenthreads14 3.2.0~rc1-5.1
ii libsimgearcore3.0.0 3.0.0-4
ii libsimgearscene3.0.0 3.0.0-4
ii libstdc++64.9.1-1
ii zlib1g1:1.2.8.dfsg-1
Versions of packages fgrun recommends:
ii flightgear 3.0.0-2
fgrun suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751847: [pkg-fgfs-crew] Bug#751847: flightgear: Seneca II interior lighting
Markus Wanner writes: Thanks for working on this. (And kudos for using monotone for that. Did you import the entire fgdata? Or just that aircraft?) Just that aircraft; I figured I'd use a branch per aircraft I wanted to work on. I named it org.flightgear.aircraft.SenecaII. I've just forwarded the patch to the fgfs-devel mailing list with you CC'ed. Thanks for that; I hope people like my changes. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754320: gnat-gps: Could not locate executable on path: gnatinspect
Thierry Rascle writes: When I build my Ada project in gnat-gps 5.3 using the Build All command, I see the following error message in the messages window: Could not locate executable on path: gnatinspect. I have already fixed this in development and will upload shortly. gnatinspect is a new program supplied as part of GPS. I have yet to write a man page for it, per Debian policy. The error occurs immediately after the build. The build is successful. I have searched a file named gnatinspect on my system and did not find any. I'm not sure if this is related, but the generation of the documentation does not work properly (menu Tools|Documentation|Generate project). I see warning messages like (one for each Ada source file of my project): warning: cross references for file Ada source file are not up-to-date. Documentation not generated. There is no reason why the cross references would not be up-to-date because the project has just been built. I'm not sure whether it is related or not. I'll know more when I learn what gnatinspect is supposed to do :) Thanks for trying gnat-gps and reporting this bug. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: Bug #750939: flightgear: Occasional deadlock when processing key input
Happened again after I pressed 'x' multiple times; in a Seneca II. When I attached the debugger, sound stopped; when I typed cont in the debugger, sound resumed. This suggests that thread 5 is not part of the deadlock; but we already knew that, didn't we ? :) -- Ludovic Brenta. (gdb) thread apply all bt Thread 7 (Thread 0x7f61d3f98700 (LWP 31715)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61df88329b in waitOnNotEmpty (this=0x3323b50) at /usr/src/simgear.git/simgear/threads/SGQueue.hxx:392 #2 simgear::SGTerraSync::SvnThread::runInternal (this=0x3323970) at /usr/src/simgear.git/simgear/scene/tsync/terrasync.cxx:651 #3 0x7f61df883535 in simgear::SGTerraSync::SvnThread::run (this=0x3323970) at /usr/src/simgear.git/simgear/scene/tsync/terrasync.cxx:474 #4 0x7f61df85feea in SGThread::PrivateData::start_routine (data=optimized out) at /usr/src/simgear.git/simgear/threads/SGThread.cxx:204 #5 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #6 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 6 (Thread 0x7f61d2c3e700 (LWP 31717)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61df7a7933 in (anonymous namespace)::Resolver::run (this=0x3446680) at /usr/src/simgear.git/simgear/io/raw_socket.cxx:168 #2 0x7f61df85feea in SGThread::PrivateData::start_routine (data=optimized out) at /usr/src/simgear.git/simgear/threads/SGThread.cxx:204 #3 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #4 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 5 (Thread 0x7f61c237e700 (LWP 31719)): #0 0x7f61daa5ad5d in poll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x7f61c1888c26 in ?? () from /usr/lib/x86_64-linux-gnu/libasound.so.2 #2 0x7f61e0708be8 in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1 #3 0x7f61e070054a in ?? () from /usr/lib/x86_64-linux-gnu/libopenal.so.1 #4 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 4 (Thread 0x7f61d7a07700 (LWP 31720)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61df79f5db in pop (this=0x26e9958) at /usr/src/simgear.git/simgear/threads/SGQueue.hxx:228 #2 LogStreamPrivate::run (this=0x26e9940) at /usr/src/simgear.git/simgear/debug/logstream.cxx:261 #3 0x7f61df85feea in SGThread::PrivateData::start_routine (data=optimized out) at /usr/src/simgear.git/simgear/threads/SGThread.cxx:204 #4 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 3 (Thread 0x7f61c0e4d700 (LWP 31721)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61dda8fd9e in OpenThreads::Condition::wait(OpenThreads::Mutex*) () from /usr/lib/libOpenThreads.so.14 #2 0x7f61defad5c8 in osgDB::DatabasePager::DatabaseThread::run() () from /usr/lib/libosgDB.so.99 #3 0x7f61dda8f82b in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /usr/lib/libOpenThreads.so.14 #4 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 2 (Thread 0x7f61bbfff700 (LWP 31722)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61dda8fd9e in OpenThreads::Condition::wait(OpenThreads::Mutex*) () from /usr/lib/libOpenThreads.so.14 #2 0x7f61defad5c8 in osgDB::DatabasePager::DatabaseThread::run() () from /usr/lib/libosgDB.so.99 #3 0x7f61dda8f82b in OpenThreads::ThreadPrivateActions::StartThread(void*) () from /usr/lib/libOpenThreads.so.14 #4 0x7f61dffc20ca in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #5 0x7f61daa65ffd in clone () from /lib/x86_64-linux-gnu/libc.so.6 Thread 1 (Thread 0x7f61e0b227c0 (LWP 31708)): #0 0x7f61dffc60b0 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/x86_64-linux-gnu/libpthread.so.0 #1 0x7f61df80452b in naSemDown (sh=0xa7a7260) at /usr/src/simgear.git/simgear/nasal/thread-posix.c:57 #2 0x7f61df7fb5af in bottleneck () at /usr/src/simgear.git/simgear/nasal/gc.c:111 #3 0x7f61df7fbb67 in naGC_swapfree (target=0x10ed6ab8, val=0x191c1bb0) at /usr/src/simgear.git/simgear/nasal/gc.c:332 #4 0x7f61df7fc189 in resize (hash=0x10ed6ab0) at /usr/src/simgear.git/simgear/nasal/hash.c:120 #5 0x7f61df7fc975 in naiHash_newsym (hash=optimized out, sym=0xd6fe8c8, val=val@entry=0x7fff96687d20) at /usr/src/simgear.git/simgear/nasal/hash.c:259 #6 0x7f61df7f57bf in setupArgs (ctx=ctx@entry=0xd853950, args=args@entry
Bug#751847: flightgear: Seneca II interior lighting
I have prepared a much more extensive patch that resolves the second issue, viz. the fact that the cockpit remains dark even with the overhead lights swicthed on. I'll post it here in the next 12 hours. This patch illuminates many non-backlit areas of the cockpit with the overhead lights: the charts on the copilot's seat, the instrument panel, the throttle/RPM/mixture levers, coil flap levers, flap lever, etc. Parts of this patch might be controversial in that the left-hand electrical buttons (main battery, magnetos, start button, etc.) and the instrument and radio light dimmers are no longer back-lit and no longer controlled by the instrument light; instead they are dimly lit only by the overhead light. I believe this to be more realistic but then again I've never been in an actual Seneca II, let alone at night :) I'd like to add a keyboard shortcut to turn the overhead lights on; I think the key Ctrl+L is a good candidate. Also to add an entry in the Seneca menu (F10). This way, a pilot could enter the cockpit in the middle of the night, hit Ctrl+L, see the instrument lighting dimmer on the panel, turn that on and fly the aircraft, all without resorting to Ctrl+C a single time. All in all I think this is a *big* improvement to the cockpit for night flying. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751847: flightgear: Seneca II interior lighting
As promised here is the patch. Additionally to my earlier description, it sets the key c to show and hide the aircraft, like in the Beechcraft 1900D. If there is any better place to send such patches please tell me :) -- Ludovic Brenta. --- SenecaII/Instruments-3d/SwitchPanel.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/SwitchPanel.xml 2014-06-19 21:21:57.223347712 +0200 @@ -47,10 +47,10 @@ object-nameMaster/object-name emission -red-prop/sim/model/instrument-lighting/emission/red/red-prop -green-prop/sim/model/instrument-lighting/emission/green/green-prop -blue-prop/sim/model/instrument-lighting/emission/blue/blue-prop -factor-prop/controls/lighting/instruments-norm/factor-prop +red-propsim/model/overhead-lighting/red/red-prop +green-propsim/model/overhead-lighting/green/green-prop +blue-propsim/model/overhead-lighting/blue/blue-prop +factor-propcontrols/lighting/overhead-norm/factor-prop /emission /animation --- SenecaII/Models/AI/AI.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/AI/AI.xml 2014-06-19 21:08:29.667221949 +0200 @@ -15,7 +15,7 @@ red1.0/red green0.2/green blue0.0/blue - factor-propsim/model/material/instruments/factor/factor-prop + factor-propcontrols/lighting/instruments-norm/factor-prop /emission /animation --- SenecaII/Models/AI/AttitudeGyro.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/AI/AttitudeGyro.xml 2014-06-19 04:06:28.99840 +0200 @@ -32,7 +32,7 @@ red1.0/red green0.2/green blue0.0/blue - factor-propsim/model/material/instruments/factor/factor-prop + factor-propcontrols/lighting/instruments-norm/factor-prop /emission /animation animation @@ -42,7 +42,7 @@ red1.0/red green0.2/green blue0.0/blue - factor-propsim/model/material/instruments/factor/factor-prop + factor-propcontrols/lighting/instruments-norm/factor-prop /emission /animation animation --- SenecaII/Models/kcs55/ka51b.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/kcs55/ka51b.xml 2014-06-19 21:21:56.763358499 +0200 @@ -30,15 +30,14 @@ animation typematerial/type - property-basesim/model/material/cockpit/property-base object-nameface/object-name object-nameauto/object-name object-namedirection/object-name emission -red-propred/red-prop -green-propgreen/green-prop -blue-propblue/blue-prop -factor-propfactor/factor-prop +red-propsim/model/overhead-lighting/red/red-prop +green-propsim/model/overhead-lighting/green/green-prop +blue-propsim/model/overhead-lighting/blue/blue-prop +factor-propcontrols/lighting/overhead-norm/factor-prop /emission /animation --- SenecaII/Models/kcs55/ki525a.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/kcs55/ki525a.xml 2014-06-19 21:21:56.267370130 +0200 @@ -46,14 +46,13 @@ animation typematerial/type -property-basesim/model/material/cockpit/property-base object-nameChassis/object-name object-nameScrew/object-name emission - red-propred/red-prop - green-propgreen/green-prop - blue-propblue/blue-prop - factor-propfactor/factor-prop + red-propsim/model/overhead-lighting/red/red-prop + green-propsim/model/overhead-lighting/green/green-prop + blue-propsim/model/overhead-lighting/blue/blue-prop + factor-propcontrols/lighting/overhead-norm/factor-prop /emission /animation --- SenecaII/Models/ki227_228.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/ki227_228.xml 2014-06-19 04:06:28.478403517 +0200 @@ -63,7 +63,7 @@ red1.0/red green0.2/green blue0.0/blue - factor-propsim/model/material/instruments/factor/factor-prop + factor-propcontrols/lighting/instruments-norm/factor-prop /emission /animation --- SenecaII/Models/SenecaII.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Models/SenecaII.xml 2014-06-19 21:21:55.751382231 +0200 @@ -771,6 +771,16 @@ /action /animation animation + typematerial/type + object-nameCowlFlapsControl.L/object-name + emission +red-propsim/model/overhead-lighting/red/red-prop +green-propsim/model/overhead-lighting/green/green-prop +blue-propsim/model/overhead-lighting/blue/blue-prop +factor-propcontrols/lighting/overhead-norm/factor-prop + /emission +/animation +animation typerotate/type object-nameCowlFlapsControl.L/object-name propertycontrols/engines/engine[0]/cowl-flaps-norm/property @@ -786,6 +796,16 @@ /axis /animation animation + typematerial/type + object-nameCowlFlapsControl.R/object-name + emission +red-propsim/model/overhead-lighting/red
Bug#751847: flightgear: Seneca II interior lighting
I discovered that the SenecaII uses some instruments that are shared with other aircraft and not defined in the SenecaII file hierarchy. These instruments seem to agree that the property controlling the dimming of instrument lights is /sim/model/material/instruments/factor, not /controls/lighting/instruments-norm. This new version of my patch unifies all uses of the lighting properties for consistency and compatibility with common instruments. Only the following properties are used now: model material instruments red type=double1.0/red green type=double0.2/green blue type=double0.0/blue factor type=double0/factor !-- used by instruments common to several aircraft -- /instruments overhead-lighting red type=double0.06/red green type=double0.003/green blue type=double0/blue factor type=double0/factor /overhead-lighting /material (This version replaces the earlier ones I posted; it is cumulative.) -- Ludovic Brenta. --- SenecaII/Instruments-3d/DeiceControl.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/DeiceControl.xml 2014-06-19 23:33:34.530355244 +0200 @@ -36,10 +36,10 @@ object-nameDeiceControl.Ampmeter.Scale/object-name emission -red-prop/sim/model/instrument-lighting/emission/red/red-prop -green-prop/sim/model/instrument-lighting/emission/green/green-prop -blue-prop/sim/model/instrument-lighting/emission/blue/blue-prop -factor-prop/controls/lighting/instruments-norm/factor-prop +red-prop/sim/model/material/instruments/red/red-prop +green-prop/sim/model/material/instruments/green/green-prop +blue-prop/sim/model/material/instruments/blue/blue-prop +factor-prop/sim/model/material/instruments/factor/factor-prop /emission /animation --- SenecaII/Instruments-3d/FuelFlow.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/FuelFlow.xml 2014-06-19 23:33:34.502355427 +0200 @@ -28,10 +28,10 @@ typematerial/type object-nameFuelFlow/object-name emission -red-propsim/model/instrument-lighting/emission/red/red-prop -green-propsim/model/instrument-lighting/emission/green/green-prop -blue-propsim/model/instrument-lighting/emission/blue/blue-prop -factor-propcontrols/lighting/instruments-norm/factor-prop +red-propsim/model/material/instruments/red/red-prop +green-propsim/model/material/instruments/green/green-prop +blue-propsim/model/material/instruments/blue/blue-prop +factor-propsim/model/material/instruments/factor/factor-prop /emission /animation --- SenecaII/Instruments-3d/ki266.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/ki266.xml 2014-06-19 23:33:34.538355193 +0200 @@ -59,10 +59,10 @@ typematerial/type object-nameModeSwitch/object-name emission -red-propsim/model/instrument-lighting/emission/red/red-prop -green-propsim/model/instrument-lighting/emission/green/green-prop -blue-propsim/model/instrument-lighting/emission/blue/blue-prop -factor-propcontrols/lighting/instruments-norm/factor-prop +red-propsim/model/material/instruments/red/red-prop +green-propsim/model/material/instruments/green/green-prop +blue-propsim/model/material/instruments/blue/blue-prop +factor-propsim/model/material/instruments/factor/factor-prop /emission /animation --- SenecaII/Instruments-3d/kr87.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/kr87.xml 2014-06-19 23:33:34.542355166 +0200 @@ -48,10 +48,10 @@ object-nameknobs.FLT/object-name object-nameknobs.SET/object-name emission -red-prop/sim/model/instrument-lighting/emission/red/red-prop -green-prop/sim/model/instrument-lighting/emission/green/green-prop -blue-prop/sim/model/instrument-lighting/emission/blue/blue-prop -factor-prop/controls/lighting/instruments-norm/factor-prop +red-prop/sim/model/material/instruments/red/red-prop +green-prop/sim/model/material/instruments/green/green-prop +blue-prop/sim/model/material/instruments/blue/blue-prop +factor-prop/sim/model/material/instruments/factor/factor-prop /emission /animation --- SenecaII/Instruments-3d/kra10a.xml 2012-08-02 10:43:27.0 +0200 +++ SenecaII/Instruments-3d/kra10a.xml 2014-06-19 23:33:34.538355193 +0200 @@ -28,10 +28,10 @@ typematerial/type object-namekra10.face/object-name emission -red-prop/sim/model/instrument-lighting/emission/red/red-prop -green-prop/sim/model/instrument-lighting/emission
Bug#751847: flightgear: Seneca II interior lighting
Hello, The following patch fixes the first problem, i.e. the overhead light switch becomes sensitive and lights the overhead lights. --- Aircraft/SenecaII/Models/SenecaII.xml 2012-08-02 10:43:27.0 +0200 +++ Aircraft/SenecaII/Models/SenecaII.xml 2014-06-18 22:32:50.550356390 +0200 @@ -2250,6 +2250,19 @@ z2-m1.94148/z2-m /axis /animation +animation + typepick/type + object-nameOverhead.CockpitLightSwitch/object-name + visibletrue/visible + action +button0/button +repeatablefalse/repeatable +binding + commandproperty-toggle/command + propertycontrols/lighting/panel-norm/property +/binding + /action +/animation animation typenoshadow/type -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751847: flightgear: Seneca II interior lighting
Package: flightgear Version: 3.0.0-1 Severity: minor Hello, In the cockpit of the Seneca II, the overhead light switch is insensitive to the mouse and not highlighted by Ctrl+C. However, one can turn cockpit lighting on by going to the property browser (in Debug menu) and setting the property /controls/lighting/panel-norm to a value larger than 0; in this case the button actually rotates like a dimmer would, when this button clearly looks like an on-off switch with no intermediate values possible. A slightly more serious issue is that, even with /controls/lighting/panel-norm set to 1 (the maximum), the cockpit remains entirely dark, i.e. the overhead lights are useless. It would be nice if these lights actually allowed seeing the controls that don't have a backlight, i.e. throttle, RPM, mixture, etc. Such lighting would make it easier to find the instrument lighting dimmer in the dark :) See http://wiki.flightgear.org/Howto:Lightmap for what I mean. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751855: flightgear: Beechcraft 1900D and NAV2 on the EFIS
Package: flightgear Version: 3.0.0-1 Severity: minor Hello, The Beechcraft 1900D has two VOR/DME radios but only one is ever displayed on the EFIS (cathode ray tube below the primary flight display). There seems to be no way at all to show NAV2, which is most annoying as far as DME is concerned. (One can still use parts of NAV2 as the double-stemmed arrow of the Radio-Magnetic Indicator, under the airspeed indicator, points to the beacon). On the autopilot panel between the seats, next to the YD and AP buttons are two buttons labelled with upward pointing arrows; one with a single stem and the other with a double stem. These buttons also appear in the autopilot settings dialog box called by F11 but they seem not to do anything. It is my understanding that these buttons should toggle the display of NAV1 and NAV2, respectively, on the EFIS; NAV1 uses the single-stemmed arrow and NAV2 uses the double-stemmed arrow. Is this correct? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: Bug #750939: flightgear: Occasional deadlock when processing key input
) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: flightgear: Occasional deadlock when processing key input
table info available. #25 0x7fbb5986f219 in osgViewer::ViewerBase::frame(double) () from /usr/lib/libosgViewer.so.99 No symbol table info available. #26 0x00ad3eaa in fgOSMainLoop() () No symbol table info available. #27 0x005e150c in fgMainInit(int, char**) () No symbol table info available. #28 0x005a43f1 in main () No symbol table info available. (gdb) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750939: flightgear: Occasional deadlock when processing key input
in FGNasalSys::handleCommand(char const*, char const*, char const*, SGPropertyNode const*) () #18 0x00919617 in FGNasalSys::handleCommand(SGPropertyNode const*) () #19 0x7f4453bb in SGBinding::innerFire() const () from /usr/lib/x86_64-linux-gnu/libSimGearCore.so.3.0.0 #20 0x7f445f47 in fireBindingList(std::vectorSGSharedPtrSGBinding, std::allocatorSGSharedPtrSGBinding const, SGPropertyNode*) () from /usr/lib/x86_64-linux-gnu/libSimGearCore.so.3.0.0 #21 0x007489d1 in FGKeyboardInput::doKey(int, int, int, int) () #22 0x00acec18 in flightgear::FGEventHandler::handle(osgGA::GUIEventAdapter const, osgGA::GUIActionAdapter) () #23 0x7f4eedaa9a77 in osgViewer::Viewer::eventTraversal() () from /usr/lib/libosgViewer.so.99 #24 0x7f4eedaab219 in osgViewer::ViewerBase::frame(double) () from /usr/lib/libosgViewer.so.99 #25 0x00ad3eaa in fgOSMainLoop() () #26 0x005e150c in fgMainInit(int, char**) () #27 0x005a43f1 in main () This looks very much like a deadlock; all threads are waiting for a condition variable; one thread is polling in libasound.so. The last time this deadlock occurred while after pressing 'v' several times to cycle though all the views. Presumably, this is what FGKeyboardInput::doKey(int, int, int, int) () (frame #21 in thread 1) was trying to do. If the deadlock occurs again, I'll compare the stack traces and report back here. I am not certain whether the airplane being flown is part of the trigger for this problem (but IIRC, Nasal is the scripting system of FlightGear and thread 1 appears to be running some sort of Nasal script). I suppose the best way to resolve this deadlock is to audit the source code of FlightGear to see which threads are waiting for the same condition variable and to run FlightGear with a breakpoint on one of these threads. I'll keep a core dump handy for anyone willing to investigate. -- Ludovic Brenta. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flightgear depends on: ii flightgear-data-all 3.0.0-1 ii freeglut3 2.8.1-2 ii libc6 2.18-7 ii libdbus-1-3 1.8.2-1 ii libgcc1 1:4.9.0-5 ii libgl1-mesa-glx [libgl1] 10.1.4-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgsm1 1.0.13-4 ii libice6 2:1.0.8-2 ii libjpeg8 8d-2 ii libopenal11:1.14-4 ii libopenscenegraph99 3.2.0~rc1-5.1 ii libopenthreads14 3.2.0~rc1-5.1 ii libplib1 1.8.5-7 ii libpng12-01.2.50-1 ii libsimgearcore3.0.0 3.0.0-3 ii libsimgearscene3.0.0 3.0.0-3 ii libsm62:1.2.1-2 ii libspeex1 1.2~rc1.1-1 ii libspeexdsp1 1.2~rc1.1-1 ii libsqlite3-0 3.8.4.3-3 ii libstdc++64.9.0-5 ii libudev1 204-8 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii libxi62:1.7.2-1 ii libxmu6 2:1.1.2-1 ii zlib1g1:1.2.8.dfsg-1 flightgear recommends no packages. flightgear suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750859: flightgear: Crashes on some scenery objects: strutils.cxx:65:utf8ToLatin1: wrong char value
Package: flightgear Version: 3.0.0-2 Severity: important Hello, FlightGear crashes when loading certain tiles downloaded using TerraSync. One particular tile can reproduce the crash reliably; here is a recipe: * Start FlightGear Launch Control (aka fgrun) * On the first page, the type of aircraft does not seem to matter. * On the second page, click All Airports then type EDDR (Saarbrucken). * On the third page, enable TerraSync. * Run. * Be patient while FlightGear downloads the scenery for northeastern France and parts of Germany (if you don't have those tiles yet). * Open the map (Equipment Map); it starts at zoom level 6 for me by default, helping pinpoint the object that triggers the problem. * Tick Data. This causes FlightGear to crash, leaving a 80-MiB log file in ~/.fgfs/fgfs.log. The last messages in this log file are: terrain:3:/usr/src/simgear.git/simgear/scene/tgdb/ReaderWriterSTG.cxx:256:Loading stg file /home/lbrenta/.fgfs/TerraSync/Terrain/e000n40/e007n49/3072728.stg io:4:/usr/src/simgear.git/simgear/misc/strutils.cxx:65:utf8ToLatin1: wrong char value: 4294967168 (this last line repeated millions of times with different numbers). I suspect a bug in strutils.cxx wherein the UTF-8 parser fails to recover from incorrect UTF-8 input. For that matter, the implementation of utf8ToLatin1 seems incorrect to me as it ignores the high-order bits of every byte, only checking one bit per byte of input. The terrain: message changes at each crash but the first wrong char value is always the same; for example I also got: terrain:3:/usr/src/simgear.git/simgear/scene/tgdb/ReaderWriterSTG.cxx:256:Loading stg file /home/lbrenta/.fgfs/TerraSync/Terrain/e000n40/e006n48/3056307.stg io:4:/usr/src/simgear.git/simgear/misc/strutils.cxx:65:utf8ToLatin1: wrong char value: 4294967168 terrain:3:/usr/src/simgear.git/simgear/scene/tgdb/ReaderWriterSTG.cxx:256:Loading stg file /home/lbrenta/.fgfs/TerraSync/Terrain/e000n40/e006n48/3056315.stg io:4:/usr/src/simgear.git/simgear/misc/strutils.cxx:65:utf8ToLatin1: wrong char value: 4294967168 this suggests that the terrain message might be unrelated to the io message. For completeness, here is the complete command line I used to launch FlightGear: /usr/games/fgfs --fg-root=/usr/share/games/flightgear --fg-scenery=/usr/share/games/flightgear/Scenery --airport=EDDR --aircraft=SenecaII --control=mouse --disable-random-objects --disable-hud-3d --enable-auto-coordination --disable-ai-models --disable-ai-traffic --disable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --geometry=1920x1200 --bpp=32 --enable-terrasync --disable-fgcom -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (1, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages flightgear depends on: ii flightgear-data-all 3.0.0-1 ii freeglut3 2.8.1-2 ii libc6 2.18-7 ii libdbus-1-3 1.8.2-1 ii libgcc1 1:4.9.0-5 ii libgl1-mesa-glx [libgl1] 10.1.4-1 ii libglu1-mesa [libglu1]9.0.0-2 ii libgsm1 1.0.13-4 ii libice6 2:1.0.8-2 ii libjpeg8 8d-2 ii libopenal11:1.14-4 ii libopenscenegraph99 3.2.0~rc1-5.1 ii libopenthreads14 3.2.0~rc1-5.1 ii libplib1 1.8.5-7 ii libpng12-01.2.50-1 ii libsimgearcore3.0.0 3.0.0-3 ii libsimgearscene3.0.0 3.0.0-3 ii libsm62:1.2.1-2 ii libspeex1 1.2~rc1.1-1 ii libspeexdsp1 1.2~rc1.1-1 ii libsqlite3-0 3.8.4.3-3 ii libstdc++64.9.0-5 ii libudev1 204-8 ii libx11-6 2:1.6.2-2 ii libxext6 2:1.3.2-1 ii libxi62:1.7.2-1 ii libxmu6 2:1.1.2-1 ii zlib1g1:1.2.8.dfsg-1 flightgear recommends no packages. flightgear suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749869: gnat-4.9-base: arch-dependent file in Multi-Arch: same package
tags 749869 pending thanks I have moved the offending file to the architecture-dependent package gnat-4.9. This mirrors a similar arrangement in gcc-4.9 and gcc-4.9-base. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749714: liblog4ada: failed to rename -dev package
Package: src:liblog4ada Version: 1.2-4 Severity: serious Justification: policy violation The name of the -dev package must change whenever any of the .ali files in the package changes. Compiling against libgnat-4.9 instead of libgnat-4.6 causes such a change. Similarly the name and soname of the shared library must change. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749574: gnat-4.9: Gnatlink fails with CONSTRAINT_ERROR in gnatlink.adb
I have been able to fix this problem by patching gnatlink.adb; patch attached. I am puzzled by your report that this bug is not triggered in the home-built upstream gnat-4.9 snapshot (gcc-4.9-20140112). Could you please try the following in the directory containing mai_read_config.adb: cat gdb-gnatlink EOF #!/bin/sh exec gdb /gnatlink # here, substitute the absolute path to gnatlink EOF gnatmake -D obj --GNATLINK=./gdb-gnatlink mai_read_config.adb The output should be: gnatbind -aO/home/lbrenta/src/ada/g/obj -x /home/lbrenta/src/ada/g/obj/mai_read_config.ali ./gdb-gnatlink /home/lbrenta/src/ada/g/obj/mai_read_config.ali (gdb) at which point you are in the debugger. In gdb: break base_name run obj/mai_read_config.ali finish print Linker_Options.Table (2).all'First If this is 1 without my patch then I am baffled; if this is 5 (the index of the letter 'm' in the string obj/mai_read_config.ali) then you should later see the same bug as in the Debian build of gnatlink. -- Ludovic Brenta. From: Ludovic Brenta lbre...@debian.org Forwarded: no Bug-Debian: http://bugs.debian.org/749574 Description: Constraint_Error, range check failed at gnatlink.adb:2195, when called from gnatmake with -D option The procedure gnatlink assumes that the Linker_Options.Table contains access values to strings whose 'First index is always 1. This assumption is wrong for the string returned by function Base_Name. . Instead of fixing the assumption in many places, this patch changes the function Base_Name always to return a string with 'First=1. . This looks like an upstream bug but strangely the reporter of this bug says it does not happen on GCC built from upstream sources. Further investigation is required to determine whether or not to forward this bug and patch upstream. Index: b/src/gcc/ada/gnatlink.adb === --- a/src/gcc/ada/gnatlink.adb +++ b/src/gcc/ada/gnatlink.adb @@ -273,7 +273,12 @@ Findex2 := File_Name'Last + 1; end if; - return File_Name (Findex1 .. Findex2 - 1); + declare + Result : String (1 .. Findex2 - Findex1); + begin + Result (1 .. Findex2 - Findex1) := File_Name (Findex1 .. Findex2 - 1); + return Result; + end; end Base_Name; ---
Bug#749574: gnat-4.9: Gnatlink fails with CONSTRAINT_ERROR in gnatlink.adb
I have found the reason why upstream gnatlink appears to work where Debian's gnatlink fails. Consider this program: with Ada.Text_IO; procedure A is type String_Access is access String; G : constant String (3 .. 5) := 345; H : constant String_Access := new String'(G); begin if G (1 .. 2) = ab then -- line 1 Ada.Text_IO.Put_Line (True); else Ada.Text_IO.Put_Line (False); end if; if H.all (1 .. 2) = ab then -- line 2 Ada.Text_IO.Put_Line (True); else Ada.Text_IO.Put_Line (False); end if; end A; If you compile normally, GNAT correctly warns that Constraint_Error will be raised at run time at line 1 since the bounds of G are static (3..5) and different from the ones in the if statement; and this is exactly what happens if you run the program. If you compile with -gnatpg, you get no warning and the program runs and prints: False False Well, gnatlink.adb contains such a construct at line 2195. Upstream compiles gnatlink.adb with -gnatpg and Debian compiles it without -gnatpg, thereby forcing conformance with Ada semantics. This explains the difference in behavior. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539562: RFH: gnat-4.9 -- help needed to execute test cases
retitle 539562 RFH: gnat-4.9 -- help needed to execute test cases thanks Nicolas Boulenguez has contributed a script to execute all test cases automatically; this script is part of package gnat-4.9. But the test cases themselves are not packaged and the execution of the script is not automatic, so I'm not closing this RFH yet. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746588: gnat should be an architecture dependent package
Nicolas Boulenguez writes: Ludovic, could you describe the scenario you are trying to prevent? The scenario I'd like to prevent is wherein most architectures use gnat-4.9 to build all other Ada packages but one architecture decides to use gnat-4.8 instead, resulting in compilation problems and wasted effort on that architecture. Matthias said: sure, the immediate problem is solved until the next port with a version discrepancy. A port with a version discrepancy is precisely the scenario I want to prevent. I'm not ideologically opposed to making gnat architecture-dependent, it's just that gnat has now become architecture-independent thanks to your moving /usr/bin/gnatgcc out of it. I think making gnat architecture-dependent again would only help this bad scenario. The part about gnat build-depending on gnat-4.9 is OK for me, of course. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746588: gnat should be an architecture dependent package
It is our policy[1] to support the same version of gnat on all architectures. The package gnat exists for this very purpose. Allowing gnat to depend on different versions of gnat-x.y on different architectures would defeat this purpose. If some architecture cannot support the chosen version of gnat-x.y, then we prefer to drop support for that achitecture altogether. The transition from gnat-4.6 to gnat-4.9 has been planned and announced in due course [3,4] (and furthermore accepted and approved by the Ada maintainers), therefore should have come as no surprise to anyone interested in Ada or gnat. [1] http://people.debian.org/~lbrenta/debian-ada-policy.html#The-Debian-Ada-compiler [2] https://lists.debian.org/debian-ada/2014/02/msg0.html [3] https://lists.debian.org/debian-ada/2014/04/msg00025.html Therefore I am tempted to close this bug as WONTFIX. If you have objections, please explain the benefits of making it easier to break policy. (Note that, pursuant to our policy, I intend to request removal of gnat-4.8 in the near future.) -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746588: gnat should be an architecture dependent package
Thorsten Glaser writes: Right, but there is still the transition period to take care of. There are two transition periods. The first one started on 2014-02-03 with the announcement of gnat-4.9 and ended on 2014-05-01 with the upload of gnat (=4.9). This three-month period was to bootstrap and stabilize gnat-4.9. The second transition period started with the upload of gnat (=4.9) and is for the upgrade and recompilation of all Ada packages. This second period ends with the freeze (2014-11-05) and we really need all the time we can get. In fact, right now I should be spending my time on libgtkada or some other package. If I had been aware of your porting efforts, I might have delayed the upload of gnat (=4.9) by a few days but not weeks. gnat to depend on different versions of gnat-x.y on different architectures would defeat this purpose. If some architecture cannot This is not the intention. The idea here is that, for as long as the _new_ version of gnat cannot _yet_ be built, the old version can stick around for some architecture. We will *see* the new version, and know there is something to do, but until such time, we can still use the old version. The problem is simply that m68k failed to produce a working gnat-4.9 in time for the upload of gnat. As I said, if I had been aware of your efforts I could have helped a little. support the chosen version of gnat-x.y, then we prefer to drop support for that achitecture altogether. Really? Especially debian-ports.org architectures can sometimes be a bit slower in adopting things like this, but gnat *can* work there. Do you really want to throw this into porters' faces? Yes, really. I'm not saying this to disparage your work or your dedication but, honestly, how many people do you think write and deploy Ada programs, on Debian, on m68k machines? Ada is a minority language, for starters. popcon shows ~1000 installs of gnat-4.6 on all architectures of Debian (compare this with ~170k installs of libc6). In my 10+ years of maintaining Ada on Debian, I have learned to allocate my time in the way that I perceive will benefit the most users. Sorry. What I can do for you at this point is accept your m68k patches and apply them in future uploads of gnat-4.9. objections, please explain the benefits of making it easier to break policy. There is no break of any policy involved. If something depends on gnat 4.9, it must have 'gnat (= 4.9)' in Build-Depends anyway, for at least until gnat 4.9 (distinguished from gnat-4.9) is in stable or even oldstable, which is true for all versioned Build-Depends in Debian. No, the Debian Ada Policy says that packages must build-depend on both gnat and gnat-4.9 (and explains why). -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#666106: gnat-4.8: kfreebsd-i386: Exceptions with tracebacks in task rendezvous cause STORAGE_ERROR
I have requested removal of gnat-4.8 from the archive. Can you please tell me whether this bug is still present in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#673772: gnat-4.8: mips: ATC with syscalls not working
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#687642: armel armhf: gcc -shared reads libgnarl.a instead of .so
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? IIUC, upstream has improved support for arm in this new release. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717014: gnat-4.8: on some archs, a library using Elementary_Functions needs -lm
I have requested removal of gnat-4.8 from the archive; can you tell me if this bug is still presend in gnat-4.9? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746755: ftp.debian.org: RM: gnat-4.8 -- RoM, no rdeps, superseded by gnat-4.9
Package: ftp.debian.org Severity: normal I do not have the manpower to support more than one version of gnat at a time. Future uploads of gcc-4.8-source might break gnat-4.8. gnat-4.8 has no reverse dependencies. Please remove it. -- Ludovic Brenta, maintainer of gnat-4.8 and gnat-4.9. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746588: gnat should be an architecture dependent package
I've just uploaded gnat to depend on gnat-4.9 on all architectures. Does this solve the immediate problem? Making the package architecture-dependent is, of course, a longer-term solution. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745372: When build apt (1.0.1) with gcc-4.9, it cannot start with libstdc++6 (4.8)
Everything looks fine on amd64 but the bug was reported on mips64el. Perhaps there is a discrepancy between architectures? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742590: gnat-4.9: FTBFS on powerpc, Storage_Error in two source files
Package: src:gnat-4.9 Version: 4.9-20140218-1 Severity: serious Symptoms from the buildd log: /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-zcx' make[6]: *** [rts-static-zcx/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-zcx] Error 2 make[4]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC a-direct.adb -o a-direct.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-direct.o] Error 1 make[7]: *** Waiting for unfinished jobs /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -W -Wall -gnatpg -nostdinc -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-static-sjlj' make[6]: *** [rts-static-sjlj/libgnat.a] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-static-sjlj] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-static-sjlj] Error 2 /«PKGBUILDDIR»/build/./gcc/xgcc -B/«PKGBUILDDIR»/build/./gcc/ -c -g -O2 -fPIC -W -Wall -gnatpg -nostdinc -fPIC -g -O1 -fno-inline \ -fno-toplevel-reorder a-except.adb -o a-except.o raised STORAGE_ERROR : stack overflow or erroneous memory access make[7]: *** [a-except.o] Error 1 make[7]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada/rts-shared-zcx' make[6]: *** [rts-shared-zcx/libgnat-4.9.so] Error 2 make[6]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[5]: *** [gnatlib-shared-zcx] Error 2 make[5]: Leaving directory `/«PKGBUILDDIR»/build/gcc/ada' make[4]: *** [gnatlib-shared-zcx] Error 2 make[4]: Leaving directory `/«PKGBUILDDIR»/build/libada' make[3]: *** [all-libada] Error 2 make[3]: Leaving directory `/«PKGBUILDDIR»/build' make[2]: *** [bootstrap] Error 2 make[2]: Leaving directory `/«PKGBUILDDIR»/build' Note that none of these exceptions are raised when using the bootstrap compiler (gnat-4.6) to compile a-except.adb. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
The reasons for the upstream change are explained in the bug report I referenced: http://gcc.gnu.org/PR54040, and discussed in detail in the thread referenced there, viz.: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01504.html Since the decision to use time_t instead of long has been discussed and approved upstream, I think you should take your objections there, i.e. by following up to that thread. I will not change s-osinte-posix.adb without approval from upstream but I will take your suggestion to change ada-kfreebsd.diff to use s-osinte-posix.adb, introducing time_t in the private part of s-osinte-kfreebsd-gnu.ads. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
The thread I referenced ends here: http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02069.html So it seems upstream is aware of the issue but has been unable to find the time to fix it properly. If you send a proper patch to them, I think they'd be delighted. Note that x32 seems *not* to adhere to POSIX in this respect as it defines long to be 32-bit but uses a 64-bit value for timespec.tv_nsec. You cannot change that but you can try to support all architectures in a clean way as Arno suggested. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
Ludovic Brenta writes: Svante Signell svante.sign...@gmail.com writes: Ping, adding this bug report to debian-ada too. Who is Ada upstream? Patience. I'm waiting for Matthias to upload a newer gcc-4.9-source containing the fix for your bug #740153, then I will upload a gnat-4.9 incorporating this and your patch. Now that the newer gcc-4.9 has been uploaded, I am reviewing this issue and I discovered that the change you complain about was in fact made upstream (that was not clear to me from your bug report): commit e3a1f6b50495473f677f413d8740808a3fde5a9a Author: hjl hjl@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Fri Nov 15 12:06:25 2013 + Add and use System.Linux.time_t for time_t PR ada/54040 * s-linux-x32.ads: New file. * s-osprim-x32.adb: Likewise. * s-linux.ads (time_t): New type. * s-linux-alpha.ads (time_t): Likewise. * s-linux-hppa.ads (time_t): Likewise. * s-linux-mipsel.ads (time_t): Likewise. * s-linux-sparc.ads (time_t): Likewise. * s-osinte-linux.ads (time_t): Mark it private. Replace long with System.Linux.time_t. (timespec): Replace long with time_t. * s-osinte-posix.adb (To_Timespec): Likewise. * s-taprop-linux.adb (timeval): Replace C.long with System.OS_Interface.time_t. * gcc-interface/Makefile.in (LIBGNAT_TARGET_PAIRS): Replace s-linux.ads with s-linux-x32.ads, s-osprim-posix.adb with s-osprim-x32.adb for x32. git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@204840 138bc75d-0d04-0410-961f-82ee72b054a4 I also see that s-osinte-gnu.ads, which is used solely by hurd-i386 and added by the Debian patch ada-hurd.diff, has this to say about the matter: type time_t is new long; type timespec is record tv_sec : time_t; tv_nsec : long; end record; pragma Convention (C, timespec); I propose to make time_t a subtype, rather than a derived type, of long. This should keep everyone happy. Comments? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#740286: gnat-4.9: s-osinte-posix.adb is wrong about timespec.tv_nsec compared to gnat-4.8
Svante Signell svante.sign...@gmail.com writes: Ping, adding this bug report to debian-ada too. Who is Ada upstream? Patience. I'm waiting for Matthias to upload a newer gcc-4.9-source containing the fix for your bug #740153, then I will upload a gnat-4.9 incorporating this and your patch. In the mean time, Xavier, do you have any comments on this specific bug? In particular, how do you think Svante's change might affect GNU/kFreeBSD? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713124: gnat-4.6: FTBFS: unsatisfiable build-dependency: automake ( 1:1.12) but 1:1.13.3-1 is to be installed
Is there any reason to specify Build-Depends: automake ( 1:1.12)? I can build this package without it. Patch attached. Thanks but please modify debian/control.m4 and debian/rules.conf, not debian/control, which is generated. I cannot answer your question myself because these build-dependencies are from the GCC sources. doko, can you shed some light on this? -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#539562: RFH: gnat-4.8 -- help needed to execute test cases
retitle 539562 RFH: gnat-4.8 -- help needed to execute test cases thanks I am updating the title of this bug to reflect the fact that we're now working on gnat-4.8. However, work on gnat-4.9 will start Real Soon Now. Help on running the tests is *always* welcome and even more welcome would be someone with the time and energy to turn the remaining bug reports into an automated test suite. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#713297: polyorb: FTBFS: CosEventChannelAdmin.idl:24:31: CosEventComm is undefined
Email forwarded from Pavel Zhukov:
Hi debian ada team! ,
First of all I'm not familar with debian bug tracking system (sorry
about that).
I hit the same issue as described in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713297 while building
polyorb for fedora (with gcc 4.8).
The patch [1] fixed issue for me and it was accepted by Adacore. Feel
free to use one :)
--
Pavel
[1]
--- a/configure 2014-01-27 23:38:14.944966528 +0100
+++ b/configure 2014-01-27 23:38:28.841024943 +0100
@@ -5641,7 +5641,7 @@
case $CXXCPP in
*g++*)
if test ${CXXCPPFLAGS} = ; then
-IDLCPPFLAGS=-x c++ -ansi
+IDLCPPFLAGS=-x c++ -ansi -ffreestanding
# Options to use GNU C++ preprocessor as IDL preprocessor
# -x c++ force C++ preprocessor mode (even though it cannot be
# inferred from filename extension .idl)
--- a/support/idlcpp.m4 2014-01-27 23:37:44.230837412 +0100
+++ b/support/idlcpp.m4 2014-01-27 23:38:04.278921691 +0100
@@ -38,7 +38,7 @@
case $CXXCPP in
*g++*)
if test ${CXXCPPFLAGS} = ; then
-IDLCPPFLAGS=-x c++ -ansi
+IDLCPPFLAGS=-x c++ -ansi -ffreestanding
# Options to use GNU C++ preprocessor as IDL preprocessor
# -x c++ force C++ preprocessor mode (even though it cannot be
# inferred from filename extension .idl)
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#669082: 669082: libtexttools: obey DEB_BUILD_OPTIONS parallel=n
The -j16 in the buildd log was the result of *not* defining DEB_BUILD_OPTIONS; the default was to use all processors. DEB_BUILD_OPTIONS was intended as an optional way to override this default. If this works correctly i.e. use all processors or the number defined in DEB_BUILD_OPTIONS then of course this bug is moot. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732253: Error in `angband': double free or corruption (fasttop)
Package: angband Version: 1:3.3.2-2.1 Severity: important angband crashes on startup when using the -msdl option: $ angband -snone -msdl *** Error in `angband': double free or corruption (fasttop): 0x01357b40 *** === Backtrace: = /lib/x86_64-linux-gnu/libc.so.6(+0x7aa16)[0x7f25c3e17a16] /lib/x86_64-linux-gnu/libc.so.6(+0x7b793)[0x7f25c3e18793] /usr/lib/x86_64-linux-gnu/libSDL_ttf-2.0.so.0(TTF_CloseFont+0x2c)[0x7f25c7685b1c] angband[0x4db94e] angband[0x4e227d] angband(init_sdl+0x8a)[0x4e2566] angband(main+0x3e2)[0x4d2cda] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x7f25c3dbe995] angband[0x418419] === Memory map: 0040-00531000 r-xp 08:01 100677903 /usr/games/angband 0073-0073b000 rw-p 0013 08:01 100677903 /usr/games/angband 0073b000-00759000 rw-p 00:00 0 0130a000-01391000 rw-p 00:00 0 [heap] 7f25b7cf2000-7f25b84d6000 rw-s 00:04 49414146 /SYSV (deleted) 7f25b84d6000-7f25b854a000 rw-p 00:00 0 7f25b854a000-7f25b86d4000 r--p 08:01 67155845 /usr/lib/locale/locale-archive 7f25b86d4000-7f25b86e r-xp 08:01 92840 /lib/x86_64-linux-gnu/libnss_files-2.17.so 7f25b86e-7f25b88df000 ---p c000 08:01 92840 /lib/x86_64-linux-gnu/libnss_files-2.17.so 7f25b88df000-7f25b88e r--p b000 08:01 92840 /lib/x86_64-linux-gnu/libnss_files-2.17.so 7f25b88e-7f25b88e1000 rw-p c000 08:01 92840 /lib/x86_64-linux-gnu/libnss_files-2.17.so 7f25b88e1000-7f25b88eb000 r-xp 08:01 92836 /lib/x86_64-linux-gnu/libnss_nis-2.17.so 7f25b88eb000-7f25b8aea000 ---p a000 08:01 92836 /lib/x86_64-linux-gnu/libnss_nis-2.17.so 7f25b8aea000-7f25b8aeb000 r--p 9000 08:01 92836 /lib/x86_64-linux-gnu/libnss_nis-2.17.so 7f25b8aeb000-7f25b8aec000 rw-p a000 08:01 92836 /lib/x86_64-linux-gnu/libnss_nis-2.17.so 7f25b8aec000-7f25b8af3000 r-xp 08:01 92834 /lib/x86_64-linux-gnu/libnss_compat-2.17.so 7f25b8af3000-7f25b8cf2000 ---p 7000 08:01 92834 /lib/x86_64-linux-gnu/libnss_compat-2.17.so 7f25b8cf2000-7f25b8cf3000 r--p 6000 08:01 92834 /lib/x86_64-linux-gnu/libnss_compat-2.17.so 7f25b8cf3000-7f25b8cf4000 rw-p 7000 08:01 92834 /lib/x86_64-linux-gnu/libnss_compat-2.17.so 7f25b8cf4000-7f25b8d09000 r-xp 08:01 92862 /lib/x86_64-linux-gnu/libnsl-2.17.so 7f25b8d09000-7f25b8f08000 ---p 00015000 08:01 92862 /lib/x86_64-linux-gnu/libnsl-2.17.so 7f25b8f08000-7f25b8f09000 r--p 00014000 08:01 92862 /lib/x86_64-linux-gnu/libnsl-2.17.so 7f25b8f09000-7f25b8f0a000 rw-p 00015000 08:01 92862 /lib/x86_64-linux-gnu/libnsl-2.17.so 7f25b8f0a000-7f25b8f0c000 rw-p 00:00 0 7f25b8f0c000-7f25b91bf000 r-xp 08:01 100688156 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 7f25b91bf000-7f25b93be000 ---p 002b3000 08:01 100688156 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 7f25b93be000-7f25b93da000 r--p 002b2000 08:01 100688156 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 7f25b93da000-7f25b93db000 rw-p 002ce000 08:01 100688156 /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2.0.8 7f25b93db000-7f25b93f r-xp 08:01 151 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f25b93f-7f25b95f ---p 00015000 08:01 151 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f25b95f-7f25b95f1000 rw-p 00015000 08:01 151 /lib/x86_64-linux-gnu/libgcc_s.so.1 7f25b95f1000-7f25b96d6000 r-xp 08:01 100663456 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18 7f25b96d6000-7f25b98d5000 ---p 000e5000 08:01 100663456 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18 7f25b98d5000-7f25b98dd000 r--p 000e4000 08:01 100663456 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18 7f25b98dd000-7f25b98df000 rw-p 000ec000 08:01 100663456 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.18 7f25b98df000-7f25b98f4000 rw-p 00:00 0 7f25b98f4000-7f25b993b000 r-xp 08:01 100667150 /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0 7f25b993b000-7f25b9b3a000 ---p 00047000 08:01 100667150 /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0 7f25b9b3a000-7f25b9b3b000 r--p 00046000 08:01 100667150 /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0 7f25b9b3b000-7f25b9b3c000 rw-p 00047000 08:01 100667150 /usr/lib/x86_64-linux-gnu/libopus.so.0.5.0 7f25b9b3c000-7f25b9b4 r-xp 08:01 3801
Bug#574609: Bug #574609: RFH: monotone -- a distributed version (revision) control system; more maintainers needed
On Tue, 20 Aug 2013 13:01:40 +0200, Markus Wanner wrote: Anybody opposed to closing this? Given my recent work on the package and the 1.0-11 that just migrated to testing. I suggest you close this bug in the next upload, explaining that you added yourself to Uploaders. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#714577: RM: gnat-4.4 -- obsolete
Matthias Klose d...@debian.org writes: Package: ftp.debian.org Not sure why that wasn't removed before. But please lets do it now. Because of ghdl. We cannot remove gnat-4.4 before ghdl. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709831: dput-ng: dcut says: [Errno 2] No such file or directory, without an explanation
Arno Töll writes: Hi Ludovic, On 25.05.2013 22:40, Ludovic Brenta wrote: [TRACE] 1369514263.261604: (maybe_print_traceback) File /usr/lib/python2.7/dist-packages/dput/commands/dm.py, line 39, in generate_dak_commands_name [TRACE] 1369514263.261674: (maybe_print_traceback) the_file = %s-%s.dak-commands % (os.getlogin(), int(time.time())) could you please try again with the version in git or cherry-pick [1] to your installation? os.getlogin() requires a controlling terminal to obtain your log-in name, which is not available in some setups which may throw your error in that case. We fixed this a while back in f7418f6b [1] and I suspect this being your problem. You are correct, now I realize that I was running dcut inside an emacs shell window. Running dcut in a plain xterm seems to have worked around the problem. I have not tried the latest version in git but I have reviewed the commit you mentioned and I think it probably solves the bug. Still, I think this bug report should remain open until a newer version of dcut-ng reaches unstable. Thanks for the spot-on diagnosis. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709831: dput-ng: dcut says: [Errno 2] No such file or directory, without an explanation
Package: dput-ng
Version: 1.4
Severity: normal
I made several attemps to grant DM upload permissions using dcut from
package dput-ng:
$ dcut dm --uid=025AFE95AC9DF31B --allow monotone
Uploading commands file to ftp.upload.debian.org (incoming: /pub/UploadQueue/)
Picking DM Markus Wanner mar...@bluegap.ch with fingerprint
ED6762360784E331E25303D6025AFE95AC9DF31B
[Errno 2] No such file or directory
I have no idea what's going wrong and the debug trace below is not much
help for me either. Perhaps you can tell me which file is missing and
why?
$ dcut -d -d dm --uid=025AFE95AC9DF31B --allow monotone
[DEBUG] 1369514263.082472: (load_config) Loading configuration: profiles DEFAULT
[TRACE] 1369514263.082546: (load_config) Checking for configuration: skel/
[TRACE] 1369514263.082582: (load_config) Checking - skel//profiles/DEFAULT.json
[TRACE] 1369514263.082626: (get_config) name: DEFAULT - {} / {'default': {},
'config_cleanup': False, 'configs': ['skel/']}
[DEBUG] 1369514263.082665: (load_config) Loading configuration: profiles DEFAULT
[TRACE] 1369514263.082695: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1369514263.082723: (load_config) Checking -
/usr/share/dput-ng//profiles/DEFAULT.json
[TRACE] 1369514263.082765: (get_config) name: DEFAULT - {} / {'default': {},
'config_cleanup': False, 'configs': ['/usr/share/dput-ng/']}
[DEBUG] 1369514263.082801: (load_config) Loading configuration: profiles DEFAULT
[TRACE] 1369514263.082829: (load_config) Checking for configuration:
/etc/dput.d/
[TRACE] 1369514263.082857: (load_config) Checking -
/etc/dput.d//profiles/DEFAULT.json
[DEBUG] 1369514263.082933: (load_config) Loading configuration: metas debian
[TRACE] 1369514263.082975: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1369514263.083006: (load_config) Checking -
/usr/share/dput-ng//metas/debian.json
[TRACE] 1369514263.083048: (load_config) Checking for configuration:
/etc/dput.d/
[TRACE] 1369514263.083079: (load_config) Checking -
/etc/dput.d//metas/debian.json
[TRACE] 1369514263.083154: (load_config) Checking for configuration:
/home/lbrenta/.dput.d
[TRACE] 1369514263.083189: (load_config) Checking -
/home/lbrenta/.dput.d/metas/debian.json
[TRACE] 1369514263.083230: (load_config) Checking for configuration: skel/
[TRACE] 1369514263.083260: (load_config) Checking - skel//metas/debian.json
[TRACE] 1369514263.083306: (load_config) Ignoring key allow_dcut for debian
(True)
[TRACE] 1369514263.083358: (get_config) name: DEFAULT - {u'default_host_main':
u'', u'hash': u'sha1', u'allowed_distributions': u'(?!UNRELEASED)',
u'check-debs': {u'skip': False, u'enforce': u'debs'}, u'pre_upload_command':
u'', u'allow_unsigned_uploads': False, u'passive_ftp': True,
u'full_upload_log': False, u'meta': u'debian', u'hooks':
[u'allowed-distribution', u'protected-distribution', u'checksum',
u'suite-mismatch', u'check-debs', u'gpg'], u'interface': u'cli',
u'run_lintian': False, u'login': u'*', u'post_upload_command': u'',
u'allow_dcut': False, u'method': u'ftp', u'scp_compress': True} / {'default':
{}, 'config_cleanup': False, 'configs': ['/etc/dput.d/']}
[DEBUG] 1369514263.083440: (preload) Skipping file /etc/dput.cf: Not accessible
[DEBUG] 1369514263.083515: (load_config) Loading configuration: profiles DEFAULT
[TRACE] 1369514263.083547: (load_config) Checking for configuration:
/home/lbrenta/.dput.d
[TRACE] 1369514263.083575: (load_config) Checking -
/home/lbrenta/.dput.d/profiles/DEFAULT.json
[TRACE] 1369514263.083612: (get_config) name: DEFAULT - {} / {'default': {},
'config_cleanup': False, 'configs': ['/home/lbrenta/.dput.d']}
[DEBUG] 1369514263.083667: (preload) Skipping file /home/lbrenta/.dput.cf: Not
accessible
[TRACE] 1369514263.083905: (get_config) Loading entry security-master
[DEBUG] 1369514263.083942: (load_config) Loading configuration: profiles
security-master
[TRACE] 1369514263.083971: (load_config) Checking for configuration: skel/
[TRACE] 1369514263.084109: (load_config) Checking -
skel//profiles/security-master.json
[TRACE] 1369514263.084154: (get_config) name: security-master - {} /
{'default': {}, 'config_cleanup': False, 'configs': ['skel/']}
[TRACE] 1369514263.084186: (get_config) {'name': 'security-master'}
[TRACE] 1369514263.084221: (get_config) Rewrote to:
[TRACE] 1369514263.084247: (get_config) {'name': 'security-master'}
[DEBUG] 1369514263.084278: (load_config) Loading configuration: profiles
security-master
[TRACE] 1369514263.084305: (load_config) Checking for configuration:
/usr/share/dput-ng/
[TRACE] 1369514263.084331: (load_config) Checking -
/usr/share/dput-ng//profiles/security-master.json
[TRACE] 1369514263.084382: (get_config) name: security-master - {} /
{'default': {}, 'config_cleanup': False, 'configs': ['/usr/share/dput-ng/']}
[TRACE] 1369514263.084414: (get_config) {'name': 'security-master'}
[TRACE] 1369514263.084448: (get_config) Rewrote to:
[TRACE] 1369514263.084478: (get_config) {'name':
Bug#706169: libtemplates-parser11.6: arch-dependent file in Multi-Arch: same package
Jakub Wilk writes: Package: libtemplates-parser11.6 Version: 11.6-2 Severity: important User: multiarch-de...@lists.alioth.debian.org Usertags: multiarch libtemplates-parser11.6 is marked as Multi-Arch: same, but the following file is architecture-dependent: /usr/share/doc/libtemplates-parser11.6/changelog.Debian.gz An example diff between i386 and amd64 (after ungzipping) is attached. Probably the result of uploading to amd64 and i386 manually, which I do very seldom, and changing the changelog in between. A rebuild request or a binNMU should fix this but I don't think this would be accepted in wheezy. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
