Bug#994789: rsync: Errors out with "deflate on token returned 0 (8864 bytes left)" when tranferring 3GB file
Hi Samuel, On Fri, 24 Sep 2021, Samuel Henrique wrote: Hello Faheem, thank you for the bug report :) I can see you're transferring to another host, this issue could be related to the target's rsync version/distribution. Can you share some details around what you have running on the other end? I can see that the sender has 3.2.3. It would also be a good idea to try to reproduce the issue with the parameters "-vvv", which will provide a verbose output. The root cause might be showing up there. I think this is a good starting point in the investigation. I did some investigation, but forgot to update the bug report. Based on priors, I was not expecting to get a reply. The problem is that I'm connecting to a remote VPS, which is an OpenVZ VM, and currently runs a badly outdated version of Debian, Debian 8 (jessie). It was running the default version of rsync for that release (3.1.1-3+deb8u2), which appears to be too old to do the handshake that rsync expects for compression. I'm going by what is in the manual, i.e. Rsync supports multiple compression methods and will choose one for you unless you force the choice using the --compress-choice (--zc) option. Run rsync --version to see the default compress list compiled into your version. When both sides of the transfer are at least 3.2.0, rsync chooses the first algorithm in the client's list of choices that is also in the server's list of choices. If no common compress choice is found, rsync exits with an error. If the remote rsync is too old to support checksum negotiation, its list is assumed to be "zlib". However, as an error message, this really sucked. Unless the rsync maintainers consider compatibility with older rsync versions not worth bothering with, it would be good to have a more intelligible error message. But I don't know if it is worth trying to follow up with the rsync project. I managed to backport the current version of rsync to Debian 8 on the OpenVZ VPS, and the error went away. Other workarounds I tried (like --compress-choice) all failed, because the rsync version seemed to be too old. The output of `apt-cache policy rsync` on that server now looks like rsync: Installed: 3.2.3-7 Candidate: 3.1.1-3+deb8u2 Package pin: (not found) Version table: 3.2.3-7 1001 50 http://ftp.us.debian.org/debian/ testing/main amd64 Packages 50 http://ftp.us.debian.org/debian/ unstable/main amd64 Packages *** 3.2.3-7 1001 100 /var/lib/dpkg/status 3.1.1-3+deb8u2 1001 500 http://security.debian.org/ jessie/updates/main amd64 Packages 3.1.1-3+deb8u1 1001 500 http://ftp.us.debian.org/debian/ jessie/main amd64 Packages If you don't think it's worth following up upstream regarding the quality of their error messages, you can close this bug report. Regards, Faheem Mitha Thank you, -- Samuel Henrique
Bug#994789: rsync: Errors out with "deflate on token returned 0 (8864 bytes left)" when tranferring 3GB file
Package: rsync Version: 3.2.3-7 Severity: normal Dear Maintainer, After upgrading to Debian 11 (bullseye), I started seeing a problem when running the following backup command rsync -abvz --partial -e ssh /var/spool/mail/faheem faheem@servername:Mail/faheem With this command `rsync` returns sending incremental file list faheem deflate on token returned 0 (8864 bytes left) rsync error: error in rsync protocol data stream (code 12) at token.c(476) [sender=3.2.3] The file `/var/spool/mail/faheem` is approximately 3GB. ls -lah /var/spool/mail/faheem -rw-rw 1 faheem mail 3.1G Sep 21 02:15 /var/spool/mail/faheem I can confirm that the file is not correctly updated. I didn't see this issue with the `rsync` version in the previous release, Debian 10 (buster), namely `3.1.3-6`. I also don't see this issue with smaller files. Any pointers or suggestions for debugging appreciated. Regards, Faheem Mitha -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-debug'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-8-amd64 (SMP w/6 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages rsync depends on: ii init-system-helpers 1.60 ii libacl1 2.2.53-10 ii libc62.31-13 ii liblz4-1 1.9.3-2 ii libpopt0 1.18-2 ii libssl1.11.1.1k-1+deb11u1 ii libxxhash0 0.8.0-2 ii libzstd1 1.4.8+dfsg-2.1 ii lsb-base 11.1.0 ii zlib1g 1:1.2.11.dfsg-2 rsync recommends no packages. Versions of packages rsync suggests: ii openssh-client 1:8.4p1-5 ii openssh-server 1:8.4p1-5 ii python3 3.9.2-3 -- debconf-show failed
Bug#954407: Update?
Hi Daniel Baumann, Do you have an update on this? I just installed this using pip. It's a Python program, so probably not too hard to package unless it has a lot of dependencies. Regards, Faheem Mitha
Bug#967025: python3-yaml: Build dependency on libyaml needs to be versioned (for 5.3.1-2)
Package: python3-yaml Version: 5.3.1-2 Severity: normal Dear Maintainer, I'm on Debian 10/buster. I tried building pyyaml/python3-yaml on buster, and it failed. I then upgraded libyaml to the version on unstable, namely 0.2.2-1, and it built correctly, and runs on my current (small) script, though I have hardly tested it. I didn't change anything else, so I conclude that the build dependency on libyaml needs to be versioned to >=0.2.2-1. A patch for this should be trivial, but I can submit one if you want. I could even submit a pull request to https://salsa.debian.org/python-team/modules/pyyaml, though I don't currently have an account on salsa, and do not know anything about the service. Let me know. Thanks. Regards, Faheem Mitha -- System Information: Debian Release: 10.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-debug'), (500, 'stable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-9-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled Versions of packages python3-yaml depends on: ii libc62.28-10 ii libyaml-0-2 0.2.2-1 ii python3 3.7.3-1 python3-yaml recommends no packages. python3-yaml suggests no packages. -- no debconf information
Bug#946567: Mention of luahbtex in texlive-luatex description
There's also a mention of luahbtex in https://packages.debian.org/de/sid/texlive-luatex luahbtex -- LuaTeX with HarfBuzz library for glyph shaping But I have version 2019.20191208-4 installed, and it doesn't contain `luahbtex`. Regards, Faheem Mitha
Bug#908902: Close?
This one should probably be closed, since the bug submitter said it was user error. Regards, Faheem Mitha
Bug#930488: mercurial: Include tests/run-tests.py from Mercurial sources in Debian package
Package: mercurial Version: 5.0-1 Severity: wishlist Dear Maintainer, The Evolve Mercurial extension has a third-party Debian package. It's not packaged or distributed by Debian. It's part of upstream sources. The development version of Evolve is at https://bitbucket.org/octobus/evolve-devel. The Evolve tests are run using Mercurial's test runner, namely the file `tests/run-tests.py` in the Mercurial sources. And the tests are run by default as part of the Evolve Debian build. The current situation is that if a user wants to run the Evolve tests, he/she has to download the Mercurial sources, and point the Debian build to those sources to get access to the test runner. Which is rather manual. Otherwise, the tests will fail to run. So a better solution would be to include `tests/run-tests.py` as part of the Debian package. Since the Evolve Debian package has a runtime dependency on the Debian Mercurial package, the location of tests/run-tests.py in the Debian Mercurial package could then be hard-wired into Evolve's `debian/rules`. It could probably be installed in the mercurial-common package, at `/usr/share/mercurial/tests/run-tests.py`. Regards, Faheem Mitha -- System Information: Debian Release: 10.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled Versions of packages mercurial depends on: ii libc6 2.28-10 ii mercurial-common 5.0-1 ii python2.7.16-1 ii ucf 3.0038+nmu1 Versions of packages mercurial recommends: ii openssh-client 1:7.9p1-10 Versions of packages mercurial suggests: ii kdiff3 1.7.90-3 pn qct -- no debconf information
Bug#930257: luarocks: Request for update
Package: luarocks Version: 2.4.2+dfsg-1 Severity: wishlist Dear Maintainer, The current packaged version is 2.4.2, but the current release is 3.1.3. Could I get an update on the status of this package? I could assist with an update on the packaging, if anyone out there is interested in sponsoring it. Regards, Faheem Mitha -- System Information: Debian Release: 10.0 APT prefers testing-debug APT policy: (500, 'testing-debug'), (500, 'testing'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-5-amd64 (SMP w/6 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE 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) LSM: AppArmor: enabled Versions of packages luarocks depends on: ii liblua5.1-0-dev [liblua5.1-dev] 5.1.5-8.1+b2 ii liblua5.2-dev5.2.4-1.1+b2 ii liblua5.3-dev5.3.3-1.1 ii lua-any 25 ii lua5.1 5.1.5-8.1+b2 ii lua5.2 5.2.4-1.1+b2 ii lua5.3 5.3.3-1.1 ii unzip6.0-23 ii wget 1.20.1-1.1 ii zip 3.0-11+b1 Versions of packages luarocks recommends: ii lua-sec 0.7-1 luarocks suggests no packages. -- no debconf information
Bug#926326: elpa-elpy: configuration issues
Hi Nicholas, On Sun, 14 Apr 2019, Nicholas D Steeves wrote: Dear Faheem, Thank you for filing an excellent bug report that includes all relevant information. Reply follows in-line, but please take care to reply to the appropriate sub-bugs that will be momentarily created: https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=elpa-elpy Thank you for the kind words. I've noted the bug split. I'm not sure exactly what you want me to do regarding replying to the bugs, so I've CCed the original bug, as well as the three new sub-bugs that you created. I could have split up my reply across the three different bugs, but that would be quite a lot of work, and might be confusing. I suggest followups for the relevant points from here on should just go to the relevant bugs. elpa-elpy: README.Debian misleads users into enabling nonexistent Python 2 support * Concerning points: #1, #5, #6, #7 elpa-elpy: Please provide a QuickStart page * Concerning point #4 elpa-elpy: Please enable Python 2 support * Concerning points: #1, #5, #6, #7 It would be more accurate to write README.Debian misleads users into assuming nonexistent Python 2 support Since it does not say anything to the contrary. The only really important thing is to make it clear to users that Buster's elpy does not support usage with Python 2, as mentioned later. Bug#926326: elpa-elpy: configuration issues is now * Concerning points: #2, #3 I've split the aggregate into discrete bugs, because some of these issues will not receive an unblock for buster. On Wed, Apr 03, 2019 at 08:39:35PM +0530, Faheem Mitha wrote: Package: elpa-elpy Version: 1.28.0-1 Severity: normal Dear Maintainer, I've been struggling with getting elpy to work on Debian stable. Thank you for letting me know, and sorry it wasn't easy. Let's fix this! :-) For right now, some comments and suggestions about README.Debian. 1) There's a typo in your code: (setq python-shell-interpreter "python" python-shell-interpreter-args "-i") elpy-rpc-python-command "python") It should be: (setq python-shell-interpreter "python" python-shell-interpreter-args "-i" elpy-rpc-python-command "python") Good catch, thanks! 2) You should mention that elpy isn't loaded by default, and indicate how to load it. Historically, Debian packages autoload modes once installed, and personally I find that more convenient. But I understand if you don't load it to preserce compatibility with upstream EPLA. Yes, for simple packages this is absolutely the way to go. I chose to leave (elpa-enable) up to the user because on my system it doubles Emacs startup time, because elpa-enable is unconditionally executed. Also, a user may choose to enable Elpy using an alternative (conditional) method. Fine, just document it in the README.Debian. And (preferably) tell users what to add to enable it. If they don't want to use it, they don't have to. But at least then they won't have to go looking for a method that will work. The elpy manual mentions in https://elpy.readthedocs.io/en/latest/introduction.html that elpy should be enabled with (package-initialize) (elpy-enable) Just the second line works for me here. I'm not sure what the first part does. Some sort of global enable, apparently. For info about package-initialize, see the Emacs manual §48.2 "Package Installation". Also, your init file may have already had the following automatically added to the top of it: ;; Added by Package.el. This must come before configurations of ;; installed packages. Don't delete this line. If you don't want it, ;; just comment it out by adding a semicolon to the start of the line. ;; You may delete these explanatory comments. (package-initialize) Yes, it does indeed have exactly that on top. 3) I suggest mentioning the upstream manual in README.Debian. Namely, https://elpy.readthedocs.io/en/latest/ Unfortunately this will not provide accurate documentation for users of Debian buster in the coming months, because that URL will document a newer version of Elpy, and buster is shipping with 1.28.0. Also, a link is useless for users who are offline. Would you please comment on your experience with "info elpy" or "man elpy"? P.S. The sphinx-generated info page is much nicer than the the man page it generates, and the following is nicer still: emacs --eval '(info "elpy")' # or M-x info, C-s elpy It didn't occur to me that either of those exists. Thank you for the pointers. I think that's also something that could usefully be mentioned in README.Debian. Most Python packages don't have either of those, I think. So it will probably not occur to people to look for them. 4) And if I were writing the README.Debian, I'd also mention that C-c C-c runs the buffer, and that you need C-c C-z to o
Bug#927890: xorg: X crashed with log message client 1814[0:0] has disconnected
Package: xorg Version: 1:7.7+19 Severity: normal Dear Maintainer, My computer was idling, and when I came back to it, when I tried to log in, I just got a black screen. Clearly X had crashed. I was not able to get X to respond, and rebooted. I'm currently on Buster, which is currently still in testing. It's possible some recent package upgrade caused this instability, but that's purely speculation. And I have no plausible candidates for such packages. This appears to correspond to the following lines in `journalctl. These entries all appeared around the time of the crash, and I rebooted shortly afterwards. Apr 24 18:12:04 orwell acpid[1060]: client 1814[0:0] has disconnected Apr 24 18:12:24 orwell acpid[1060]: client connected from 1814[0:0] Apr 24 18:12:24 orwell acpid[1060]: 1 client rule loaded Apr 24 18:12:43 orwell acpid[1060]: client 1814[0:0] has disconnected Apr 24 18:13:34 orwell acpid[1060]: client connected from 1814[0:0] Apr 24 18:13:34 orwell acpid[1060]: 1 client rule loaded Apr 24 18:13:45 orwell acpid[1060]: client 1814[0:0] has disconnected Apr 24 18:13:51 orwell acpid[1060]: client connected from 1814[0:0] Apr 24 18:13:51 orwell acpid[1060]: 1 client rule loaded Apr 24 18:13:56 orwell acpid[1060]: client 1814[0:0] has disconnected Apr 24 18:18:12 orwell acpid[1060]: client connected from 1814[0:0] Apr 24 18:18:12 orwell acpid[1060]: 1 client rule loaded Apr 24 18:18:18 orwell acpid[1060]: client 1814[0:0] has disconnected Apr 24 18:18:29 orwell systemd-logind[1075]: System is rebooting. Also, lines like the following appear in the current xorg.0.log, and also appear in the information collected by the Debian template, below. They may be related. [ 112.253] (--) NVIDIA(GPU-0): DFP-0: disconnected [ 112.253] (--) NVIDIA(GPU-0): DFP-0: Internal TMDS [ 112.253] (--) NVIDIA(GPU-0): DFP-0: 330.0 MHz maximum pixel clock I could not find anything relating to the crash in earlier X logs. Regards, Faheem Mitha -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 31 2013 /etc/X11/X -> /usr/bin/Xorg -rwxr-xr-x 1 root root 274 Oct 25 23:45 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.0.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.0.0 by glx-diversions diversion of /usr/lib/libGLESv2.so.2 to /usr/lib/mesa-diverted/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so by glx-diversions sdiversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLX_indirect.so.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv2.so.2.1.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv2.so.2.1.0 by glx-diversions diversion of /usr/lib/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGLESv1_CM.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGLESv1_CM.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGLESv1_CM.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGLESv1_CM.so by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGLESv1_CM.so.1.1.0 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by
Bug#926822: gimp: clean target is missing some files
Package: gimp Version: 2.10.8-2 Severity: normal Dear Maintainer, When trying to backport 2.10.8 from unstable to stable, I keep seeing dpkg-source: info: local changes detected, the modified files are: gimp-2.10.8/app/tests/gimpdir/pluginrc gimp-2.10.8/app/tests/gimpdir/profilerc gimp-2.10.8/app/tests/gimpdir/themerc dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/gimp_2.10.8-2.diff.eL_rzG dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -b gimp-2.10.8 gave error exit status 2 debuild: fatal error at line 1116: dpkg-buildpackage -rfakeroot -us -uc failed I'm using `debuild -uc -us` to build. Either the Gimp is generating different files when building on stable, or your cleanup is missing some files. I'm not sure where your clean target is, or I would send a patch. More details available if required, but I'm not sure what would be relevant right now. Since 2.10.8-2 isn't actually installed on my system when this bug template was generated, the Gimp package information refers to the Gimp in staxble. Regards, Faheem Mitha -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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) Versions of packages gimp depends on: ii gimp-data2.8.18-1+deb9u1 ii libaa1 1.4p5-44+b1 ii libatk1.0-0 2.22.0-1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libexif120.6.21-2+b2 ii libexpat12.2.0-2+deb9u1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libgegl-0.3-00.3.8-4 ii libgimp2.0 2.8.18-1+deb9u1 ii libglib2.0-0 2.60.0-1 ii libgs9 9.26a~dfsg-0+deb9u1 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.1-2 ii libjson-glib-1.0-0 1.2.6-1 ii liblcms2-2 2.9-3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpng16-16 1.6.28-1 ii libpoppler-glib8 0.48.0-2+deb9u2 ii librsvg2-2 2.40.16-1+b1 ii libsm6 2:1.2.2-1+b3 ii libtiff5 4.0.8-2+deb9u4 ii libwmf0.2-7 0.2.8.4-10.6 ii libx11-6 2:1.6.4-3+deb9u1 ii libxcursor1 1:1.1.14-1+deb9u2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii python 2.7.13-2 ii python-gtk2 2.24.0-5.1 ii python2.72.7.13-2+deb9u3 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.26a~dfsg-0+deb9u1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-0.1 ii gvfs-backends 1.30.4-1 ii libasound21.1.3-5 -- debconf-show failed
Bug#926744: gimp: Error message when backporting Gimp 2.10.8-2 Debian package from unstable to stable
Package: gimp Version: 2.10.8-2 Severity: normal Dear Maintainer, Reported at https://gitlab.gnome.org/GNOME/gimp/issues/3216 but I got answer which suggests the Gimp devs consider this a Debian issue. So reporting it here. Summary, I tried to backport the Debian Gimp 2.10.8 packaging to stable, the build errors out with failed tests. I've done this with lots of packages. It normally works, but I realise Gimp is a complex piece of software with many dependencies. I'm attaching app/tests/test-suite.log. I haven't actually installed the 2.10.8 package, though I'm upgraded a bunch of dependencies. So the versions reported are a bit off. I'd appreciate any ideas about what these failed tests might mean. Regards, Faheem Mitha -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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) Versions of packages gimp depends on: ii gimp-data2.8.18-1+deb9u1 ii libaa1 1.4p5-44+b1 ii libatk1.0-0 2.22.0-1 ii libbabl-0.1-00.1.62-1 ii libbz2-1.0 1.0.6-8.1 ii libc62.24-11+deb9u4 ii libcairo21.14.8-1 ii libdbus-1-3 1.10.26-0+deb9u1 ii libdbus-glib-1-2 0.108-2 ii libexif120.6.21-2+b2 ii libexpat12.2.0-2+deb9u1 ii libfontconfig1 2.12.6-0.1 ii libfreetype6 2.6.3-3.2 ii libgdk-pixbuf2.0-0 2.36.5-2+deb9u2 ii libgegl-0.3-00.3.8-4 ii libgimp2.0 2.8.18-1+deb9u1 ii libglib2.0-0 2.60.0-1 ii libgs9 9.26a~dfsg-0+deb9u1 ii libgtk2.0-0 2.24.31-2 ii libgudev-1.0-0 230-3 ii libice6 2:1.0.9-2 ii libjpeg62-turbo 1:1.5.1-2 ii libjson-glib-1.0-0 1.2.6-1 ii liblcms2-2 2.9-3 ii libmng1 1.0.10+dfsg-3.1+b5 ii libpango-1.0-0 1.40.5-1 ii libpangocairo-1.0-0 1.40.5-1 ii libpangoft2-1.0-01.40.5-1 ii libpng16-16 1.6.28-1 ii libpoppler-glib8 0.48.0-2+deb9u2 ii librsvg2-2 2.40.16-1+b1 ii libsm6 2:1.2.2-1+b3 ii libtiff5 4.0.8-2+deb9u4 ii libwmf0.2-7 0.2.8.4-10.6 ii libx11-6 2:1.6.4-3+deb9u1 ii libxcursor1 1:1.1.14-1+deb9u2 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxmu6 2:1.1.2-2 ii libxpm4 1:3.5.12-1 ii libxt6 1:1.1.5-1 ii python 2.7.13-2 ii python-gtk2 2.24.0-5.1 ii python2.72.7.13-2+deb9u3 ii zlib1g 1:1.2.8.dfsg-5 Versions of packages gimp recommends: ii ghostscript 9.26a~dfsg-0+deb9u1 Versions of packages gimp suggests: pn gimp-data-extras ii gimp-help-en [gimp-help] 2.8.2-0.1 ii gvfs-backends 1.30.4-1 ii libasound21.1.3-5 -- no debconf information === GIMP 2.10.8: app/tests/test-suite.log === # TOTAL: 9 # PASS: 3 # SKIP: 0 # XFAIL: 0 # FAIL: 6 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: test-save-and-export == gimp_icons_sanity_check: Icon theme path has no 'hicolor' subdirectory: /usr/share/gimp/2.0/icons /gimp-save-and-export/new_file_has_no_files: Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) OK /gimp-save-and-export/opened_xcf_file_files: OK /gimp-save-and-export/imported_file_files: OK /gimp-save-and-export/saved_imported_file_files: OK /gimp-save-and-export/exported_file_files: Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) Error creating proxy: Error sending credentials: Error sending message: Operation not permitted (g-io-error-quark, 14) OK /gimp-save-and-export/clear_import_file_after_export: OK (/usr/local/src/gimp/gimp-2.10.8/app/tests/.libs/test
Bug#926326: elpa-elpy: configuration issues
Package: elpa-elpy Version: 1.28.0-1 Severity: normal Dear Maintainer, I've been struggling with getting elpy to work on Debian stable. For right now, some comments and suggestions about README.Debian. 1) There's a typo in your code: (setq python-shell-interpreter "python" python-shell-interpreter-args "-i") elpy-rpc-python-command "python") It should be: (setq python-shell-interpreter "python" python-shell-interpreter-args "-i" elpy-rpc-python-command "python") 2) You should mention that elpy isn't loaded by default, and indicate how to load it. Historically, Debian packages autoload modes once installed, and personally I find that more convenient. But I understand if you don't load it to preserce compatibility with upstream EPLA. The elpy manual mentions in https://elpy.readthedocs.io/en/latest/introduction.html that elpy should be enabled with (package-initialize) (elpy-enable) Just the second line works for me here. I'm not sure what the first part does. Some sort of global enable, apparently. 3) I suggest mentioning the upstream manual in README.Debian. Namely, https://elpy.readthedocs.io/en/latest/ 4) And if I were writing the README.Debian, I'd also mention that C-c C-c runs the buffer, and that you need C-c C-z to open up a Python interpreter buffer. This would help people to get going quickly, instead of flailing around trying to figure out what to do. These commands are both in https://elpy.readthedocs.io/en/latest/ide.html C-c C-y r (elpy-shell-send-region-or-buffer) [...] Also bound to C-c C-c. and C-c C-z (elpy-shell-switch-to-shell) There are a ton of commands in that manual, and it's really confusing. But you really only need a couple to get going. That manual really needs a quickstart page. Do you happen to know if it is possible to configure emacs to open a Python buffer in elpy mode by default and skip the C-c C-z? 5) I'm also running into the error message mentioned in https://github.com/jorgenschaefer/elpy/issues/1521 Should I report it here? Or just upstream? I added a comment to that thread. 6) Your bug report template should include the output of elpy-config. I've included mine at the bottom. I'm not sure what is going on with Elpy..: Not found (Python), 1.28.0 (Emacs Lisp) though. What's the difference between those two cases? 7) I suggest adding Python 2 packages to the package dependencies/recommends/suggests too. Like for Jedi. People are still using Python 2, and are likely to be doing so for awhile. Regards, Faheem Mitha -- System Information: Debian Release: 9.8 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-8-amd64 (SMP w/6 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) Versions of packages elpa-elpy depends on: ii elpa-company0.9.9-2 ii elpa-find-file-in-project 5.7.3-1 ii elpa-highlight-indentation 0.7.0-1 ii elpa-pyvenv 1.20-1 ii elpa-s 1.12.0-2 ii elpa-yasnippet 0.11.0-2 ii emacsen-common 2.0.8 ii flake8 3.2.1-1 ii python3 3.5.3-1 ii python3-flake8 3.2.1-1 Versions of packages elpa-elpy recommends: ii emacs 46.1 ii python3-jedi 0.10.0~git1+f05c071-1 Versions of packages elpa-elpy suggests: pn black ii python3-autopep8 1.4.3-1 ii python3-jupyter-console 5.0.0-1 ii python3-pip 9.0.1-2 pn yapf3 -- debconf-show failed Output of M-x elpy-config Elpy Configuration Virtualenv: None RPC Python: 2.7.13 (/usr/bin/python) Interactive Python: python (/usr/bin/python) Emacs.: 25.1.1 Elpy..: Not found (Python), 1.28.0 (Emacs Lisp) Jedi..: 0.12.0 Rope..: 0.10.3 Autopep8..: 0.9.1 Yapf..: Not found Black.: Not found Syntax checker: flake8 (/usr/bin/flake8) You have not activated a virtual env. While Elpy supports this, it is often a good idea to work inside a virtual env. You can use M-x pyvenv-activate or M-x pyvenv-workon to activate a virtual env. The directory ~/.local/bin/ is not in your PATH. As there is no active virtualenv, installing Python packages locally will place executables in that directory, so Emacs won't find them. If you are missing some commands, do add this directory to your PATH -- and then do `elpy-rpc-restart'. The Python interpreter could not find the elpy module. Make s
Bug#804438: Related bug report
Related: https://bugs.debian.org/870350
Bug#870350: systemd: "systemctl disable --now" doesn't stop either cron or fetchmail
Package: systemd Version: 232-25+deb9u1 Severity: normal Dear Maintainer, According to the documentation, systemctl disable service --now stops the service. For example, `man systemctl` says: --now When used with enable, the units will also be started. When used with disable or mask, the units will also be stopped. The start or stop operation is only carried out when the respective enable or disable operation has been successful. But here it doesn't, at least for cron and fetchmail. See output below. This is similar to https://bugs.debian.org/804438 and may be related or a dupe. Regards, Faheem Mitha root@orwell:/home/faheem# systemctl disable cron --now Synchronizing state of cron.service with SysV service script with /lib/systemd/systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable cron insserv: warning: current start runlevel(s) (empty) of script `cron' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (2 3 4 5) of script `cron' overrides LSB defaults (empty). root@orwell:/home/faheem# systemctl status cron ● cron.service - Regular background program processing daemon Loaded: loaded (/lib/systemd/system/cron.service; disabled; vendor preset: enabled) Active: active (running) since Mon 2017-07-31 12:25:36 IST; 1 day 3h ago Docs: man:cron(8) Main PID: 10356 (cron) CPU: 3ms CGroup: /system.slice/cron.service ├─10356 /usr/sbin/cron -f ├─23104 /usr/sbin/CRON -f ├─23105 /usr/sbin/CRON -f [...] ### root@orwell:/home/faheem# systemctl disable fetchmail --now fetchmail.service is not a native service, redirecting to systemd-sysv-install. Executing: /lib/systemd/systemd-sysv-install disable fetchmail insserv: warning: current stop runlevel(s) (empty) of script `fetchmail' overrides LSB defaults (0 1 6). insserv: warning: current start runlevel(s) (empty) of script `fetchmail' overrides LSB defaults (2 3 4 5). insserv: warning: current stop runlevel(s) (2 3 4 5) of script `fetchmail' overrides LSB defaults (0 1 6). root@orwell:/home/faheem# systemctl status fetchmail ● fetchmail.service - LSB: init-Script for system wide fetchmail daemon Loaded: loaded (/etc/init.d/fetchmail; generated; vendor preset: enabled) Active: active (running) since Mon 2017-07-31 12:23:20 IST; 1 day 3h ago Docs: man:systemd-sysv-generator(8) CPU: 18ms CGroup: /system.slice/fetchmail.service └─9777 /usr/bin/fetchmail -f /etc/fetchmailrc --pidfile /var/run/fetchmail/fetchmail.pid -d 300 --syslog [...] -- Package-specific info: -- System Information: Debian Release: 9.1 APT prefers stable APT policy: (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.9.0-3-amd64 (SMP w/6 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) Versions of packages systemd depends on: ii adduser 3.115 ii libacl1 2.2.52-3+b1 ii libapparmor12.11.0-3 ii libaudit1 1:2.6.7-2 ii libblkid1 2.29.2-1 ii libc6 2.24-11+deb9u1 ii libcap2 1:2.25-1 ii libcryptsetup4 2:1.7.3-4 ii libgcrypt20 1.7.6-2+deb9u1 ii libgpg-error0 1.26-2 ii libidn111.33-1 ii libip4tc0 1.6.0+snapshot20161117-6 ii libkmod223-2 ii liblz4-10.0~r131-2+b1 ii liblzma55.2.2-1.2+b1 ii libmount1 2.29.2-1 ii libpam0g1.1.8-3.6 ii libseccomp2 2.3.1-2.1 ii libselinux1 2.6-3+b1 ii libsystemd0 232-25+deb9u1 ii mount 2.29.2-1 ii procps 2:3.3.12-3 ii util-linux 2.29.2-1 Versions of packages systemd recommends: ii dbus1.10.18-1 ii libpam-systemd 232-25+deb9u1 Versions of packages systemd suggests: ii policykit-10.105-18 pn systemd-container pn systemd-ui Versions of packages systemd is related to: pn dracut ii initramfs-tools 0.130 ii udev 232-25+deb9u1 -- debconf-show failed
Bug#592834: me too (on a libvirt VM generated by virt-manager)
I'm seeing this in a virtual machine created by virt-manager. LVM on top of RAID 1. I'm not sure what debugging information would be useful here, but please do ask if you want any. Regards, Faheem Mitha
Bug#867206: grub-common: Setting GRUB_DISABLE_LINUX_UUID=true in /etc/default/grub does not work as expected
Package: grub-common Version: 2.02~beta3-5 Severity: normal Dear Maintainer, See https://unix.stackexchange.com/q/375155/4671 I reproduce the content of that question below. Please also see the comments, where a couple of other U users confirm that they can reproduce the bug. I haven't attempted to debug this problem, however. ** Background: I was motivated to change `/boot/grub/grub.cfg` to stop using UUIDs because the UUID of my root VG changed, and my machine refused to boot, saying that the UUID didn't exist. Which was correct. It didn't any longer. See https://unix.stackexchange.com/q/375051/4671 for how that happened. I'm using Debian stretch (9.0), the current stable. My arch is AMD64. My root and boot partitions are LVM volume groups on top of an MD RAID 1 device. According to my understanding of the documentation, uncommenting GRUB_DISABLE_LINUX_UUID=true in `/etc/default/grub` should stop GRUB2 from using UUIDs in `/boot/grub/grub.cfg`. However, it continues to use UUIDs even after I have made that change. To be clear, the UUIDS it is using are the LVM UUID for the root volume group (/dev/debian), and the root logical volume (/dev/debian/root). An additional comment: There is also a file /usr/share/grub/default/grub, which has identical contents (same md5sum) to /etc/default/grub. I'm not sure what the point of that file is. -- Package-specific info: *** BEGIN /proc/mounts /dev/mapper/debian-root / ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/chroots/xenial-amd64/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-wheezy32 /mnt/wheezy32chroot ext4 rw,relatime,data=ordered 0 0 /dev/mapper/data-local_src /usr/local/src ext3 rw,relatime,data=ordered 0 0 /dev/mapper/data-videobuild /mnt/videobuild ext4 rw,nosuid,nodev,noexec,relatime,data=ordered 0 0 /dev/mapper/data-wheezy /mnt/wheezychroot ext4 rw,relatime,data=ordered 0 0 /dev/mapper/data-jessie /mnt/jessiechroot ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-postgres /var/lib/postgresql ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-data /data ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-boot /boot ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-windows /home/faheem/VirtualBox\040VMs/IE11\040-\040Win7 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-vboxshare /home/faheem/win7 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-windows10 /home/faheem/VirtualBox\040VMs/IE11\040-\040Win10 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-video /home/faheem/video ext3 rw,relatime,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-057b9bbc-4320-4771-a5d7-0b13308f2a04 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /var/lib/schroot/mount/jessiechroot-057b9bbc-4320-4771-a5d7-0b13308f2a04/home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/mount/jessiechroot-057b9bbc-4320-4771-a5d7-0b13308f2a04/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-0ccf15f2-f92c-4c8a-921a-5a4aaaef08fd ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /var/lib/schroot/mount/jessiechroot-0ccf15f2-f92c-4c8a-921a-5a4aaaef08fd/home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/mount/jessiechroot-0ccf15f2-f92c-4c8a-921a-5a4aaaef08fd/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-20696854-176f-4a5f-bc00-0a64ce738756 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /var/lib/schroot/mount/jessiechroot-20696854-176f-4a5f-bc00-0a64ce738756/home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/mount/jessiechroot-20696854-176f-4a5f-bc00-0a64ce738756/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-22d7a8b7-2260-4307-a4bb-01867c52b9f4 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /var/lib/schroot/mount/jessiechroot-22d7a8b7-2260-4307-a4bb-01867c52b9f4/home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/mount/jessiechroot-22d7a8b7-2260-4307-a4bb-01867c52b9f4/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-30587a46-fe24-4492-9340-a699adcbf1e5 ext4 rw,relatime,data=ordered 0 0 /dev/mapper/debian-home /var/lib/schroot/mount/jessiechroot-30587a46-fe24-4492-9340-a699adcbf1e5/home ext3 rw,relatime,data=ordered 0 0 /dev/mapper/debian-root /var/lib/schroot/mount/jessiechroot-30587a46-fe24-4492-9340-a699adcbf1e5/tmp ext4 rw,relatime,errors=remount-ro,data=ordered 0 0 /dev/mapper/data-jessie /var/lib/schroot/mount/jessiechroot-441d2562-b89c-47c9-b0ad-c10aeba9c762 ext4
Bug#822209: udiskie: Mention something about policykit, possibly in README.Debian
Hi Gianfranco, Thanks for the commit. Regards, Faheem Mitha On Tue, 10 May 2016, Gianfranco Costamagna wrote: control: tags -1 pending Hi, I committed and uploaded this new file a few seconds ago. I don't think the end user should have privileges to mount/unmount disks, so I gave up in making a polkit file for everybody. I thought about configuring it, but I don't see how I can do that. Thanks for now for the README.Debian file, and let me know if you have another solution, I'll happily review it again! (and sorry for the long wait) Gianfranco Il Martedì 26 Aprile 2016 14:09, Faheem Mitha <fah...@faheem.info> ha scritto: On Fri, 22 Apr 2016, Gianfranco Costamagna wrote: Hi, can you please provide a patch for this? I can also install a policykit file if needed, just please send a patch thanks G. Hi Gianfranco, This is the same patch as I posted earlier in https://github.com/coldfix/udiskie/issues/111 Consider creating a README.Debian with this content. Please feel free to make modifications as you think appropriate. Or I can make modifications if you want. Regards, Faheem Note that by default not all udiskie actions may be allowed. You may see an error like: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation That error means you need to give udiskie addition permissions to perform whatever actions are necessary. These permissions are governed by policykit (package `policykit-1` in Debian), Here is an example. If you run `udiskie-mount` and/or `udiskie-umount` inside a user cron job, you will need to grant your user additional permissions for the policykit actions as follows: 1) `org.freedesktop.udisks2.filesystem-mount-other-seat` for when nobody is logged in and 2) `org.freedesktop.udisks2.filesystem-mount` when somebody is logged into the system in an active session. To grant these permissions, you can (for example) create a file called `/etc/polkit-1/localauthority/50-local.d/10-udiskie.pkla` containing the following: ``` [udisks2] Identity=unix-group:plugdev Action=org.freedesktop.udisks2.filesystem-mount-other-seat;org.freedesktop.udisks2.filesystem-mount ResultAny=yes ``` This gives the necessary permissions to all users in the `plugdev` group. If you wish to only give permissions to a single user, you can replace the first line with ``` Identity=unix-group:plugdev ``` Note additionally that the policykit version in Debian (for jessie and later) is 105. The Javascript syntax you will see for Policykit is for versions 106 and later. The `*.pkla` suffix and the corresponding syntax is only used for policykit 105 and earlier.
Bug#822209: udiskie: Mention something about policykit, possibly in README.Debian
On Fri, 22 Apr 2016, Gianfranco Costamagna wrote: Hi, can you please provide a patch for this? I can also install a policykit file if needed, just please send a patch thanks G. Hi Gianfranco, This is the same patch as I posted earlier in https://github.com/coldfix/udiskie/issues/111 Consider creating a README.Debian with this content. Please feel free to make modifications as you think appropriate. Or I can make modifications if you want. Regards, Faheem Note that by default not all udiskie actions may be allowed. You may see an error like: GDBus.Error:org.freedesktop.UDisks2.Error.NotAuthorizedCanObtain: Not authorized to perform operation That error means you need to give udiskie addition permissions to perform whatever actions are necessary. These permissions are governed by policykit (package `policykit-1` in Debian), Here is an example. If you run `udiskie-mount` and/or `udiskie-umount` inside a user cron job, you will need to grant your user additional permissions for the policykit actions as follows: 1) `org.freedesktop.udisks2.filesystem-mount-other-seat` for when nobody is logged in and 2) `org.freedesktop.udisks2.filesystem-mount` when somebody is logged into the system in an active session. To grant these permissions, you can (for example) create a file called `/etc/polkit-1/localauthority/50-local.d/10-udiskie.pkla` containing the following: ``` [udisks2] Identity=unix-group:plugdev Action=org.freedesktop.udisks2.filesystem-mount-other-seat;org.freedesktop.udisks2.filesystem-mount ResultAny=yes ``` This gives the necessary permissions to all users in the `plugdev` group. If you wish to only give permissions to a single user, you can replace the first line with ``` Identity=unix-group:plugdev ``` Note additionally that the policykit version in Debian (for jessie and later) is 105. The Javascript syntax you will see for Policykit is for versions 106 and later. The `*.pkla` suffix and the corresponding syntax is only used for policykit 105 and earlier.
Bug#822209: udiskie: Mention something about policykit, possibly in README.Debian
On Fri, 22 Apr 2016, Gianfranco Costamagna wrote: Hi, can you please provide a patch for this? I can also install a policykit file if needed, just please send a patch thanks G. Hi Gianfranco, Ok. I filed an issue about this upstream, including a first attempt at a patch. Maybe the maintainer has thoughts about it. See https://github.com/coldfix/udiskie/issues/111 Feel free to comment if you wish. Regards, Faheem Mitha Il Venerdì 22 Aprile 2016 3:03, Faheem Mitha <fah...@faheem.info> ha scritto: Package: udiskie Version: 1.4.9-1 Severity: wishlist Dear Maintainer, See the discussion in https://github.com/coldfix/udiskie/issues/102 The upshot is that one needs to allow policykit to give permissions to udiskie for doing certain things - in this case, cron. Despite what Jason says, I don't think that cron is a particularly unusual use case for udiske, and it's been around for a long time. So one could reasonably say something about policykit, possibly in a README.Debian, I think. Regards, Faheem -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages udiskie depends on: ii gobject-introspection 1.42.0-2.2 ii python3-docopt 0.6.2-1 ii python3-gi 3.14.0-1 ii python3-pkg-resources 5.5.1-1 ii python3-yaml 3.11-2 pn python3:any ii udisks22.1.7-1 Versions of packages udiskie recommends: ii gir1.2-gtk-3.0 3.14.5-1+deb8u1 ii gir1.2-notify-0.7 0.7.6-2 ii notification-daemon 0.7.6-2 ii plasma-widgets-workspace [notification-daemon] 4:4.11.13-2 ii python3-keyutils0.3.0-3 ii xfce4-notifyd [notification-daemon] 0.2.4-3 udiskie suggests no packages. -- debconf-show failed
Bug#822209: udiskie: Mention something about policykit, possibly in README.Debian
Package: udiskie Version: 1.4.9-1 Severity: wishlist Dear Maintainer, See the discussion in https://github.com/coldfix/udiskie/issues/102 The upshot is that one needs to allow policykit to give permissions to udiskie for doing certain things - in this case, cron. Despite what Jason says, I don't think that cron is a particularly unusual use case for udiske, and it's been around for a long time. So one could reasonably say something about policykit, possibly in a README.Debian, I think. Regards, Faheem -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages udiskie depends on: ii gobject-introspection 1.42.0-2.2 ii python3-docopt 0.6.2-1 ii python3-gi 3.14.0-1 ii python3-pkg-resources 5.5.1-1 ii python3-yaml 3.11-2 pn python3:any ii udisks22.1.7-1 Versions of packages udiskie recommends: ii gir1.2-gtk-3.0 3.14.5-1+deb8u1 ii gir1.2-notify-0.7 0.7.6-2 ii notification-daemon 0.7.6-2 ii plasma-widgets-workspace [notification-daemon] 4:4.11.13-2 ii python3-keyutils0.3.0-3 ii xfce4-notifyd [notification-daemon] 0.2.4-3 udiskie suggests no packages. -- debconf-show failed
Bug#631504: confused about this bug report
Hi, I'm using Debian jessie/stable. I see that there was much discussion about using the internal FUSE library, which finally did happen before jessie, and I confirmed that the jessie version *is* using the internal version. But mounting as user is still not working for me. I get mount /mnt/passport/ Error opening '/dev/sde1': Permission denied Failed to mount '/dev/sde1': Permission denied Please check '/dev/sde1' and the ntfs-3g binary permissions, and the mounting user ID. More explanation is provided at http://tuxera.com/community/ntfs-3g-faq/#unprivileged I have the following in my /etc/fstab UUID="4E1AEA7B1AEA6007" /mnt/passport autorw,user,noauto 0 0 Can anyone help me out? Thanks. Regards, Faheem Mitha
Bug#693814: Bug#820208: postgresql-autodoc: the listed home page no longer resolves
On Wed, 6 Apr 2016, Tim Retout wrote: On Wed, 2016-04-06 at 20:53 +0530, Faheem Mitha wrote: If I try to go to http://www.rbt.ca/autodoc/, I get Hi Faheem, and thanks for the bug. It's been that way for a while. :( The closest I've found to an alternative upstream is this github repo, which contains version 1.41: https://github.com/cbbrowne/autodoc Yes, it looks like the original maintainer has abandoned it, and nobody has really picked it up. Any plans to package 1.41? I don't know what the changes are. Regards, Faheem Mitha Arch appear to use archive.org, and have a snapshot of that version: https://aur.archlinux.org/packages/postgresql-autodoc/ (Copying the other bug to note this.) -- Tim Retout <dioc...@debian.org>
Bug#820208: postgresql-autodoc: the listed home page no longer resolves
Package: postgresql-autodoc Version: 1.40-3 Severity: normal Tags: upstream Dear Maintainer, If I try to go to http://www.rbt.ca/autodoc/, I get ## Not Found The requested URL /autodoc/ was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. ## -- System Information: Debian Release: 8.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages postgresql-autodoc depends on: ii libdbd-pg-perl 3.4.2-1 ii libhtml-template-perl 2.95-1 ii libterm-readkey-perl 2.32-1+b1 ii perl 5.20.2-3+deb8u4 Versions of packages postgresql-autodoc recommends: ii chromium [www-browser] 49.0.2623.108-1~deb8u1 ii dia 0.97.3-1 ii docbook-defguide [docbook-book] 2.0.17+svn9912-1 ii google-chrome-stable [www-browser] 49.0.2623.110-1 ii graphviz2.38.0-7 ii iceweasel [www-browser] 38.7.1esr-1~deb8u1 ii konqueror [www-browser] 4:4.14.2-1 ii links [www-browser] 2.8-2+b3 ii lynx2.8.9dev1-2+deb8u1 ii lynx-cur [www-browser] 2.8.9dev1-2+deb8u1 ii w3m [www-browser] 0.5.3-19 postgresql-autodoc suggests no packages. -- debconf-show failed
Bug#818162: apt: /var/log/apt/history.log does not report epochs
Package: apt Version: 1.0.9.8.2 Severity: normal Dear Maintainer, I happened to notice that history.log does not include package epochs when reporting installs etc al. I don't care about that, but apt-get does. Context: I'm getting a log of Hash Sum type breakage, and because of this, was accidentally upgraded to a lot of jessie-backports packages I didn't want to be upgraded to. I discovered the thing about epochs, when trying to use history to roll back to stable. When I fed apt-get the output of history.log, it complained about the package numbers, and it was clear the epochs were the problem. And indeed, when I added the epochs, it stopped complaining. Regards, Faheem Mitha -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-headers-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-image-extra-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-signed-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^kfreebsd-headers-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^gnumach-image-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-modules-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^.*-kernel-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-backports-modules-.*-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-tools-3\.16\.0-4-amd64$"; APT::NeverAutoRemove:: "^linux-tools-3\.2\.0-4-amd64$"; APT::NeverAutoRemove:: "^postgresql-"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-image"; APT::VersionedKernelPackages:: "linux-headers"; APT::VersionedKernelPackages:: "linux-image-extra"; APT::VersionedKernelPackages:: "linux-signed-image"; APT::VersionedKernelPackages:: "kfreebsd-image"; APT::VersionedKernelPackages:: "kfreebsd-headers"; APT::VersionedKernelPackages:: "gnumach-image"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::VersionedKernelPackages:: "linux-backports-modules-.*"; APT::VersionedKernelPackages:: "linux-tools"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Never-MarkAuto-Sections:: "oldlibs"; APT::Never-MarkAuto-Sections:: "restricted/oldlibs"; APT::Never-MarkAuto-Sections:: "universe/oldlibs"; APT::Never-MarkAuto-Sections:: "multiverse/oldlibs"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i"; APT::Update::Post-Invoke-Success:: "[ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true"; APT::Update::Post-Invoke ""; APT::Update::Post-Invoke:: "[ ! -x /usr/bin/debtags ] || debtags update || true"; APT::Periodic ""; APT::Periodic::Unattended-Upgrade "1"; APT::Get ""; APT::Get::Build-Dep-Automatic "true"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Architectures:: "i386"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension "&
Bug#809926: /usr/bin/apt-get: --install-recommends appears to be a no-op
Package: apt Version: 1.0.9.8.1 Severity: normal File: /usr/bin/apt-get Dear Maintainer, Consider: apt-get install gnumeric Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: guile-1.8 guile-1.8-libs libappconfig-perl lilypond-doc lilypond-doc-html lilypond-doc-pdf pfb2t1c2pfb ps2eps pxlib1 texmacs-common Use 'apt-get autoremove' to remove them. The following extra packages will be installed: gnumeric-doc Suggested packages: gnumeric-plugins-extra The following NEW packages will be installed: gnumeric gnumeric-doc 0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded. Need to get 11.3 MB/13.6 MB of archives. After this operation, 21.6 MB of additional disk space will be used. Do you want to continue? [Y/n] But let's install without the recommended gnumeric-doc. apt-get install --no-install-recommends gnumeric Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: guile-1.8 guile-1.8-libs libappconfig-perl lilypond-doc lilypond-doc-html lilypond-doc-pdf pfb2t1c2pfb ps2eps pxlib1 texmacs-common Use 'apt-get autoremove' to remove them. Suggested packages: gnumeric-plugins-extra Recommended packages: gnumeric-doc The following NEW packages will be installed: gnumeric 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded. Need to get 0 B/2,315 kB of archives. After this operation, 7,803 kB of additional disk space will be used. Preconfiguring packages ... Selecting previously unselected package gnumeric. (Reading database ... 515181 files and directories currently installed.) Preparing to unpack .../gnumeric_1.12.18-2_amd64.deb ... Unpacking gnumeric (1.12.18-2) ... Processing triggers for mime-support (3.58) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for desktop-file-utils (0.22-1) ... Setting up gnumeric (1.12.18-2) ... Processing triggers for menu (2.1.47) ... Processing triggers for libc-bin (2.19-18+deb8u1) ... But reinstalling doesn't bring in the recommended gnumeric-doc. apt-get install --reinstall gnumeric Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: guile-1.8 guile-1.8-libs libappconfig-perl lilypond-doc lilypond-doc-html lilypond-doc-pdf pfb2t1c2pfb ps2eps pxlib1 texmacs-common Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/2,315 kB of archives. After this operation, 0 B of additional disk space will be used. Preconfiguring packages ... (Reading database ... 515475 files and directories currently installed.) Preparing to unpack .../gnumeric_1.12.18-2_amd64.deb ... Unpacking gnumeric (1.12.18-2) over (1.12.18-2) ... Processing triggers for mime-support (3.58) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for desktop-file-utils (0.22-1) ... Setting up gnumeric (1.12.18-2) ... Processing triggers for menu (2.1.47) ... Processing triggers for libc-bin (2.19-18+deb8u1) ... Nor does using the --install-recommends flag, which isn't documented in the man page. apt-get install --install-recommends --reinstall gnumeric Reading package lists... Done Building dependency tree Reading state information... Done The following packages were automatically installed and are no longer required: guile-1.8 guile-1.8-libs libappconfig-perl lilypond-doc lilypond-doc-html lilypond-doc-pdf pfb2t1c2pfb ps2eps pxlib1 texmacs-common Use 'apt-get autoremove' to remove them. 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded. Need to get 0 B/2,315 kB of archives. After this operation, 0 B of additional disk space will be used. Preconfiguring packages ... (Reading database ... 515475 files and directories currently installed.) Preparing to unpack .../gnumeric_1.12.18-2_amd64.deb ... Unpacking gnumeric (1.12.18-2) over (1.12.18-2) ... Processing triggers for mime-support (3.58) ... Processing triggers for menu (2.1.47) ... Processing triggers for man-db (2.7.0.2-5) ... Processing triggers for desktop-file-utils (0.22-1) ... Setting up gnumeric (1.12.18-2) ... Processing triggers for menu (2.1.47) ... Processing triggers for libc-bin (2.19-18+deb8u1) ... Surely this should add gnumeric-doc? Regards, Faheem -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove::
Bug#759292: smuxi-engine: init script for smuxi-server
On Sun, 27 Dec 2015, Michael Meskes wrote: On Tue, Aug 26, 2014 at 02:57:28AM +0530, Faheem Mitha wrote: Package: smuxi-engine Version: 0.11~rc5-1~bpo70+1 Severity: wishlist I doubt wishlist is the right priority, it should by higher IMO. Actually I wonder if policy says anything about it. Anyhow, is there a reason why this bug did not even get a reply, let alone a fix in more than a year? Michael Hi Michael, Thanks for writing. I must admit that I don't even remember filing this bug. You could talk to Mirco on IRC (#smuxi) about it. He's quite helpful and cooperative. He's upstream as well as being the Debian maintainer. I don't currently use smuxi myself, so I'm not in touch. And I'm not sure about policy, but a good place to ask about such things is #debian-mentors on OFTC. Regards, Faheem Mitha -- Michael Meskes Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org) Meskes at (Debian|Postgresql) dot Org Jabber: michael.meskes at gmail dot com VfL Borussia! Força Barça! Go SF 49ers! Use Debian GNU/Linux, PostgreSQL
Bug#806560: subscribing to Debian bug reports for python-udiskie
Hi Thomas, You can subscribe to Debian bug reports for python-udiskie by going to https://packages.qa.debian.org/p/python-udiskie.html and entering your address in the bottom left hand corner. Alternatively, you can do this by email, see https://www.debian.org/doc/manuals/developers-reference/resources.html#pts-commands ### You can control your subscription(s) to the PTS by sending various commands to <p...@qa.debian.org>. subscribe [] Subscribes email to communications related to the source package sourcepackage. Sender address is used if the second argument is not present. If sourcepackage is not a valid source package, you'll get a warning. However if it's a valid binary package, the PTS will subscribe you to the corresponding source package. ### Regards, Faheem Mitha
Bug#774149: fixing the stable package
[CCs to suitable-seeming people. If you are getting this email via the BTS too, sorry about the noise, but the BTS really should say who is subscribed.] Hi, The patch by Christian Weinberger fixes the problem for me, though I don't really understand it. It seems this bug breaks usbmount in stable, at least for me, and (it seems) others too. Is this a candidate for a stable fix? I'm willing to make a fix and do an upload if there is someone out there who will sponsor me. Or should I submit a pull request? And if so, where? Oh, but first, could we get come concensus that the Christian patch is the correct way to go? It looks good to me, but I don't understand the context well enough to say. Regard, Faheem Mitha
Bug#774149: fixing the stable package
On Fri, 4 Dec 2015, Jürgen Braun wrote: Hi all, the Patch from Christian works for me as well with one exception. I had to remove the file /lib/udev/rules.d/usbmount.rules after creating /etc/udev/rules.d/usbmount.rules. If I do not remove the original file, usbmount is called twice which leads to a double mount of the usb flash drive: $mount|grep sdd1 /dev/sdd1 on /media/usb1 type ext2 (rw,nosuid,nodev,noatime,nodiratime,errors=continue,user_xattr,acl) /dev/sdd1 on /media/usb2 type ext2 (rw,nosuid,nodev,noatime,nodiratime,errors=continue,user_xattr,acl) I've successfully tested ext2, vfat and ntfs based usb flash drives so far using this patch. I guess this is the systemd way to get this done. As far as I understood Christians patch, this adds a dependency to systemd (since it is using systemd-escape). I am not sure if this is the *best* way to do. How to deal with systems using sysvinit or upstart? I forgot to say that I replaced the old usbmount.rules with the old ones. Having two didn't make sense to me. So usbmount.rules went into /lib/udev/rules.d. Also, I put usbmount@.service in /lib/systemd/system. This was what lintian seemed to think was correct. anyway. I didn't check any documentation about this. I've no idea whether how or if this works for systems not using systemd. Regards, Faheem
Bug#806561: borgbackup: The borg man page should mention it was written by Debian
Hi Gianfranco, On Sat, 28 Nov 2015, Gianfranco Costamagna wrote: Hi Faheem, The borg man page was written by Debian, or so Thomas Waldmann tells me. But this is not mentioned anywhere on it. It should be mentioned. 1) why? do you have any policy requirement where a manpage written should mention who and where wrote it? It's just standard attribution. If something is not part of upstream, it's customary to say so. Avoids confusion. 2) where? where did Thomas say so? On IRC. #borgbackup on Freenode. 3) is an autogenerated with help2man manpage even copyrightable? Was that how it was created? The whole thing? anyway, starting with borgbackup 0.28.2 the manpage is *not* written by Debian, nor with the autogenerated help2man stuff. Now (as suggested by me), the manpage is created starting from their rst files, that were on the git repository so long before Debian introduced the package. Ok. So this bug seems to be invalid to me. Ok. It was just a suggestion. Like I said, it's good to give credit where credit is due. Regards, Faheem Mitha (of course feel free to reopen if you don't agree with me, and in that case patches would be so appreciated!) cheers! Gianfranco
Bug#806561: borgbackup: The borg man page should mention it was written by Debian
Package: borgbackup Version: 0.28.2-1 Severity: normal Hi, The borg man page was written by Debian, or so Thomas Waldmann tells me. But this is not mentioned anywhere on it. It should be mentioned. Regards, Faheem Mitha -- System Information: Debian Release: 8.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages borgbackup depends on: ii libacl12.2.52-2 ii libc6 2.19-18+deb8u1 ii liblz4-1 0.0~r122-2 ii libssl1.0.21.0.2d-3 ii python33.4.2-2 ii python3-msgpack0.4.6-1+b1 ii python3-pkg-resources 5.5.1-1 Versions of packages borgbackup recommends: ii python3-llfuse 0.40-2+b2 Versions of packages borgbackup suggests: pn borgbackup-doc -- no debconf information
Bug#789548: summit.debconf.org: typo on web page
Package: summit.debconf.org Severity: minor In http://debconf15.debconf.org/registration.xhtml described is mis-spelled a couple of times as decribed (missing 's'). Regards, Faheem -- System Information: Debian Release: 8.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771550: I'm seeing this too
or something very similar.
calibre Mike\ Davis\ -\ Late\ Victorian\ Holocausts_El\ Nino\ Famines\ and\
the\ Making\ of\ the\ Third\ World.epub
Failed to unpickle stored object:
Traceback (most recent call last):
File /usr/lib/calibre/calibre/utils/config.py, line 215, in refresh
d = cPickle.loads(raw) if raw.strip() else {}
File /usr/lib/calibre/calibre/startup.py, line 36, in load_module
raise ImportError('Importing PyQt4 is not allowed as calibre uses
PyQt5')
ImportError: (ImportError('Importing PyQt4 is not allowed as calibre uses
PyQt5',), built-in function _unpickle_type, ('PyQt4.QtCore',
'QByteArray',
('\x01\xd9\xd0\xcb\x00\x01\x00\x00\x00\x00\x01\x96\x00\x00\x00\xd2\x00\x00\x04*\x00\x00\x03\x8c\x00\x00\x01\x9a\x00\x00\x00\xe9\x00\x00\x04\x00\x00\x03\x88\x00\x00\x00\x00\x00\x00',)))
InputFormatPlugin: EPUB Input running
on /home/faheem/Calibre Library/Mike Davis/Late Victorian Holocausts
(37)/Late Victorian Holocausts - Mike Davis.epub
Found HTML cover OEBPS/9781781680612_cover.xml
Traceback (most recent call last):
File /usr/lib/calibre/calibre/gui2/ui.py, line 952, in closeEvent
self.shutdown(write_settings=False)
File /usr/lib/calibre/calibre/gui2/ui.py, line 896, in shutdown
self.update_checker.terminate()
AttributeError: 'Main' object has no attribute 'update_checker'
I'm on Debian jessie with calibre version 2.5.0+dfsg-1.
It's probably the same underlying bug. Juhapekka, what do you think?
Regards, Faheem.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784879: upstream bug opened
Hi, I opened http://www.cmake.org/Bug/view.php?id=15566 Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784879: reproducible with vanilla Scons 3.2.2 soources
Hi, I was able to reproduce most of these test failures using vanilla Cmake sources. Thanks to Nils Gladitz for the suggestion. Nils also suggested that I report this upstream if I can reproduce it on master, so I'll check master next. A summary of the test failures with the vanilla sources follows. I'll add a link to the upstream bug report here once I open it. Regards, Faheem The following tests FAILED: 26 - FindPackageTest (Failed) 225 - CTestTestStopTime (Failed) 282 - RunCMake.CMP0041 (Failed) 331 - RunCMake.include_directories (Failed) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784906: apt does not need to repeatedly re-download package file information when switching between apt servers
Package: apt Version: 1.0.9.8 Severity: wishlist Dear Maintainer, I noticed that if I switch servers, apt goes ahead and re-downloads the package file information from scratch, completely ignoring the already existing file. But usually these files are similar, if not identical. Also, as of the just released jessie, these files are increasingly significant in size, currently of the order of 20 MB. As described in the IRC snippet below, one possibiliy would be to check hashes of files, and if they are identical, then hardlink to an existing file. ### Snipper from #debian-apt follow: faheem I'm sure I'm not saying anything that others haven't thought of before, but I noticed (not for the first time) that apt downloads the same package information from every mirror, even though each mirror has probably similar if not identical information. Can this step not be reduced or skipped? mvo faheem: that is a interessting idea, we know what hashes to expect and we could simply hardlink a existing identical file if the hash is the same -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-headers-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-image-extra-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-signed-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^kfreebsd-headers-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^gnumach-image-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-modules-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^.*-kernel-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-backports-modules-.*-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.16\.0-4-amd64$; APT::NeverAutoRemove:: ^linux-tools-3\.2\.0-4-amd64$; APT::NeverAutoRemove:: ^postgresql-; APT::VersionedKernelPackages ; APT::VersionedKernelPackages:: linux-image; APT::VersionedKernelPackages:: linux-headers; APT::VersionedKernelPackages:: linux-image-extra; APT::VersionedKernelPackages:: linux-signed-image; APT::VersionedKernelPackages:: kfreebsd-image; APT::VersionedKernelPackages:: kfreebsd-headers; APT::VersionedKernelPackages:: gnumach-image; APT::VersionedKernelPackages:: .*-modules; APT::VersionedKernelPackages:: .*-kernel; APT::VersionedKernelPackages:: linux-backports-modules-.*; APT::VersionedKernelPackages:: linux-tools; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Update::Post-Invoke-Success:: [ ! -f /var/run/dbus/system_bus_socket ] || /usr/bin/dbus-send --system --dest=org.debian.apt --type=signal /org/debian/apt org.debian.apt.CacheChanged || true; APT::Update::Post-Invoke-Success:: /usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service /usr/bin/test -S /var/run/dbus/system_bus_socket /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update /dev/null; /bin/echo /dev/null; APT::Update::Post-Invoke ; APT::Update::Post-Invoke:: [ ! -x /usr/bin/debtags ] || debtags update || true; APT::Periodic ; APT::Periodic::Unattended-Upgrade 1; APT::Get ; APT::Get::Build-Dep-Automatic true; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ;
Bug#784909: x11-common: /etc/X11/Xsession.d/20x11-common_process-args should not pass -geometry to x-terminal-emulator
Package: x11-common Version: 1:7.7+7 Severity: normal Dear Maintainer, While debugging a recent upgrade to jessie, I tried logging in with the failsafe option. This apparently just starts up a terminal specifically the terminal currently set in `x-terminal-emulator`. In my particular case, `x-terminal-emulator` was set to the terminator program. However, in this instance, this login attempt exited with an error, namely: x-terminal-emulator: error: Additional unexpected arguments found: ['+1+1'] As Gilles on Unix Linux Stack Exchange Chat (unix.stackexchange.com) explained to me, the problem was that /etc/X11/Xsession.d/20x11-common_process-args assumes that x-terminal-emulator understands -geometry. See the following extract from /etc/X11/Xsession.d/20x11-common_process-args: # Failsafe session was requested. if has_option allow-failsafe; then if [ -e /usr/bin/x-terminal-emulator ]; then if [ -x /usr/bin/x-terminal-emulator ]; then exec x-terminal-emulator -geometry +1+1 However, terminator doesn't understand this option. terminator -geometry +1+1 Usage: terminator [options] terminator: error: Additional unexpected arguments found: ['+1+1'] Though it does understand terminator --geometry +1+1 However, Policy (11.8.3 Packages providing a terminal emulator) only says To be an x-terminal-emulator, a program must: Be able to emulate a DEC VT100 terminal, or a compatible terminal. Support the command-line option -e command, which creates a new terminal window[106] and runs the specified command, interpreting the entirety of the rest of the command line as a command to pass straight to exec, in the manner that xterm does. Support the command-line option -T title, which creates a new terminal window with the window title title. So this looks like a bug. Regards, Faheem -- System Information: Debian Release: 8.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages x11-common depends on: ii debconf [debconf-2.0] 1.5.56 ii lsb-base 4.1+Debian13+nmu1 x11-common recommends no packages. x11-common suggests no packages. -- debconf information: x11-common/xwrapper/allowed_users: Console Users Only x11-common/xwrapper/actual_allowed_users: console -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741681: closed by Norbert Preining prein...@logic.at (Re: Bug#741681: texlive-latex-base has unnecessary dpkg dependency)
Hi, I earlier reported bug #741681 on 15 Mar 2014. It appears that someone else (Jean-Philippe MENGUAL) sent an unrelated bug report to this same bug address (a very strange thing to do). That bug report was then closed, incidentally closing my bug report. Unless I am misunderstanding something, please reopen this bug report. Thanks. Regards, Faheem Mitha On Sun, 12 Apr 2015, Debian Bug Tracking System wrote: This is an automatic notification regarding your Bug report which was filed against the texlive-latex-base package: #741681: texlive-latex-base has unnecessary dpkg dependency It has been closed by Norbert Preining prein...@logic.at. Their explanation is attached below along with your original report. If this explanation is unsatisfactory and you have not received a better one in a separate message then please contact Norbert Preining prein...@logic.at by replying to this email. -- 741681: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741681 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774710: ruby2.1: FTBFS on Wheezy
Hi Antonion, See at bottom. On Wed, 7 Jan 2015, Antonio Terceiro wrote: Control: severity -1 wishlist Hello Faheem, On Tue, Jan 06, 2015 at 09:36:23PM +0530, Faheem Mitha wrote: Package: ruby2.1 Version: 2.1.5-1 Severity: normal Ruby 2.1 fails to build on Wheezy, even though the build dependencies are all satisfied. See the attached file ruby2.1_2.1.5-1_amd64.build. This build log ends with: make[2]: Leaving directory `/usr/local/src/ruby2.1/ruby2.1-2.1.5' # remove RPATH from tcltklib bindings chrpath --delete /usr/local/src/ruby2.1/ruby2.1-2.1.5/debian/tmp/usr/lib/x86_64-linux-gnu/ruby/2.1.0/tcltklib.so open: No such file or directory elf_open: Invalid argument Thanks for getting in touch, but note that ruby2.1 was never meant for wheezy anyway, I won't look into this, but if you can come up with a patch to make the build work on both wheezy and jessie, I would be happy to consider it. Hint: you want to look at debian/rules. The problem is due to the build not finding the Tk stuff, because the paths to the tcl/tk libaries changed between wheezy and jessie: Specified Tcl/Tk version is [8.5, 8.5] Use ActiveTcl libraries (if available). Search tclConfig.sh (in /usr/lib/x86_64-linux-gnu/tcl8.5/tclConfig.sh) and tkConfig.sh (in /usr/lib/x86_64-linux-gnu/tk8.5/tkConfig.sh).. Fail to find [tclConfig.sh, tkConfig.sh] Use X11 libraries (or use TK_XINCLUDES/TK_XLIBSW information on tkConfig.sh). Search tcl.h. Search tk.h.Search Tcl library.Search Tk library. Warning:: cannot find Tk library. tcltklib will not be compiled (tcltklib is disabled on your Ruby. That is, Ruby/Tk will not work). Please check configure options. Can't find proper Tcl/Tk libraries. So, can't make tcltklib.so which is required by Ruby/Tk. If you have Tcl/Tk libraries on your environment, you may be able to use them with configure options (see ext/tk/README.tcltklib). At present, Tcl/Tk8.6 is not supported. Although you can try to use Tcl/Tk8.6 with configure options, it will not work correctly. I recommend you to use Tcl/Tk8.5 or 8.4. Failed to configure tk. It will not be installed. ../../.././ext/tk/tkutil/extconf.rb Failed to configure tk/tkutil. It will not be installed. ../.././ext/win32/extconf.rb I might take a look at this bug later. I don't have time right now. If so, I'll follow up here. I'm sort of interested in learning more about autorools, and it looks like an autotools issue. But maybe I'm mistaken. As it happens, I'm not a Ruby user. :-) I happened across this build failure when trying to answer a SE (unix.stackexchange.com) question. Thanks for the fast reply. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773506: libflite1: build should check for texi2any
On Fri, 2 Jan 2015, Samuel Thibault wrote: Control: tags -1 + pending Hello, [snip] It's actually sorta both. See debian/patches/texi2html_to_texi2any_migration.patch which we introduced to migrate from texi2html to texi2any. It happens that upstream didn't actually checked for texi2html. But it didn't enable the documentation generation either anyway. So in the end it's really only a matter for Debian. I will bump the version of the dependency to make sure to have texinfo = 5.2. If backports are desired, it is a matter of not applying the abovementioned patch and putting back the texi2html dependency. Ok. Thanks for looking at this, Samuel. Could you document the backport thing somewhere? I don't know what an appropriate place would be. Perhaps README.sources. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773506: libflite1: build should check for texi2any
Package: libflite1 Version: 1.4-release-6 Severity: normal Dear Maintainer, The build exits with the following error for texinfo 4.13a.dfsg.1-10. This is only present in more recent versions of texinfo. It is present in 5.2. (cd html; texi2any --set-customization-variable TEXI2HTML=1 --split=chapter ../flite.texi) /bin/sh: 1: texi2any: not found make[1]: *** [flite.html] Error 127 It should possibly check for texi2anyd directly, perhaps in configure. This probably should be an upstream bug, but I'm filing it here anyway. Please forward upstream if appropriate. If I figure out how to file an upstream bug, I may post it upstream as well. Regards, Faheem Mitha -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 libflite1 depends on: ii libasound2 1.0.25-4 ii libc6 2.13-38+deb7u6 ii multiarch-support 2.13-38+deb7u6 libflite1 recommends no packages. Versions of packages libflite1 suggests: ii alsa-base 1.0.25+3~deb7u1 -- no debconf information dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package flite dpkg-buildpackage: source version 1.4-release-12 dpkg-buildpackage: source changed by Samuel Thibault sthiba...@debian.org dpkg-source --before-build flite-1.4-release dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -f build-stamp for i in aux cp dvi fn info ky log pdf pg ps toc tp vr; do \ rm -f doc/flite.$i; \ done cp /usr/share/misc/config.guess . cp /usr/share/misc/config.sub . autoconf /usr/bin/make clean *** *** Making default config file *** *** checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking target system type... x86_64-unknown-linux-gnu checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking for ranlib... ranlib checking for a BSD-compatible install... /usr/bin/install -c checking for ar... ar checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking whether byte ordering is bigendian... no checking for mmap... yes checking sys/soundcard.h usability... yes checking sys/soundcard.h presence... yes checking for sys/soundcard.h... yes checking machine/soundcard.h usability... no checking machine/soundcard.h presence... no checking for machine/soundcard.h... no checking sys/audioio.h usability... no checking sys/audioio.h presence... no checking for sys/audioio.h... no checking mmsystem.h usability... no checking mmsystem.h presence... no checking for mmsystem.h... no configure: creating ./config.status config.status: creating config/config config.status: creating config/system.mak make[1]: Entering directory `/usr/local/src/libflite1/flite-1.4-release' make clean in ... make clean in config ... make clean in include ... make clean in src ... make clean in src/audio ... make clean in src/utils ... make clean in src/regex ... make clean in src/hrg ... make clean in src/stats ... make clean in src/speech ... make clean in src/lexicon ... make clean in src/synth ... make clean in src/wavesynth ... make clean in src/cg ... make clean in lang ... make clean in lang/cmulex ... make clean in lang/usenglish ... make clean in lang/cmu_us_kal ... make clean in lang/cmu_time_awb ... make clean in lang/cmu_us_kal16 ... make clean in lang/cmu_us_awb ... make clean in lang/cmu_us_rms ... make clean in lang/cmu_us_slt ... make clean in doc ... make clean in testsuite ... make clean in sapi ... make clean in sapi/FliteCMUKalDiphone ... make clean in sapi/FliteCMUKalDiphone/register_vox ... make clean in sapi/FliteTTSEngineObj ... make clean in sapi/cmu_us_kal ... make clean in sapi/cmulex ... make clean in sapi/flite ... make clean in sapi/usenglish ... make clean in palm ... po_MemPtrNew.c:44:20: fatal error: pocore.h: No such file or directory
Bug#768022: mercurial: 3.2 has been released
On Fri, 14 Nov 2014, Javi Merino wrote: Hi Faheem, I've seen that you are using the backported version. As Jessie will release with 3.1.2, wheezy-backports will stay with 3.1.2. I can upload 3.2 (well, 3.2.1, which shall be uploaded soon) to wheezy-backports-sloppy if you are interested in it. Sure, I'm interested, and I expect other people are too. I think the Mercurial project has itself considered providing Debian backports, but that hasn't happened so far, presumably due to a lack of manpower. If you need help with the Debian packaging, let the community know. There are people who can help. The package is team-maintained, I'm just the most regular uploader. Other people have uploaded mercurial when I was unavailable. So yes, I know there is a community and no, I'm not *the* maintainer but *a* maintainer. Cheers, Ok. I don't know the current situation of the team. Just saying. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769520: dpkg-dev: debuild clean fails to first apply patches to source in quilt 3.0 format
Package: dpkg-dev Version: 1.17.21 Severity: wishlist Dear Maintainer, NOTE: This is being run inside a jessie chroot on a wheezy system. The subject line says it all. I noticed today that if the patches in debian/patches are not applied, then debuild clean does not apply them, and if a patch is required to run clean successfully, then clean fails. Included is the clean section of debian/rules for my example package, and also the output of running 'debuild clean' with and without patches applied. I think that debuild clean (or to be precise, the underlying dpkg-buildpackage) command should apply the patches before running any command, and presumably unapply it afterwards. I don't see a downside to this. Regards, Faheem Mitha ### section of debian/rules dealing with clean ### override_dh_auto_clean: find . -name *.pyc -delete find . -name symbols_scraped_inc.h -delete find . -name _symbolTableAfterBuild.txt -delete rm -rf debian/build rm -rf src/lisp/build rm -f src/core/a rm -f src/core/b rm -f src/main/taa.sh rm -f src/main/clasp_gc.ccBackup rm -f src/main/clasp_gc.telemetry.cc rm -f bin/config.log rm -f boost_build_v2/b2 rm -f boost_build_v2/engine/bin.macosxx86_64/b2 rm -f boost_build_v2/bin/config.log rm -f boost_build_v2/bjam rm -f boost_build_v2/bootstrap.log rm -f boost_build_v2/engine/bin.linuxx86_64/b2 rm -f boost_build_v2/engine/bin.linuxx86_64/bjam rm -f boost_build_v2/engine/bootstrap/jam0 rm -f src/core/_symbolTableAfterBuild.txt rm -f src/core/registerClasses.log rm -f src/core/symbols_scraped_inc.h rm -f src/llvmo/_symbolTableAfterBuild.txt rm -f src/llvmo/symbols_scraped_inc.h rm -f src/mpip/bin/boehm/clang-linux-3.6.0/release/link-static/mpip_scrape_flag.h rm -f src/main/image_test_prepass.bc rm -f src/asttooling/registerClasses.log rm -f src/cffi/registerClasses.log rm -f src/clbind/registerClasses.log rm -f src/gctools/registerClasses.log rm -f src/llvmo/registerClasses.log rm -f src/serveEvent/registerClasses.log rm -f src/sockets/registerClasses.log make clean ### Just running debuild clean (jessiechroot)faheem@orwell:/usr/local/src/clasp-llvm/clasp-llvm-0.1$ debuild clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory '/usr/local/src/clasp-llvm/clasp-llvm-0.1' find . -name *.pyc -delete find . -name symbols_scraped_inc.h -delete find . -name _symbolTableAfterBuild.txt -delete rm -rf debian/build rm -rf src/lisp/build rm -f src/core/a rm -f src/core/b rm -f src/main/taa.sh rm -f src/main/clasp_gc.ccBackup rm -f src/main/clasp_gc.telemetry.cc rm -f bin/config.log rm -f boost_build_v2/b2 rm -f boost_build_v2/engine/bin.macosxx86_64/b2 rm -f boost_build_v2/bin/config.log rm -f boost_build_v2/bjam rm -f boost_build_v2/bootstrap.log rm -f boost_build_v2/engine/bin.linuxx86_64/b2 rm -f boost_build_v2/engine/bin.linuxx86_64/bjam rm -f boost_build_v2/engine/bootstrap/jam0 rm -f src/core/_symbolTableAfterBuild.txt rm -f src/core/registerClasses.log rm -f src/core/symbols_scraped_inc.h rm -f src/llvmo/_symbolTableAfterBuild.txt rm -f src/llvmo/symbols_scraped_inc.h rm -f src/mpip/bin/boehm/clang-linux-3.6.0/release/link-static/mpip_scrape_flag.h rm -f src/main/image_test_prepass.bc rm -f src/asttooling/registerClasses.log rm -f src/cffi/registerClasses.log rm -f src/clbind/registerClasses.log rm -f src/gctools/registerClasses.log rm -f src/llvmo/registerClasses.log rm -f src/serveEvent/registerClasses.log rm -f src/sockets/registerClasses.log make clean make[2]: Entering directory '/usr/local/src/clasp-llvm/clasp-llvm-0.1' makefile:1: local.config: No such file or directory make[2]: *** No rule to make target 'local.config'. Stop. make[2]: Leaving directory '/usr/local/src/clasp-llvm/clasp-llvm-0.1' debian/rules:14: recipe for target 'override_dh_auto_clean' failed make[1]: *** [override_dh_auto_clean] Error 2 make[1]: Leaving directory '/usr/local/src/clasp-llvm/clasp-llvm-0.1' debian/rules:11: recipe for target 'clean' failed make: *** [clean] Error 2 debuild: fatal error at line 1346: couldn't exec fakeroot debian/rules: ## ## Applying patches first, then running debuild clean ## (jessiechroot)faheem@orwell:/usr/local/src/clasp-llvm/clasp-llvm-0.1
Bug#769520: dpkg-dev: debuild clean fails to first apply patches to source in quilt 3.0 format
On Fri, 14 Nov 2014, Raphael Hertzog wrote: On Fri, 14 Nov 2014, Faheem Mitha wrote: The subject line says it all. I noticed today that if the patches in debian/patches are not applied, then debuild clean does not apply them, and if a patch is required to run clean successfully, then clean fails. Included is the clean section of debian/rules for my example package, and also the output of running 'debuild clean' with and without patches applied. I think that debuild clean (or to be precise, the underlying dpkg-buildpackage) command should apply the patches before running any command, and presumably unapply it afterwards. I don't see a downside to this. dpkg-buildpackage is not called when you run debuild clean. The manual page clearly indicates that it calls debian/rules target directly. And your log doesn't show any message of dpkg-buildpackage. In general, opting to call a specific target doesn't do any build preparation work. It's the same if you do dpkg-buildpackage --target=clean. I'm not sure this can be considered as a bug. It behaves as documented. Hi Raphael, Ok, if you don't think it is a bug, please close it. If you can take a moment, can you advise me what the correct approach to handling this should be? Just make sure to push the patches before running 'debuild clean'? Thanks. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769520: dpkg-dev: debuild clean fails to first apply patches to source in quilt 3.0 format
On Fri, 14 Nov 2014, Raphael Hertzog wrote: On Fri, 14 Nov 2014, Faheem Mitha wrote: Hi Raphael, Ok, if you don't think it is a bug, please close it. I'll let Guillem do that if he agrees with me. Ok. If you can take a moment, can you advise me what the correct approach to handling this should be? Just make sure to push the patches before running 'debuild clean'? Thanks. It depends on why you're trying to clean your source package. If it's just after a build, you might want to consider using the -tc option that calls the clean target after a successfull build. Ok, I'll consider doing that. Thanks. Usually debian/rules clean tends to work even with patches unapplied but in the few cases where it doesn't, it's certainly ok if you manually ensure that they are applied. Note that the default state of the source package after dpkg-source -x is patches applied... if you use a workflow where patches are unapplied, it's up to this workflow to ensure that they are applied at the correct time. Ok. I think that at the end of a build the patches are unapplied, so calling clean directly after completion of a build can fail if it requires patches to be applied. Thanks. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768022: mercurial: 3.2 has been released
Hi Javi, On Thu, 6 Nov 2014, Javi Merino wrote: On Tue, Nov 04, 2014 at 02:58:31PM +0530, Faheem Mitha wrote: Package: mercurial Version: 3.1.2-1~bpo70+1 Severity: wishlist Dear Maintainer, Hi Faheem, Please consider packaging 3.2. I can build it myself, but the Debian patches have changed enough since the last release that they are no longer trivial to re-sync. If you could just refresh the patches, that would be helpful. Thanks. It's not as easy as refreshing the patches as you have seen. I'm working on it and I hope to upload it before Sunday. It will go to experimental though. I missed your email. I just saw it now. It looks like you have just uploaded to experimental. If you need help with the Debian packaging, let the community know. There are people who can help. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768022: mercurial: 3.2 has been released
Package: mercurial Version: 3.1.2-1~bpo70+1 Severity: wishlist Dear Maintainer, Please consider packaging 3.2. I can build it myself, but the Debian patches have changed enough since the last release that they are no longer trivial to re-sync. If you could just refresh the patches, that would be helpful. Thanks. Regards, Faheem Mitha -- System Information: Debian Release: 7.7 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 mercurial depends on: ii libc6 2.13-38+deb7u6 ii mercurial-common 3.1.2-1~bpo70+1 ii python2.7.3-4+deb7u1 ii ucf 3.0025+nmu3 Versions of packages mercurial recommends: ii openssh-client 1:6.0p1-4+deb7u2 Versions of packages mercurial suggests: ii kdiff3 0.9.96-4 pn qct none -- 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#765311: lintian: strange warning messages building experimental Common Lisp implementation package
Package: lintian Version: 2.5.28~bpo70+1 Severity: minor Dear Maintainer, When building an experimental CL implementation, namely https://github.com/drmeister/clasp with the Debian packaging at https://bitbucket.org/faheem/clasp-debian I get the following odd messages. I've not seen them before. They may not be anything of interest, in which case, please close the issue. If you want further details, let me know. Now running lintian... Use of uninitialized value $perm in exists at /usr/share/perl5/Lintian/Collect/Package.pm line 439, $_[...] line 1. Use of uninitialized value $t in pattern match (m//) at /usr/share/perl5/Lintian/Util.pm line 885, $_[...] line 1. Use of uninitialized value $t in concatenation (.) or string at /usr/share/perl5/Lintian/Util.pm line 892, $_[...] line 1. does not appear to be a permission string at /usr/share/perl5/Lintian/Collect/Package.pm line 442. warning: collect info md5sums about package clasp failed warning: skipping check of source package clasp Use of uninitialized value $perm in exists at /usr/share/perl5/Lintian/Collect/Package.pm line 439, $_[...] line 1. Use of uninitialized value $t in pattern match (m//) at /usr/share/perl5/Lintian/Util.pm line 885, $_[...] line 1. Use of uninitialized value $t in concatenation (.) or string at /usr/share/perl5/Lintian/Util.pm line 892, $_[...] line 1. does not appear to be a permission string at /usr/share/perl5/Lintian/Collect/Package.pm line 442. warning: collect info file-info about package clasp failed Regards, Faheem -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 lintian depends on: ii binutils 2.22-8 ii bzip2 1.0.6-4 ii diffstat 1.55-3 ii file 5.11-2+deb7u5 ii gettext0.18.1.1-9 ii hardening-includes 2.2 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.26+b1 ii libarchive-zip-perl1.30-6 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.31-1+b2 ii libdpkg-perl 1.16.15 ii libemail-valid-perl0.190-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-1+b1 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-1 ii libtimedate-perl 1.2000-1 ii liburi-perl1.60-1 ii man-db 2.6.2-1 ii patchutils 0.3.2-1.1 ii perl [libdigest-sha-perl] 5.14.2-21+deb7u1 ii t1utils1.37-1 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.18-1+b2 ii perl5.14.2-21+deb7u1 ii perl-modules [libautodie-perl] 5.14.2-21+deb7u1 Versions of packages lintian suggests: ii binutils-multiarch 2.22-8 ii dpkg-dev 1.16.15 ii libhtml-parser-perl3.69-2 pn libtext-template-perl none ii libyaml-perl 0.81-1 ii xz-utils 5.1.1alpha+20120614-2 -- 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#761431: usbmount: add ntfs to FILESYSTEMS variable
Package: usbmount Version: 0.0.22 Severity: wishlist Tags: patch Dear Maintainer, I gather usbmount is not longer maintained, but this trivial patch adds support for usbmount to mount ntfs filesystems. Please consider applying it. Regards, Faheem Mitha diff -r 4b18f079d6e4 usbmount/usbmount.conf --- a/usbmount/usbmount.confSat Sep 13 21:28:34 2014 +0530 +++ b/usbmount/usbmount.confSun Sep 14 02:12:37 2014 +0530 @@ -14,7 +14,7 @@ # Filesystem types: removable storage devices are only mounted if they # contain a filesystem type which is in this list. -FILESYSTEMS=vfat ext2 ext3 ext4 hfsplus +FILESYSTEMS=vfat ext2 ext3 ext4 hfsplus ntfs # # WARNING! # -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 usbmount depends on: ii lockfile-progs 0.1.17 ii udev175-7.2 ii util-linux 2.20.1-5.3 Versions of packages usbmount recommends: ii pmount 0.9.23-2 usbmount suggests no packages. -- Configuration Files: /etc/usbmount/usbmount.conf changed: ENABLED=1 MOUNTPOINTS=/media/usb0 /media/usb1 /media/usb2 /media/usb3 /media/usb4 /media/usb5 /media/usb6 /media/usb7 FILESYSTEMS=vfat ext2 ext3 ext4 hfsplus ntfs MOUNTOPTIONS=sync,noexec,nodev,noatime,nodiratime FS_MOUNTOPTIONS= VERBOSE=yes -- 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#459647: I can reproduce this too
This bug is present in 1.5-cvs20081009-1, 6 years later. Was this ever reported upstream? Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759292: smuxi-engine: init script for smuxi-server
Package: smuxi-engine Version: 0.11~rc5-1~bpo70+1 Severity: wishlist Hi, It would be nice to have an init script for smuxi-server in the smuxi-engine Debian package. There are a couple of examples at http://blog.elsdoerfer.name/2010/04/23/init-d-script-for-smuxi-server/ I don't know if licensing is an issue, but these are small scripts, so hopefully not. See also http://unix.stackexchange.com/q/152114/4671 Regards, Faheem -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 smuxi-engine depends on: ii liblog4net1.2-cil1.2.10+dfsg-6 ii libmono-corlib4.0-cil2.10.8.1-8 ii libmono-posix4.0-cil 2.10.8.1-8 ii libmono-system-core4.0-cil 2.10.8.1-8 ii libmono-system-data-linq4.0-cil 2.10.8.1-8 ii libmono-system-data4.0-cil 2.10.8.1-8 ii libmono-system-drawing4.0-cil2.10.8.1-8 ii libmono-system-runtime-serialization4.0-cil 2.10.8.1-8 ii libmono-system-runtime4.0-cil2.10.8.1-8 ii libmono-system-web4.0-cil2.10.8.1-8 ii libmono-system-xml-linq4.0-cil 2.10.8.1-8 ii libmono-system-xml4.0-cil2.10.8.1-8 ii libmono-system4.0-cil2.10.8.1-8 ii libnini1.1-cil 1.1.0+dfsg.2-4 ii mono-runtime 2.10.8.1-8 smuxi-engine recommends no packages. Versions of packages smuxi-engine suggests: pn oidentd | ident-server none -- 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#757138: pry installs on Debian wheezy (stable) but crashes on startup
Package: pry Version: 0.9.12.6-1 Severity: normal Dear Maintainer, pry installs on Debian wheezy (stable) but crashes on startup. I get faheem@orwell:~$ pry /usr/lib/ruby/vendor_ruby/pry/code.rb:53:in singletonclass': uninitialized constant MethodSource::CodeHelpers (NameError) from /usr/lib/ruby/vendor_ruby/pry/code.rb:52:in class:Code' from /usr/lib/ruby/vendor_ruby/pry/code.rb:31:in class:Pry' from /usr/lib/ruby/vendor_ruby/pry/code.rb:4:in top (required)' from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require' from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require' from /usr/lib/ruby/vendor_ruby/pry.rb:254:in top (required)' from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require' from /usr/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in require' from /usr/bin/pry:9:in main' I think your dependencies need to be tightened. Regards, Faheem -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 pry depends on: ii ruby 1:1.9.3 ii ruby-coderay 1.0.6-2 ii ruby-method-source0.7.1-1 ii ruby-slop 2.4.4-1 ii ruby1.8 [ruby-interpreter]1.8.7.358-7.1+deb7u1 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1+deb7u2 ii rubygems-integration 1.1 pry recommends no packages. pry 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#757039: apt-get fails to send correct http GET requests for URLS containing a dot
Package: apt Version: 1.0.1ubuntu2 Severity: normal See http://unix.stackexchange.com/q/148303/4671 Note, this is probably an Ubuntu machine. Upshot of the issue (note, I was not the person who asked this question): If we add the line to /etc/apt/sources.list, and run apt-get download appliance50 the following output is obtained. Note: the original poster used `install`, but I'm using `download`, because apt refused to try to install appliance50 on my machine. # root@orwell:/home/faheem# apt-get -o Debug::Acquire::Http=true download appliance50 0% [Working]GET /appliance50/2014/debs/dists/trusty/main/binary-i386/./appliance50_2014-0_i386.deb HTTP/1.1 Host: mirror.cs50.net Connection: keep-alive User-Agent: Debian APT-HTTP/1.3 (0.9.7.9) 0% [Waiting for headers]HTTP/1.1 404 Not Found Cache-control: no-cache=set-cookie Content-Type: text/html; charset=UTF-8 Date: Mon, 04 Aug 2014 19:45:53 GMT Server: Apache Set-Cookie: AWSELB=27CBB9F102866AACDE415904FB505399868B9DB4E22AC5183099E4BEEC583EF1DFA3B6E45DFCB95EFBFF7B8F8F555126DCFFF8A461898475BA865AD219D4E4F1F157545837;PATH=/;MAX-AGE=3600 Content-Length: 0 Connection: keep-alive Err Downloading appliance50 2014-0 404 Not Found ## but that isn't right, because apt-get doesn't strip out the dot (/./), and the server responds with a 404. For example wget sends # GET /appliance50/2014/debs/dists/trusty/main/binary-i386/appliance50_2014-0_i386.deb HTTP/1.1 Range: bytes=271380- User-Agent: Wget/1.13.4 (linux-gnu) Accept: */* Host: mirror.cs50.net Connection: Keep-Alive So, apt-get should rid of this dot in the GET request. apt-cache policy output follows. Regards, Faheem root@orwell:/home/faheem# apt-cache policy appliance50 appliance50:i386: Installed: (none) Candidate: 2014-0 Version table: 2014-0 0 500 http://mirror.cs50.net/appliance50/2014/debs/dists/trusty/main/binary-i386/ Packages -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Get ; APT::Get::Build-Dep-Automatic true; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9;
Bug#757039: omission
I should have written: If we add the line deb http://mirror.cs50.net/appliance50/2014/debs/dists/trusty/main/binary-i386 / to /etc/apt/sources.list, and run... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753975: Kallithea packaging
Hi, If you have some Debian packaging for Kallithea done, can you make it public, and share the url? Thanks. Regards, Faheem Mitha -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753975: Kallithea packaging
On Fri, 11 Jul 2014, Jelmer Vernooij wrote: On Fri, Jul 11, 2014 at 10:48:28PM +0530, Faheem Mitha wrote: Hi, If you have some Debian packaging for Kallithea done, can you make it public, and share the url? Thanks. I haven't pushed anything yet, but git://anonscm.debian.org/collab-maint/kallithea.git is where it will be located. I see. Thanks for the information. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754427: tortoisehg: libqscintilla should be a dependency (forwarded from Bitbucket)
Package: tortoisehg Version: 3.0 Severity: normal Just writing this to pass on the report from https://bitbucket.org/tortoisehg/thg/issue/3814/libqscintilla-not-a-requirement-in-debian Report pasted below. Regards, Faheem ### Anonymous created an issue 2 hours ago ** Mercurial version (3.0.1). TortoiseHg version (3.0) ** Command: --nofork ** CWD: /home/ajtag ** Encoding: UTF-8 ** Extensions loaded: gestalt, kilnauth, big-push, kiln, caseguard ** Python version: 2.7.7 (default, Jun 3 2014, 16:16:56) [GCC 4.8.3] ** System: Linux sodium 3.13-1-amd64 #1 SMP Debian 3.13.10-1 (2014-04-15) x86_64 ** Qt-4.8.6 PyQt-4.11.1 QScintilla-(unknown) Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 50, in dispatch return _runcatch(u, args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 229, in _runcatch return runcommand(ui, args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 317, in runcommand return _runcommand(lui, options, cmd, d) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 368, in _runcommand return checkargs() File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 322, in checkargs return cmdfunc() File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 316, in lambda d = lambda: qtrun(checkedfunc, ui, *args, **cmdoptions) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/qtapp.py, line 338,in __call__ dlg, reporoot = self._createdialog(dlgfunc, args, opts) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/qtapp.py, line 402, in _createdialog return dlgfunc(self._ui, *args, **opts), reporoot File /usr/lib/python2.7/dist-packages/mercurial/util.py, line 518, in check return func(*args, **kwargs) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 844, in log w = _workbench(ui, *pats, **opts) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/run.py, line 412, in _workbench w = qtrun.createWorkbench() File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/qtapp.py, line 434, in createWorkbench self._workbench = workbench.Workbench(self._ui, self._repomanager) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 102, in __getattribute__ self._load() File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 74, in _load mod = _hgextimport(_import, head, globals, locals, None, level) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, in _hgextimport return importfunc(name, globals, *args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/workbench.py, line 18, in module from tortoisehg.hgqt.repowidget import RepoWidget File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 130, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, in _hgextimport return importfunc(name, globals, *args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/repowidget.py, line 31, in module from tortoisehg.hgqt.commit import CommitWidget File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 130, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, in _hgextimport return importfunc(name, globals, *args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/commit.py, line 17, in module from tortoisehg.hgqt.messageentry import MessageEntry File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 130, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, in _hgextimport return importfunc(name, globals, *args) File /usr/lib/python2.7/dist-packages/tortoisehg/hgqt/messageentry.py, line 12, in module from PyQt4.Qsci import QsciScintilla, QsciLexerMakefile File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 130, in _demandimport mod = _hgextimport(_origimport, name, globals, locals) File /usr/lib/python2.7/dist-packages/mercurial/demandimport.py, line 43, in _hgextimport return importfunc(name, globals, *args) ImportError: /usr/lib/python2.7/dist-packages/PyQt4/Qsci.so: undefined symbol: _ZTI11QsciLexerPO worked around by apt-get installing qscintilla library. really shouldnt this be a dependency of the package? ### -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'),
Bug#587770: schroot - Please provide a way to add things to the default environment filter
Hi, I also think this is a useful feature. The particular use case I'm interested in is as follows. Currently schroot removes the DISPLAY env variable, However, I'd prefer if it wasn't, because this breaks running X applications from inside the chroot. Loic wrote I second this feature request! Something like debuild's --preserve-envvar= would be just fine with me (allows for simple regexps, but can also easily list multiple env vars to preserve). I also think this is a good idea The debuild man page says --preserve-envvar=var, -evar Do not clean the var variable from the environment. If var ends in an asterisk (*) then all variables with names that match the portion of var before the asterisk will be preserved. Something like that would work well, I think. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750871: Bug 750871 - patch
Hi Javi (and Max), On Wed, 18 Jun 2014, Max Bowsher wrote: On 17/06/14 23:40, Javi Merino wrote: Control: tags -1 - pending + wontfix On Sat, Jun 07, 2014 at 09:35:43PM +0100, Max Bowsher wrote: The problem here is that some manual sed hackery munging the /usr/bin/hg shebang was removed in PAPT SVN r10748, with the justification that dh_python2 would take care of it automatically. Unfortunately, it was not considered that the package currently circumvents large portions of dh_python2's multiple python version support by calling the upstream Makefile instead of setup.py. My guess is that the dh_python2 in sid doesn't have the problem described in the bug, that's why I didn't see it. That's not it - the bug is masked in sid by there only being one version of Python 2. Right. When there are two versions of Python 2 available, the bug can show up. Otherwise, it can't. Fortunately the solution is relatively simple: * Drop package-local Makefile constructs handling multiple python versions True, that needs to be simplified. It's been in my todo list for a while now. * Explicitly call the python_distutils debhelper buildsystem plugin No, this is not a good idea. * Use override hooks to call only the upstream Makefile targets which handle non-distutils parts of the build. I don't want to replicate upstream's Makefile in debian/rules. Today this may mean calling make doc and make tests by hand but you never know what can change in upstream's Makefile that will be lost because we're not using it any more. Mercurial is meant to be built using the Makefile so calling distutils directly should be reduced to the minimum. I suppose you can get away with this for now since upstream Python have declared there will never be a Python 2.8. However, by doing so you block debhelper's automatic support for supplying the right options to setup.py, and end up having to re-add things like --install-layout=deb within debian/rules explicitly. I'd suggest that's as much or more of an awkward tie into the internals of the buildsystem than my proposed patch. Max. I'd have to go with Max here. I asked about this bug on #mercurial on freenode. Max happened to be in the channel, and very kindly took some time to work out a patch. I think this patch merits serious consideration. Your main objection seems to be based on the assumption that Debian Mercurial packaging *must* call upstream's Makefile. To be precise, you wrote Mercurial is meant to be built using the Makefile so calling distutils directly should be reduced to the minimum. I don't see why this is so. You say but you never know what can change in upstream's Makefile that will be lost because we're not using it any more. As far as I know, the Mercurial Makefile is not going anywhere. One can easily check it periodically. Also, it does not change that often. I see the upstream Makefile is called in override_dh_auto_build: and nowhere else. It is called as $(MAKE) all Annotate run on the relevant lines shows: 2244: all: build doc [] 2235: build: 18056: $(PYTHON) setup.py $(PURE) build $(COMPILER:%=-c %) 2235: 2235: doc: 2235: $(MAKE) -C doc Now 18056 was changeset: 18056:7c9b07f0da73 parent: 18050:5522a7951bd7 user:Bryan O'Sullivan bry...@fb.com date:Tue Dec 11 13:44:00 2012 -0800 files: Makefile description: makefile: allow local builds to work on windows/mingw32 and the relevant change was - $(PYTHON) setup.py $(PURE) build + $(PYTHON) setup.py $(PURE) build $(COMPILER:%=-c %) Which afaict on Debian is a no-op. Before that, annotate shows 2244: all: build doc [] 2235: build: 7706: $(PYTHON) setup.py $(PURE) build 2235: 2235: doc: 2235: $(MAKE) -C doc This corresponds to changeset changeset: 7706:0ae7f0b312ea user:Martin Geisler m...@daimi.au.dk date:Sat Jan 24 01:47:36 2009 +0100 files: .hgignore Makefile description: use PURE option in Makefile with change. build: - $(PYTHON) setup.py build + $(PYTHON) setup.py $(PURE) build Also a no-op. So, I think we can conclude this portion of the Makefile, at least, does not change very often. Max's main point, I think, is that it makes sense to make use of debhelper's built-in functionality for handling things like multiple Python versions correctly, and it does not make sense to reinvent the wheel. (I don't presume to speak for Max here, so Max, please correct me if this is not right). The only reason not to do this is the overriding principle that the Makefile should be called correctly, and I have already attempted to point out there is no very compelling reason to do so. Granted, the fate of the world does not depend on this patch. Regardless, I suggest asking Mercurial devs directly what they think. Matt Mackall, at least, is not shy about expressing his opinion, and will
Bug#750871: mercurial: odd problem with /usr/bin/hg hash bang when backporting to wheezy
Package: mercurial Version: 3.0-1 Severity: normal Hi, When I backported the mercurial 3.0-1 package in unstable to wheezy, something odd happened. The hash bang at the top of the installed /usr/bin/hg in the backported 3.0 mercurial package is #!/usr/bin/python2.6. This is wrong, of course, since the default Python version on wheezy is 2.7. The correct hash bang is #!/usr/bin/python. The last version I backported to wheezy, which was 2.9, as well as the mercurial 3.0 unstable deb file I downloaded, both have #!/usr/bin/python as expected. So something seems to be going wrong on wheezy. Max Bowsher on #mercurial was able to reproduce this. Regards, Faheem -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 mercurial depends on: ii libc6 2.13-38+deb7u1 ii mercurial-common 3.0-1 ii python2.7.3-4+deb7u1 ii python2.6 2.6.8-1.1 ii ucf 3.0025+nmu3 Versions of packages mercurial recommends: ii openssh-client 1:6.0p1-4+deb7u1 Versions of packages mercurial suggests: ii kdiff3 0.9.96-4 pn qct none -- 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#750871: Bug 750871 - patch
On Sat, 7 Jun 2014, Max Bowsher wrote: The problem here is that some manual sed hackery munging the /usr/bin/hg shebang was removed in PAPT SVN r10748, with the justification that dh_python2 would take care of it automatically. Unfortunately, it was not considered that the package currently circumvents large portions of dh_python2's multiple python version support by calling the upstream Makefile instead of setup.py. Fortunately the solution is relatively simple: * Drop package-local Makefile constructs handling multiple python versions * Explicitly call the python_distutils debhelper buildsystem plugin * Use override hooks to call only the upstream Makefile targets which handle non-distutils parts of the build. Patch attached. Regards, Max Bowsher. Dear Maintainers, I tested Max's patch. It works, and looks like a clean solution. I hope you will apply it. Regards, Faheemdiff -ru mercurial-3.0/debian/rules mercurial-3.0.fixed/debian/rules --- mercurial-3.0/debian/rules 2014-04-07 22:58:25.0 +0100 +++ mercurial-3.0.fixed/debian/rules 2014-06-07 21:32:25.0 +0100 @@ -5,17 +5,30 @@ #export DH_VERBOSE=1 %: - dh $@ --with python2,bash-completion + dh $@ --with python2,bash-completion --buildsystem python_distutils -PYVERS=$(shell pyversions -vs) PYVER_DEFAULT=$(shell pyversions -vd) DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) +# This package uses both distutils and Makefile elements in its buildsystem. +# We configure debhelper to use the python_distutils buildsystem plugin, so +# that appropriate Debian-specific invocations of setup.py are used, and then +# call the extra needed Makefile targets from override_dh_auto_* targets. + override_dh_auto_build: - $(MAKE) all + dh_auto_build + $(MAKE) doc # Do not start a line with a word with a dot in a manpage sed -i -e 's,^[.]\(hgignore\|hg/hgrc\),\\fP\1,' doc/hg.1 +override_dh_auto_install: + dh_auto_install + $(MAKE) install-doc DESTDIR=$(CURDIR)/debian/tmp + +override_dh_auto_clean: + dh_auto_clean + $(MAKE) clean + ifneq (,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) NJOBS := $(patsubst parallel=%,%,$(filter parallel=%,$(DEB_BUILD_OPTIONS))) PARALLEL_TEST_JOBS := --jobs $(NJOBS) @@ -44,11 +57,6 @@ rename.ul .deb-backup '' $(CURDIR)/tests/* endif -override_dh_auto_install: $(PYVERS:%=install-python%) - -install-python%: - python$* setup.py install --root $(CURDIR)/debian/tmp --install-layout=deb - override_dh_install: dh_install if test -d $(CURDIR)/debian/mercurial ; then \
Bug#749163: handbrake: minor rewording in description
On Mon, 26 May 2014, Fabian Greffrath wrote: Hello Faheem, Am Samstag, den 24.05.2014, 21:36 +0530 schrieb Faheem Mitha: A more standard wording would be: It neither supports audio encoding to AAC via faac nor MP4 format muxing via libmp4v2. It falls back to the MKV format instead. thank you for your suggested update to the wording of the package description. However, most recently, this sentence has become pragmatically wrong: Nowadays handbrake supports AAC encoding via libavcodec and MP4 (and MPV) muxing via libavformat. I think it is safe to entirely remove that paragraph from the package description. Hi Fabian, Ok, if the paragraph no longer applies, then removing it is clearly the correct thing to do. Are you planning to do so for the next Debian release? Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#749163: handbrake: minor rewording in description
Source: handbrake Version: 0.9.9+svn6032+dfsg1-2 Severity: minor The current description includes It does neither support audio encoding to AAC via faac nor MP4 format muxing via libmp4v2, it falls back to the MKV format instead. A more standard wording would be: It neither supports audio encoding to AAC via faac nor MP4 format muxing via libmp4v2. It falls back to the MKV format instead. Regards, Faheem -- System Information: Debian Release: 7.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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#745769: apt: suggestion for APT::Get::Install-Automatic by analogy with APT::Get::Build-Dep-Automatic
Package: apt Version: 0.9.7.9+deb7u1 Severity: wishlist Hi, Us people on unix.stackexchange.com were discussing autoremove and related issues, see http://unix.stackexchange.com/a/126375/4671 and some related discussion starting http://chat.stackexchange.com/transcript/message/15142000#15142000 I thought that it would be useful to have a flag that one can pass to `apt-get install` that causes all packages installed with `apt-get install` to be marked automatically installed. I looked for a wishlist bug for such a flag, but didn't find it. It would be similar to how APT::Get::Build-Dep-Automatic works with `apt-get build-dep`. Regards, Faheem -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Get ; APT::Get::Build-Dep-Automatic true; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma; APT::Compressor::lzma::Binary xz; APT::Compressor::lzma::Cost 5; APT::Compressor::lzma::CompressArg ; APT::Compressor::lzma::CompressArg:: --format=lzma; APT::Compressor::lzma::CompressArg:: -9; APT::Compressor::lzma::UncompressArg ; APT::Compressor::lzma::UncompressArg:: --format=lzma; APT::Compressor::lzma::UncompressArg:: -d; APT::CompressorName ; APT::CompressorExtension .; APT::CompressorBinary ; APT::CompressorCost 100; APT::CompressorCompressArg ; APT::CompressorCompressArg:: -9; APT::CompressorUncompressArg ; APT::CompressorUncompressArg:: -d; Dir /; Dir::State var/lib/apt/; Dir::State::lists lists/; Dir::State::cdroms cdroms.list; Dir::State::mirrors mirrors/; Dir::State::extended_states extended_states; Dir::State::status /var/lib/dpkg/status; Dir::Cache var/cache/apt/; Dir::Cache::archives archives/; Dir::Cache::srcpkgcache srcpkgcache.bin; Dir::Cache::pkgcache pkgcache.bin; Dir::Etc etc/apt/; Dir::Etc::sourcelist sources.list; Dir::Etc::sourceparts sources.list.d; Dir::Etc::vendorlist vendors.list; Dir::Etc::vendorparts vendors.list.d; Dir::Etc::main apt.conf; Dir::Etc::netrc auth.conf; Dir::Etc::parts apt.conf.d; Dir::Etc::preferences preferences; Dir::Etc::preferencesparts preferences.d; Dir::Etc::trusted trusted.gpg; Dir::Etc::trustedparts trusted.gpg.d; Dir::Bin ; Dir::Bin::methods /usr/lib/apt/methods; Dir::Bin::solvers ; Dir::Bin::solvers:: /usr/lib/apt/solvers; Dir::Bin::dpkg /usr/bin/dpkg; Dir::Bin::bzip2 /bin/bzip2; Dir::Bin::xz /usr/bin/xz; Dir::Media ; Dir::Media::MountPath /media/cdrom; Dir::Log var/log/apt; Dir::Log::Terminal term.log; Dir::Log::History history.log; Dir::Ignore-Files-Silently ; Dir::Ignore-Files-Silently:: ~$; Dir::Ignore-Files-Silently::
Bug#744275: biber: build and runtime dependencies on Perl are incorrect
Package: biber Version: 1.8-1 Severity: normal As can easily be checked, biber 1.8 build depends on Perl 5.16, not 5.14, as listed in the build dependencies (see below). Package: biber Binary: biber Version: 1.8-1 Maintainer: Debian TeX maintainers debian-tex-ma...@lists.debian.org Uploaders: Danai SAE-HAN (韓達耐) da...@debian.org, Norbert Preining prein...@debian.org Build-Depends: debhelper (= 9), perl (= 5.14.0), libautovivification-perl, libconfig-autoconf-perl (= 0.15), libdata-compare-perl, libdata-dump-perl, libdate-simple-perl, libencode-eucjpms-perl, libencode-hanextra-perl, libencode-jis2k-perl, libextutils-libbuilder-perl (= 0.02), libfile-slurp-unicode-perl, libfile-which-perl, libipc-run3-pe rl, liblist-allutils-perl, liblist-moreutils-perl, liblog-log4perl-perl, liblwp-protocol-https-perl, libreadonly-perl, libreadonly-xs-perl, libregexp-common-perl, libtext-bi btex-perl (= 0.66), libunicode-collate-perl (= 0.98), libunicode-linebreak-perl, libwww-perl, libxml-libxml-simple-perl, libxml-libxslt-perl, libtest-pod-perl (= 1.22), libxml-writer-perl, libbusiness-isbn-perl, libbusiness-ismn-perl, libbusiness-issn-perl, liburi-perl, libtest-pod-coverage-perl (= 1.08), tex-common Additionally, biber has a runtime dependency on Perl 5.16 as well, not just perl, as listed in the runtime dependencies (see below). Package: biber Version: 1.8-1 Installed-Size: 1748 Maintainer: Debian TeX maintainers debian-tex-ma...@lists.debian.org Architecture: all Depends: dpkg (= 1.14.18), tex-common (= 4), perl, libautovivification-perl, libdata-compare-perl, libdata-dump-perl, libdate-simple-perl, libencode-eucjpms-perl, libencod e-hanextra-perl, libencode-jis2k-perl, libfile-slurp-unicode-perl, libipc-run3-perl, liblwp-protocol-https-perl, liblist-allutils-perl, liblist-moreutils-perl, liblog-log4pe rl-perl, libreadonly-perl, libregexp-common-perl, libtext-bibtex-perl (= 0.66), libunicode-collate-perl (= 0.98), libunicode-linebreak-perl, libwww-perl, libxml-libxml-sim ple-perl, libxml-libxslt-perl, libxml-writer-perl, libbusiness-isbn-perl, libbusiness-ismn-perl, libbusiness-issn-perl, liburi-perl Recommends: texlive-bibtex-extra, libreadonly-xs-perl Both these facts become obvious if you try to build or run biber 1.8 on Debian wheezy, which has Perl 5.14. Installng the biber binary from unstable on wheezy succeeds, but this is what you get when you try to run it: $ biber Perl v5.16.0 required--this is only v5.14.2, stopped at /usr/bin/biber line 6. BEGIN failed--compilation aborted at /usr/bin/biber line 6. Similarly, the build dependencies are satisfied on wheezy, but trying to build it produces immediate complaints as follows: faheem@orwell:/usr/local/src/biber/biber-1.8$ debuild -uc -us dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package biber dpkg-buildpackage: source version 1.8-1 dpkg-buildpackage: source changed by Norbert Preining prein...@debian.org dpkg-source --before-build biber-1.8 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean --with tex dh_testdir dh_auto_clean dh_clean dpkg-source -b biber-1.8 dpkg-source: info: using source format 3.0 (quilt)' dpkg-source: info: building biber using existing ./biber_1.8.orig.tar.gz dpkg-source: info: building biber in biber_1.8-1.debian.tar.gz dpkg-source: info: building biber in biber_1.8-1.dsc debian/rules build dh build --with tex dh_testdir dh_auto_configure Checking prerequisites... requires: ! Encode::EUCJPASCII is not installed ! Mozilla::CA is not installed ! perl (5.14.2) is installed, but we need version = 5.16.0 ERRORS/WARNINGS FOUND IN PREREQUISITES. You may wish to install the versions of the modules indicated above before proceeding with this installation Run 'Build installdeps' to install missing prerequisites. Then it gives a bunch more errors and crashes. Complete log attached. Regards, Faheem -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package biber dpkg-buildpackage: source version 1.8-1 dpkg-buildpackage: source changed by Norbert Preining prein...@debian.org dpkg-source --before-build biber-1.8 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean --with tex dh_testdir dh_auto_clean dh_clean dpkg-source -b biber-1.8 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info:
Bug#734922: update?
Hi, Any update on this bug? Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741681: texlive-latex-base has unnecessary dpkg dependency
Package: texlive-latex-base Version: 2012.20120611-5 Severity: normal It was pointed out to me that texlive-latex-base has the following unnecessary dependency. dpkg (= 1.14.18), But the version in squeeze is more recent than this. $ apt-cache policy dpkg dpkg: Installed: 1.16.12 Candidate: 1.16.12 Version table: 1.17.6 0 50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages 50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages *** 1.16.12 0 500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status 1.15.8.13 0 500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages I suggest removing this dependency. Regards, Faheem Mitha -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. *** The Debian TeX Team is *no* LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) or http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 root root 1373 Jan 30 04:34 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jun 15 2013 /usr/share/texmf/ls-R - /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf/ls-R - /var/lib/texmf/ls-R-TEXLIVEMAIN -rw-rw-r-- 1 root staff 80 Jan 10 02:13 /usr/local/share/texmf/ls-R lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf/ls-R - /var/lib/texmf/ls-R-TEXLIVEMAIN ## Config files -rw-r--r-- 1 root root 475 Jan 6 17:34 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 4745 Jan 30 04:34 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 Oct 3 2012 /usr/share/texmf/web2c/updmap.cfg - /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3245 Jan 30 04:34 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jan 10 2013 mktex.cnf -rw-r--r-- 1 root root 475 Jan 6 17:34 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: 7.4 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 texlive-latex-base depends on: ii dpkg 1.16.12 ii tex-common4.04 ii texlive-base 2012.20120611-5 ii texlive-binaries 2012.20120628-4 ii texlive-common2012.20120611-5 Versions of packages texlive-latex-base recommends: ii texlive-latex-base-doc 2012.20120611-5 texlive-latex-base suggests no packages. Versions of packages tex-common depends on: ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.12 ii ucf3.0025+nmu3 Versions of packages tex-common suggests: ii debhelper 9.20120909 Versions of packages texlive-latex-base is related to: ii tex-common4.04 ii texlive-binaries 2012.20120628-4 -- debconf information: tex-common/check_texmf_wrong: tex-common/check_texmf_missing: -- To UNSUBSCRIBE, email to debian-bugs-dist-requ
Bug#609047: ITP: ccl - Clozure CL
On Wed, 5 Mar 2014, Rafael Jesús Alcántara Pérez wrote: El Domingo, 2 de marzo de 2014 22:28:47 Faheem Mitha escribió: On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote: Hi: We have been watching this ITP for some months but we have found that there is no advance. Is there any chance to this ITP could progress any time soon? We are trying to use CCL because of its multiplatform capabilities (now running even on Raspberry Pi [1]) so we are very insterested in this ITP. Thanks in advance. [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d 5f38e7d511ff88e08d0c Hi Rafael, I'm willing to work with you (time permitting) if you want to use the CCL Debian packaging. You don't have to wait till it gets into Debian (assuming that ever happens). As far as I know it should work, though it has only been lightly tested. Perfect, where should I begin? Greets and thanks again. Rafael. Well, first do you just want binaries that work on your platform, or so you want to know how to build it yourself? Obviously, I would prefer the latter, because that way someone would have to look at my documentation and procedures, which could probably do with improvement. I think this is also preferable from your perspective for a package that isn't officially part of Debian. If you did want the former, I could just dump some binary debs somewhere, but that won't help you if I disappear off the net tomorrow. Do you have a group of people who are interested in using this? If so, can you give me a little more detail about them? As a first step, clone the following Mercurial repositories. https://bitbucket.org/faheem/ccl-debian https://bitbucket.org/faheem/ccl-bootstrap-debian https://bitbucket.org/faheem/ccl-ffigen-debian Start by seeing if you can build and install the ccl-ffigen package. That is the easiest. If you have problems with it, let me know. And what platform/arch will you be building on? Regards, Faheem
Bug#609047: ITP: ccl - Clozure CL
On Sun, 2 Mar 2014, Rafael Jesús Alcántara Pérez wrote: Hi: We have been watching this ITP for some months but we have found that there is no advance. Is there any chance to this ITP could progress any time soon? We are trying to use CCL because of its multiplatform capabilities (now running even on Raspberry Pi [1]) so we are very insterested in this ITP. Thanks in advance. [1]http://www.raspihub.com/go/f5780dbf11dabc60771e67b357ae947bc6b3fd87f35d5f38e7d511ff88e08d0c Hi Rafael, I'm willing to work with you (time permitting) if you want to use the CCL Debian packaging. You don't have to wait till it gets into Debian (assuming that ever happens). As far as I know it should work, though it has only been lightly tested. Regards, Faheem Mitha -- +-- | Rafael Jesus Alcantara Perez. | Email: mailto:ralcant...@dedaloingenieros.com mailto:rafael.alcant...@cpiia.org mailto:rafael.alcant...@ingenieroeninformatica.es | Registered Linux User: #45989 | PGP: http://pgp.rediris.es:11371/pks/lookup?op=indexsearch=0x53F330AB +- For every complex problem there is a solution that is concise, clear, simple, and wrong. (H. L. Mencken)
Bug#609047: ccl-ffigen_1.2-1_amd64.changes REJECTED
Hi, This is a second reminder. It is now 1st March 2014, i.e. approximately 5 1/2 months since I followed up to the ftpmaster email on 11th September 2013. I spent a great deal of time working on this packaging (approximately 1 month), and I would appreciate it if the ftpmasters would show me the minimal courtesy of replying to me. I thought Debian was supposed to appreciate its contributors. See https://www.debian.org/intro/diversity Right now, I am not feeling particularly appreciated or encouraged. Thanking you, Sincerely, Faheem Mitha On Mon, 30 Sep 2013, Faheem Mitha wrote: Hi, I don't mean to be impatient, but would it be possible for the FTP Master team to make a call on this, please? It does not seem like *so* difficult a technical issue. Thanks, Faheem On Wed, 11 Sep 2013, Faheem Mitha wrote: On Tue, 9 Apr 2013, Luca Falavigna wrote: Hi, sorry, but we do not think introducing a convenience copy of gcc is a good thing. Also, the 4.0 sources contain files licensed under GFDL with invariant sections, which are not suitable for main. Please try to build your code using existing gcc versions in the archive implementing Built-Using field. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. Extremely belated reply to this message, I've been busy. But if I waited for a good time, this might never be answered. I think the package was rejected based on a misunderstanding. As described at https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default this package exists to build CCL's interface databases. As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI is Foreign Function Interface) To support its FFI, CCL maintains a binary database of information about classes, methods, functions, types, and variables available from foreign libraries in several .cdb files. You will need to generate this information for your particular library. In order to do this, you will need to obtain and build ffigen4. This has little or nothing to do with GCC per se. It is *not* a fork. Basically, it uses the GCC frontend for a purpose that is presumably sufficiently similar to conventional compilation to enable a compiler frontend to be used., namely building .cdb files which reflect the C API of some .h files. I'm fuzzy about the details myself. Anyway, getting it to build the code using existing versions of GCC in the archive would be impracticably difficult for a non-expert. (For the record, getting CCL to build correctly and in particular build the interface databases in question was quite hair-raisingly difficult enough.) If you doubt me, look at the 'source' subdirectory in the ffigen tarball, which has the patches against gcc 4.0, and tell me if you understand what they do. I doubt even the main CCL developers would attempt it. They farmed out the job to someone else years ago, who used the then-current GCC compiler to get this to work. I could dig up more details, and talk to the CCL developers themselves (who are usually grumpy and not particularly sympathetic towards Debian, however) if you really need further clarification. I'm including the ffigen README below, which adds some details and history. As for the documentation thing, I guess I could just strip out the doc/FDL files from the tarball? Regards, Faheem. ### # $Log$ # Revision 1.2 2005/08/10 05:05:46 gb # Updated. # # Revision 1.1 2005/04/08 07:03:16 gb # New file. # 'ffigen' is a modified version of the GCC backend, based on similar modifications to the 'LCC' compiler described at: http://www.ccs.neu.edu/home/lth/ffigen/index.html It's a work derived from GCC, and therefore licensed under the GPL. Versions of ffigen - based on GCC 2.95 sources - were distributed as adjunct components of OpenMCL in 2001 and 2002. It's become increasingly difficult to use those versions, since they're sensitive to the exact format of the 2.95 C preprocessor output (and since GCC 2.95 is fading into obsolescence.) The source distributions consisted of a set of patches (relative to a canonical 2.95 source tree) and a README file that explained the build process. In the summer of 2004, Helmut Eller made available a set of patches relative to GCC 3.4.1. (Unlike previous versions, GCC 3.x's preprocessor and frontend are a single program, so an ffigen program derived from GCC 3 is likely to be a little more self-contained than earlier versions.) This version is based on GCC 4.0, builds on Helmut's work, and adds some initial support for translating Objective-C class and method information
Bug#609047: ITP: ccl - Clozure CL
On Wed, 26 Feb 2014, Rafael Jesús Alcántara Pérez wrote: Hi: Is there any advance on this ITP? Hi Rafael, Thanks for your interest. As you can see, I last pinged ftpmas...@debian.org about this on 30th September and nothing has happened since then. I have been meaning to follow up again. I have even considered complaining elsewhere (possibly on debian-devel), but have not done so thus far. Note that as far as I know the current packaging is essentially done, though maybe a careful review would show issues. However the version of CCL it was packaged against is now out of date, so that would need to be fixed, at least. However, I have not been very motivated to upgrade this if nobody cares. However, it should not be difficult to do. If you feel like complaining/following up with Debian, please do so, and CC me. It might only take a few people to get the ftpmasters to pay attention. Thanks. Regards, Faheem Mitha Greets. Rafael J. Alcántara Pérez. --
Bug#729904: jitsi: FTBFS on amd64 stable (wheezy)
On Wed, 29 Jan 2014, Daniel Reichelt wrote: Hi there, I managed to track down what's going wrong with compiling jitsi/2.4.4.997-1 on wheezy, although I didn't solve it in the sense that it is now compilable on plain Wheezy but on a Wheezy-based system, pulling in some build-depends from Jessie. Here are my steps: 1) minimal Wheezy installation 2) aptitude install libbcprov-java/jessie 3) aptitude install libhttpclient-java/jessie 4) apt-get build-dep jitsi/jessie Calling aptitude, you'll have to hit no until nothing get's not installed/left as it is etc... you know what I mean :) 2) was straightforward to solve. 3) however was a bit more tricky. During ant compile I wound up with 3 errors pertaining to SSLSocketFactoryEx.java (1 unfitting @Override annotation and 2 missing symbol: HttpInetSocketAddress...). Wheezy's libhttpclient-java package does not ship the required HttpInetSocketAddress class and provides an API version which indeed justifies the annotation error. Once I installed the jessie-version of the package, I could successfully build jitsi. HTH, cheers, Daniel Hi Daniel, Thanks, that is very helpful. I'm not sure whether you are one of the developers or Debian-side maintainers of Jitsi, but if the latter, can you adjust the build dependencies of jitsi accordingly? If you want to be helpful, you could also add a note for prospective backporters. When I get a chance, I'll try rebuilding it again. If you are a Debian maintainer, are you planning a new upload soon? Thanks. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734922: apt-cache showsrc shows duplicate entries
On Tue, 14 Jan 2014, Michael Vogt wrote: On Sat, Jan 11, 2014 at 01:05:23AM +0530, Faheem Mitha wrote: Package: apt Version: 0.9.7.9+deb7u1 Severity: normal Unlike, for example `apt-cache show` and `apt-cache policy`, `apt-cache showsrc` shows duplicate entries. I can't see any good reason for this inconsistency. Attached is a possilbe fix, but there is some cleanup needed before this can go in. In this line, idential should be identical. + // avoid showing idential records Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#734967: sbcl: 'debuild clean' does not clean itself properly
Package: sbcl Version: 1.1.14 Severity: normal Dear Maintainer, *** 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 lines *** After running clean, I get dpkg-source -b sbcl-1.1.14 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building sbcl using existing ./sbcl_1.1.14.orig.tar.bz2 dpkg-source: warning: file sbcl-1.1.14/tests/run-tests-6432/G688.lisp has no final newline (either original or modified version) dpkg-source: warning: file sbcl-1.1.14/tests/run-tests-6432/G689.lisp has no final newline (either original or modified version) dpkg-source: warning: file sbcl-1.1.14/tests/run-tests-6432/G690.lisp has no final newline (either original or modified version) dpkg-source: info: local changes detected, the modified files are: sbcl-1.1.14/contrib/asdf/asdf.lisp sbcl-1.1.14/tests/run-tests-6432/G688.lisp sbcl-1.1.14/tests/run-tests-6432/G689.lisp sbcl-1.1.14/tests/run-tests-6432/G690.lisp dpkg-source: error: aborting due to unexpected upstream changes, see /tmp/sbcl_1.1.14-2.diff.XcC3hl dpkg-source: info: you can integrate the local changes with dpkg-source --commit dpkg-buildpackage: error: dpkg-source -b sbcl-1.1.14 gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed Conclusion: the clean need to remove some tests too. I'm not sure what to do about sbcl-1.1.14/contrib/asdf/asdf.lisp. Build log attached. Regards, Faheem -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package sbcl dpkg-buildpackage: source version 2:1.1.14-2 dpkg-buildpackage: source changed by Christoph Egger christ...@debian.org dpkg-source --before-build sbcl-1.1.14 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh_testdir dh_testroot rm -rf target || true rm -rf stage1 || true rm -rf debian/tmpdir || true rm -rf .fontconfig || true GNUMAKE=make sh clean.sh || true find: `../../obj/asdf-cache/sb-md5': No such file or directory find: `../../obj/asdf-cache/sb-queue': No such file or directory find: `../../obj/asdf-cache/sb-concurrency': No such file or directory find: `../../obj/asdf-cache/sb-rotate-byte': No such file or directory find: `../../obj/asdf-cache/sb-grovel': No such file or directory find: `../../obj/asdf-cache/sb-sprof': No such file or directory find: `../../obj/asdf-cache/sb-bsd-sockets': No such file or directory find: `../../obj/asdf-cache/sb-cover': No such file or directory find: `../../obj/asdf-cache/sb-posix': No such file or directory make[1]: Entering directory `/usr/local/src/sbcl/sbcl-1.1.14/doc/manual' rm -f *~ *.bak *.orig \#*\# .\#* texput.log *.fasl rm -rf sbcl asdf docstrings/ rm -f sbcl.html asdf.html rm -f contrib-docs.texi-temp rm -f package-locks.texi-temp rm -f variables.texinfo rm -f sbcl.ps asdf.ps sbcl.pdf asdf.pdf html-stamp tempfiles-stamp rm -f asdf.aux asdf.cp asdf.cps asdf.fn asdf.fns asdf.ky asdf.log asdf.pg asdf.toc asdf.tp asdf.tps asdf.vr asdf.vrs sbcl.aux sbcl.cp sbcl.cps sbcl.fn sbcl.fns sbcl.ky sbcl.log sbcl.pg sbcl.toc sbcl.tp sbcl.tps sbcl.vr sbcl.vrs rm -f sbcl.info sbcl.info-* asdf.info make[1]: Leaving directory `/usr/local/src/sbcl/sbcl-1.1.14/doc/manual' make[1]: Entering directory `/usr/local/src/sbcl/sbcl-1.1.14/doc/internals' rm -rf *.include *.info *.pdf *~ *.cp *.fn *.ky *.log *.pg *.toc \ *.tp *.vr *.aux *.eps *.png *.dvi *.ps *.txt *.fns \ html-stamp sbcl-internals/ make[1]: Leaving directory `/usr/local/src/sbcl/sbcl-1.1.14/doc/internals' (cd src/runtime ; touch Config ; make clean ) || true make[1]: Entering directory `/usr/local/src/sbcl/sbcl-1.1.14/src/runtime' GNUmakefile:26: ../../output/prefix.def: No such file or directory GNUmakefile:33: genesis/Makefile.features: No such file or directory make[1]: *** No rule to make target `genesis/Makefile.features'. Stop. make[1]: Leaving directory `/usr/local/src/sbcl/sbcl-1.1.14/src/runtime' rmdir contrib/systems/ obj/ output/ || true rmdir: failed to remove `contrib/systems/': No such file or directory rmdir: failed to remove `obj/': No such file or directory rmdir: failed to remove `output/': No such file or directory make -C doc/internals clean make[1]: Entering directory `/usr/local/src/sbcl/sbcl-1.1.14/doc/internals' rm -rf *.include
Bug#734922: apt-cache showsrc shows duplicate entries
Package: apt Version: 0.9.7.9+deb7u1 Severity: normal Unlike, for example `apt-cache show` and `apt-cache policy`, `apt-cache showsrc` shows duplicate entries. I can't see any good reason for this inconsistency. For example: # $ apt-cache policy tla tla: Installed: (none) Candidate: 1.3.5+dfsg-18 Version table: 1.3.5+dfsg-18 0 500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages 50 http://debian.lcs.mit.edu/debian/ testing/main amd64 Packages 50 http://debian.lcs.mit.edu/debian/ unstable/main amd64 Packages 1.3.5+dfsg-16 0 500 http://debian.lcs.mit.edu/debian/ squeeze/main amd64 Packages ## and ## $ apt-cache show tla Package: tla Version: 1.3.5+dfsg-18 Installed-Size: 881 Maintainer: Debian QA Group packa...@qa.debian.org Architecture: amd64 Depends: libc6 (= 2.11), libexpat1 (= 1.95.8), gawk, patch Recommends: tla-doc Suggests: gnupg, ssh Description-en: GNU Arch revision control system Arch is a modern replacement for CVS, specifically designed for the distributed development. It supports development on branches, distributed repositories, changeset-oriented project management, and of course, file and directory renaming. Description-md5: b1978a310e178291e9aa549e4eefcad2 Tag: devel::rcs, implemented-in::c, interface::commandline, role::program, suite::gnu, use::synchronizing Section: vcs Priority: optional Filename: pool/main/t/tla/tla_1.3.5+dfsg-18_amd64.deb Size: 383026 MD5sum: 2e34fa6e47043991bf968f4ae631ce1c SHA1: 71447d826cb54a6c53b32b9b418590a8b48a46ff SHA256: 59e55d5dd9ca5ae6d70d0c6ff9a5d9f838bf196ff559baea1205fb6aa41cd4a3 Package: tla Priority: optional Section: vcs Installed-Size: 932 Maintainer: Debian QA Group packa...@qa.debian.org Architecture: amd64 Version: 1.3.5+dfsg-16 Depends: libc6 (= 2.3), libexpat1 (= 1.95.8), gawk, patch Recommends: tla-doc Suggests: gnupg, ssh Filename: pool/main/t/tla/tla_1.3.5+dfsg-16_amd64.deb Size: 383200 MD5sum: 293e07e53cef4f690cfe7e50d1831185 SHA1: 75ab0f97c5fb77aceaafcd5f7b4cf4c97e8c3a0e SHA256: bf00971e5cbf8163c83c12e6a9aaf243987c22f5852137af3562a8e557f58962 Description-en: GNU Arch revision control system Arch is a modern replacement for CVS, specifically designed for the distributed development. It supports development on branches, distributed repositories, changeset-oriented project management, and of course, file and directory renaming. Tag: devel::rcs, implemented-in::c, interface::commandline, qa::orphaned, role::program, suite::gnu, use::synchronizing ## but ## $ apt-cache showsrc tla Package: tla Binary: tla, tla-doc Version: 1.3.5+dfsg-18 Maintainer: Debian QA Group packa...@qa.debian.org Build-Depends: debhelper (= 7), autotools-dev, time, libexpat1-dev Architecture: any all Standards-Version: 3.9.2 Format: 3.0 (quilt) Files: 5729ed285e021c152b8c8b66ad98407a 1218 tla_1.3.5+dfsg-18.dsc 985debdf20daea547f3e4ef36a7c17cd 3182003 tla_1.3.5+dfsg.orig.tar.gz 65462ae1eb1449728914d42a010f06ec 37401 tla_1.3.5+dfsg-18.debian.tar.gz Checksums-Sha1: 7006faee7b9fc26f11bc4a7ebff21c311300101b 1218 tla_1.3.5+dfsg-18.dsc 0d5ee989801d10b4c98ae2e1d1c7a00a88fd7647 3182003 tla_1.3.5+dfsg.orig.tar.gz c83c34bcd03e366845ab38bce547708bc53a0645 37401 tla_1.3.5+dfsg-18.debian.tar.gz Checksums-Sha256: 9565ea169ad96ab7b413f30e4124d767833662aa6e418483c434bc48d61e07ea 1218 tla_1.3.5+dfsg-18.dsc 64b6dc792074ff8bb2ddf3195901baca34ec5477e394cc5109813d06d9f812ee 3182003 tla_1.3.5+dfsg.orig.tar.gz 701f705125655ac12017428ed0b2973570908109699118df0d323e9b07ecf38e 37401 tla_1.3.5+dfsg-18.debian.tar.gz Package-List: tla deb vcs optional tla-doc deb doc optional Directory: pool/main/t/tla Priority: source Section: vcs Package: tla Binary: tla, tla-doc Version: 1.3.5+dfsg-18 Maintainer: Debian QA Group packa...@qa.debian.org Build-Depends: debhelper (= 7), autotools-dev, time, libexpat1-dev Architecture: any all Standards-Version: 3.9.2 Format: 3.0 (quilt) Files: 5729ed285e021c152b8c8b66ad98407a 1218 tla_1.3.5+dfsg-18.dsc 985debdf20daea547f3e4ef36a7c17cd 3182003 tla_1.3.5+dfsg.orig.tar.gz 65462ae1eb1449728914d42a010f06ec 37401 tla_1.3.5+dfsg-18.debian.tar.gz Checksums-Sha1: 7006faee7b9fc26f11bc4a7ebff21c311300101b 1218 tla_1.3.5+dfsg-18.dsc 0d5ee989801d10b4c98ae2e1d1c7a00a88fd7647 3182003 tla_1.3.5+dfsg.orig.tar.gz c83c34bcd03e366845ab38bce547708bc53a0645 37401 tla_1.3.5+dfsg-18.debian.tar.gz Checksums-Sha256: 9565ea169ad96ab7b413f30e4124d767833662aa6e418483c434bc48d61e07ea 1218 tla_1.3.5+dfsg-18.dsc 64b6dc792074ff8bb2ddf3195901baca34ec5477e394cc5109813d06d9f812ee 3182003 tla_1.3.5+dfsg.orig.tar.gz
Bug#733414: texlive-base: fails to build from source on stable
On Mon, 6 Jan 2014, Norbert Preining wrote: tags 733414 + pending thanks This source package, currently only in unstable, fails to build from source on stable. The build ends with: git commit 949761d tightens the build-dep to = 4, which is needed. Tagging the bug as pending Hi Norbert, Thank you very much for replying. I'll try it with tex-common 4.04 in unstable. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733414: texlive-base: fails to build from source on stable
Source: texlive-base Version: 2013.20131219-1 Severity: normal This source package, currently only in unstable, fails to build from source on stable. The build ends with: dh_installdocs -p texlive-base README readme-txt.dir readme-html.dir debian/CHANGES.packaging # nasty trick # mptopdf needs a dump, but is a link to a script # we have to trick dh_installtex to accept it mv debian/texlive-latex-base/usr/bin/mptopdf\ debian/texlive-latex-base/usr/bin/mptopdf.bck ln -s pdftex debian/texlive-latex-base/usr/bin/mptopdf dh_installtex -Ntexlive-base -A --priority=10 \ -Ntexlive -Ntexlive-full\ --flavor=lsr:full,tree:texlive ln: failed to create symbolic link `debian/texlive-latex-base/usr/bin/mptopdf': File exists dh_installtex: ln -s pdftex debian/texlive-latex-base/usr/bin/mptopdf returned exit code 1 make: *** [binary-indep] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed The complete build log is attached. I haven't tried to debug it, but if you have no idea what the problem has, I can do so. In that events, debugging tips would be apprecicated. I've omitted information about my TeX installation since is does not seem relevant, but you want I can add it. Regards, Faheem -- Package-specific info: IMPORTANT INFORMATION: We will only consider bug reports concerning the packaging of TeX Live as relevant. If you have problems with combination of packages in a LaTeX document, please consult your local TeX User Group, the comp.text.tex user group, the author of the original .sty file, or any other help resource. *** The Debian TeX Team is *no* LaTeX Help Desk *** If you report an error when running one of the TeX-related binaries (latex, pdftex, metafont,...), or if the bug is related to bad or wrong output, please include a MINIMAL example input file that produces the error in your report. Please run your example with (pdf)latex -recorder ... (or any other program that supports -recorder) and send us the generated file with the extension .fls, it lists all the files loaded during the run and can easily explain problems induced by outdated files in your home directory. Don't forget to also include minimal examples of other files that are needed, e.g. bibtex databases. Often it also helps to include the logfile. Please, never send included pictures! If your example file isn't short or produces more than one page of output (except when multiple pages are needed to show the problem), you can probably minimize it further. Instructions on how to do that can be found at http://www.minimalbeispiel.de/mini-en.html (english) http://www.minimalbeispiel.de/mini.html (german) ## minimal input file ## other files ## List of ls-R files -rw-r--r-- 1 root root 1373 Nov 21 02:49 /var/lib/texmf/ls-R lrwxrwxrwx 1 root root 29 Jan 10 2013 /usr/share/texmf/ls-R - /var/lib/texmf/ls-R-TEXMFMAIN lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf/ls-R - /var/lib/texmf/ls-R-TEXLIVEMAIN lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf-dist/ls-R - /var/lib/texmf/ls-R-TEXLIVEDIST lrwxrwxrwx 1 root root 31 Oct 3 2012 /usr/share/texlive/texmf/ls-R - /var/lib/texmf/ls-R-TEXLIVEMAIN ## Config files -rw-r--r-- 1 root root 475 Aug 1 05:45 /etc/texmf/web2c/texmf.cnf -rw-r--r-- 1 root root 4745 Nov 21 02:49 /var/lib/texmf/web2c/fmtutil.cnf lrwxrwxrwx 1 root root 32 Oct 3 2012 /usr/share/texmf/web2c/updmap.cfg - /var/lib/texmf/updmap.cfg-DEBIAN -rw-r--r-- 1 root root 3245 Nov 21 02:49 /var/lib/texmf/tex/generic/config/language.dat ## Files in /etc/texmf/web2c/ total 8 -rw-r--r-- 1 root root 283 Jan 10 2013 mktex.cnf -rw-r--r-- 1 root root 475 Aug 1 05:45 texmf.cnf ## md5sums of texmf.d ca40c66f144b4bafc3e59a2dd32ecb9c /etc/texmf/texmf.d/00debian.cnf -- System Information: Debian Release: 7.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 tex-common depends on: ii debconf [debconf-2.0] 1.5.49 ii dpkg 1.16.12 ii ucf3.0025+nmu3 Versions of packages tex-common suggests: ii debhelper 9.20120909 Versions of packages texlive-base is related to: ii
Bug#731623: mercurial: recent change in debian/rules causes error on repeated builds
Package: mercurial Version: 2.8.1-1 Severity: normal Tags: patch In rev 10223 of svn://anonscm.debian.org/python-apps/packages/mercurial/trunk/debian i.e. r10223 | mithrandi | 2013-12-06 04:44:57 +0530 (Fri, 06 Dec 2013) | 1 line Changed paths: M /packages/mercurial/trunk/debian/changelog M /packages/mercurial/trunk/debian/rules Remove pyflakes test to avoid build failures when pyflakes is installed. there is the following change Index: rules === --- rules (revision 10222) +++ rules (revision 10223) @@ -94,6 +94,10 @@ mv mercurial/__version__.py.save mercurial/__version__.py $(RM) -rv tmp/ +override_dh_clean: + dh_clean + rm tests/test-check-pyflakes.t + mercurial/__version__.py: @echo $@ is missing (you probably call 'make clean' directly). @echo Restore it from sources before building the package The rm tests/test-check-pyflakes.t breaks repeated builds for me here, specifically `debuild clean`. Obvious comment: rm returns an error if the file it is asked to remove does not exist, and once it has been removed, it is not going to be restored. Changing this to rm -f tests/test-check-pyflakes.t Fixes it for me. Regards, Faheem -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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#731623: mercurial: recent change in debian/rules causes error on repeated builds
On Sat, 7 Dec 2013, Faheem Mitha wrote: The rm tests/test-check-pyflakes.t breaks repeated builds for me here, specifically `debuild clean`. Obvious comment: rm returns an error if the file it is asked to remove does not exist, and once it has been removed, it is not going to be restored. Changing this to rm -f tests/test-check-pyflakes.t Fixes it for me. On second thoughts, maybe patching out that file would be a cleaner solution. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731623: mercurial: recent change in debian/rules causes error on repeated builds
On Sun, 8 Dec 2013, Faheem Mitha wrote: On Sat, 7 Dec 2013, Faheem Mitha wrote: The rm tests/test-check-pyflakes.t breaks repeated builds for me here, specifically `debuild clean`. Obvious comment: rm returns an error if the file it is asked to remove does not exist, and once it has been removed, it is not going to be restored. Changing this to rm -f tests/test-check-pyflakes.t Fixes it for me. On second thoughts, maybe patching out that file would be a cleaner solution. #debian-mentors disagrees. They suggested two alternative slight modifications to your version. override_dh_clean: dh_clean tests/test-check-pyflakes.t or perhaps better, just add tests/test-check-pyflakes.t in debian/clean Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729153: mercurial: fails to build from source on stable.
On Fri, 22 Nov 2013, Faheem Mitha wrote: On looking at this more closely, I see the problem. As you can see from the error message, the errors occur at the lines # Move templates and help installed by setup.py to their FHS-correct location mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help $(CURDIR)/debian/mercurial-common/usr/share/mercurial mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/locale $(CURDIR)/debian/mercurial-common/usr/share On my system I have both python 2.6 and 2.7 installed. So I have two directories under debian/mercurial-common/usr/lib, namely 'python2.6' and 'python2.7', faheem@orwell:/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib$ ls python2.6 python2.7 Ok, so given that this is the case, the problem is obvious. Because of the wild card, each of these commands runs twice, for each version of python, and presumably tries to copy the same files each time. So, it fails the second time because the files are already there. I looked at the packaging for mercurial 2.7.2, and those lines were not there. So I guess they were added recently. It looks to me like they are buggy. The attached patch fixes this for me. I'm not guaranteeing that it is correct, of course. Regards, Faheemdiff -r 28fe2be2eabb rules --- a/rules +++ b/rules @@ -8,6 +8,7 @@ dh $@ --with python2,bash-completion PYVERS=$(shell pyversions -vs) +DEFAULT_PYVER=$(shell pyversions -dv) DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH) override_dh_auto_build: @@ -77,8 +78,8 @@ debian/cacerts.hgrc \ $(CURDIR)/debian/mercurial-common/etc/mercurial/hgrc.d/cacerts.rc # Move templates and help installed by setup.py to their FHS-correct location - mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help $(CURDIR)/debian/mercurial-common/usr/share/mercurial - mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/locale $(CURDIR)/debian/mercurial-common/usr/share + mv $(CURDIR)/debian/mercurial-common/usr/lib/python$(DEFAULT_PYVER)/dist-packages/mercurial/templates $(CURDIR)/debian/mercurial-common/usr/lib/python$(DEFAULT_PYVER)/dist-packages/mercurial/help $(CURDIR)/debian/mercurial-common/usr/share/mercurial + mv $(CURDIR)/debian/mercurial-common/usr/lib/python$(DEFAULT_PYVER)/dist-packages/mercurial/locale $(CURDIR)/debian/mercurial-common/usr/share # remove arch-dependent python stuff find debian/mercurial-common/usr/lib \ -name '*.so' ! -type d -delete , \
Bug#729153: mercurial: fails to build from source on stable.
On Sun, 17 Nov 2013, Javi Merino wrote: control: tags -1 + moreinfo control: severity -1 minor 2013/11/17 Javi Merino vi...@debian.org: I've just done this in a wheezy chroot: apt-get source -t sid mercurial cd mercurial-2.8/ dch --bpo debuild -us -uc And it built mercurial_2.8-2~bpo70+1_amd64.deb and mercurial-common_2.8-2~bpo70+1_all.deb that install and seem to work fine in wheezy. So I don't know what you're doing, all I can say is that it works for me. On looking at this more closely, I see the problem. As you can see from the error message, the errors occur at the lines # Move templates and help installed by setup.py to their FHS-correct location mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help $(CURDIR)/debian/mercurial-common/usr/share/mercurial mv $(CURDIR)/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/locale $(CURDIR)/debian/mercurial-common/usr/share On my system I have both python 2.6 and 2.7 installed. So I have two directories under debian/mercurial-common/usr/lib, namely 'python2.6' and 'python2.7', faheem@orwell:/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib$ ls python2.6 python2.7 Ok, so given that this is the case, the problem is obvious. Because of the wild card, each of these commands runs twice, for each version of python, and presumably tries to copy the same files each time. So, it fails the second time because the files are already there. I looked at the packaging for mercurial 2.7.2, and those lines were not there. So I guess they were added recently. It looks to me like they are buggy. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729153: mercurial: fails to build from source on stable.
On Sun, 17 Nov 2013, Javi Merino wrote: On Sat, Nov 09, 2013 at 10:03:40PM +0530, Faheem Mitha wrote: Package: mercurial Version: 2.8-1 Severity: normal Hi. I tried to rebuild 2.8 from source as stable as I usually do. I comment out the override_dh_auto_test: stanza because the tests often fail, but otherwise don't change anything. You could do DEB_BUILD_OPTIONS=nocheck instead. Anyway, the testsuite should pass, it always passes in my computer and only fails in some slow buildds. Thanks for the tip. I got # Move templates and help installed by setup.py to their FHS-correct location mv /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial mv: cannot move `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/templates' to `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/templates': Directory not empty mv: cannot move `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/help' to `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/help': Directory not empty make[2]: *** [install-archindep] Error 1 make[2]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8' make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed I'm not sure why this is happening, and haven't really investigated it. Any ideas? What command do you use to build it? 2.8-1 and 2.8-2 build fine on my machine and on the buildds, the only current failure are a couple of timeouts in the testsuite in mips. debuild -uc -us Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729153: still getting this error
Getting the same error with 2.8-2. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729153: mercurial: fails to build from source on stable.
Package: mercurial Version: 2.8-1 Severity: normal Hi. I tried to rebuild 2.8 from source as stable as I usually do. I comment out the override_dh_auto_test: stanza because the tests often fail, but otherwise don't change anything. I got # Move templates and help installed by setup.py to their FHS-correct location mv /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/templates /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python*/dist-packages/mercurial/help /usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial mv: cannot move `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/templates' to `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/templates': Directory not empty mv: cannot move `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/lib/python2.7/dist-packages/mercurial/help' to `/usr/local/src/mercurial/mercurial-2.8/debian/mercurial-common/usr/share/mercurial/help': Directory not empty make[2]: *** [install-archindep] Error 1 make[2]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8' make[1]: *** [override_dh_install] Error 2 make[1]: Leaving directory `/usr/local/src/mercurial/mercurial-2.8' make: *** [binary] Error 2 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 debuild: fatal error at line 1357: dpkg-buildpackage -rfakeroot -D -us -uc failed I'm not sure why this is happening, and haven't really investigated it. Any ideas? Regards, Faheem -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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#726613: mercurial wheezy backport has incorrect libc6 dependency
Package: mercurial Version: 2.7.2-1~bpo70+1 Severity: normal Currently, I see the mercurial wheezy backport is 2.7.2-1~bpo70+1 0 100 http://debian.lcs.mit.edu/debian/ wheezy-backports/main amd64 Packages and `apt-cache show` gives Package: mercurial Version: 2.7.2-1~bpo70+1 Installed-Size: 236 Maintainer: Python Applications Packaging Team python-apps-t...@lists.alioth.debian.org Architecture: amd64 Depends: libc6 (= 2.14), python (= 2.7), python ( 2.8), ucf (= 2.0020), mercurial-common (= 2.7.2-1~bpo70+1) But the version of libc6 in wheezy is *** 2.13-38 0 500 http://debian.lcs.mit.edu/debian/ wheezy/main amd64 Packages 100 /var/lib/dpkg/status and indeed this version does not install on my wheezy system. It looks to me like this was somehow compiled against the wrong version of libc6. Regards, Faheem -- System Information: Debian Release: 7.2 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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#609047: ccl-ffigen_1.2-1_amd64.changes REJECTED
Hi, I don't mean to be impatient, but would it be possible for the FTP Master team to make a call on this, please? It does not seem like *so* difficult a technical issue. Thanks, Faheem On Wed, 11 Sep 2013, Faheem Mitha wrote: On Tue, 9 Apr 2013, Luca Falavigna wrote: Hi, sorry, but we do not think introducing a convenience copy of gcc is a good thing. Also, the 4.0 sources contain files licensed under GFDL with invariant sections, which are not suitable for main. Please try to build your code using existing gcc versions in the archive implementing Built-Using field. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. Extremely belated reply to this message, I've been busy. But if I waited for a good time, this might never be answered. I think the package was rejected based on a misunderstanding. As described at https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default this package exists to build CCL's interface databases. As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI is Foreign Function Interface) To support its FFI, CCL maintains a binary database of information about classes, methods, functions, types, and variables available from foreign libraries in several .cdb files. You will need to generate this information for your particular library. In order to do this, you will need to obtain and build ffigen4. This has little or nothing to do with GCC per se. It is *not* a fork. Basically, it uses the GCC frontend for a purpose that is presumably sufficiently similar to conventional compilation to enable a compiler frontend to be used., namely building .cdb files which reflect the C API of some .h files. I'm fuzzy about the details myself. Anyway, getting it to build the code using existing versions of GCC in the archive would be impracticably difficult for a non-expert. (For the record, getting CCL to build correctly and in particular build the interface databases in question was quite hair-raisingly difficult enough.) If you doubt me, look at the 'source' subdirectory in the ffigen tarball, which has the patches against gcc 4.0, and tell me if you understand what they do. I doubt even the main CCL developers would attempt it. They farmed out the job to someone else years ago, who used the then-current GCC compiler to get this to work. I could dig up more details, and talk to the CCL developers themselves (who are usually grumpy and not particularly sympathetic towards Debian, however) if you really need further clarification. I'm including the ffigen README below, which adds some details and history. As for the documentation thing, I guess I could just strip out the doc/FDL files from the tarball? Regards, Faheem. ### # $Log$ # Revision 1.2 2005/08/10 05:05:46 gb # Updated. # # Revision 1.1 2005/04/08 07:03:16 gb # New file. # 'ffigen' is a modified version of the GCC backend, based on similar modifications to the 'LCC' compiler described at: http://www.ccs.neu.edu/home/lth/ffigen/index.html It's a work derived from GCC, and therefore licensed under the GPL. Versions of ffigen - based on GCC 2.95 sources - were distributed as adjunct components of OpenMCL in 2001 and 2002. It's become increasingly difficult to use those versions, since they're sensitive to the exact format of the 2.95 C preprocessor output (and since GCC 2.95 is fading into obsolescence.) The source distributions consisted of a set of patches (relative to a canonical 2.95 source tree) and a README file that explained the build process. In the summer of 2004, Helmut Eller made available a set of patches relative to GCC 3.4.1. (Unlike previous versions, GCC 3.x's preprocessor and frontend are a single program, so an ffigen program derived from GCC 3 is likely to be a little more self-contained than earlier versions.) This version is based on GCC 4.0, builds on Helmut's work, and adds some initial support for translating Objective-C class and method information. In addition, it provides a heavily conditionalized Makefile which builds a binary package (.tar.gz file) on both LinuxPPC and DarwinPPC. In order to build the program, it's necessary to obtain canonical versions of GCC (with ObjC support) for the target platform; the Makefile tersely explains what's missing and suggests where to find it. You need to obtain the following files from gcc.gnu.org or a mirror site and install them in this directory: gcc-core-4.0.0.tar.bz2 gcc-objc-4.0.0.tar.bz2 Once those archives are installed, doing: shell make will build the modified frontend, create an archive containing that frontend and related support files, and create a text file explaining
Bug#724854: apt: incorrect warning about unmet dependencies with virtual package
Package: apt Version: 0.9.7.9 Severity: normal On wheezy amd64, I'm getting: faheem@orwell:~$ sudo apt-get install libjpeg62-dev libtiff4-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libtiff4-dev : Depends: libjpeg-dev E: Unable to correct problems, you have held broken packages. It is fairly obvious what the problem is. libtiff4-dev depends on the virtual package libjpeg-dev, which is currently provided by the installed libjpeg8-dev. faheem@orwell:~$ sudo apt-get install libjpeg-dev Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libjpeg8-dev' instead of 'libjpeg-dev' libjpeg8-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. However, libjpeg62-dev also provides libjpeg-dev. When installing libjpeg62-dev, libjpeg8-dev is removed. faheem@orwell:~$ sudo apt-get install libjpeg62-dev Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libjpeg62 The following packages will be REMOVED: libjpeg8-dev r-base-dev The following NEW packages will be installed: libjpeg62 libjpeg62-dev 0 upgraded, 2 newly installed, 2 to remove and 0 not upgraded. Need to get 298 kB of archives. After this operation, 78.8 kB of additional disk space will be used. Do you want to continue [Y/n]? So, we are trying to install package A which depends on virtual package V, which is provides by the installed package V1. However, we are simultaneously trying to install package V2 which also provides V. In a nutshell, sudo apt-get install A V2 is what is giving the error. This odd combination presumably confuses apt, but there is no error here as such. This may be a duplicate of a known problem. I saw a couple of bugs that look kind of similar, but I'm not sure. If so, please merge as appropriate. Thanks. Regards, Faheem -- Package-specific info: -- apt-config dump -- APT ; APT::Architecture amd64; APT::Build-Essential ; APT::Build-Essential:: build-essential; APT::Install-Recommends 1; APT::Install-Suggests 0; APT::Authentication ; APT::Authentication::TrustCDROM true; APT::NeverAutoRemove ; APT::NeverAutoRemove:: ^firmware-linux.*; APT::NeverAutoRemove:: ^linux-firmware$; APT::NeverAutoRemove:: ^linux-image.*; APT::NeverAutoRemove:: ^kfreebsd-image.*; APT::NeverAutoRemove:: ^linux-restricted-modules.*; APT::NeverAutoRemove:: ^linux-ubuntu-modules-.*; APT::NeverAutoRemove:: ^gnumach$; APT::NeverAutoRemove:: ^gnumach-image.*; APT::Never-MarkAuto-Sections ; APT::Never-MarkAuto-Sections:: metapackages; APT::Never-MarkAuto-Sections:: restricted/metapackages; APT::Never-MarkAuto-Sections:: universe/metapackages; APT::Never-MarkAuto-Sections:: multiverse/metapackages; APT::Never-MarkAuto-Sections:: oldlibs; APT::Never-MarkAuto-Sections:: restricted/oldlibs; APT::Never-MarkAuto-Sections:: universe/oldlibs; APT::Never-MarkAuto-Sections:: multiverse/oldlibs; APT::Update ; APT::Update::Post-Invoke-Success ; APT::Update::Post-Invoke-Success:: test -x /usr/bin/apt-show-versions || exit 0 ; apt-show-versions -i; APT::Architectures ; APT::Architectures:: amd64; APT::Architectures:: i386; APT::Compressor ; APT::Compressor::. ; APT::Compressor::.::Name .; APT::Compressor::.::Extension ; APT::Compressor::.::Binary ; APT::Compressor::.::Cost 1; APT::Compressor::gzip ; APT::Compressor::gzip::Name gzip; APT::Compressor::gzip::Extension .gz; APT::Compressor::gzip::Binary gzip; APT::Compressor::gzip::Cost 2; APT::Compressor::gzip::CompressArg ; APT::Compressor::gzip::CompressArg:: -9n; APT::Compressor::gzip::UncompressArg ; APT::Compressor::gzip::UncompressArg:: -d; APT::Compressor::bzip2 ; APT::Compressor::bzip2::Name bzip2; APT::Compressor::bzip2::Extension .bz2; APT::Compressor::bzip2::Binary bzip2; APT::Compressor::bzip2::Cost 3; APT::Compressor::bzip2::CompressArg ; APT::Compressor::bzip2::CompressArg:: -9; APT::Compressor::bzip2::UncompressArg ; APT::Compressor::bzip2::UncompressArg:: -d; APT::Compressor::xz ; APT::Compressor::xz::Name xz; APT::Compressor::xz::Extension .xz; APT::Compressor::xz::Binary xz; APT::Compressor::xz::Cost 4; APT::Compressor::xz::CompressArg ; APT::Compressor::xz::CompressArg:: -6; APT::Compressor::xz::UncompressArg ; APT::Compressor::xz::UncompressArg:: -d; APT::Compressor::lzma ; APT::Compressor::lzma::Name lzma; APT::Compressor::lzma::Extension .lzma;
Bug#724854: apt: incorrect warning about unmet dependencies with virtual package
On Sat, 28 Sep 2013, David Kalnischkies wrote: Hi Faheem, On Sat, Sep 28, 2013 at 8:53 PM, Faheem Mitha fah...@faheem.info wrote: On wheezy amd64, I'm getting: faheem@orwell:~$ sudo apt-get install libjpeg62-dev libtiff4-dev Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libtiff4-dev : Depends: libjpeg-dev E: Unable to correct problems, you have held broken packages. It is fairly obvious what the problem is. libtiff4-dev depends on the virtual package libjpeg-dev, which is currently provided by the installed libjpeg8-dev. faheem@orwell:~$ sudo apt-get install libjpeg-dev Reading package lists... Done Building dependency tree Reading state information... Done Note, selecting 'libjpeg8-dev' instead of 'libjpeg-dev' libjpeg8-dev is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. However, libjpeg62-dev also provides libjpeg-dev. When installing libjpeg62-dev, libjpeg8-dev is removed. Sorry, but you lost me here. apt-cache show libjpeg62-dev/stable libjpeg8-dev/stable | grep -e '^Package:' -e 'Provides:' Package: libjpeg62-dev Package: libjpeg8-dev Provides: libjpeg-dev So, libjpeg62-dev isn't providing libjpeg-dev in stable – and also not in testing or unstable. You're right, this was in squeeze. (It is also why apt-get is automatically deciding that you mean libjpeg8-dev as it is the only provider, if there would be more, you would need to choose) Right. Also, libjpeg8-dev conflicts with libjpeg62-dev, so they can't co-exist - your first install request is indeed an impossible situation. Ok, so it wasn't a bug after all. Sorry for the noise. Please close it. Sorry. Regards, Faheem
Bug#609047: update on CCL packaging status (resent)
On Wed, 11 Sep 2013, Faré wrote: : Faheem Mitha The main outstanding thing that (probably) should be fixed before the CCL package itself is ready to be submitted to NEW is to remove the local copy of ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I think at least Christoph Egger suggested this, and it is clearly a good idea. That's a totally crazy thing to do, of the kind of horror that was necessary in the days of ASDF 1. Please don't do it. If Christoph suggested it, he might have been traumatized in those days. Please let CCL come with its own ASDF 3, or maybe ASDF 2, if you're packaging the CCL release rather than trunk. ASDF 3 is a big boy, and will upgrade itself to the version from debian, if available, and will know how NOT to downgrade itself, thank you. Hi Faré. Sorry, I did not mean to distress you. I'm ccing Christoph and Peter in case they have comments. My reasons for suggesting this is that it is in line with Debian policy.that says you should not have local copies of libraries already in the Debian archives. Yes, I'd be packaging the release. Can you elaborate on the reasons why looking to an external ASDF is not a good idea? I assume that having multiple versions of ASDF in the archive is Ok. This is done for lots of other packages. In any case, the ftp masters will need to be ok with this. Christoph/Peter/anybody, comments? Regards, Faheem
Bug#609047: update on CCL packaging status (resent)
Hi Faré, Sorry to put you to the trouble of having to explain this again. I'm sure you have had to do it before. On Wed, 11 Sep 2013, Faré wrote: Can you elaborate on the reasons why looking to an external ASDF is not a good idea? I assume that having multiple versions of ASDF in the archive is Ok. This is done for lots of other packages. For the horror of ASDF1 days and its upgrade strategy, see http://fare.livejournal.com/149264.html The issue is: when an implementation comes with an updated version of ASDF that it depends on, then the packager of that implementation must update the ASDF package in debian, and make sure it works with all other packaged implementations. Oops. Now you have an expensive coordination problem. And if any implementation depends on patches that didn't make it to an ASDF release yet, you're really screwed. Also, now that ASDF 3 includes its own mechanism for self-upgrade and avoiding self-downgrade, and will automatically look at the debian-provided version if available (and unless told not to), you don't gain much, if at all, by doing these complex packaging tricks. Any time that your packaging tricks would have helped, ASDF 3 will already bring the same benefits at the tiny cost of loading an extra FASL for the newer ASDF. And then there are the times when the tricks come back to bite you in the ass, so let just ASDF 3 sort it out. In the bad old days of ASDF 1, few implementations shipped with ASDF, and those that did usually sported an obsolete version. Special packaging tricks for ASDF were not just useful, but necessary. These days are happily long gone. Ok. I don't really understand the details, and I don't have a problem with an internal ASDF. But just to play devil's advocate, it is possible to have multiple versions of ASDF installed simultaneously, right? And is it common (or is there even an actual known case) of an implementation depending on a patched ASDF? Or even being very sensitive to the particular ASDF version? In any case, the ftp masters will need to be ok with this. I don't see why not. ASDF needn't count as a library. Plus it's relatively small (depending on the implementation, the order of magnitude of the installed copy is 1MB), and copied only once per implementation, of which there are but a handful (in debian: sbcl, clisp, ecl, now ccl, formerly gcl). Ok. I don't personally care, but if the ftp masters object (assuming that the CCL package actually gets to the point of being reviewed by them), then is it Ok if I point them to you? BTW, the current status as you can see on the 609047 bug thread, is that the ccl-ffigen package, which is used to build the interface databases for CCL, was rejected by the ftpmasters as it was a copy of GCC, or something. This happened in April, but I only just got around to writing a response. You can see the email in the bug thread. If I get around to updating the package to the current CCL, would you be willing to test it? The only debian-packaged common lisp that doesn't work well with ASDF 3 is GCL, but then again, I believe GCL hasn't been re-packaged in Debian in quite some time. And it's not like it worked that great with ASDF 1, either. Also, it requires an old version of libgmp, if I understand correctly, and sorely needs some re-packaging. PS: it looks like current CCL trunk fails to pre-compile the asdf.lisp it packages. Unless you wait for them to fix that, you may want to do it yourself. Any version of CCL that I package for Debian will be the release. So I guess this is not an issue. Regards, Faheem
Bug#609047: update on CCL packaging status (resent)
On Wed, 11 Sep 2013, Faré wrote: On Wed, Sep 11, 2013 at 2:03 PM, Faheem Mitha fah...@faheem.info wrote: But just to play devil's advocate, it is possible to have multiple versions of ASDF installed simultaneously, right? Depends what you mean by installed, but I'll take it that you mean (a) each installed implementation's precompiled asdf FASL. (b) the source-only code installation (NO precompiled FASL) from the cl-asdf package, to be compiled in each user's personal FASL cache with whatever implementation he uses (if any). These are different enough things that I wouldn't call them multiple versions of ASDF installed simultaneously. And the magic of ASDF 3 is that you, the debian packager, need not do any magic about it anymore, like in the bad old days of ASDF 1. Sorry if I was unclear. I meant multiple cl-asdf Debian packages installed simultaneously, corresponding to different ASDF versions. I.e. option (b). Here I am imagining a world where CL implementations don't have their own private copy of ASDF. If I understand you correctly, (a) corresponds the case where the implementations do have their private implementation. And is it common (or is there even an actual known case) of an implementation depending on a patched ASDF? Or even being very sensitive to the particular ASDF version? It is common for an implementation to depend on a recent enough ASDF, whether patched or not. The ASDF maintainer (previously, me) is usually quick enough to merge patches upstream, though ASDF release can lag a month (or sometimes two) after such patch merge. I've read the second sentence several times, but I don't get it. Merge patches upstream implies there is a downstream. Are there multiple forks of ASDF? Do the implementations develop/modify ASDF themselves? I got the impression they just take some released version of ASDF and stick it in, often only after been told by an ASDF maintainer. Ok. I don't personally care, but if the ftp masters object (assuming that the CCL package actually gets to the point of being reviewed by them), then is it Ok if I point them to you? Of course. Great, thanks. BTW, the current status as you can see on the 609047 bug thread, is that the ccl-ffigen package, which is used to build the interface databases for CCL, was rejected by the ftpmasters as it was a copy of GCC, or something. This happened in April, but I only just got around to writing a response. You can see the email in the bug thread. I saw that. As a fallback, could you just consider the bootstrapped .cdb files as source? Or is the issue due to your trying to build more .cdb files than CCL usually comes with? I'm like 100% sure Debian would not go for shipping the .cdb files from upstream, and I'd have to agree with them there. Anyway, generating the .cdb files is not a problem now, though it was ridiculously hard to get working correctly initially. No, the main issue is just that the ftpmasters don't like copies of libraries (or just software generally) that is already in Debian. And they considered ffigen to contain such a copy of gcc, though the outdated 4.0. In his email, Luca made the ridiculous suggestion that I should update ffigen for versions of gcc currently in Debian. If I get around to updating the package to the current CCL, would you be willing to test it? Most gladly. Are you packaging from trunk or from the latest CCL release? I personally prefer trunk, but I can totally see a case for the release branch. The latest CCL release. I don't think Debian cares, but it seems the more natural thing to do. If it ever actually hits Debian, and enough people want trunk instead, I could switch to trunk. PS: it looks like current CCL trunk fails to pre-compile the asdf.lisp it packages. Unless you wait for them to fix that, you may want to do it yourself. Any version of CCL that I package for Debian will be the release. So I guess this is not an issue. Actually, this is an issue since CCL 1.6, that will hopefully be fixed in trunk soon — see http://trac.clozure.com/ccl/ticket/ So, please make sure you pre-compile ASDF as part of your installation of the CCL. Ok, but I'll need instructions on how to do this. Regards, Faheem
Bug#722420: debbugs: control phrases error out if they start with whitespace
Package: debbugs Severity: normal I just sent the following to cont...@bugs.debian.org retitle 609047 ITP: ccl -- Clozure CL owner 609047 ! thanks This gave the error: ### Processing commands for cont...@bugs.debian.org: retitle 609047 ITP: ccl -- Clozure CL Bug #609047 [wnpp] RFP: ccl -- Clozure CL Changed Bug title to 'ITP: ccl -- Clozure CL' from 'RFP: ccl -- Clozure CL' owner 609047 ! Unknown command or malformed arguments to command. thanks Unknown command or malformed arguments to command. Hi, Unknown command or malformed arguments to command. The current state of this package is reflected in the repositories Unknown command or malformed arguments to command. https://bitbucket.org/faheem/ccl-debian and Unknown command or malformed arguments to command. Too many unknown commands, stopping here. ### It would be better if this worked even with leading spaces - failing that, a useful error message would be nice. Regards, Faheem -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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#609047: update on CCL packaging status (resent)
retitle 609047 ITP: ccl -- Clozure CL owner 609047 ! thanks [Please CC responses to the bug report at 609...@bugs.debian.org] Hi, The current state of this package is reflected in the repositories https://bitbucket.org/faheem/ccl-debian and https://bitbucket.org/faheem/ccl-ffigen-debian The packaging is essentially done. Earlier this year Julien Danjou submitted ccl-ffigen to NEW, (ccl-ffigen is a build dependency on ccl) and it got bounced by someone on the FTP masters team with the following message: Date: Tue, 09 Apr 2013 21:00:37 + From: Luca Falavigna ftpmas...@debian.org To: Debian Common Lisp Team pkg-common-lisp-de...@lists.alioth.debian.org, Faheem Mitha fah...@faheem.info, a...@debian.org Subject: ccl-ffigen_1.2-1_amd64.changes REJECTED Hi, sorry, but we do not think introducing a convenience copy of gcc is a good thing. Also, the 4.0 sources contain files licensed under GFDL with invariant sections, which are not suitable for main. Please try to build your code using existing gcc versions in the archive implementing Built-Using field. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. I think the writer misunderstood the point of the package, which is to build interface headers for ccl, and is pretty much hardwired to 4.0. Getting it to work for more recent versions of GCC is an extremely non-trivial task that I doubt anyone but the author of that code would attempt. I haven't had time to follow up on this, and I expect Julien is similarly busy. So there matters rest for the moment. The main outstanding thing that (probably) should be fixed before the CCL package itself is ready to be submitted to NEW is to remove the local copy of ASDF from CCL and configure CCL to look for the Debian installation of ASDF. I think at least Christoph Egger suggested this, and it is clearly a good idea. Feedback/comments welcome as always. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#609047: ccl-ffigen_1.2-1_amd64.changes REJECTED
On Tue, 9 Apr 2013, Luca Falavigna wrote: Hi, sorry, but we do not think introducing a convenience copy of gcc is a good thing. Also, the 4.0 sources contain files licensed under GFDL with invariant sections, which are not suitable for main. Please try to build your code using existing gcc versions in the archive implementing Built-Using field. Cheers, Luca === Please feel free to respond to this email if you don't understand why your files were rejected, or if you upload new files which address our concerns. Extremely belated reply to this message, I've been busy. But if I waited for a good time, this might never be answered. I think the package was rejected based on a misunderstanding. As described at https://bitbucket.org/faheem/ccl-ffigen-debian/src/tip/README.Debian?at=default this package exists to build CCL's interface databases. As described in http://trac.clozure.com/ccl/wiki/CustomFramework (FFI is Foreign Function Interface) To support its FFI, CCL maintains a binary database of information about classes, methods, functions, types, and variables available from foreign libraries in several .cdb files. You will need to generate this information for your particular library. In order to do this, you will need to obtain and build ffigen4. This has little or nothing to do with GCC per se. It is *not* a fork. Basically, it uses the GCC frontend for a purpose that is presumably sufficiently similar to conventional compilation to enable a compiler frontend to be used., namely building .cdb files which reflect the C API of some .h files. I'm fuzzy about the details myself. Anyway, getting it to build the code using existing versions of GCC in the archive would be impracticably difficult for a non-expert. (For the record, getting CCL to build correctly and in particular build the interface databases in question was quite hair-raisingly difficult enough.) If you doubt me, look at the 'source' subdirectory in the ffigen tarball, which has the patches against gcc 4.0, and tell me if you understand what they do. I doubt even the main CCL developers would attempt it. They farmed out the job to someone else years ago, who used the then-current GCC compiler to get this to work. I could dig up more details, and talk to the CCL developers themselves (who are usually grumpy and not particularly sympathetic towards Debian, however) if you really need further clarification. I'm including the ffigen README below, which adds some details and history. As for the documentation thing, I guess I could just strip out the doc/FDL files from the tarball? Regards, Faheem. ### # $Log$ # Revision 1.2 2005/08/10 05:05:46 gb # Updated. # # Revision 1.1 2005/04/08 07:03:16 gb # New file. # 'ffigen' is a modified version of the GCC backend, based on similar modifications to the 'LCC' compiler described at: http://www.ccs.neu.edu/home/lth/ffigen/index.html It's a work derived from GCC, and therefore licensed under the GPL. Versions of ffigen - based on GCC 2.95 sources - were distributed as adjunct components of OpenMCL in 2001 and 2002. It's become increasingly difficult to use those versions, since they're sensitive to the exact format of the 2.95 C preprocessor output (and since GCC 2.95 is fading into obsolescence.) The source distributions consisted of a set of patches (relative to a canonical 2.95 source tree) and a README file that explained the build process. In the summer of 2004, Helmut Eller made available a set of patches relative to GCC 3.4.1. (Unlike previous versions, GCC 3.x's preprocessor and frontend are a single program, so an ffigen program derived from GCC 3 is likely to be a little more self-contained than earlier versions.) This version is based on GCC 4.0, builds on Helmut's work, and adds some initial support for translating Objective-C class and method information. In addition, it provides a heavily conditionalized Makefile which builds a binary package (.tar.gz file) on both LinuxPPC and DarwinPPC. In order to build the program, it's necessary to obtain canonical versions of GCC (with ObjC support) for the target platform; the Makefile tersely explains what's missing and suggests where to find it. You need to obtain the following files from gcc.gnu.org or a mirror site and install them in this directory: gcc-core-4.0.0.tar.bz2 gcc-objc-4.0.0.tar.bz2 Once those archives are installed, doing: shell make will build the modified frontend, create an archive containing that frontend and related support files, and create a text file explaining how to install things. These patches are maintained in CVS on clozure.com. For anonymous access: shell cvs -d :pserver:c...@clozure.com:/usr/local/publiccvs login [The anonymous CVS password is 'cvs'] shell cvs -d :pserver:c...@clozure.com:/usr/local/publiccvs get ffigen4 -- To
Bug#722155: llvm-toolchain-snapshot: does not clean itself properly
Package: llvm-toolchain-snapshot Version: 1:3.4~svn183914-1 Severity: normal Hi, I tried to rebuild this package on stable. It failed. I tried to rebuild it again, but the package did not clean itself properly. Build log is attached. Probably running debuild -uc -us twice will reproduce this. Regards, Faheem -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dpkg-buildpackage -rfakeroot -D -us -uc dpkg-buildpackage: source package llvm-toolchain-snapshot dpkg-buildpackage: source version 1:3.4~svn183914-1 dpkg-buildpackage: source changed by Sylvestre Ledru sylves...@debian.org dpkg-source --before-build llvm-toolchain-snapshot-3.4~svn183914 dpkg-buildpackage: host architecture amd64 fakeroot debian/rules clean dh clean dh_testdir debian/rules override_dh_auto_clean make[1]: Entering directory `/usr/local/src/clang/llvm-toolchain-snapshot-3.4~svn183914' dh_auto_clean rm -rf build-llvm tools/clang/include/clang/Debian/debian_path.h docs/_build/ tools/clang/docs/_html/ rm -f `ls debian/*.in|sed -e s|.in$||g` find utils -name '*.pyc' | xargs -r rm -f find test -name '*.pyc' -o -name '*.o' -o -name '*.cm[ix]' | xargs -r rm -f rm -f tools/clang tools/polly tools/lldb projects/compiler-rt rm -rf tools/clang/tools/extra make[1]: Leaving directory `/usr/local/src/clang/llvm-toolchain-snapshot-3.4~svn183914' dh_clean dpkg-source -b llvm-toolchain-snapshot-3.4~svn183914 dpkg-source: info: using source format `3.0 (quilt)' dpkg-source: info: building llvm-toolchain-snapshot using existing ./llvm-toolchain-snapshot_3.4~svn183914.orig-clang-tools-extra.tar.bz2 ./llvm-toolchain-snapshot_3.4~svn183914.orig-clang.tar.bz2 ./llvm-toolchain-snapshot_3.4~svn183914.orig-compiler-rt.tar.bz2 ./llvm-toolchain-snapshot_3.4~svn183914.orig-lldb.tar.bz2 ./llvm-toolchain-snapshot_3.4~svn183914.orig-polly.tar.bz2 ./llvm-toolchain-snapshot_3.4~svn183914.orig.tar.bz2 dpkg-source: warning: ignoring deletion of file polly/autoconf/configure.bak dpkg-source: warning: ignoring deletion of file test/Archive/IsNAN.o dpkg-source: warning: ignoring deletion of file test/DebugInfo/Inputs/test-inline.o dpkg-source: warning: ignoring deletion of file test/DebugInfo/Inputs/dwarfdump-test-32bit.elf.o dpkg-source: warning: ignoring deletion of file test/DebugInfo/Inputs/test-parameters.o dpkg-source: warning: file llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/test/modularize/ProblemsDuplicate.modularize has no final newline (either original or modified version) dpkg-source: info: local changes detected, the modified files are: llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/.arcconfig llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/CMakeLists.txt llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/CODE_OWNERS.TXT llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/LICENSE.TXT llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/Makefile llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/README.txt llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverride.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverride.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverrideActions.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverrideActions.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverrideMatchers.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/AddOverride/AddOverrideMatchers.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/CMakeLists.txt llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/CMakeLists.txt llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/FileOverrides.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/FileOverrides.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/IncludeExcludeInfo.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/IncludeExcludeInfo.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/Makefile llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/PerfSupport.cpp llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/PerfSupport.h llvm-toolchain-snapshot-3.4~svn183914/clang/tools/extra/cpp11-migrate/Core/SyntaxCheck.cpp
Bug#721541: qcomicbook: unrar-free does not work with .cbr files
Package: qcomicbook Version: 0.8.2-1 Severity: normal Hi, I had to install unrar from non-free in order to get qcomicbook to work. Therefore, I think recommending unrar-free is perhaps not the right thing to do. Maybe recommend unrar instead? Additionally qcomicbook 0.9 has now been released. Regards, Faheem -- System Information: Debian Release: 7.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (500, 'oldstable'), (50, 'unstable'), (50, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 qcomicbook depends on: ii libc6 2.13-38 ii libgcc1 1:4.7.2-5 ii libpoppler-qt4-3 0.18.4-6 ii libqtcore44:4.8.2+dfsg-11 ii libqtgui4 4:4.8.2+dfsg-11 ii libstdc++64.7.2-5 Versions of packages qcomicbook recommends: ii bzip2 1.0.6-4 ii unace 1.2b-10 ii unrar-free 1:0.0.1+cvs20071127-2 ii unzip 6.0-8 ii zip 3.0-6 Versions of packages qcomicbook suggests: pn rarnone ii unrar 1:4.1.4-1 -- 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#718451: installation-reports: comments about GRUB on LVM over software raid
Package: installation-reports Severity: normal Tags: d-i Dear Maintainer, *** 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 lines *** -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/debian-cd/7.1.0/amd64/iso-cd/debian-7.1.0-amd64-netinst.iso (via Bittorrent) Date: Date and time of the install Machine: Custom machine: ASUS Sabertooth 990FX chipset, AMD FX 6300 Partitions: df -Tl will do; the raw partition table is preferred I don't know how to get the raw partition table. Please Specify. Filesystem Type 1K-blocks Used Available Use% Mounted on rootfs rootfs48057224 5755232 39860776 13% / udev devtmpfs 10240 0 10240 0% /dev tmpfstmpfs 1637004 588 1636416 1% /run /dev/mapper/debian-root ext4 48057224 5755232 39860776 13% / tmpfstmpfs 5120 0 5120 0% /run/lock tmpfstmpfs 3274000 0 3274000 0% /run/shm /dev/mapper/debian-boot ext4959512 36468874304 5% /boot /dev/mapper/debian-data ext3 20642428 10719832 8874020 55% /data /dev/mapper/debian-home ext3 96118540 79467036 11768868 88% /home /dev/mapper/debian-video ext3 206424760 169039648 26899352 87% /home/faheem/video /dev/mapper/backup-local_src ext3 36124288 33363128926152 98% /usr/local/src Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [O] Install boot loader:[E] Overall install:[O] Comments/Problems: Description of the install, in prose, and any thoughts, comments and ideas you had during the initial install. BEGIN COMMENTS This machine is a custom machine that was originally built for me in 2007. This was a amd64 capable machine, but which I had installed i386 on in 2007. The motherboard died, and so the MB, processor, and memory had to be replaced. The hard drives actually worked with the new hardware with only minor adjustments for the ethernet and display cards due to them having changed their location information. However, I decided to reinstall because at the time the machine died, it was running squeeze, and wheezy has come out shortly before. I could not do an upgrade because I had decided to switch to amd64, partly because the machine now had 16GB of memory after the new hardware was put in. Therefore, the harddisks had prexisting sw raid and lvm devices at the time of the installation. I just enabled them. The install went smoothly for the most part. The main issue was with GRUB 2. During the install, when the installer asked to install GRUB to a device, I inadvertantly pressed enter without entering a device, but it went ahead and ran anyway, leaving me wondering what it was doing. SUGGESTION: Say what grub-install does if no device is given and enter is pressed. On an earlier occasion, I had successfully used grml to install GRUB 2 to a raid device by chrooting my system and then doing grub-install /dev/md0 or possibly md1. After the GRUB install ran with empty device, I tried entering /dev/md0, and /dev/md1, and both of these gave me an error. At this point I was not sure to do, and exited, which was probably a mistake. When I rebooted the machine was unbootable, unsurprisingly. I then went to the rescue mode in the GRUB installer. When I tried grub-install /dev/md0 and grub-install /dev/md1 I got a segmentation fault. Then I tried grub-install /dev/hda and grub-install /dev/hdb which fixed the problem. The machine booted into the new system, but my passwords did not work. Maybe the rescue mode overwrote something, I dunno. So I ran the installer from scratch a second time. This time. I entered the device /dev/sda and then went back a second time and entered /dev/sdb. Then the installation completed successfully, and I was able to boot and log into the new system. COMMENT: One oddity I noticed is that while running grub-install, the installer popped up a window asking to install the wheezy netinst cd, which was already in the drive. Hitting Ok didn't make the window go away.
Bug#717001: lintian appears to exit with error message, probably perl related, on squeeze
On Mon, 15 Jul 2013, Niels Thykier wrote: Control: retitle -1 lintian: 2.5.14 not supported on Squeeze Control: tags -1 confirmed wontfix On 2013-07-15 23:06, Faheem Mitha wrote: Package: lintian Version: 2.5.14 Severity: minor Hi, I'm aware that squeeze is no longer stable, and therefore probably not supported. Regardless, I just installed 2.5.14 on squeeze. It installed without error, but appears to exit with an error message, see below. Indeed, all the code for supporting Squeeze has been removed in 2.5.14, so it will generally not work. Oldstable is currently not a requirement for Lintian and I am not willing to actively maintain it myself at the moment. If you are interested in maintaining a squeeze backport, you are more than welcome to do so. I will gladly help you get started and you are welcome to maintain this backport as a branch in the lintian git repository. At the moment, the Lintian codebase is probably still mostly compatible with Squeeze. I have attached 4 patches you definitely want to carry if you are rebuilding Lintian for Squeeze[1]. Mind you, the codebase may still need a bit of fix up beyond these patches. The error in question refers to the line STDOUT-autoflush; I suspect, you can fix this by adding a use FileHandle; to frontend/lintian. If that fails, you can replace the line with (I believe) $| = 1;. Since the dependencies were satisfied, this may reflect some versioning issue. Regards, Faheem [...] Yes, we deliberately removed that versioning since it was satisfied in stable (see the 0002-patch). Also, without the other patches listed above/attached, the versioning is meaningless as Lintian would still be broken (even with its old dependencies satisfied). ~Niels [1] Admittedly, the patches are based on the current master branch rather than the current release, so they may apply with fuzz or not at all against the source of 2.5.14. Hi Niels, Thanks very much for going to the trouble of such a detailed response. Often, people don't bother to reply at all to issues. I don't plan to maintain a squeeze backport, nor am I suggesting the lintian maintainers do so. I just haven't got around to upgrading to the current stable yet, and I thought the error might be of interest/use. Apparently not. Sorry for troubling you. I suggest just closing this bug - there is little point in leaving it open. Regards, Faheem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
