Bug#941544: NMU upload
Gard Spreemann writes: > If I don't hear back from anyone within three days, my AM will upload > this NMU in DELAYED/7. Thanks for working on this. As far as I am concerned, please upload directly without delay. Hendrik
Bug#876533: hol-light FTBFS with OCaml 4.05.0
> Hi Hendrik, any progress on this? I notice in the ocaml transition tracker: I really spend more than 4 weeks in discussions with upstream about license and copyright clarifications. Now it is finished. I uploaded a new hol-light version to DOM git yesterday. Please review and upload. If you think I fulfill the conditions for directly uploading hol-light, I would appreciate, if somebody could execute dcut dm --uid "Hendrik Tews" --allow hol-light Bye, Hendrik
Bug#878968: libglvnd0-nvidia: undefined symbol: _glapi_tls_Current makes system unusable
> Please attach the full report by running > > reportbug --template nvidia-driver I am not sure this helps, but here you go. This is the result that ``reportbug --template nvidia-driver'' saved in /tmp: Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: Hendrik Tews To: Debian Bug Tracking System Subject: nvidia-driver: none Package: nvidia-driver Severity: wishlist Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf, arm64 Kernel: Linux 4.13.0-1-amd64 (SMP w/4 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: systemd (via /run/systemd/system)
Bug#878968: libglvnd0-nvidia: undefined symbol: _glapi_tls_Current makes system unusable
Package: libglvnd0-nvidia Version: 375.82-5 Severity: critical Dear Maintainer, after updating some packages this morning, X11 did not come up any more and the system was completely unusable. Apparently gdm was restarting continuously, making it impossible to enter anything in a terminal window. I needed to boot in recovery mode to get access again. The syslog contains /usr/lib/gdm3/gdm-x-session[2703]: (EE) Failed to load /usr/lib/xorg/modules/extensions/libglx.so: /usr/lib/x86_64-linux-gnu/libGL.so.1: undefined symbol: _glapi_tls_Current and I get the same undefined symbol error when I try startx. After installing libglvnd0 (and purging libglvnd0-nvidia) everything is fine again. In contrast to what is reported in https://lists.debian.org/debian-kde/2017/10/msg00028.html, the problem appears again, when I reinstall libglvnd0-nvidia. Bye, Hendrik -- Package-specific info: uname -a: Linux cert 4.13.0-1-amd64 #1 SMP Debian 4.13.4-1 (2017-10-01) x86_64 GNU/Linux /proc/version: Linux version 4.13.0-1-amd64 (debian-ker...@lists.debian.org) (gcc version 6.4.0 20170920 (Debian 6.4.0-7)) #1 SMP Debian 4.13.4-1 (2017-10-01) lspci 'VGA compatible controller [0300]': 00:02.0 VGA compatible controller [0300]: Intel Corporation HD Graphics 530 [8086:191b] (rev 06) (prog-if 00 [VGA controller]) Subsystem: Lenovo HD Graphics 530 [17aa:5056] Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Kernel driver in use: i915 Kernel modules: i915 dmesg: Device node permissions: crw-rw+ 1 root video 226, 0 Oct 17 21:58 /dev/dri/card0 crw-rw+ 1 root video 226, 128 Oct 17 21:58 /dev/dri/renderD128 /dev/dri/by-path: total 0 lrwxrwxrwx 1 root root 8 Oct 17 21:58 pci-:00:02.0-card -> ../card0 lrwxrwxrwx 1 root root 13 Oct 17 21:58 pci-:00:02.0-render -> ../renderD128 video:x:44:tews OpenGL and NVIDIA library files installed: lrwxrwxrwx 1 root root 15 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> libEGL.so.1.0.0 -rw-r--r-- 1 root root 76344 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libEGL.so.1.0.0 lrwxrwxrwx 1 root root 14 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGL.so.1 -> libGL.so.1.0.0 -rw-r--r-- 1 root root 567624 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGL.so.1.0.0 lrwxrwxrwx 1 root root 18 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 -> libGLESv2.so.2.0.0 -rw-r--r-- 1 root root 55616 Sep 28 22:04 /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.0.0 -rw-r--r-- 1 root root 29 Jul 7 07:31 /usr/lib/xorg/modules/extensions/libglx.so -rw-r--r-- 1 root root 5883 Oct 17 09:07 /var/log/Xorg.0.log /etc/modprobe.d: total 24 drwxr-xr-x 2 root root 4096 Sep 18 13:14 . drwxr-xr-x 162 root root 12288 Oct 17 21:55 .. -rw-r--r-- 1 root root 154 Nov 30 2016 amd64-microcode-blacklist.conf -rw-r--r-- 1 root root 154 Nov 9 2016 intel-microcode-blacklist.conf /etc/modules-load.d: -rw-r--r-- 1 root root 195 Mar 1 2017 /etc/modules /etc/modules-load.d/: total 20 drwxr-xr-x 2 root root 4096 Oct 17 08:42 . drwxr-xr-x 162 root root 12288 Oct 17 21:55 .. -rw-r--r-- 1 root root 119 Jan 19 2017 cups-filters.conf lrwxrwxrwx 1 root root10 Oct 11 00:46 modules.conf -> ../modules Files from nvidia-installer: Config and logfiles: << /home/tews/.local/share/xorg/Xorg.0.log >> [32.985] X.Org X Server 1.19.3 Release Date: 2017-03-15 [32.991] X Protocol Version 11, Revision 0 [32.992] Build Operating System: Linux 4.9.0-3-amd64 x86_64 Debian [32.994] Current Operating System: Linux cert 4.13.0-1-amd64 #1 SMP Debian 4.13.4-1 (2017-10-01) x86_64 [32.994] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.13.0-1-amd64 root=/dev/mapper/cert--vg-root1 ro single [32.998] Build Date: 07 July 2017 06:22:09AM [33.000] xorg-server 2:1.19.3-2 (https://www.debian.org/support) [33.001] Current version of pixman: 0.34.0 [33.005]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [33.005] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [33.012] (==) Log file: "/home/tews/.local/share/xorg/Xorg.0.log", Time: Tue Oct 17 21:58:39 2017 [33.019] (==) Using system config directory "/usr/share/X11/xorg.conf.d" [33.024] (==) No Layout section. Using the first Screen section. [33.024] (==) No screen section available. Using defaults. [33.024] (**) |-->Screen "Default Screen Section" (0) [33.024] (**) | |-->Monitor "" [33.024] (==) No monitor specified for screen "Default Screen Section". Using a default monitor configuration. [33.024] (==) Automatically adding devices [33.024] (==) Automatically enabling
Bug#876533: hol-light FTBFS with OCaml 4.05.0
Upstream does indeed fix this problem. However, it also contains a few files with unclear license and copyright, currently preventing to package it. I am trying to solve these license and copyright issues with upstream. Hendrik
Bug#876537: otags FTBFS with OCaml 4.05.0
Yesterday, I prepared a new otags package that builds fine with 4.05, see https://lists.debian.org/debian-ocaml-maint/2017/09/msg00079.html and https://anonscm.debian.org/gitweb/?p=pkg-ocaml-maint/packages/otags.git . The only thing that is missing now is somebody who sponsors an upload. Hendrik
Bug#876533: hol-light FTBFS with OCaml 4.05.0
I have a look at it, hopefully a new upstream version will fix the problem. Hendrik
Bug#868606: 868606: hol-light FTBFS
tags 868606 upstream thanks Camlp4 version 7 is not yet supported upstream. I asked upstream about it. Hendrik
Bug#868606: hol-light FTBFS: Error: This expression has type (MLast.loc * string Ploc.vala) Ploc.vala but an expression was expected of type MLast.loc * 'a
> Some recent change in unstable make hol-light FTBFS: I blame the new camlp5 version for this. I have to see if upstream supports camlp5 version 7 already. Hendrik
Bug#843319: FTBFS: libsexplib-camlp4-dev is no longer available
Hi, AFAIR the libsexplib dependency is only used for testing after building. It can safely be removed when the the tests are disabled (or when those files that depend on libsexplib have been removed from the Makefile). Bye, Hendrik
Bug#802166: otags: fails to install: post-installation script returned error exit status 3
Mehdi Dogguy writes: > Can you give us a hint on how to work out a real fix for this issue? I am looking at it now. There is quite a bit new syntax in 4.02, yielding quite a few warnings about incomplete pattern in otags. Each of these will crash otags in the same way, for instance attributes, extension nodes, extensible variant types. I try to make a new release, but it will take more than one day. Bye, Hendrik
Bug#802166: otags: fails to install: post-installation script returned error exit status 3
Hi, it's a pattern matching failure in tag_module_type, which means the file stdLabels.mli contains some module type that I didn't know about when I wrote tag_module_type. As a quick solution you can add a catch-all line | _ -> () to tag_module_type. This will hopefully fix the bug, but you won't get tags for the offending module type. If somebody could send me that stdLabels.mli (or include it here in the bug report) I will try to take a look. (When I wrote otags, I explicitly avoided catch-all clauses. This way I could check at compile time that I covered all existing syntax. You are paying the price for this now - sorry for that. You may add catch-all clauses to all functions in tags.ml to avoid crashes like this one for new syntax constructs.) Bye, Hendrik
Bug#768619: proofgeneral: FTBFS in jessie: build-dependency not installable: emacs23-nox
Hi, thanks, this is certainly one way to solve the bug. I would however have preferred to fix the problem in sbuild, as Felix Gruber pointed out. The build-dependencies of the package are IMHO not wrong, the package should also build with emacs23. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#751049: proofgeneral: FTBFS - pdfetex (file cm-super-t1.enc): cannot open encoding file for reading
Hi, please apologize the delay. I am investigating now. @Michael Tautschnig: Can I simply close this bug if the package now builds fine in cowbuilder? Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738392: proofgeneral: FTBFS: Latex errors
Hi, Hideki Yamane writes: > Also, I'll upload it to 10-delayed queue. If you don't want it, please > tell me. thanks a lot for helping me out here! Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#718748: oasis: FTBFS on armhf
forwarded 718748 https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=1306&group_id=54&atid=291 tags 718748 confirmed upstream thanks Hi, Hector Oron writes: Your package fails to build from source on Debian autobuilder network. Thanks for recording this issue with the BTS. The software itself builds fine, the problem is that the tests expect wrong results on bytecode architectures. I discussed this with upstream already in June, Sylvain works on it, but I haven't got a patch yet. Note that there is no real difference between oasis 0.3.0-1 and 0.3.0-2, it's only that the tests are disabled in 0.3.0-1. Please tell me if this build failure is a real problem for you, because I'll then prepare 0.3.0-3 with tests disabled again. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711524: atdgen: fails to build with new ocaml-atd
Colin Watson writes: Package: atdgen Version: 1.2.2-1 Severity: serious User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu saucy I tried to rebuild atdgen against the new ocaml-atd, and it failed as follows: The current upstream version of atdgen is 1.2.5, it build-depends on biniou and yojson, whose packages are both not up-to-date in Debian, too. Why do you expect that an old atdgen compiles with an up-to-date version of ocaml-atd? I don't think this is a bug at all. I am working on updating all these atd related packages from Martin Jambon. The problem is that all the still missing ones build-depend on biniou and biniou has one test that fails on i386 (and works on amd64). So far, Martin only confirmed that this test is supposed to work, but I haven't got a fix yet. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#694285: proofgeneral-doc: missing Breaks+Replaces: proofgeneral (<< 4)
Hi, thanks for detecting this problem. Package: proofgeneral-doc Breaks: proofgeneral (<< 4) Replaces: proofgeneral (<< 4) It makes certainly sense to add these dependencies, although, without having read the documentation, I would only add the Breaks, because the new proofgeneral-doc does not replace the old proofgeneral. I am on a conference next week and I am not a DD, so it might probably take two weeks until this is fixed. If anybody wants to do a NMU for this, I would certainly be grateful. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#679917: korganizer: cannot add ics calendar files
Those two errors come from Phonon and more precisely phonon-backend-vlc. Do you have audio working? Yes, audio is working fine. Maybe it would help if you shared the non-working ics file. Have you tried with any ics file? For me korganizer fails for _every_ ics file. For instance also for the one appended below. Bye, Hendrik a.ics Description: Binary data
Bug#679917: korganizer: cannot add ics calendar files
Package: korganizer Version: 4:4.4.11.1+l10n-3 Severity: grave Dear Maintainer, after upgrading from Squeeze to Wheezy I cannot use my old calendar files any more. When I start korganizer, the list of calendars is empty. When I then select an ics file via File -> Import -> Import Calendar and tick "Add as new calendar" I get the error Unable to create calendar '/home/tews/SharedConfig/calendar.ics'. and the terminal contains [0x8f95d90] main services discovery error: no suitable services discovery module [0x8e507c0] main input error: ES_OUT_RESET_PCR called When I add the "+" at the calendar list and put "calendar" or "calendar.ics" as Name, I get "Unable to create calendar" and when I acknowledge the error, korganizer dies with a segmentation fault. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 3.2.0-2-686-pae (SMP w/2 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 korganizer depends on: ii kde-runtime 4:4.8.4-1 ii kdepim-runtime4:4.4.11.1-4 ii libakonadi-contact4 4:4.8.4-1 ii libc6 2.13-33 ii libkabc4 4:4.8.4-1 ii libkcal4 4:4.8.4-1 ii libkcmutils4 4:4.8.3-2 ii libkde3support4 4:4.8.3-2 ii libkdecore5 4:4.8.3-2 ii libkdepim44:4.4.11.1+l10n-3 ii libkdeui5 4:4.8.3-2 ii libkholidays4 4:4.8.4-1 ii libkio5 4:4.8.3-2 ii libkmime4 4:4.8.4-1 ii libknewstuff2-4 4:4.8.3-2 ii libkontactinterface4 4:4.8.4-1 ii libkparts44:4.8.3-2 ii libkpimidentities44:4.8.4-1 ii libkpimutils4 4:4.8.4-1 ii libkprintutils4 4:4.8.3-2 ii libkresources44:4.8.4-1 ii libphonon44:4.6.0.0-2 ii libqt4-dbus 4:4.8.2-1 ii libqt4-qt3support 4:4.8.2-1 ii libqt4-xml4:4.8.2-1 ii libqtcore44:4.8.2-1 ii libqtgui4 4:4.8.2-1 ii libstdc++64.7.0-8 ii perl 5.14.2-12 ii phonon4:4.6.0.0-2 ii zlib1g1:1.2.7.dfsg-13 korganizer recommends no packages. Versions of packages korganizer suggests: pn kdepim-groupware pn kdepim-kresources -- no debconf information Bye, Hendrik Tews -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670733: Some remarks
Romain Beauxis writes: I agree that the configure test is naive, but it relies on reasonable and documented behaviours and variables. OK. What is your source of documentation for the contents of $USER? Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy
order would be right anyway if the coq package uses debian-pkg-add-load-path-item -- which it ought to do anyway. This is wrong. Just read #676424. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#676424: emacsen-common: debian-startup puts items before /usr/local directories in load-path, violating policy
Package: emacsen-common
Version: 2.0.3
Severity: serious
Hi,
the line
(setq load-path (append add-on-package-paths old-load-path))
in debian-run-directories in debian-startup.el puts directories
which packages have been added to load-path with
debian-pkg-add-load-path-item at the head of load-path, _before_
the "/usr/local" entries in load-path. This makes the requirement
in the Debian Emacs policy
Emacs add-on packages may not modify load-path directly. They must
use (debian-pkg-add-load-path-item ). This function will
make sure that their additions end up in the right place -- before
the emacs system directories, but after the /usr/local/
directories.
an absurdity.
Even worse, packages that work fine may break when they switch to
use debian-pkg-add-load-path-item, because the order in the
load-path is wrong.
For an example, consider coq and proofgeneral and assume both
packages solely use debian-pkg-add-load-path-item (which is not
the case right now). coq installs 50coq.el, which adds
/usr/share/emacs23/site-lisp/coq to load-path. The reorder bug in
debian-startup actually causes a (non-fatal) problem during
proofgeneral installation, which I am not going to explain here.
When proofgeneral is installed it installs 50proofgeneral.el,
which adds site-lisp/proofgeneral/{generic,lib} to load-path.
When you now start emacs you see all these directories at the
head of load-path, before /usr/local items. When you now open a
coq file, say x.v, Proof General loads its Coq incarnation and
adds site-lisp/proofgeneral/coq to load-path. This will now be
added after /usr/local items and appear far after site-lisp/coq.
"(require 'coq)" therefore loads site-lisp/coq/coq.el instead of
site-lisp/proofgeneral/coq/coq.el and Proof General is completely
broken.
(Yes, Coq and Proof General should not use the same Emacs feature
name for different packages. I am trying to solve this upstream,
see http://lists.inf.ed.ac.uk/pipermail/proofgeneral-devel/2012/000241.html)
Kevin, you filed quite a lot reports about
debian-pkg-add-load-path-item. Would you add a note to all of
them, telling the maintainers that their package may break when
they switch to debian-pkg-add-load-path-item? It took me several
hours to track down this issue, maybe you can one of them save
the hassle.
Bye,
Hendrik Tews
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 3.2.0-2-686-pae (SMP w/4 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-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670733: ocaml-cry: FTBFS: Incorrectly thinks it's building as root
Mehdi Dogguy writes: On 13/05/12 23:37, Hendrik Tews wrote: > > ... the incorrect root test comes from file m4/base_checks.m4 > > deleting the line 'RUNNING_USER="$USER"' there and running > ./bootstrap then yields > > checking that calling user is not root... ok > > and the package builds fine (done with autoconf 2.69; maybe its > better to downgrade to 2.68 to keep the patch small). > Thanks for the investigation! Could you prepare patches for the affected I can commit fixes to the git repositories if I can downgrade to autoconf 2.68. However, environ(7) says: USER The name of the logged-in user (used by some BSD-derived pro‐ grams). Therefore, I would say pbuilder is wrong with leaving $USER=root. On the other hand, I cannot find any standard document specifying $USER on the web, http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html lists $USER, but does not say anything about its contents. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672669: ocaml-lame: FTBFS: Incorrectly thinks it's building as root
Hi, Daniel, are you sure it was ocaml-lame that FTBFS? Here it builds fine with user id 56789 inside pbuilder. My previously reported build failure comes from an incorrect pbuilder setup. The problem was that CCACHE_DIR (/var/cache/pbuilder/ccache outside and inside pbuilder) was not writable by BUILDUSERNAME. When I add the necessary permissions, the package builds fine. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672669: ocaml-lame: FTBFS: Incorrectly thinks it's building as root
I cannot reproduce the "Incorrectly thinks it's building as root" problem. When I try the build fails with checking for suffix of object files... configure: error: in `/tmp/buildd/ocaml-lame-0.3.0': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details make: *** [debian/stamp-autotools] Error 1 Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#672666: Bug#6726XX: ocaml-xxx: FTBFS: Incorrectly thinks it's building as root
See #670733 for the source of the problem. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670733: ocaml-cry: FTBFS: Incorrectly thinks it's building as root
... the incorrect root test comes from file m4/base_checks.m4 deleting the line 'RUNNING_USER="$USER"' there and running ./bootstrap then yields checking that calling user is not root... ok and the package builds fine (done with autoconf 2.69; maybe its better to downgrade to 2.68 to keep the patch small). Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#670733: ocaml-cry: FTBFS: Incorrectly thinks it's building as root
Hi, I played a bit around to investigate the problem. What I see is: - inside pbuilder, after installing the build dependencies and after patching the sources, dh_clean runs as root [env says $SUDO_USER=tews and $USER=root; id says uid=0(root) gid=0(root)] - Later the configure script of the package runs not as root. At line 2871 in configure, where the root test is, id says uid=56789(pbuilder) gid=56789(pbuilder) groups=56789(pbuilder) however, env still says $SUDO_USER=tews and $USER=root. The configure script runs `whoami` only if $USER is empty. Therefore configure believes $USER=root and aborts. For me this looks like pbuilder is not setting the environment correctly when changing to the non-root user. Or the configure script is wrong in taken the contents of $USER. Gruss, Hendrik PS. To reproduce - pbuilder create - pbuilder login --save-after-login - in the pbuilder shell: useradd -m -u 56789 pbuilder - put "BUILDUSERNAME=pbuilder" into /etc/pbuilderrc - build package with git-buildpackage --git-builder=pdebuild -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#605014: proofgeneral-coq: PG for coq unusable because hilit19 is missing
Package: proofgeneral-coq Version: 3.7-4 Severity: grave Opening any .v file or starting coq-mode manually only gives the error File mode specification error: (file-error "Cannot open load file" "hilit19") and no proof-general functionality is available. The package is therefore completely unusable. Bye, Hendrik -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (x86_64) Kernel: Linux 2.6.32-5-amd64 (SMP w/2 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 proofgeneral-coq depends on: ii proofgeneral 3.7-4 generic interface for proof assist Versions of packages proofgeneral-coq recommends: ii coq 8.2.pl2+dfsg-1 proof assistant for higher-order l proofgeneral-coq suggests no packages. -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590210: fixed by isc-dhcp
The appearence of isc-dhcp in squeeze fixes this problem. Bye, Hendrik -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#590210: ntp: ntp breaks dhcp3-client deinstalls dhcp in testing
Package: ntp Version: 1:4.2.6.p2+dfsg-1 Severity: critical ntp_1%3a4.2.6.p2+dfsg-1_i386.deb has "breaks dhcp3-client" in squeeze while the new dhcp client is not yet available for squeeze. The default procedure of aptitude is to upgrade ntp and deinstall dhcp, which makes it impossible to connect to the internet afterwards. The system information below might not be entirely correct, because it was gathered after reinstalling dhcp3-client and downgrading ntp. Bye, Hendrik -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Kernel: Linux 2.6.32-5-686 (SMP w/2 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 ntp depends on: ii adduser 3.112 add and remove users and groups ii dpkg 1.15.7.2Debian package management system ii libc62.11.2-2Embedded GNU C Library: Shared lib ii libcap2 1:2.17-2support for getting/setting POSIX. ii libedit2 2.11-20080614-1 BSD editline and history libraries ii libopts251:5.10-1.1 automated option processing librar ii libssl0.9.8 0.9.8o-1SSL shared libraries ii lsb-base 3.2-23.1Linux Standard Base 3.2 init scrip ii netbase 4.42Basic TCP/IP networking system Versions of packages ntp recommends: ii perl 5.10.1-13 Larry Wall's Practical Extraction Versions of packages ntp suggests: pn ntp-doc(no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#408929: emacs21: crash on spam
Package: emacs21 Version: 21.4a+1-3 Severity: critical The spam email appended below causes emacs to crash with *** glibc detected *** free(): invalid next size (normal): 0x08706488 *** Fatal error (6). or even simply with Fatal error (11).Segmentation fault To reproduce: start emacs with emacs -q --no-site-file inside emacs, evaluate (setq load-path (nconc load-path (list "/usr/share/emacs21/site-lisp/vm"))) (autoload 'vm-mode "vm" "Run VM major mode on a buffer" t) then visit the file spam-bug do M-x vm-mode --everything fine up to here-- hit space -- System Information: Debian Release: 4.0 APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.18-3-k7 Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Versions of packages emacs21 depends on: ii emacs21-bin-common21.4a+1-3 The GNU Emacs editor's shared, arc ii libc6 2.3.6.ds1-8GNU C Library: Shared libraries ii libice6 1:1.0.1-2 X11 Inter-Client Exchange library ii libjpeg62 6b-13 The Independent JPEG Group's JPEG ii libncurses5 5.5-5 Shared libraries for terminal hand ii libpng12-01.2.15~beta5-1 PNG library - runtime ii libsm61:1.0.1-3 X11 Session Management library ii libtiff4 3.8.2-7Tag Image File Format (TIFF) libra ii libungif4g4.1.4-4shared library for GIF images ii libx11-6 2:1.0.3-4 X11 client-side library ii libxext6 1:1.0.1-2 X11 miscellaneous extension librar ii libxmu6 1:1.0.2-2 X11 miscellaneous utility library ii libxpm4 1:3.5.5-2 X11 pixmap library ii libxt61:1.0.2-2 X11 toolkit intrinsics library ii xaw3dg1.5+E-14 Xaw3d widget set ii zlib1g1:1.2.3-13 compression library - runtime emacs21 recommends no packages. Package: vm Version: 7.19-11 Versions of packages vm depends on: ii emacs21 21.4a+1-3 The GNU Emacs editor ii ucf 2.0018.1 Update Configuration File: preserv Versions of packages vm recommends: ii make 3.81-2 The GNU version of the "make" util -- no debconf information Here is the problematic spam: spam-bug Description: Binary data
