Bug#384346: bug with xfig 1:3.2.5-alpha5-7 - fonts seriously broken
Package: xfig Version: 1:3.2.5-alpha5-8 Followup-For: Bug #384346 On Sept 24, Roland Rosenfeld stated that he could not reproduce this bug and therefore cannot find a solution for it. I am experiencing a similar bug. If I start xfig and attempt to place a text object in a drawing, xfig generates an error message saying Can't find -*-times-medium-r-normal--13-*-*-*-*-*-ISO8859-*, using 6x13 All fonts in existing drawings are replaced with 6x13 as well. This is on a fresh system which I've just installed with testing. This problem is related to the fact that -*-times-medium-r-normal--13-*-*-*-*-*-ISO8859-* is not available on this system. This seems therefore to be due to a missing dependency for the xfig package. I am far from an expert in X11 fonts - can you suggest how to discover what package provides the that font? Regards, Mike Miller These font packages are installed: [EMAIL PROTECTED]:~\> dpkg --get-selections \*fonts\* gsfonts install gsfonts-x11 install msttcorefonts install texlive-fonts-extra install texlive-fonts-recommended install ttf-sjfonts install xfonts-100dpi install xfonts-75dpiinstall xfonts-base install xfonts-encodingsinstall xfonts-scalable install xfonts-utilsinstall [EMAIL PROTECTED]:~\> dpkg --get-selections \*defom\* defoma install My font paths in /etc/X11/xorg.conf is Section "Files" FontPath"/usr/share/fonts/X11/misc" FontPath"/usr/X11R6/lib/X11/fonts/misc" FontPath"/usr/share/fonts/X11/cyrillic" FontPath"/usr/X11R6/lib/X11/fonts/cyrillic" FontPath"/usr/share/fonts/X11/100dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/100dpi/:unscaled" FontPath"/usr/share/fonts/X11/75dpi/:unscaled" FontPath"/usr/X11R6/lib/X11/fonts/75dpi/:unscaled" FontPath"/usr/share/fonts/X11/Type1" FontPath"/usr/X11R6/lib/X11/fonts/Type1" FontPath"/usr/share/fonts/X11/100dpi" FontPath"/usr/X11R6/lib/X11/fonts/100dpi" FontPath"/usr/share/fonts/X11/75dpi" FontPath"/usr/X11R6/lib/X11/fonts/75dpi" # path to defoma fonts FontPath"/var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType" EndSection -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.17-2-686 Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages xfig depends on: ii libc6 2.3.6.ds1-4 GNU C Library: Shared libraries ii libjpeg62 6b-13The Independent JPEG Group's JPEG ii libpng12-0 1.2.8rel-5.2 PNG library - runtime ii libx11-62:1.0.0-9X11 client-side library ii libxi6 1:1.0.1-3X11 Input extension library ii libxpm4 1:3.5.5-2X11 pixmap library ii libxt6 1:1.0.2-2X11 toolkit intrinsics library ii xaw3dg 1.5+E-14 Xaw3d widget set Versions of packages xfig recommends: ii transfig1:3.2.5-alpha7-5 Utilities for converting XFig figu ii xfig-libs 1:3.2.5-alpha5-7 XFig image libraries and examples -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#732440: ghostscript: Error: /typecheck in /findfont with fonts-font-awesome installed
Control: tags -1 + patch
Fixed in upstream git now [1], patch adapted and included inline below
applies cleanly to the current Debian package and works there as well.
Please consider applying this patch to the next source update, otherwise
will be fixed in ghostscript 9.11 when that is released.
>From f4584b0e162a96ec143f0057de63c116e649e02b Mon Sep 17 00:00:00 2001
From: Chris Liddell
Date: Tue, 11 Feb 2014 15:15:56 +
Subject: [PATCH] Bug 695031: don't assume we can read a font file
When we scan system fonts, we were assuming fonts found would be in a format
Ghostscript understands. This is not necessarily the case.
So put the minimal parsing call to get the font's name in a stopped context,
so we can skip the file it's not an understandable format. And clean up the
stack in the event we try such a file.
No cluster differences.
---
Resource/Init/gs_fonts.ps | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/Resource/Init/gs_fonts.ps b/Resource/Init/gs_fonts.ps
index a597c5a..8ab6872 100644
--- a/Resource/Init/gs_fonts.ps
+++ b/Resource/Init/gs_fonts.ps
@@ -385,12 +385,20 @@ systemdict /NONATIVEFONTMAP known .setnativefontmapbuilt
pop pop pop
}{
% we could open the font file
-.findfontname
-not { dup 0 get } if % stack: (newname) [ (name) (path) ]
-% DEBUG { ( found ) print dup print (\n) print flush } if
-% add entry to the fontmap
-1 index exch 0 exch dup type /nametype ne {cvn} if put
-aload pop .definefontmap
+mark 2 1 roll
+{.findfontname} stopped
+{
+ cleartomark
+ pop pop
+}
+{
+ 3 -1 roll pop
+ not { dup 0 get } if % stack: (newname) [ (name) (path) ]
+ % DEBUG { ( found ) print dup print (\n) print flush } if
+ % add entry to the fontmap
+ 1 index exch 0 exch dup type /nametype ne {cvn} if put
+ aload pop .definefontmap
+} ifelse
} ifelse
} forall
} if
--
1.7.9.5
[1] http://git.ghostscript.com/?p=ghostpdl.git;a=commitdiff;h=f4584b0e
Thanks,
--
mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#738672: [Pkg-octave-devel] Bug#738672: Bug#738672: --force-gui first segfaults and then seems to not start (at least I can't see it)
On Wed, Feb 12, 2014 at 13:18:02 -0500, Yaroslav Halchenko wrote: > doh -- forgot to check either I am getting a segfault as well (by > removing config file)... but as for window not appearing -- seems > to be the problem of awesome. verified also in clean sid chroot that it > remains The problem with the window not appearing in awesome is known and fixed upstream [1], expected to be fixed in the 3.8.1 point release. [1] https://savannah.gnu.org/bugs/?41452 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726571: RlwrapFilter.pm should be /usr/share/perl5/App/Rlwrap/Filter.pm
Hi Ivan, is this still something you'd like to see changed? On Sat, Nov 02, 2013 at 10:30:30 +, Ivan Shmakov wrote: > Being unfamiliar with rlwrap(1), I’ve implemented a crude but > seemingly useful work-alike in Perl. While I’m not planning to > release it anytime soon (now that I’ve learned that rlwrap(1) > fits my needs more than I’ve initially thought), it’s possible > that it will borrow the rlwrap’s protocol, and thus filters > based on RlwrapFilter.pm will no longer be specific to rlwrap. This seems like a reasonable argument for making the Perl module visible in the standard Perl library path, and therefore something you might want to discuss with upstream. I don't see a big advantage to making the Debian package deviate from the intentions of upstream to this extent, so if you'd like to see the RlwrapFilter module be more useful to applications outside of rlwrap itself, I suggest you discuss it with Hans Lub, the upstream author. Feel free to cc me or this bug report. -- mike signature.asc Description: Digital signature
Bug#730718: rlwrap doesn't get exit on EOF with gcc 4.8 and -O2
Hi Hans, I'm investigating Debian bug #730718 (cc'd on this mail, bug history at [1]). It appears to me at this point that rlwrap built with gcc 4.8 and -O2 does not exit correctly when EOF is received. Compiling with -O0 or -O1 or with gcc 4.7 restores the proper behavior. What I've been able to gather from the debug log so far is that the EOF is read and passed to the child process, which does correctly exit immediately. The difference looks like the next call to select does not return until another byte is read from the terminal when built with -O2. I'll certainly investigate further, but I wanted to report this to you along with my findings so far and see if you have any insights or have already run into this problem. [1] http://bugs.debian.org/730718 Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732440: ghostscript: Error: /typecheck in /findfont with fonts-font-awesome installed
On Tue, Dec 17, 2013 at 21:14:59 -0500, Mike Miller wrote: > Ghostscript produces the following error when operating on a postscript file > that references an unknown font name, but only when the fonts-font-awesome > package is installed: After a bit more digging and narrowing down, this error seems to be completely due to any WOFF fonts installed under /usr/share/fonts. This is apparently a new font format that ghostscript doesn't seem to know what to do with. There are two packages in the Debian archive that install WOFF fonts under /usr/share/fonts so far, fonts-font-awesome and fonts-meera-taml. Installing either of those packages produces this ghostscript error. Manually deleting just the .woff file from either package and re-running fc-cache -s restores ghostscript to working order. This serves as a workaround for me for now. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731147: createrepo: -s option not implemented fully
On Wed, Feb 5, 2014 at 11:25:26 -0800, Ryan McKern wrote: > Has there been any traction on this bug? It's impacting some work I've had > to do in a fairly major way. I believe this fix is already merged upstream > and I can confirm that this patch resolved the problem. Hi Ryan, thanks for confirming that the patch resolves this bug for you. I'm working on packaging the latest upstream release which includes the fix. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732440: ghostscript: Error: /typecheck in /findfont with fonts-font-awesome installed
Control: tags -1 + upstream I've confirmed this error occurs on upstream git master, reported upstream as well [1]. [1] http://bugs.ghostscript.com/show_bug.cgi?id=695031 Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#731147: createrepo: -s option not implemented fully
On Mon, 2 Dec 2013 14:20:27 +0100, Thorsten Glaser wrote: > running “createrepo -s sha .” no longer produces repositories > that can be used with production CentOS 5 instances. This has > been reported upstream: Thanks for the report, I don't have a CentOS 5 instance at the moment to confirm but this looks reasonable. There is a new upstream version pending packaging with this fix included, I plan on getting to that soon and I will make sure to test with CentOS 5. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732440: ghostscript: Error: /typecheck in /findfont with fonts-font-awesome installed
Package: ghostscript Version: 9.05~dfsg-8+b1 Severity: normal Dear Maintainer, Ghostscript produces the following error when operating on a postscript file that references an unknown font name, but only when the fonts-font-awesome package is installed: $ cat test.ps %!PS-Adobe-2.0 /NotInstalledFont findfont 20 scalefont setfont 100 500 moveto (Hello world) show showpage $ gs -dQUIET -dNOPAUSE -dBATCH -dSAFER -sDEVICE=pdfwrite \ -dEmbedAllFonts=true -dOptimize=true -sOutputFile=test.pdf test.ps Error: /typecheck in /findfont Operand stack: NotInstalledFont Execution stack: %interp_exit .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- --nostringval-- --nostringval-- false 1 %stopped_push 1910 1 3 %oparray_pop 1909 1 3 %oparray_pop 1893 1 3 %oparray_pop 1787 1 3 %oparray_pop --nostringval-- %errorexec_pop .runexec2 --nostringval-- --nostringval-- --nostringval-- 2 %stopped_push --nostringval-- 1868 1 3 %oparray_pop Dictionary stack: --dict:1164/1684(ro)(G)-- --dict:0/20(G)-- --dict:77/200(L)-- Current allocation mode is local Current file position is 42 GPL Ghostscript 9.05: Unrecoverable error, exit code 1 Removing the fonts-font-awesome package restores the correct behavior, which is that ghostscript does not find a matching font and falls back to Courier. I used strace to determine that the "awesome" font was the most recent file opened by ghostscript before it exited. The fonts-font-awesome package was recently installed as a new dependency of the latest texlive-fonts-extra package. This behavior looks somewhat similar to this upstream bug report: http://bugs.ghostscript.com/show_bug.cgi?id=694790 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ghostscript depends on: ii debconf [debconf-2.0] 1.5.52 ii gsfonts1:8.11+urwcyr1.0.7~pre44-4.2 ii libc6 2.17-97 ii libgs9 9.05~dfsg-8+b1 ghostscript recommends no packages. Versions of packages ghostscript suggests: ii ghostscript-cups 9.05~dfsg-8+b1 ii ghostscript-x 9.05~dfsg-8+b1 ii hpijs 3.13.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#732666: libvirt-bin: special device cgroup_memory does not exist
Package: libvirt-bin Version: 1.1.4-2 Severity: normal Dear Maintainer, I am unable to start the libvirt-bin init script with the mount_cgroups option set. The "memory" mountpoint fails to mount with the following error mount: special device cgroup_memory does not exist and the init script fails. If I add the following line to /etc/default/libvirt- bin MOUNTS="cpuset cpu cpuacct devices freezer net_cls blkio perf_event" then the script succeeds and the daemon runs and is able to start kvm instances again. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libvirt-bin depends on: ii adduser 3.113+nmu3 ii gettext-base 0.18.3.1-2 ii init-system-helpers 1.13 ii libaudit11:2.3.2-2 ii libavahi-client3 0.6.31-2 ii libavahi-common3 0.6.31-2 ii libblkid12.20.1-5.5 ii libc62.17-97 ii libcap-ng0 0.7.3-1+b1 ii libdbus-1-3 1.6.18-2 ii libdevmapper1.02.1 2:1.02.77-6+b1 ii libfuse2 2.9.2-4 ii libgcrypt11 1.5.3-2 ii libgnutls26 2.12.23-8 ii libnetcf11:0.2.3-4 ii libnl-3-200 3.2.21-1 ii libnl-route-3-2003.2.21-1 ii libnuma1 2.0.9~rc5-1 ii libparted0debian12.3-16 ii libpcap0.8 1.5.2-1 ii libpciaccess00.13.2-1 ii librados20.48-2 ii librbd1 0.48-2 ii libreadline6 6.2+dfsg-0.1 ii libsasl2-2 2.1.25.dfsg1-17 ii libssh2-11.4.3-2 ii libudev1 204-5 ii libvirt0 1.1.4-2 ii libxen-4.3 4.3.0-3+b1 ii libxenstore3.0 4.3.0-3+b1 ii libxml2 2.9.1+dfsg1-3 ii libyajl2 2.0.4-4 ii logrotate3.8.6-1 Versions of packages libvirt-bin recommends: ii bridge-utils1.5-7 ii dmidecode 2.12-2 ii dnsmasq-base2.68-1 ii ebtables2.0.10.4-3 ii iproute 1:3.12.0-1 ii iptables1.4.20-2 ii libxml2-utils 2.9.1+dfsg1-3 ii netcat-openbsd 1.105-7 ii parted 2.3-16 ii pm-utils1.4.1-13 ii qemu1.7.0+dfsg-2 ii qemu-kvm1.7.0+dfsg-2 Versions of packages libvirt-bin suggests: pn auditd ii policykit-1 0.105-4 pn radvd pn systemtap -- Configuration Files: /etc/default/libvirt-bin changed [not included] /etc/libvirt/qemu.conf [Errno 13] Permission denied: u'/etc/libvirt/qemu.conf' -- 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#732666: [Pkg-libvirt-maintainers] Bug#732666: libvirt-bin: special device cgroup_memory does not exist
On Fri, 20 Dec 2013 08:07:51 +0100, Guido Günther wrote: > You need > > cgroup_enable=memory > > on the kernel command line to enable the memory cgroup. Could you check > if this fixes your problem as well? If so we should add some run time > detection. Yes, adding this to the command line allows the mount to work and libvirtd starts up again. Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726571: RlwrapFilter.pm should be /usr/share/perl5/App/Rlwrap/Filter.pm
On Wed, Oct 16, 2013 at 18:56:33 +, Ivan Shmakov wrote: > The conventional namespace for application-specific Perl modules > is App::⟨package name⟩::⟨module name…⟩. Can you give some examples or references? I see a few but not enough that I'd call it a convention. As opposed to simply $PACKAGE::$MODULE... > Moreover, the > conventional directory for Perl modules is /usr/share/perl5, and > indeed, – it’s already in @INC, while /usr/share/rlwrap isn’t. This is indeed required for packages that primarily provide perl libraries. However there are also many packages in Debian that install perl modules in application-specific directories when those modules are primarily for that application's use only. > Therefore, my suggestion would be to move RlwrapFilter.pm from > /usr/share/rlwrap to /usr/share/perl5/App/Rlwrap/Filter.pm, and > edit its ‘package’ line (as well as the filters’ ‘use’ lines) > respectively. (In order to preserve compatibility, a > “redirecting” .pm may be installed at the former location.) > > This will bring the module in line with the other Perl modules > in Debian, and will allow for a Perl filter to be started with > simple ‘use App::Rlwrap::Filter;’ instead of the current form, > which explicitly the Perl module search path (as shown below.) Do you have any other reasons for wanting to make this change, some added functionality or benefit that would come from doing this reorganization? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#726942: override: createrepo:admin/extra
Package: ftp.debian.org Severity: normal Dear ftpmasters, Please downgrade createrepo to priority extra since it depends on several packages of priority extra (including deltarpm, rpm, and yum). Thanks, -- mike signature.asc Description: Digital signature
Bug#734735: llvm-3.2: executables are not executable on hurd-i386
Package: llvm-3.2 Version: 1:3.2repack-11 Severity: normal Dear Maintainer, The executables under /usr/lib/llvm-3.2/bin are not executable on a hurd-i386 system. All files in that directory are 644 instead of 755. The result of this is $ llvm-config -bash: /usr/bin/llvm-config: Permission denied Discovered when attempting to build src:octave on hurd-i386, which build-depends on llvm-dev. This might apply equally to all versions of llvm but llvm-3.2 is the only one in the archive built for hurd-i386 currently. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734779: [Pkg-utopia-maintainers] Bug#734779: applet dropdown does not show VPN connected when it is
On Thu, 9 Jan 2014 20:06:53 -0500, Brent S. Elmer, Ph.D. wrote: > On Fri, 2014-01-10 at 01:48 +0100, Michael Biebl wrote: >> reassign 734779 gnome-shell >> thanks >> >> Am 09.01.2014 20:03, schrieb Brent S. Elmer Ph.D.: >> > Here is a screen shot showing what I mean. >> >> that screenshot shows gnome-shell, so re-assigning. >> Please provide the version of gnome-shell you are using. > > gnome-shell version 3.8.4-5 This certainly looks like #729288. Can you test whether the patch there fixes it for you? -- mike signature.asc Description: OpenPGP digital signature
Bug#724755: yum-utils: Add python2.7-iniparse to yum-utils depends
tags 724755 + pending thanks Added python-iniparse as a dependency, along with some other indirect dependencies now made explicit. http://anonscm.debian.org/gitweb/?p=users/mtmiller-guest/yum-utils.git;a=commitdiff;h=845a9f6a0a03c3c019a357b778ecbcca8119008a -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#728753: mock: should create mock system group and directories
Package: mock
Version: 1.1.33-1
Severity: normal
Dear Maintainer,
Installing mock from scratch does not create the mock group, which seems to be
required when calling mock even with sudo.
Running as root without mock in /etc/group yields:
ERROR: 'getgrnam(): name not found: mock'
Traceback (most recent call last):
File "/usr/sbin/mock", line 305, in
def do_buildsrpm(config_opts, chroot, options, args):
File "/usr/sbin/mock", line 384, in main
mockgid = grp.getgrnam('mock').gr_gid
KeyError: 'getgrnam(): name not found: mock'
Running as non-root user yields:
The password you typed is invalid.
Please try again.
until both the group is created and the non-root user is added to the mock
group.
The default directories /var/cache/mock and /var/lib/mock should probably also
be created in the postinst script and made writable by the mock group,
otherwise:
ERROR: Could not create dir /var/lib/mock/epel-6-x86_64/result. Error: [Errno
13] Permission denied: '/var/lib/mock/epel-6-x86_64/result'
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/mockbuild/util.py", line 68, in
mkdirIfAbsent
os.makedirs(dirName)
File "/usr/lib/python2.7/os.py", line 157, in makedirs
mkdir(name, mode)
OSError: [Errno 13] Permission denied: '/var/lib/mock/epel-6-x86_64/result'
ERROR:
Could not create output directory for built rpms. The directory specified was:
/var/lib/mock/epel-6-x86_64/result
Try using the --resultdir= option to select another location. Recommended
location is --resultdir=~/mock/.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages mock depends on:
ii python 2.7.5-5
ii python-decoratortools 1.8-2
ii python-rpm 4.11.1-3
ii usermode 1.109-1
ii yum3.4.3-2
ii yum-utils 1.1.31-2
mock recommends no packages.
Versions of packages mock suggests:
ii pigz 2.3-2
-- Configuration Files:
/etc/mock/site-defaults.cfg changed [not included]
-- 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#730017: network-manager-openconnect: OpenVPN connections cannot be opened and cannot be configured anymore.
Control: tags -1 + moreinfo On Wed, 20 Nov 2013 03:39:56 -0500, Hans Heukenkamp wrote: > Package: network-manager-openconnect > Version: 0.9.8.4-1 > Severity: normal > You haven't provided much information here. Can you give some more details on the problem you are seeing? Also which VPN type did you mean, OpenConnect or OpenVPN? -- mike signature.asc Description: OpenPGP digital signature
Bug#730017: network-manager-openconnect: OpenVPN connections cannot be opened and cannot be configured anymore.
On Wed, 20 Nov 2013 16:40:53 +0100, Hans Heukenkamp wrote: > Dear Mike, > I had a working openconnect configuration (CISCO) using the > network-manager-openconnect plugin with Debian/Jessie and its current XFCE4 > version. > As I am using it for daily work, I know for sure it had worked until the > last dist-upgrade I did yesterday. So you had a working connection and the ability to edit connections with network-manager-openconnect version 0.9.4.0-8 and now fails since version 0.9.8.4-1 showed up in jessie? Do you also have network-manager-openconnect-gnome 0.9.8.4-1 installed? > Observations are: > - Starting an OpenConnect VPN using the network manager plugin fails > silently. The daemon log does not tell anything. There are ways to get debug output from NetworkManager, see [1] for example. > - Configuration of new OpenConnect VPN connections does not work anymore. > The graphical form does not accept any user entries it just stays grey. So to confirm, this is the nm-connection-editor tool? Do you get to the point where the openconnect-specific form shows up, but it won't let you edit the form fields? Do you get the same behavior if you try to edit an existing connection? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730017: network-manager-openconnect: OpenVPN connections cannot be opened and cannot be configured anymore.
On Wed, 20 Nov 2013 20:24:29 -0500, Mike Miller wrote: > There are ways to get debug output from NetworkManager, see [1] for example. This time with the link. [1] https://wiki.gnome.org/NetworkManager/Debugging -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730718: Regression: Ctrl-D must be hit twice to work
On Thu, 28 Nov 2013 16:25:26 +0100, Marc-Jano Knopp wrote: > In newer versions of rlwrap, Ctrl-D must be pressed twice to end the > command. More precisely: The effects of a Ctrl-D on an empty line are > delayed until any other character is entered. > > > Example > --- > > $ rlwrap cat > # nothing happens > # (or any other input!) -- now I get back to the prompt > $ > > In older versions, Ctrl-D worked as expected, i.e. it had to be hit > only once to get instantly accepted. Thanks for finding and reporting this bug. I can confirm the same behavior present with the latest package build and not present in the version in wheezy. > Interestingly enough, which versions are affected by this bug depends > on the method I use for installing the software, namely whether I take > the prebuilt package from snapshot.debian.org or build it myself. I > take it that my system and the Debian build system have/had different > package versions that fulfilled rlwrap's build-dependencies. Hmm, any more insight into why this is? I haven't started looking at the different combinations of installed package vs. built source package vs. build-dependencies yet. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752340: network-manager-openconnect: OpenConnect plugin does not show in network manager.
Control: tags -1 + moreinfo Thanks for your bug report. Can you provide some more information about the following? On Sun, Jun 22, 2014 at 21:22:53 +0200, Stefan Haun wrote: > the openconnect plugin from network-manager-openconnect is not visible in > the network manager configuration (Manager connections -> VPN -> Add). Which desktop environment (GNOME, KDE, XFCE, etc) and which NetworkManager configuration GUI are you using? > Using openconnect on the CLI works fine. > Installing the GNOME UI does not make a difference. Which specific packages are you speaking of when you say you tried "installing the GNOME UI"? You do not have network-manager-openconnect-gnome installed, it is not expected to show up in the NM GUI without this package: > Versions of packages network-manager-openconnect recommends: > pn network-manager-openconnect-gnome Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752340: network-manager-openconnect: OpenConnect plugin does not show in network manager.
On Mon, Jun 23, 2014 at 21:02:33 +0200, Stefan Haun wrote: > Am Montag, 23. Juni 2014, 17:22:04 schrieb Mike Miller: >> Thanks for your bug report. Can you provide some more information >> about the following? >> >> On Sun, Jun 22, 2014 at 21:22:53 +0200, Stefan Haun wrote: >> > the openconnect plugin from network-manager-openconnect is not visible in >> > the network manager configuration (Manager connections -> VPN -> Add). >> >> Which desktop environment (GNOME, KDE, XFCE, etc) and which >> NetworkManager configuration GUI are you using? > > Sorry, I forgot. > > I am using the KDE with the plasma widget. Ok, this is unfortunately the current state of things in the wheezy release with OpenConnect and KDE. OpenConnect version 4 or newer is needed to legally link libopenconnect with KDE's plasma widget for networking, and version 4 did not make it into Debian before the last release. So this is completely expected with the version you are using. I don't use KDE, I don't currently have a KDE environment to test on. If you can test the current Debian testing release with KDE and OpenConnect (network-manager-openconnect and plasma-nm packages), it should be enabled and work correctly. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Tue, Jun 24, 2014 at 14:28:41 +0200, Laurent Bigonville wrote: > Hello, > > Is there any plans to have this fixed for the version currently in > unstable version? Originally no, since 5.99 was supposed to be followed very closely by 6.00. So I've been waiting on that to happen. This beta has been going on for over 3 months now though, so maybe I should update unstable until upstream is ready to release. I'll take a look at this and any other small improvements I can cherry pick from experimental. Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744244: octave: missing function "dispatch" causes configure to fail
Control: tags -1 + moreinfo On Fri, Apr 11, 2014 at 20:23:33 +0200, Winfried Boxleitner wrote: >>> error: 'dispatch' undefined near line 2 column 1 >>> error: called from: >>> error: /usr/share/octave/packages/fixed-0.7.10/PKG_ADD at line 2, column 1 > [...] > so it seems that "dispatch" was removed deliberately, however the > install/upgrade process depends on it. Actually the octave-fixed package has been removed from the Debian archive because it is unmaintained and no longer works with current Octave. And octave 3.8.1-1 should have forced a removal of the octave-fixed package if it were installed. How do you have it installed in /usr/share/octave/packages/fixed-0.7.10? > to workaround this and to finally finish the upgrade I searched > for "dispatch.oct" in an older deb-package and copied it into: > /usr/lib/octave/3.2.4/site/oct/x86_64-pc-linux-gnu/dispatch.oct > [...] > the install finished successfully, however other error messages appear > whenever I try > to start octave, since I introduced library inconsistencies by using an > ancient version > of "dispatch.oct" The correct resolution should be removal of the fixed package, whether it was installed locally by you or from the octave-fixed Debian package. Depending on your answer to the above, does removal of the package (and removal of this dispatch.oct file) fix the configuration error for you? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744244: octave: missing function "dispatch" causes configure to fail
On Fri, Apr 11, 2014 at 21:45:11 +0200, Winfried Boxleitner wrote: > On Fri, 11 Apr 2014, Mike Miller wrote: >> The correct resolution should be removal of the fixed package, whether >> it was installed locally by you or from the octave-fixed Debian >> package. Depending on your answer to the above, does removal of the >> package (and removal of this dispatch.oct file) fix the configuration >> error for you? > > thank you mike! > the removal of octave-fixed solves the problem for me. > > to test I did a reinstall of octave and it went through without a problem. That's great that it's solved for you. It might still be useful to us to know how octave-fixed was installed on your system. Did you have a Debian package installed that you now apt-get removed, or had you locally installed it with the pkg command in Octave? If it was a deb package, what was its version? Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744214: openconnect: PKCS#11 support broken with GnuTLS 2.12.x
On Sat, Apr 12, 2014 at 18:49:17 +0200, Thomas Uhle wrote: > Thank you for the immediate response! So, to cut a long story short: I have > spent some more time on debugging the code changes in gnutls.c, and you were > right. Both versions from git are failing. The bug was hiding in the code > you had changed before. Eventually, the bug was found in the function > assign_privkey() (line 510), please see the attached patch. The substantive change in your patch has already been fixed in the current git master, so this will be fixed in the upcoming 6.00 release: http://git.infradead.org/users/dwmw2/openconnect.git/commitdiff/43e514b4f53c147936a7379e8e6fc67f78cae2fb Additionally, the current 5.99 package in Debian experimental is built using GnuTLS 3.x, so AFAICT this bug does not affect these packages. Can you install 5.99-2 from experimental and verify that the bug is not present? As far as Ubuntu is concerned, could you please submit a launchpad bug and we can apply this fix as an SRU for the next 14.04 update? Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#661242: gnome-shell: clock shows UTC time instead of local when POSIX timezone format is specified in the environment
Control: found -1 gnome-shell/3.4.2-2 Control: found -1 gnome-shell/3.4.2-7+deb7u1 On Wed, Mar 19, 2014 at 22:45:45 -0400, Mike Miller wrote: > On Wed, Mar 19, 2014 at 15:25:43 +, althaser wrote: > > Could you please still reproduce this issue with newer gnome-shell version > > like 3.4.2-7+deb7u1 or 3.8.4-5+b1 ? > > I haven't tried with wheezy yet, but yes this now works for me with the > version in jessie. I will check other versions when I get a chance. Bug is still present in the current version in wheezy. Also snagged 3.4.2-2 from snapshot.d.o to verify it is found there as well. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#744244: octave: missing function "dispatch" causes configure to fail
Control: tags -1 - moreinfo Control: tags -1 + pending On Fri, Apr 11, 2014 at 22:19:35 +0200, Winfried Boxleitner wrote: > On Fri, 11 Apr 2014, Mike Miller wrote: >> That's great that it's solved for you. It might still be useful to us >> to know how octave-fixed was installed on your system. Did you have a >> Debian package installed that you now apt-get removed, or had you >> locally installed it with the pkg command in Octave? If it was a deb >> package, what was its version? > > octave-fixed appeared on my machine the first time 2012-05-16 21:22:41 > in version: 0.7.10-5. > since then the version was never upgraded. the logs indicate, > that it was installed from a debian-package (entry in dpkg.log) I hadn't noticed yet at the time I was discussing this with you, but this had already been fixed in git [1] and is not yet released. The next update to the Octave packages will correctly force the octave-fixed package to be uninstalled, the current 3.8.1-1 version does not. Thanks for reporting this. [1] http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=93f27c6 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740449: octave: Changing the figure visibility breaks the print to a file
On Sat, Mar 01, 2014 at 17:32:45 +0100, Maximiliano Curia wrote: > In octave to get a file output without showing the plot on the screen you > would normaly do: > figure(1, "visible", "off"); > plot(sin(1:100)); > print -deps "/tmp/sin.eps" > > Sadly, the new version produces no output file after touching the "visible" > attribute, either for a particualar figure, as shown, or setting the > default behaviour with: > set(0, 'defaultfigurevisible', 'off'); Yes, this is a known issue upstream due to use of gl2ps which requires an OpenGL display to render plots to postscript. The default plotting backend in Octave 3.8 is now the OpenGL backend, which brings many improvements but also this one missing feature. See upstream bug report: https://savannah.gnu.org/bugs/?33180 > This issue breaks, a very useful scripting feature and the octave frontends > that depends on this behaviour, such as cantor. A workaround is for scripts and frontends that require this to set the plotting backend to gnuplot. This should preserve whatever plotting capability they had with previous versions of Octave: graphics_toolkit gnuplot figure (1, "visible", "off"); ... -- mike signature.asc Description: Digital signature
Bug#702241: gnome-packagekit: gpk-update-viewer does not update package index so falsely says is up to date.
Package: gnome-packagekit Version: 3.10.1-1 Followup-For: Bug #702241 Dear Maintainer, I'm seeing this behavior on jessie also. I'm using a standard GNOME desktop environment, packagekitd is running, but the apt cache is never updated. The apt cron job is not active. If I run either pkcon refresh or apt-get update, then it lists updated packages available. But just leaving packagekitd to itself in the background, apt is not updated as far as I can tell. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages gnome-packagekit depends on: ii gnome-packagekit-session 3.10.1-1 ii libatk1.0-0 2.10.0-2 ii libc6 2.17-97 ii libcairo-gobject2 1.12.16-2 ii libcairo2 1.12.16-2 ii libcanberra-gtk3-00.30-2 ii libcanberra0 0.30-2 ii libdbus-1-3 1.8.0-1 ii libdbus-glib-1-2 0.102-1 ii libfontconfig12.11.0-2 ii libfreetype6 2.5.2-1 ii libgdk-pixbuf2.0-02.30.5-1 ii libglib2.0-0 2.38.2-5 ii libgtk-3-03.10.7-1 ii libnotify40.7.6-2 ii libpackagekit-glib2-160.8.16-1 ii libpango-1.0-01.36.0-1+b1 ii libpangocairo-1.0-0 1.36.0-1+b1 ii libpolkit-gobject-1-0 0.105-4 ii libsqlite3-0 3.8.3.1-1 ii libsystemd-login0 204-7 ii libupower-glib1 0.9.23-2+b1 ii libx11-6 2:1.6.2-1 gnome-packagekit recommends no packages. Versions of packages gnome-packagekit suggests: ii gnome-packagekit-tools 3.10.1-1 -- no debconf information signature.asc Description: Digital signature
Bug#740993: transition: openconnect
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I would like to request a transition slot for the openconnect package. The upcoming version 6.00 will come with a new library soname bump to libopenconnect.so.3. The 6.00 version has not been released yet, but I have already packaged and uploaded the 5.99 release candidate to experimental for testing. The reverse dependencies are only the source packages network-manager- openconnect and plasma-nm. Both of these will likely require sourceful uploads to make use of the library API changes. I maintain network-manager-openconnect, so I plan on working on the necessary changes to it next, and I will look into what is needed for plasma-nm as well. Ben file: title = "openconnect"; is_affected = .depends ~ "libopenconnect2" | .depends ~ "libopenconnect3"; is_good = .depends ~ "libopenconnect3"; is_bad = .depends ~ "libopenconnect2"; Thanks. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740984: octave-vrml: unversioned Depends entries break Octave 3.8.0
Control: reassign -1 octave 3.8.0-5 Control: retitle -1 octave: unable to handle package dependencies with a hyphen Control: tags -1 + upstream Control: forwarded -1 https://savannah.gnu.org/bugs/?41087 On Thu, Mar 06, 2014 at 19:29:10 -0500, Aaron M. Ucko wrote: > It's impossible to configure octave 3.8.0 with octave-vrml installed: > > Processing triggers for octave (3.8.0-5) ... > error: strcmp: nonconformant cell arrays > error: evaluating argument list element number 1 > error: called from: > error: /usr/share/octave/3.8.0/m/pkg/private/fix_depends.m at line 46, > column 9 > error: /usr/share/octave/3.8.0/m/pkg/private/get_description.m at line 74, > column 18 > error: /usr/share/octave/3.8.0/m/pkg/private/rebuild.m at line 50, column 12 > error: /usr/share/octave/3.8.0/m/pkg/pkg.m at line 495, column 25 > dpkg: error processing package octave (--unpack): > subprocess installed post-installation script returned error exit status 1 > Errors were encountered while processing: > octave > > The problem appears to be that most of the Depends entries in > octave-vrml's DESCRIPTION file lack version requirements; could you > please take a look, and either fix octave to permit such entries or > octave-vrml not to supply them? Confirmed, but the problem is actually that octave-vrml depends on something that has a hyphen in its name (linear-algebra). This bug was identified and fixed upstream, patch linked in the upstream bug report, and the fix will be in the 3.8.1 upstream bug-fix release. I've confirmed that applying that patch allows octave-vrml to be installed. -- mike signature.asc Description: Digital signature
Bug#670030: found again in readline6 6.3-1
Dear Maintainer, It appears that bug #670030 has reappeared in the 6.3-1 version of libreadline6-dev. I am unable to install amd64 and i386 packages together, examples/Makefile.gz is the problem file, exactly the same as previously noted in this bug report and fixed in an earlier version. -- mike signature.asc Description: Digital signature
Bug#741097: octave: nox package of Octave
On Sat, Mar 08, 2014 at 13:48:08 +, Arno Onken wrote: > Starting with version 3.8, the octave package contains a GUI based on > the Qt toolkit. An `octave-cli' executable which is not linked against > Qt is provided in the package, but there is no octave package that does > not depend on Qt. Packages like emacs and gnuplot have nox alternatives. > A similar octave package would be a great asset. Can you explain specifically what you think the advantages of having a "nox" version of octave would be? I'm not refuting your request, just that you haven't specifically said what the problem with the current approach is and what specific benefits would derive from having a nox package, just that "these others are doing it". We considered this when starting work on packaging octave 3.8, please take a look at the discussions (thread starting at [1]) we had where we did look at a few different aspects and decided to keep everything in one package for now. Also keep in mind that 3.8 is a transitional period for the octave command-line and GUI modes, upstream may yet make changes about how octave is run in one mode or the other. For all we know, there may not be a separate octave-cli executable in the 4.0 version. I'm not saying this is likely or that I'm in favor of it, just that this is still a developmental period and things could change by 4.0. [1] https://lists.alioth.debian.org/pipermail/pkg-octave-devel/2013-December/010385.html -- mike signature.asc Description: Digital signature
Bug#741399: dkms: consider avoiding unnecessary rpm commands
Package: dkms Version: 2.2.0.3-1.2 Severity: normal Tags: patch Dear Maintainer, Please consider patching dkms when built for Debian to avoid unnecessary rpm commands. We know that Debian systems do not use the rpm database so there is no need to query it. The lsb-core package pulls in rpm. The primary reason to patch these commands out is because when rpm is installed, an rpm database query will be run unavoidably. With the default configuration of the rpm package for Debian, this will create an empty rpm database in either /root/.rpmdb (if HOME=/root) or in the system root directory /.rpmdb (if HOME is not set, e.g. running under PackageKit). Avoiding rpmdb queries in dkms will avoid inadvertent creation of these stray directories. A patch to dkms [1] was posted to Ubuntu bug #1069350 [2] that is reported there to fix this behavior. [1] https://launchpadlibrarian.net/167218071/disable-rpm.patch [2] https://launchpad.net/bugs/1069350 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dkms depends on: ii build-essential11.6 ii coreutils 8.21-1 ii dpkg-dev 1.17.6 ii gcc4:4.8.2-2 ii make 3.81-8.3 ii module-init-tools 16-2 ii patch 2.7.1-4 Versions of packages dkms recommends: ii fakeroot 1.18.4-2 ii linux-headers-amd64 3.12+55 pn linux-image ii menu 2.1.46 ii sudo 1.8.9p5-1 dkms 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#741324: rpm regulary creates directory /~
On Tue, Mar 11, 2014 at 11:01:38 +0100, Klaus Ethgen wrote: > rpm did create /.rpmdb before and now it does much more annoyingly > create /~/.rpmdb. Confirmed here as well with the default configuration when rpm runs as root with HOME undefined. This is due to the change in 4.11.2-1 that attempted to fix the problem with /.rpmdb, but apparently ~ as a fallback is not doing what it was meant to do. You might also be interested in #741399 I just reported, based on findings from Ubuntu bug #1069350, requesting dkms to avoid calling rpm which should prevent creation of these directories. This interaction between dkms and rpm appears to be the primary cause. Do you have dkms built kernel modules on your system? -- mike signature.asc Description: Digital signature
Bug#742272: ITP: ocserv -- OpenConnect VPN Server
On Mon, Mar 24, 2014 at 13:42:21 +0800, Liang Guo wrote: > I'm glad that you have worked on it, would you like upload your > ocserv package and close this bug? > > I compiled it from source and it works in Debian, but have not > packaging it yet. I do have a start, but not fully suitable for uploading to the archive yet (not lintian clean, copyright needs work, clean up default configuration for a fresh install). You can certainly grab what I have so far, I just updated to the 0.3.2 version: http://people.debian.org/~mtmiller/ocserv_0.3.2-1~local1.dsc I just noticed a segfault while quickly testing this latest version, I'll have to look into that. It's up to you, since you have the ITP if you want feel free to take my work and finish and upload it. But I'm certainly willing to finish it as well if you'd rather I finish what I started :) Cheers, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742755: openconnect: avoid OpenSSL in openconnect, just use libgnutls28
On Wed, Mar 26, 2014 at 18:32:42 -0400, Daniel Kahn Gillmor wrote: > The openconnect package in debian builds against both OpenSSL and > GnuTLS, and links in both of these libraries. This is two separate > TLS stacks that need to be audited for the package to work correctly. > It also introduces potential licensing concerns due to the mix of > OpenSSL and GPL'ed code (i don't know whether openconnect's LGPL > licensing itself conflicts with OpenSSL's licensing, and i don't know > what effect this has on GPL'ed downstream dependencies like > network-manager). The portions that are built into the openconnect library are LGPL and link with GnuTLS while the openconnect program links with OpenSSL (or a new enough GnuTLS), which should allow GPL rdeps to link. But regardless... > Both of the above concerns can be avoided by building openconnect > solely against GnuTLS, which appears to support all the features > needed. Yes, definitely will do. I've been anxiously watching the discussion about migrating Debian to GnuTLS 3.x by default and waiting for the relicensed GMP release that just hit the archive. This was the most important blocker holding OpenConnect back on GnuTLS 2.x. > I'm attaching a patch that resolves this for 5.03 (in unstable). the > patch for 5.99 (in experimental) is basically identical. i can submit > it explicitly as well if that would be useful. No need, but thanks for the patch. I will probably incorporate this into 5.99-2 in experimental and the upcoming 6.00-1 once the upstream major release happens (imminently). Thanks! -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742755: openconnect: avoid OpenSSL in openconnect, just use libgnutls28
On Wed, Mar 26, 2014 at 23:59:26 +, David Woodhouse wrote: > Hm, since we moved the mainloop into libopenconnect itself (which is > what allows it to be used easily from Java in the Android client, etc.), > that is no longer true. > > Sorry, I had forgotten the implications of that — even when we recently > discussed the possibility of dropping older versions of GnuTLS. Hmm, looks that way to me too, undefined SSL_* symbols in libopenconnect.so.3 where there weren't any in libopenconnect.so.2. > If you want to continue to build with GnuTLS 2.12, and want to retain > DTLS support (which must therefore come from OpenSSL), I think you > probably need to revert most of commit 30320884589e and the subsequent > related changes. Nope, all the more reason to move to GnuTLS 3.x now that we have a GPLv2-compatible GMP. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#675509: still problems with Emacs inferior-octave mode iwth 3.8.0
On Fri, Mar 07, 2014 at 19:44:30 +0100, Francesco Potortì wrote: > Good news first: > > launching Octave 3.8 from screen under a virtual terminal shows no > problems with fltk. Same from the gui. > > From inside the inferior-octave emacs mode, the plot window appears and > is regularly updated if I make a new plot. If it is resized, the plot > inside is resized only if I replot it. It freezes if I use close or use > the mouse to close the window. Ciao Francesco, More good news. In case you're not monitoring the upstream bug, I commented that I am now able to reproduce this and think I know the cause. The fltk toolkit relies on the readline event loop running in the Octave shell as its event loop. If readline is disabled (--no-line-editing) or was not compiled in Octave (not the case for Debian) then fltk exhibits exactly the behavior you are describing. It is responsive to commands from the interpreter but freezes after that and cannot react to events originating from the windowing environment. When Octave is running in the Emacs inferior mode, it is given the --no-line-editing option. Therefore, I believe that this is the same underlying cause. And that means that fltk cannot work within Emacs currently. I think there are two possible ways forward. This can be discussed with the Emacs maintainers to see if that option can be removed. If Octave does run readline, does it fatally break the inferior mode interface to Emacs, or is it just doing extra work and the mode authors thought they would be saving some overhead? Another way is to simply prevent the fltk toolkit from being selected as the active toolkit when readline is disabled in Octave. This is already done when DISPLAY is unset, for example. Gnuplot would be used as a fallback. Of course, if you or anyone else can show a case where this fltk problem still happens without the --no-line-editing option and outside of Emacs mode, then there may still be an undiagnosed problem with fltk. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742755: openconnect: avoid OpenSSL in openconnect, just use libgnutls28
On Fri, Mar 28, 2014 at 10:00:07 +, David Woodhouse wrote: > On Wed, 2014-03-26 at 21:34 -0400, Mike Miller wrote: > > > > Nope, all the more reason to move to GnuTLS 3.x now that we have a > > GPLv2-compatible GMP. > > Is that something you can do on all platforms where you wanted to ship > OpenConnect 6.00? Should be able to. GMP 6 is already built and installable for all platforms except for temporary build errors on arm and hurd. We have no network-manager on hurd anyway, so it doesn't matter much for that platform which GMP is used. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743260: octave: fltk plotting segfaults when using llvmpipe direct rendering
Package: octave Version: 3.8.1-1+b1 Severity: normal Octave segfaults when plotting anything with the fltk toolkit when Octave is built with JIT and when using one of the Gallium llvmpipe Mesa drivers for direct rendering. JIT does not have to be enabled in Octave for the crash to occur. This is perhaps some kind of LLVM conflict, since Octave uses LLVM for JIT and Mesa uses LLVM for the software rendering drivers. At a minimum, just drawing an empty axes object is enough: $ gdb --args /usr/bin/octave --persist --eval "axes" ... (gdb) run ... Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt (gdb) bt #0 0x in ?? () #1 0x71f12779 in llvm::TargetRegistry::lookupTarget(std::string const&, std::string&) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1 #2 0x719b27a1 in llvm::EngineBuilder::selectTarget(llvm::Triple const&, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl const&) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1 #3 0x7fffe4aa9a58 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #4 0x7fffe4a8660d in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #5 0x7fffe4af69bc in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #6 0x7fffe4aef4a0 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #7 0x7fffe4ad8471 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #8 0x7fffe48d05fc in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #9 0x7fffe48a57f7 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #10 0x7fffe488de6f in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #11 0x7fffe48a2946 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #12 0x7fffe47ecd57 in ?? () from /usr/lib/x86_64-linux-gnu/dri/swrast_dri.so #13 0x7757b233 in opengl_renderer::set_polygon_offset (this=, on=, offset=) at corefcn/gl-render.cc:2761 #14 0x7757d1d4 in opengl_renderer::draw_axes_planes (this=this@entry=0xca9a90, props=...) at corefcn/gl-render.cc:868 #15 0x77583208 in opengl_renderer::draw_axes (this=0xca9a90, props=...) at corefcn/gl-render.cc:1418 #16 0x7757b89e in opengl_renderer::draw (this=0xca9a90, go=..., toplevel=) at corefcn/gl-render.cc:566 #17 0x7758db0e in opengl_renderer::draw (this=this@entry=0xca9a90, hlist=..., toplevel=toplevel@entry=false) at corefcn/gl-render.h:73 #18 0x77584816 in opengl_renderer::draw_figure (this=0xca9a90, props=...) at corefcn/gl-render.cc:592 #19 0x7757b89e in opengl_renderer::draw (this=this@entry=0xca9a90, go=..., toplevel=toplevel@entry=true) at corefcn/gl-render.cc:566 #20 0x7fffe5fef209 in OpenGL_fltk::draw (this=0xca9970) at dldfcn/__init_fltk__.cc:200 #21 0x7fffe5db8275 in Fl_Gl_Window::flush() () from /usr/lib/x86_64-linux-gnu/libfltk_gl.so.1.3 #22 0x7fffe5aaec62 in Fl::flush() () from /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 #23 0x7fffe5aafba8 in Fl::wait(double) () from /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 #24 0x7fffe5aafc3d in Fl::check() () from /usr/lib/x86_64-linux-gnu/libfltk.so.1.3 #25 0x7fffe5fdf321 in __fltk_redraw__ () at dldfcn/__init_fltk__.cc:1886 #26 0x7fffe5feeea5 in fltk_graphics_toolkit::redraw_figure (this=, go=...) at dldfcn/__init_fltk__.cc:2010 #27 0x776131de in redraw_figure (go=..., this=0x7fffd830) at corefcn/graphics.h:2169 #28 Fdrawnow (args=...) at corefcn/graphics.cc:9737 ... I think this bug has affected a handful of people now and again on the upstream mailing list and bug tracker but AFAICT the specific configuration was never identified. Rebuilding Octave without LLVM (--disable-jit) appears to resolve this problem. Another workaround is to disable Mesa direct rendering: (gdb) set env LIBGL_ALWAYS_INDIRECT y (gdb) run ... No segfault. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.13-1-amd64 (SMP w/1 CPU core) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages octave depends on: ii default-jre-headless 2:1.7-51 ii libamd2.3.1 1:4.2.1-3 ii libarpack2 3.1.5-2 ii libatlas3-base [liblapack.so.3] 3.10.1-4 ii libblas3 [libblas.so.3] 1.2.20110419-7 ii libc62.18-4 ii libcamd2.3.1 1:4.2.1-3 ii libccolamd2.8.0 1:4.2.1-3 ii libcholmod2.1.2 1:4.2.1-3 ii libcolamd2.8.0 1:4.2.1-3 ii libcxsparse3.1.2 1:4.2.1-3 ii libfftw3-double3 3.3.3-7 ii libfftw3-single3 3.3.3-7 ii libfltk-gl1.31.3.2-4 ii libfltk1.3 1.3.2-4 ii libfontco
Bug#743260: octave: fltk plotting segfaults when using llvmpipe direct rendering
On Tue, Apr 01, 2014 at 00:48:38 -0400, Mike Miller wrote: > Octave segfaults when plotting anything with the fltk toolkit when > Octave is built with JIT and when using one of the Gallium llvmpipe Mesa > drivers for direct rendering. JIT does not have to be enabled in Octave > for the crash to occur. This is perhaps some kind of LLVM conflict, > since Octave uses LLVM for JIT and Mesa uses LLVM for the software > rendering drivers. I just looked again and noticed that Octave is built against LLVM-3.3 while Mesa is built against LLVM-3.4. I will try to rebuild Octave against LLVM-3.4 and see if that also resolves this crash. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743260: octave: fltk plotting segfaults when using llvmpipe direct rendering
Control: severity -1 important On Tue, Apr 01, 2014 at 00:56:53 -0400, Mike Miller wrote: > On Tue, Apr 01, 2014 at 00:48:38 -0400, Mike Miller wrote: > > Octave segfaults when plotting anything with the fltk toolkit when > > Octave is built with JIT and when using one of the Gallium llvmpipe Mesa > > drivers for direct rendering. JIT does not have to be enabled in Octave > > for the crash to occur. This is perhaps some kind of LLVM conflict, > > since Octave uses LLVM for JIT and Mesa uses LLVM for the software > > rendering drivers. > > I just looked again and noticed that Octave is built against LLVM-3.3 > while Mesa is built against LLVM-3.4. I will try to rebuild Octave > against LLVM-3.4 and see if that also resolves this crash. I was able to build Octave against LLVM 3.4 using the proof-of-concept patch on the upstream bug tracker [1]. After installing and running some simple plot tests, everything works for me, so it does look like this library conflict is indeed what causes the segfault. This bug affects all Octave users plotting with fltk, which is now the Octave default, and who are using the free LLVM-based graphics drivers for AMD and NVIDIA cards, the VMware virtual GPU, or the swrast driver. Upgrading severity to important. [1] https://savannah.gnu.org/bugs/index.php#comment11 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743260: octave: fltk plotting segfaults when using llvmpipe direct rendering
On Tue, Apr 1, 2014 at 19:26:12 +0200, Sébastien Villemot wrote: > Le mardi 01 avril 2014 à 10:57 -0400, Mike Miller a écrit : > >> This bug affects all Octave users plotting with fltk, which is now the >> Octave default, and who are using the free LLVM-based graphics drivers >> for AMD and NVIDIA cards, the VMware virtual GPU, or the swrast driver. >> Upgrading severity to important. > > Doesn't that mean that we should drop the JIT for the time being? Or > should we immediately upgrade to LLVM 3.4 ? Yeah I think dropping JIT is best until a more stable solution is worked out upstream, that seems to be the upstream sentiment as well. For reference, the LLVM API breakage problem has also been discussed on debbug #739903 [1] and upstream bug #41061 [2]. [1] https://bugs.debian.org/739903 [2] https://savannah.gnu.org/bugs/?41061 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743679: octave: plot(1:4) triggers segfault crash
On Sat, Apr 05, 2014 at 15:19:31 +0800, Hörmetjan Yiltiz wrote: > This bug was introduced after upgrading to Octave 3.8.1-1+b1, > and the bug was not there in 3.8.0 (I am not sure about this > version number. I can only remember that it was already 3.8, > introducing the experimental gui). It was actually likely introduced by recent changes in the mesa package. It looks like it transitioned to testing around the same time that Octave did. If you like you can try to revert to Octave 3.8.0 from snapshot.debian.org, you will probably have the same error. This sounds like #743260. Can you get a backtrace of your error and verify that the segfault is in the llvm::TargetRegistry::lookupTarget function? -- mike signature.asc Description: Digital signature
Bug#743260: [pkg-octave/master] Disable JIT on all archs to fix LLVM library conflicts.
tag 743260 pending thanks Date: Sun Apr 6 23:21:45 2014 -0400 Author: Mike Miller Commit ID: 6b6d0ca9b3f5c374fe07e9b49821a2b65d7bdf4e Commit URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff;h=6b6d0ca9b3f5c374fe07e9b49821a2b65d7bdf4e Patch URL: http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=commitdiff_plain;h=6b6d0ca9b3f5c374fe07e9b49821a2b65d7bdf4e Disable JIT on all archs to fix LLVM library conflicts. Fixes segfault when plotting with fltk using certain video drivers. Closes: #743260 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743679: octave: plot(1:4) triggers segfault crash
Control: forcemerge 743260 -1 On Mon, Apr 07, 2014 at 15:15:34 +0800, Hörmetjan Yiltiz wrote: > [...] > to Octave 3.8.1-1 on 20140316, then to Octave 3.8.1-1+b1. I also reverted > back to Octave 3.8.0-5, only to verify that the bug was introduced not by > Octave. As you pointed out, that should be the transition of "mesa package" > that is causing the problem. > [...] > The backtrace of command "axes" are as follows: > [...] > #1 0x71f12779 in llvm::TargetRegistry::lookupTarget(std::string > const&, std::string&) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1 > #2 0x719b27a1 in llvm::EngineBuilder::selectTarget(llvm::Triple > const&, llvm::StringRef, llvm::StringRef, llvm::SmallVectorImpl > const&) () from /usr/lib/x86_64-linux-gnu/libLLVM-3.3.so.1 > #3 0x7fffe47c0bc8 in ?? () from /usr/lib/x86_64-linux-gnu/dri/r600_dri.so > [...] Thanks, that confirms for me that they are the same bug, merging. A fix has already been committed and will be in the next upload of Octave 3.8.1. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743672: octave: save -ascii ignores save_precision
On Sat, Apr 5, 2014 at 01:20:14 +0200, Francesco Potortì wrote: > octave> format long > octave> a=1234567890123 > a = 1234567890123 > octave> save a a > octave> save -ascii a a > octave> quit > $ cat a > 1.23456789e+12 True, but this is not a bug, this is the required behavior for Matlab compatibility. Note that save -ascii is the Matlab compatible way of saving data in a plain text format, while save -text (which is also the default) uses Octave's own plain text format. Use fprintf if you want more control over how data is represented as text. So for compatibility, Octave has to save in a fixed floating-point precision format with -ascii. You can use save -ascii -double to get twice the precision. This option works and is Matlab compatible but doesn't appear to be documented at all in Octave. These formats and options could certainly be documented better. I would take up the issue of improving the documentation upstream, but otherwise there's not much to do about this. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743885: octave: Octave triggers an assertion in Mesa
On Mon, Apr 7, 2014 at 23:51:46 +0200, Thomas Weber wrote: > I am filing the bug right now in the hope that someone has an idea on > how to continue with this - I have no clue whatsoever about Mesa. I am unable to reproduce on my laptop with Intel integrated graphics, and I'm using the same i965 driver that your backtrace lists. I don't know much about mesa either, but it could be that this is hardware dependent since the assertion seems to be coming specifically from the i965 driver. Do you have a different video card you can test on? Any difference when you run the test with LIBGL_ALWAYS_INDIRECT=y in your environment? I see this listed in the mesa upstream bug tracker: https://bugs.freedesktop.org/show_bug.cgi?id=36193 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740993: transition: openconnect
On Tue, May 27, 2014 at 16:19:34 +0200, Emilio Pozuelo Monfort wrote: > I see that those bugs are now fixed in unstable. I suppose that means we can > just binnmu them once openconnect is available in unstable, is that right? That sounds right to me. > Please go ahead and upload openconnect to unstable. There is still some upstream work going on before finalizing the 6.00 release, so there is only the 5.99 beta in experimental for now. Once 6.00 is released upstream I will make sure there is no more additional ABI breakage, and then upload it to unstable, thanks for the go-ahead. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#749820: gnuplot: Uninstallable
(Not maintainer, just interested user.) On Fri, May 30, 2014 at 01:00:06 +0200, Axel Beckert wrote: > since the 4.6.5-2 upload gnuplot is uninstallable at least on amd64: > > gnuplot depends on gnuplot-nox and ( gnuplot-x11 or gnuplot-qt ) > > Both, gnuplot-x11 and gnuplot-qt conflict with gnuplot-nox. It is not uninstallable for me at least. Both gnuplot-x11 and gnuplot-qt provide gnuplot-nox, so either one will satisfy both of the depends. The change I see with 4.6.5-2 is gnuplot and gnuplot-nox can no longer be installed together. Installing gnuplot-nox now removes gnuplot, and installing gnuplot requires either gnuplot-x11 or gnuplot-qt and uninstalls gnuplot-nox. Whether or not that's desired I can't say, but that's the effect I see here at least. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740379: ITP: asciinema -- Record and share your terminal sessions,
On Sat, Mar 08, 2014 at 21:49:54 -0300, gustavo panizzo wrote: > On 02/28/2014 06:03 PM, Paul Tagliamonte wrote: > > I will sponsor this, no problem. > pkg is ready, take a look to it. > > git+ssh://git.debian.org/git/collab-maint/asciinema.git Hi Gustavo, I may not be able to sponsor but I am interested in trying this package out when it is uploaded. I just cloned and tried to build, here is some feedback. * Can you arrange for the git HEAD to point to debian/upstream branch? That way when it is cloned it is ready to build. * The contents of the upstream tarball do not match the state of git at the upstream tag. Also d/gbp.conf sets compression to xz, but upstream is .tar.gz. This confused my build when I ran uscan and then attempted to build the package. Instead I had to delete the .orig.tar.gz fetched by uscan and let gbp create a different .orig.tar.xz from the git tag. This may be an accepted workflow that I'm not used to, but confused me when there is a d/watch with a tarball that breaks the build. * d/rules optionally includes openstack-pkg-tools, but it is not required (I can build without it) and is not listed in Build-Depends. I'm not familiar with openstack packaging, what purpose does including it serve? * pybuild seems to be the preferred way to build Python packages now in Debian, I'd suggest packaging with that instead of python_distutils. It's as simple as adding dh-python to Build-Depends and changing buildsystem to pybuild. - https://wiki.debian.org/Python/Pybuild * I see asciinema supports both Python 2 and 3. If it doesn't matter to users which one is used, why not build it for Python 3 only? Cheers, looking forward to seeing this in Debian, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#741796: network-manager-openconnect: FTBFS [...]
On Sun, Mar 16, 2014 at 13:52:04 +0100, David Suárez wrote: > During a rebuild of all packages in sid, your package failed to build on > amd64. Confirmed here, thanks for the report. This has been fixed upstream and will be included in version 0.9.8.6-1. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742087: network-manager-openconnect: FTBFS with openconnect 5.99-1 from experimental: error: request for member 'label' in something not a structure or union
Package: network-manager-openconnect Version: 0.9.8.4-1 Severity: important The latest version of openconnect includes an API change that breaks the current build. This has been fixed upstream and is in the just-released 0.9.8.6 version of network-manager-openconnect. This bug will be fixed with the next upload of 0.9.8.6-1. The full build log is available at http://people.debian.org/~mtmiller/network- manager-openconnect_0.9.8.4-1_amd64-experimental.build -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742090: plasma-nm: FTBFS with openconnect 5.99-1 from experimental: error: request for member 'label' in ...
Source: plasma-nm Version: 0.9.3.2-3 Severity: important The latest version of openconnect includes an API change that breaks the current version of plasma-nm. Openconnect 5.99-1 is currently in experimental for testing but will soon be beginning a transition in unstable to the new library with the upcoming 6.00 upstream release. Initial support for the new openconnect library has been committed upstream at: http://quickgit.kde.org/?p=plasma-nm.git&a=commitdiff&h=947f56f1cd21a72fa0f88e1c42ac8c19e23864d0 The relevant errors look like: > /«PKGBUILDDIR»/vpn/openconnect/openconnectauth.cpp:444:65: error: request for > member 'label' in '*(sopt->oc_form_opt_select::choices + ((sizetype)(((long > unsigned int)i) * 8ul)))', which is of pointer type 'oc_choice*' (maybe you > meant to use '->' ?) > cmb->addItem(QString::fromUtf8(sopt->choices[i].label), > QString::fromUtf8(sopt->choices[i].name)); > ^ > /«PKGBUILDDIR»/vpn/openconnect/openconnectauth.cpp:444:108: error: request > for member 'name' in '*(sopt->oc_form_opt_select::choices + > ((sizetype)(((long unsigned int)i) * 8ul)))', which is of pointer type > 'oc_choice*' (maybe you meant to use '->' ?) > cmb->addItem(QString::fromUtf8(sopt->choices[i].label), > QString::fromUtf8(sopt->choices[i].name)); > > ^ > /«PKGBUILDDIR»/vpn/openconnect/openconnectauth.cpp:445:65: error: request for > member 'name' in '*(sopt->oc_form_opt_select::choices + ((sizetype)(((long > unsigned int)i) * 8ul)))', which is of pointer type 'oc_choice*' (maybe you > meant to use '->' ?) > if (value == QString::fromUtf8(sopt->choices[i].name)) > ^ The full build log with the relevant errors can be found at: http://people.debian.org/~mtmiller/plasma-nm_0.9.3.2-3_amd64-experimental.build Let me know if I can provide any more information to help with the transition. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740993: transition: openconnect
On Mon, Mar 17, 2014 at 23:01:51 +0100, Julien Cristau wrote: > Are there bugs tracking the needed changes in the reverse deps? Bugs are now filed and set to block this bug. Thanks, -- mike signature.asc Description: Digital signature
Bug#661242: gnome-shell: clock shows UTC time instead of local when POSIX timezone format is specified in the environment
On Wed, Mar 19, 2014 at 15:25:43 +, althaser wrote: > Could you please still reproduce this issue with newer gnome-shell version > like 3.4.2-7+deb7u1 or 3.8.4-5+b1 ? I haven't tried with wheezy yet, but yes this now works for me with the version in jessie. I will check other versions when I get a chance. Thanks for the reminder to revisit this. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742272: ITP: ocserv -- OpenConnect VPN Server
On Fri, Mar 21, 2014 at 21:52:40 +0800, Liang Guo wrote: >Package name: ocserv > Version: 0.3.2 > Upstream Author: Nikos Mavrogiannopoulos > URL: http://www.infradead.org/openconnect/ > License: GPLv2 > Description: OpenConnect VPN Server As maintainer of the OpenConnect client, I have been playing around with my own local packaging of ocserv for some time now but hadn't gotten around to filing an ITP yet. This will be great to get into the Debian archive, thanks for offering to work on this. Let me know if you need help packaging or testing ocserv. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742306: mesa: libwayland-egl1-mesa dependency unsatisfiable on kfreebsd-any
Source: mesa Version: 10.1.0-3 Severity: normal Dear Maintainer, The unstable version of libegl1-mesa-drivers is uninstallable on kfreebsd-any because of an unsatisfiable Depends: libwayland-egl1-mesa (= 10.1.0-3) This appears to be due to the following git commit: http://anonscm.debian.org/gitweb/?p=pkg-xorg/lib/mesa.git;a=commitdiff;h=3d2e8e66ce9c5c07a73f45ef01b9ade475ef5a13 in which this library package is introduced and built for linux-any, but is added to the Depends of libegl1-mesa-drivers without any arch restriction. This dependency should probably be restricted to apply to linux architectures only. Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#742503: octave 3.8.1 requires java
Control: found -1 3.8.1-1 Control: notfound -1 3.6.4-4+b2 Control: severity -1 wishlist Control: tags -1 + moreinfo On Mon, Mar 24, 2014 at 14:30:30 +, Leo Butler wrote: > Since Octave introduced its java-dependent gui (congrats) in v3.8.1, I > have been unable/unwilling to upgrade. I believe that these graphical > dependencies should be downgraded to *recommended* and/or a separate > octave-nox package--which installs only a terminal version of > octave--be provided. Thanks for your bug report and feedback on octave packaging. The request for an octave-nox package is already reported as #741097, you might want to read the discussion and comment there. But actually the addition of a dependency on java has nothing to do with the GUI. The java dependency is to allow the Octave interpreter to run an embedded JVM and interface with java libraries from the interpreter. This essentially merges the functionality of the former octave-java add-on package into octave itself. This is a feature which makes the Octave runtime environment more compatible with Matlab. A hypothetical octave-nox terminal-mode package would likely still be dependent on java. Can you clarify whether your primary concern is having an Octave package that does not have the libraries needed for a GUI which you find unnecessary, or is it the inclusion of java for whatever reason? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#696719: ITP: mock -- build rpm packages inside a chroot
On Wed, Dec 26, 2012 at 6:55 AM, Tzafrir Cohen wrote: > Mock was previously packaged in Debian, but unmaintained and eventually > removed: > http://bugs.debian.org/616383 > I believe it can be handy for us and would like to re-introduce it. Good to see this, I've been using mock locally for some time now myself, extremely useful to me. Let me know if you need help testing or whatever. I am working on packaging yum-utils (#547171) which looks like it should be in Depends for mock. Thanks, looking forward to testing what you have so far. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#698222: git-import-dsc: does not merge already-imported upstream version
Package: git-buildpackage Version: 0.6.0~git20121124 Severity: wishlist I found the following steps do not work: git-import-orig --no-merge ../foo_1.2.orig.tar.gz git-import-dsc ../foo_1.2-1.dsc The resulting debian/1.2-1 commit is a child of only master, it does not properly merge upstream/1.2 at all. The reason I needed this is because git-import-orig is the only interface with --upstream-vcs-tag. I am importing packages from snapshot.d.o and I want the upstream branch to derive from upstream's git repo. Therefore I needed to import-orig first, then import dsc(s) for that version. The logic in import_dsc seems to assume that if the upstream tag already exists, then it must have already been merged into the debian branch. More robust logic might be to check the ancestry of the debian branch to see if it contains the upstream tag or not. I was able to get by with the following hack that only solves this case but breaks the normal case: diff --git a/gbp/scripts/import_dsc.py b/gbp/scripts/import_dsc.py index 28ceb2e..6b60f00 100644 --- a/gbp/scripts/import_dsc.py +++ b/gbp/scripts/import_dsc.py @@ -344,6 +344,8 @@ def main(argv): parents = [ options.upstream_branch ] if is_empty and not repo.has_branch(options.debian_branch): repo.create_branch(options.debian_branch, commit) +else: +parents = [ options.upstream_branch ] if not src.native: if src.diff or src.deb_tgz: apply_debian_patch(repo, upstream.unpacked, src, options, parents) -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages git-buildpackage depends on: ii devscripts 2.12.6 ii git 1:1.7.10.4-1+wheezy1 ii python 2.7.3~rc2-1 ii python-dateutil 1.5+dfsg-0.1 Versions of packages git-buildpackage recommends: ii cowbuilder0.70 ii pristine-tar 1.25 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-3 ii unzip 6.0-8 -- 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#698222: git-import-dsc: does not merge already-imported upstream version
On Tue, Jan 15, 2013 at 10:15 AM, Guido Günther wrote: > On Tue, Jan 15, 2013 at 08:43:59AM -0500, Mike Miller wrote: >> I found the following steps do not work: >> >> git-import-orig --no-merge ../foo_1.2.orig.tar.gz >> git-import-dsc ../foo_1.2-1.dsc >> >> The resulting debian/1.2-1 commit is a child of only master, it does not >> properly merge upstream/1.2 at all. >> >> [...] > > It seems that we might want to move the upstream-vcs-tag logic to > git-import-dsc then. Makes sense, that would address what I was really trying to do. If there's no other use case for doing separate import-orig followed by import-dsc, feel free to redefine this bug as "support git-import-dsc --upstream-vcs-tag". Even better would be to somehow support upstream-vcs-tags with "git-import-dscs --debsnap" but I'm not sure how you would map multiple versions to tags without an unwieldy interface. > * Don't you still want to import the upstream tarball too? Yes, I used --pristine-tar on the import-orig. > Escpecially when using git-import-dsc I think we should do: > > * import upstream tarball with the possibility to have the upstream VCS > tag as parent (as with git-import-orig) > * proceed from there as usual > > There wouldn't be any need for using git-import-orig then. > > Patches are welcome. Sounds good, thanks for the feedback, I'll look at that. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#697222: yum exists when printing certain errors: 'rpm.prob' object has no attribute 'startswith'
fixed 697222 yum/3.4.3-1 forwarded 697222 https://bugzilla.redhat.com/show_bug.cgi?id=552178 thanks On Wed, Jan 2, 2013 at 3:43 PM, Tzafrir Cohen wrote: > /usr/bin/yum --installroot /srv/mock/root/epel-6-x86_64/root/ groupinstall > buildsys-build > > It starts updating sources and locating packages. Then it gives the > following (given here with a PoC patch): I assume you mean it gives the error mentioned in the bug title. > but this is an issue for a different bug report, if any. This was because > I was foolish enough to run that from a 32bit system. If you install a i386 chroot or run on an amd64 host does yum complete without a crash? I have not tried to reproduce this yet, but this looks like upstream BZ 552178 which was fixed in yum 3.2.26. Can you please test this patch to see if it fixes your error case: http://yum.baseurl.org/gitweb?p=yum.git;a=commitdiff;h=0111d892922ba35c51287b273ed954afdc97e7e4 So it looks like yum is incompatible with rpm in wheezy to some extent, at least in error handling, possibly in other ways. Thanks, -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690240: network-manager-openconnect-gnome: crashes gnome-shell when connection succeeds
severity 690240 serious thanks On Thu, Nov 1, 2012 at 3:24 PM, CruX wrote: > I'm having this exact same issue, but I'd like to add a little more > info in case it's useful. > > I have two machines, an old one where I never had this issue. Same > debian release and preferences, and obviously, same packages version. > I've had the VPN configured for about a month. > > On the new machine I installed wheezy about a week ago and then I also > configured the same VPN. On this machine gnome-shell crashes EVERY > time I try to connect to the VPN. > > I tried spotting the differences on gconf, dconf, /etc/NetworkManager, > $HOME, etc. but haven't been able to find anything useful. > > Let me know if my setup can help you with anything. Thanks for the additional information. I think I'm justified in bumping this to serious, since it affects a fair number of users (over 3 duplicate reports) and, at least in your case and very likely many others, makes the package completely unusable. I am uploading a fix to unstable now, what you can do to help is install this update from unstable once it shows up in the archive and report back here if the problem persists. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691065: unblock (pre-approval): network-manager-openconnect/0.9.4.0-8
retitle 691065 unblock: network-manager-openconnect/0.9.4.0-8 thanks On Sat, Oct 20, 2012 at 05:38:47PM -0400, Mike Miller wrote: > Dear Release Team, > > I would like to upload a new network-manager-openconnect that fixes an > RC bug (#687557 and duplicates). Without this fix the gnome-shell window > manager crashes and the VPN connection fails, unreliably but somewhere > between occasionally and frequently. Just updating status: I have gone ahead and uploaded the proposed package to unstable, debdiff remains the same. I hope you will consider allowing this into the wheezy release, thanks for your time. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691065: unblock (pre-approval): network-manager-openconnect/0.9.4.0-8
On Fri, Nov 02, 2012 at 10:03:55AM +, Adam D. Barratt wrote: > I'm possibly missing something, but...: > > ++ g_string_append_c (str, c); > ++ if (strstr (str->str, "QUIT") || (str->len > 10)) > ++ break; > > Isn't that "wait for QUIT or any 11 eleven characters", rather than > "wait for QUIT"? Yes, this is true. This is a helper program spawned from NM applet or gnome-shell and communicating over a pipe. The NM authentication helper programs all use the identical wait_for_quit function, which is really waiting for the first of any of the following "semaphores" from the parent: 1) "QUIT" 2) any 11 characters 3) any I/O error 4) any input after 20 seconds elapsed Any of these events allow the function to return, which in turn allows the program to exit normally. The contents of str are not used in any other way. I suppose the length limit here is to avoid accumulating a large buffer just in case the parent process sends something other than QUIT for some reason. Thanks for your feedback. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674243: Dell XPS 14z: Kernel crash when closing the lid
On Tue, Aug 28, 2012 at 09:05:03PM -0400, Sylvain Archenault wrote: > After a lot of tries, I found out which module causes the crash, > it's CONFIG_HOTPLUG_PCI_ACPI (module acpiphp). > > When it's built as a module, it's not loaded by default on my > machine, and closing the lid works. But if I load it, it crashes. I have the same laptop with the same lid closure crash. I was about to rebuild with this config change to try it when I found updating to the latest 3.6 experimental package fixed it for me. Can you try installing linux-image-3.6-trunk-amd64 from experimental and confirm? Summary of versions I have tried: * linux-image-3.2.0-4-amd64/3.2.32-1 crashes * linux-image-3.5-trunk-amd64/3.5.2-1~experimental.1 crashes * linux-image-3.6-trunk-amd64/3.6.4-1~experimental.1 works -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#674243: Dell XPS 14z: Kernel crash when closing the lid
fixed 674243 linux/3.2.32-1 thanks Correcting my earlier bogus assertion, I just tested 3.2.32 and it *does* work, it no longer hangs my XPS 14z. Apologies all, I must have tested with an earlier 3.2.x before and somehow overlooked 3.2.32 when I was testing this weekend. On Tue, Nov 13, 2012 at 09:53:44PM -0500, Sylvain Archenault wrote: > I install the latest trunk version, and I was unable to load the > module acpiphp. I haven't looked at deeply, is it built-in? which > would explain why I am not able to load it !!! Yes, it will continue to be built in to the kernel (see #663433). > On my 3,6,2 I built from source, every time I try to load it I have > this error: > > [ 650.277617] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5 > [ 650.278069] acpiphp_glue: can't evaluate _ADR (0x5) > > Which I also found in mike dmesg log. > > So I'm thinking that maybe since 3.6, there is a "fix" that prevents > the module from being loaded if it can't. I found this: > http://www.mail-archive.com/stable@vger.kernel.org/msg18981.html Yes, I think that is exactly it, thanks for pointing that out. I read your message, checked the commit log, saw that this fix should be in 3.2.32, prompting me to double-check and sure enough it does work. Can you confirm that the crash is gone for you as well running the 3.2.32-1 Debian kernel? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#690240: network-manager-openconnect-gnome: crashes gnome-shell when connection succeeds
tags 690240 confirmed thanks On Thu, Oct 11, 2012 at 8:33 AM, Brice Goglin wrote: > Package: network-manager-openconnect-gnome > Version: 0.9.4.0-7 > Severity: normal > > Dear Maintainer, > > Everytime I connect my openconnect VPN with the NM gnome applet, > I enter my login/passwd as usual, and gnome-shell crashes (and restarts) > once the connection succeeds. > I tried upgrading openconnect to experimental, it didn't crash gnome-shell > but it failed to connect. Do you get a successful connection after gnome-shell restarts or not? I see gnome-shell crash and the connection does not succeed for me. The nm-openconnect-service is running but openconnect is not. Does this match what you're seeing? > Looks similar to > https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/990108 Do you by chance have a stack trace similar to the one in this bug report? Do you have any other VPN connections you can try to see if the same crash occurs? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691065: unblock (pre-approval): network-manager-openconnect/0.9.4.0-8
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Dear Release Team,
I would like to upload a new network-manager-openconnect that fixes an
RC bug (#687557 and duplicates). Without this fix the gnome-shell window
manager crashes and the VPN connection fails, unreliably but somewhere
between occasionally and frequently.
The debdiff is included below, does this look reasonable to upload and
make it into the wheezy release?
Thanks for all your work,
mike
diffstat for network-manager-openconnect-0.9.4.0
network-manager-openconnect-0.9.4.0
changelog |8 ++
patches/05_Wait-for-QUIT-command-before-exiting.patch | 51 ++
patches/series|1
3 files changed, 60 insertions(+)
diff -Nru network-manager-openconnect-0.9.4.0/debian/changelog
network-manager-openconnect-0.9.4.0/debian/changelog
--- network-manager-openconnect-0.9.4.0/debian/changelog2012-06-02
11:00:50.0 -0400
+++ network-manager-openconnect-0.9.4.0/debian/changelog2012-10-20
16:59:22.0 -0400
@@ -1,3 +1,11 @@
+network-manager-openconnect (0.9.4.0-8) unstable; urgency=low
+
+ * debian/patches/05_Wait-for-QUIT-command-before-exiting.patch:
+Cherry-pick patch from upstream git to fix a race condition causing
+gnome-shell to crash. (Closes: #687557)
+
+ -- Mike Miller Sat, 20 Oct 2012 16:59:21 -0400
+
network-manager-openconnect (0.9.4.0-7) unstable; urgency=low
* New patches pulled from upstream git fixing auth-dialog bugs:
diff -Nru
network-manager-openconnect-0.9.4.0/debian/patches/05_Wait-for-QUIT-command-before-exiting.patch
network-manager-openconnect-0.9.4.0/debian/patches/05_Wait-for-QUIT-command-before-exiting.patch
---
network-manager-openconnect-0.9.4.0/debian/patches/05_Wait-for-QUIT-command-before-exiting.patch
1969-12-31 19:00:00.0 -0500
+++
network-manager-openconnect-0.9.4.0/debian/patches/05_Wait-for-QUIT-command-before-exiting.patch
2012-10-20 16:31:10.0 -0400
@@ -0,0 +1,51 @@
+From: Dan Winship
+Origin: upstream,
http://git.gnome.org/browse/network-manager-openconnect/commit/?id=d0c4ce17395d48566300e7bdd25a06617d13ecb3
+Bug: https://bugzilla.gnome.org/show_bug.cgi?id=674991
+Bug-Debian: http://bugs.debian.org/687557
+Subject: [PATCH] Wait for "QUIT" command before exiting
+
+According to the NM VPN auth dialog "protocol", the helper isn't
+supposed to exit until the caller sends "QUIT". Doing otherwise
+creates a race condition. Copy in the code that the other plugins use
+for this.
+--- a/auth-dialog/main.c
b/auth-dialog/main.c
+@@ -1434,6 +1434,30 @@ static auth_ui_data *init_ui_data (char
+ return ui_data;
+ }
+
++static void wait_for_quit (void)
++{
++ GString *str;
++ char c;
++ ssize_t n;
++ time_t start;
++
++ str = g_string_sized_new (10);
++ start = time (NULL);
++ do {
++ errno = 0;
++ n = read (0, &c, 1);
++ if (n == 0 || (n < 0 && errno == EAGAIN))
++ g_usleep (G_USEC_PER_SEC / 10);
++ else if (n == 1) {
++ g_string_append_c (str, c);
++ if (strstr (str->str, "QUIT") || (str->len > 10))
++ break;
++ } else
++ break;
++ } while (time (NULL) < start + 20);
++ g_string_free (str, TRUE);
++}
++
+ static struct option long_options[] = {
+ {"reprompt", 0, 0, 'r'},
+ {"uuid", 1, 0, 'u'},
+@@ -1538,5 +1562,7 @@ int main (int argc, char **argv)
+ printf("\n\n");
+ fflush(stdout);
+
++ wait_for_quit ();
++
+ return _ui_data->retval;
+ }
diff -Nru network-manager-openconnect-0.9.4.0/debian/patches/series
network-manager-openconnect-0.9.4.0/debian/patches/series
--- network-manager-openconnect-0.9.4.0/debian/patches/series 2012-06-02
09:29:36.0 -0400
+++ network-manager-openconnect-0.9.4.0/debian/patches/series 2012-10-20
16:22:35.0 -0400
@@ -1,3 +1,4 @@
01_implement-proper-cancellation.patch
02_fix-ignoring-return-value.patch
04_fix-hitting-cancel-after-failure.patch
+05_Wait-for-QUIT-command-before-exiting.patch
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691311: [Pkg-octave-devel] Bug#691311: Bug#691311: error: feval: function `unimplemented' not found
On Wed, Oct 24, 2012 at 4:32 AM, Sébastien Villemot wrote: > It appears that octave 3.6.2 does not work with liboctave1 3.6.3, and > conversely octave 3.6.3 does not work with liboctave1 3.6.2. I took a look at this and the problem is simply that the load path contains Octave's version number. No soname incompatibility. And unless something is changed, this will continue to be the case between different upstream versions of octave and liboctaveX. The octave package provides the directories, and liboctinterp.so.1 has a compiled-in set of paths with its version number that it attempts to load. You can see these paths with: $ strings /usr/lib/x86_64-linux-gnu/liboctinterp.so.1 | grep /3.6../ If I print the default path from a working 3.6.3: $ octave -qf --eval "disp(path)" then downgrade liboctave1/sid and set that full string to be the path in the interpreter: $ octave -qf octave:1> ls error: feval: function `unimplemented' not found octave:1> path (full_path_here); octave:2> ls no more error. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#691342: rpm: install missing manpages, remove obsolete links
Package: rpm Version: 4.10.1-1 Severity: normal Tags: patch Originally reported at https://bugs.launchpad.net/bugs/1018372 Upstream provides manpages for rpmdb and rpmsign, so these should be installed and not replaced with links to rpm.8. The rpme, rpmi, and rpmu aliases to rpm are no longer present, so there's no need for manpages for nonexistent commands. --- debian/rpm.links |5 - 1 file changed, 5 deletions(-) diff --git a/debian/rpm.links b/debian/rpm.links index bea8b18..90ac8b8 100644 --- a/debian/rpm.links +++ b/debian/rpm.links @@ -1,7 +1,2 @@ -usr/share/man/man8/rpm.8 usr/share/man/man8/rpmdb.8 -usr/share/man/man8/rpm.8 usr/share/man/man8/rpme.8 -usr/share/man/man8/rpm.8 usr/share/man/man8/rpmi.8 usr/share/man/man8/rpm.8 usr/share/man/man8/rpmquery.8 -usr/share/man/man8/rpm.8 usr/share/man/man8/rpmsign.8 -usr/share/man/man8/rpm.8 usr/share/man/man8/rpmu.8 usr/share/man/man8/rpm.8 usr/share/man/man8/rpmverify.8 -- 1.7.10.4 -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpm depends on: ii libc6 2.13-35 ii libelf1 0.152-1+b1 ii libpopt0 1.16-7 ii librpm3 4.10.1-1 ii librpmbuild3 4.10.1-1 ii librpmio3 4.10.1-1 ii librpmsign1 4.10.1-1 ii perl 5.14.2-14 ii rpm-common4.10.1-1 ii rpm2cpio 4.10.1-1 rpm recommends no packages. Versions of packages rpm suggests: ii alien 8.87 pn elfutils pn rpm-i18n -- 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#683759: need to provide rpmlib(X-CheckUnifiedSystemdir) for f17
On Mon, 6 Aug 2012 09:21:08 +0200 Michal Čihař wrote:
> Hi
>
> Dne Fri, 3 Aug 2012 17:55:53 +0200
> Julien Cristau napsal(a):
>
> > I'm using mock to create chroots for centos/fedora, and 'sudo mock
> > -r fedora-17-x86_64' fails with:
> >
> > [('rpmlib(X-CheckUnifiedSystemdir) is needed by
> > setup-2.8.48-1.fc17.noarch', (4, 'rpmlib(X-CheckUnifiedSystemdir)',
> > 0L)), ('rpmlib(X-CheckUnifiedSystemdir) is needed by
> > filesystem-3-2.fc17.x86_64', (4, 'rpmlib(X-CheckUnifiedSystemdir)',
> > 0L))]
> >
> > It would be nice if that was somehow worked around in debian's rpm
> > package.
>
> This is added by vendor patch to rpm:
>
> - this is Fedora only patch
> - itself is marked as "temporary support for live-conversion"
> - they plan to remove the patch in Fedora 19
>
> Given we're now in freeze, I don't think this would be important
> enough to gain freeze exception. And this patch would not make much
> sense for future stable release (as it will be already gone from
> Fedora by that time anyway).
>
> IMHO better approach would be if mock could fake this dependency as it
> is not doing live conversion and it should not matter.
I just ran into this same problem. If we do not apply this vendor patch
to rpm, do you have any suggestions of other ways to work around it? The
only thing I can think of would be to build a fake dependency RPM and
install it into the mock chroot somehow before mock runs yum install. A
bit awkward compared to applying a vetted patch from essentially
upstream.
Keep in mind, you can use a straight yum command to build a Fedora
chroot and get the same error, so it's not just a problem for mock to
solve.
This may only affect F17 and F18 for now, but that means 2 or 3 years
from now if I want to install a F18 chroot the problem is still there.
Also this may appear in the next RHEL7 release.
--
mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678569: transition: openconnect
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Dear Release Team, I'd like to upload the latest version of openconnect to unstable. Updating from 3.20 to 4.00 brings a new ABI with a new soname for libopenconnect. The only source package affected is network-manager-openconnect, for which I am also maintainer. I am currently updating it to make use of the API changes, so there will be a sourceful upload of that ready soon as well, no need for a binNMU. I completely understand if this is delayed due to the imminent release freeze, this upstream version just happened to come out this week. Ben file: title = "openconnect"; is_affected = .build-depends ~ /libopenconnect-dev/; is_good = .depends ~ /libopenconnect2/; is_bad = .depends ~ /libopenconnect1/; Please let me know if/when I can upload to unstable. Thanks! -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678569: transition: openconnect
On Fri, Jun 22, 2012 at 5:12 PM, Julien Cristau wrote: > On Fri, Jun 22, 2012 at 23:00:26 +0200, Luk Claes wrote: > >> On 06/22/2012 09:04 PM, Julien Cristau wrote: >> > On Fri, Jun 22, 2012 at 14:50:44 -0400, Mike Miller wrote: >> > >> >> I'd like to upload the latest version of openconnect to unstable. >> >> Updating from 3.20 to 4.00 brings a new ABI with a new soname for >> >> libopenconnect. >> >> >> > Unless the current version is completely broken, I don't think we should >> > do this. No, the current version is not even slightly broken. >> Are you seriously almost objecting to uploading 2 closely related >> packages which would bring needed bug fixes for its users just because >> the maintainer is so polite to ask? Did you even read further or did you >> stop at that sentence? >> > I didn't see anything about bug fixes in the initial mail. No bugs are fixed by this update alone. However this version would unblock #669702 which has a patch available and adds real functionality for our KDE desktop users. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#678887: rpm-common: /usr/lib/rpm/macros defines incorrect default version of python
Package: rpm-common Version: 4.10.0-2 Severity: normal Tags: patch Dear Maintainer, The /usr/lib/rpm/macros file contains a definition of %__python that points to /usr/bin/python2.6 on my system, which is not the current default version. I believe this is due to the order in which the rpm package is built in debian/rules against different versions of python. The included patch fixes this for me by building against the "extra" pythons first, then the default python. -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpm-common depends on: ii libc6 2.13-33 ii librpm34.10.0-2 ii librpmio3 4.10.0-2 rpm-common recommends no packages. rpm-common suggests no packages. -- no debconf information >From 717fb4b2ac018b81e7a2ebc70f25b19f53af296e Mon Sep 17 00:00:00 2001 From: Mike Miller Date: Sun, 24 Jun 2012 16:40:29 -0400 Subject: [PATCH] Configure alternate python versions before default --- debian/rules |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/debian/rules b/debian/rules index b216a5a..ca895de 100755 --- a/debian/rules +++ b/debian/rules @@ -27,20 +27,20 @@ configure_flags += \ CPPFLAGS="$(CPPFLAGS)" override_dh_auto_configure: - dh_auto_configure --builddirectory=b-default -- $(configure_flags) set -e -x; for p in $(PYEXTRA) ; do \ dh_auto_configure --builddirectory=b-python-$$p -- $(configure_flags) \ PYTHON=/usr/bin/python$$p \ __PYTHON=/usr/bin/python$$p ;\ done + dh_auto_configure --builddirectory=b-default -- $(configure_flags) override_dh_auto_build: - dh_auto_build --builddirectory=b-default set -e -x; for p in $(PYEXTRA) ; do dh_auto_build --builddirectory=b-python-$$p ; done + dh_auto_build --builddirectory=b-default override_dh_auto_install: - dh_auto_install --builddirectory=b-default set -e -x; for p in $(PYEXTRA) ; do dh_auto_install --builddirectory=b-python-$$p ; done + dh_auto_install --builddirectory=b-default # Kill all the junk this installs. rm -f debian/tmp/usr/lib/rpm/config.guess \ debian/tmp/usr/lib/rpm/config.sub \ -- 1.7.10
Bug#680963: network-manager-gnome: Cannot connect to VPN with nm-applet
On Wed, Jul 11, 2012 at 03:57:13PM +0200, Michael Biebl wrote: > > I never get the VPN dialog anymore, not even with the method described > > in the first post. > > Ok, so it is even worse with this patch applied :-/ > > Thanks for testing the patched packages anyway. I just started testing the 0.9.6-rc1 packages in experimental and I am seeing this same behavior there as well. And only with gnome3, with the fallback session the auth dialog comes up as usual. The following workaround works for me: cd /usr/lib/gnome-shell ln -s ../NetworkManager/nm-openconnect-auth-dialog and then restart gnome-shell or log out and log in. This seems to be the only path where gnome-shell is looking for the auth-dialog executable [1]. [1] http://git.gnome.org/browse/gnome-shell/tree/js/ui/networkAgent.js#n681 -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681737: run vpn authentication dialogs from correct path
tags 681737 patch thanks On Sun, Jul 15, 2012 at 11:53 PM, Michael Biebl wrote: > So it seems we need two fixes here: > 1/ nm-applet needs to reliably disable itself if gnome-shell is used > 2/ gnome-shell needs to look at the right place for the authentication > dialogs. > > Problem 2/ is most likely caused by Redhat distros using $libexecdir: > /usr/lib/gnome-shell → /usr/libexec and > /usr/lib/NetworkManager → /usr/libexec This has apparently been reported and tentatively fixed upstream, bug report and patch: https://bugzilla.gnome.org/show_bug.cgi?id=679212 http://git.gnome.org/browse/gnome-shell/commit/?id=8845a2170c01f83ac23b54ef6f6389b94b142f78 With this patch gnome-shell expects the NM plugins to specify the full path in auth-dialog. If that's the right way to go, now each VPN plugin needs to fix their config files, and possibly nm-applet to work with that change to auth-dialog. Clone and assign to each VPN package + nm-gnome? -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685353: qemu-kvm: kvm process hangs with 100% CPU usage
On Mon, Aug 20, 2012 at 08:01:15AM +0200, Mike Gerber wrote: > > I currently run 3 VMs using libvirt/qemu-kvm. Two of them are mostly idle and > stable, but the third one locks up within 1 or 2 days. This third VM > uses an emulated ES1370 sound card (host has an ASUS Xonar DX sound card), > to stream host audio input to an icecast server using darkice. > > The hanging kvm process uses 100% CPU, there's no serial console anymore, no > access to VNC anymore. No output on netconsole either. Unfortunately, I cannot > even get a useful gdb backtrace: Hi, I think I am seeing a similar manifestation of this bug. Please let me know if you agree this is the same or if I should report it separately. I have several VMs of different distros, all pretty much the same hardware configuration, with ich6 sound emulation. Recently the Fedora 17 VM started hanging during every boot, 100% cpu used. The guest console reports a kernel error related to sound. If I remove the sound card from the guest hardware configuration it boots fine. I can give more details and help debug, I just don't have them at the moment. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682207: [Pkg-octave-devel] Bug#682207: Bug#682207: octave: using dpkg-architecture at run time is a bad idea
On Fri, Jul 20, 2012 at 01:50:49PM +0200, Sébastien Villemot wrote:
> Andreas Beckmann writes:
>
> > octave depends on dpkg-dev in order to use dpkg-architecture at runtime.
> > This is a bad idea. The path that is being computed in this way needs to
> > be built into the binary.
> >
> > The current approach will fail in a multiarch installation of octave:
> > dpkg-architecture will report information about the primary
> > architecture, but octave may be installed from another architecture and
> > will be using a wrong path ...
>
> My understanding is that it is not possible to install a non-multi-arch
> aware package (like octave) from another architecture, so that the
> scenario that you describe cannot materialize. Am I wrong?
This is not correct. You can install a foreign architecture package as
long as all dependencies are either multi-arch-aware or there are no
conflicts.
# dpkg --print-architecture
amd64
# dpkg --print-foreign-architectures
i386
# apt-cache show screen | grep Multi
# apt-get install screen:i386
...
# screen --version
Screen version 4.01.00devel (GNU) 2-May-06
# file /usr/bin/screen
/usr/bin/screen: setgid ELF 32-bit LSB executable, ...
> > And the dpkg-dev dependency needs to be dropped.
>
> Why is this dependency a problem (independently of the above issue)?
I don't think it's a policy problem, but it does pull in a lot of
unneeded packages.
In any event, here's a patch against the experimental branch that has
the added bonus of using built-in octave functions instead of system(),
ok to commit?
--
mike
>From a143539b59db5e4ca66f1010aca981ce7e9ed815 Mon Sep 17 00:00:00 2001
From: Mike Miller
Date: Fri, 20 Jul 2012 19:39:31 -0400
Subject: [PATCH] Modify octave.conf to set pkg prefix without
dpkg-architecture
Remove dependency on dpkg-dev.
Closes: #682207
---
debian/control |3 +--
debian/octave.conf |7 ---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/debian/control b/debian/control
index 94dc66b..ed43e0d 100644
--- a/debian/control
+++ b/debian/control
@@ -23,8 +23,7 @@ Vcs-Browser: http://git.debian.org/?p=pkg-octave/octave.git
Package: octave
Architecture: any
-Depends: ${shlibs:Depends}, ${misc:Depends}, texinfo, octave-common (= ${source:Version}),
- dpkg-dev (>= 1.16.0)
+Depends: ${shlibs:Depends}, ${misc:Depends}, texinfo, octave-common (= ${source:Version})
Recommends: gnuplot-x11 | gnuplot-qt, libatlas3-base | libopenblas-base
Suggests: octave-info,
octave-doc,
diff --git a/debian/octave.conf b/debian/octave.conf
index 687659a..2896f80 100644
--- a/debian/octave.conf
+++ b/debian/octave.conf
@@ -22,9 +22,10 @@ pkg global_list /usr/share/octave/octave_packages;
## Adjust pkg prefix
-[~, target] = system("dpkg-architecture -qDEB_HOST_MULTIARCH");
-pkg ("prefix", "/usr/share/octave/packages", [ "/usr/lib/" strtrim(target) "/octave/packages/"]);
-clear target
+suffix = "/octave/packages";
+pkg ("prefix", sprintf ("%s%s", octave_config_info ("datadir"), suffix),
+ sprintf ("%s%s", octave_config_info ("libdir"), suffix));
+clear suffix;
## This appears here instead of in the pkg/PKG_ADD file so that --norc
## will also skip automatic loading of packages.
--
1.7.10.4
Bug#682207: [pkg-octave/master] Modify octave.conf to set pkg prefix without dpkg-architecture
tag 682207 pending thanks Date: Fri Jul 20 19:39:31 2012 -0400 Author: Mike Miller Commit ID: ecf9137782ad2329687cdb8f9e7d5c92cae64176 Commit URL: http://git.debian.org/?p=pkg-octave/octave.git;a=commitdiff;h=ecf9137782ad2329687cdb8f9e7d5c92cae64176 Patch URL: http://git.debian.org/?p=pkg-octave/octave.git;a=commitdiff_plain;h=ecf9137782ad2329687cdb8f9e7d5c92cae64176 Modify octave.conf to set pkg prefix without dpkg-architecture Remove dependency on dpkg-dev. Closes: #682207 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682207: [Pkg-octave-devel] Bug#682207: Bug#682207: Bug#682207: Bug#682207: octave: using dpkg-architecture at run time is a bad idea
On Sat, Jul 21, 2012 at 3:24 AM, Sébastien Villemot wrote: > Mike Miller writes: >> In any event, here's a patch against the experimental branch that has >> the added bonus of using built-in octave functions instead of system(), >> ok to commit? > > Thanks for the patch, it looks good. > > I would rather have it applied to the master branch. The present bug > being of severity important, its fix can be accepted into Wheezy per > freeze policy. Sounds good, just pushed to master. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#664297: [NMU] yum-metadata-parser: Helping to update to packaging format 3.0
On Fri, Apr 06, 2012 at 01:38:58PM +0300, Jari Aalto wrote: > I'm planning to NMU with changes listed in previous mail's patch to help > migrate away from deprecated dpatch. > > Please let me know if an update is alredy being worked on, or if the > previous patch needs adjustments, or if there is anything that should > delay the NMU. Hi Jari, I don't think there's a need for an NMU as it wouldn't get into unstable now anyway. I've recently adopted this package as of last week and I'm working on incorporating your patch. This will go into unstable after the freeze thaws. Thanks for your contribution! -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681737: Bug#682960: unblock (pre-aproval): gnome-shell/3.4.2-1
On Fri, Jul 27, 2012 at 7:21 AM, Laurent Bigonville wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: freeze-exception > > Hi, > > Please unblock package gnome-shell > > This new stable release is fixing severals bugs with telepathy > notifications and other issues as well. Just happened to spot this, sorry if I'm intruding, but how about fixing RC bug #681737 in this release? It's an easy cherry-pick patch, fuzz-free, I've been running with this patch applied for over a week with no problems. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#682960: unblock (pre-aproval): gnome-shell/3.4.2-1
On Sat, Jul 28, 2012 at 12:44:13AM +0200, Michael Biebl wrote: > Am 28.07.2012 00:31, schrieb Mike Miller: > > Just happened to spot this, sorry if I'm intruding, but how about > > fixing RC bug #681737 in this release? It's an easy cherry-pick patch, > > fuzz-free, I've been running with this patch applied for over a week > > with no problems. > > While we should definitely fix this issue for wheezy, the upstream patch > only works, if we update *all* NM vpn plugins to supply an absolute path > in their corresponding .name file. (I assume you manually patched the > .name file on your local system?) Yes. > It might be easier to just change gnome-shell to look for the > vpn-auth-dialogs in /usr/lib/NetworkManager instead of Config.LIBEXECDIR > (which expands to /usr/lib/gnome-shell). True enough. That was how I was looking at it until I ran across the upstream bug report. Solving it that way is slightly more coordination now, but it's future-proof and less coordination later. If you all decide hardcoding gnome-shell to /usr/lib/NetworkManager is the best for wheezy, that's fine too. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#681737: Bug#682960: unblock (pre-approval): gnome-shell/3.4.2-1
On Sat, Jul 28, 2012 at 11:51:06AM +0200, Laurent Bigonville wrote:
> Le Fri, 27 Jul 2012 19:47:41 -0400,
> Mike Miller a écrit :
>
> > On Sat, Jul 28, 2012 at 12:44:13AM +0200, Michael Biebl wrote:
> > > Am 28.07.2012 00:31, schrieb Mike Miller:
> > > > Just happened to spot this, sorry if I'm intruding, but how about
> > > > fixing RC bug #681737 in this release? It's an easy cherry-pick
> > > > patch, fuzz-free, I've been running with this patch applied for
> > > > over a week with no problems.
> > >
> > > While we should definitely fix this issue for wheezy, the upstream
> > > patch only works, if we update *all* NM vpn plugins to supply an
> > > absolute path in their corresponding .name file. (I assume you
> > > manually patched the .name file on your local system?)
> >
> > Yes.
> >
> > > It might be easier to just change gnome-shell to look for the
> > > vpn-auth-dialogs in /usr/lib/NetworkManager instead of
> > > Config.LIBEXECDIR (which expands to /usr/lib/gnome-shell).
> >
> > True enough. That was how I was looking at it until I ran across the
> > upstream bug report. Solving it that way is slightly more coordination
> > now, but it's future-proof and less coordination later.
> >
> > If you all decide hardcoding gnome-shell to /usr/lib/NetworkManager is
> > the best for wheezy, that's fine too.
> >
>
> I think both should be done as some VPN modules (like nm-strongswan)
> are already using a full path.
>
> I've added the following patch to the package. I'm waiting RT ack
> before pushing everything to the svn.
>
> =8<==
>
> Description: Use Debian specific NM VPN helpers paths
> Author: Laurent Bigonville
> Forwarded: not-needed
>
> --- a/js/ui/networkAgent.js
> +++ b/js/ui/networkAgent.js
> @@ -685,7 +685,7 @@ const NetworkAgent = new Lang.Class({
> } catch(e) { } // ignore errors if key does not exist
> let path = binary;
> if (!GLib.path_is_absolute(path)) {
> -path = GLib.build_filenamev([Config.LIBEXECDIR,
> path]);
> +path =
> GLib.build_filenamev(['/usr/lib/NetworkManager/VPN', path]);
Except the Debian path is /usr/lib/NetworkManager without the VPN part.
Fix that, and this looks good to me. Thanks!
--
mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#683867: grub-installer: Fails to install grub: line 45: syntax error: unexpected else
Package: grub-installer Version: 1.76 Severity: important Tags: patch Installation with the daily build from August 3 fails at grub-installer. (process:26576): /usr/bin/grub-installer: line 45: syntax error: unexpected "else" (expecting "then") WARNING **: Configuring 'grub-installer' failed with error code 2 WARNING **: Menu item 'grub-installer' failed. Simple syntax typo, attached patch fixes (patched while installing and installation succeeded). -- System Information: Debian Release: wheezy/sid APT prefers testing APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-3-amd64 (SMP w/4 CPU cores) >From adab600b7412379da97e13e12d87bbe6a547bc53 Mon Sep 17 00:00:00 2001 From: Mike Miller Date: Sat, 4 Aug 2012 18:57:23 -0400 Subject: [PATCH] Fix shell "unexpected else" syntax error --- grub-installer |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/grub-installer b/grub-installer index 768fbed..a0a4d8c 100755 --- a/grub-installer +++ b/grub-installer @@ -40,7 +40,7 @@ info "architecture: $ARCH" local initial_proc_contents="$(ls $ROOT/proc)" if [ -z "$initial_proc_contents" ]; then info "Mounting /proc into $ROOT" - if [ "$(udpkg --print-os)" = "kfreebsd" ]; + if [ "$(udpkg --print-os)" = "kfreebsd" ]; then mount -t linprocfs proc $ROOT/proc else mount -t proc proc $ROOT/proc -- 1.7.10.4
Bug#682207: [pkg-octave/experimental] Modify octave.conf to set pkg prefix without dpkg-architecture
tag 682207 pending thanks Date: Fri Jul 20 19:39:31 2012 -0400 Author: Mike Miller Commit ID: ecf9137782ad2329687cdb8f9e7d5c92cae64176 Commit URL: http://git.debian.org/?p=pkg-octave/octave.git;a=commitdiff;h=ecf9137782ad2329687cdb8f9e7d5c92cae64176 Patch URL: http://git.debian.org/?p=pkg-octave/octave.git;a=commitdiff_plain;h=ecf9137782ad2329687cdb8f9e7d5c92cae64176 Modify octave.conf to set pkg prefix without dpkg-architecture Remove dependency on dpkg-dev. Closes: #682207 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686926: [Pkg-octave-devel] Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Fri, Sep 7, 2012 at 4:50 AM, Sébastien Villemot wrote: > Note that this problem is only present with libhdf5-openmpi-dev: it is not > present with libhdf5-dev (serial version, the default) or libhdf5-mpich2-dev. Hm, are you sure? I see the same error with either libhdf5-mpich2-dev or libhdf5-openmpi-dev installed. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686926: [Pkg-octave-devel] Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Fri, Sep 7, 2012 at 8:51 AM, Sébastien Villemot wrote: > Mike Miller writes: > >> On Fri, Sep 7, 2012 at 4:50 AM, Sébastien Villemot wrote: >>> Note that this problem is only present with libhdf5-openmpi-dev: it is not >>> present with libhdf5-dev (serial version, the default) or >>> libhdf5-mpich2-dev. >> >> Hm, are you sure? I see the same error with either libhdf5-mpich2-dev >> or libhdf5-openmpi-dev installed. > > When testing against libhdf5-mpich2-dev, you should make sure that all > OpenMPI libraries are removed (in particular libopenmpi-dev). Otherwise > they take precedence over MPICH2 because of the alternatives priority. Yep, just found that out myself. Thanks. So here's a workaround that works for me with either set of libraries installed. Each has their own symbol to avoid including the C++ API, which is where the trouble lies. mkoctfile -DMPICH_SKIP_MPICXX=1 -DOMPI_SKIP_MPICXX=1 helloworld.cc I don't know enough about HDF5, but if it doesn't make use of the MPI C++ bindings at all, I'd argue this should be reassigned to hdf5 upstream so H5public.h would now contain: #ifdef H5_HAVE_PARALLEL # define MPICH_SKIP_MPICXX 1 # define OMPI_SKIP_MPICXX 1 # include #endif -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686926: [Pkg-octave-devel] Bug#686926: Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Mon, Sep 10, 2012 at 2:46 PM, Thomas Weber wrote: > On Fri, Sep 07, 2012 at 09:11:34AM -0400, Mike Miller wrote: >> mkoctfile -DMPICH_SKIP_MPICXX=1 -DOMPI_SKIP_MPICXX=1 helloworld.cc >> >> I don't know enough about HDF5, but if it doesn't make use of the MPI >> C++ bindings at all, I'd argue this should be reassigned to hdf5 >> upstream so H5public.h would now contain: >> >> #ifdef H5_HAVE_PARALLEL >> # define MPICH_SKIP_MPICXX 1 >> # define OMPI_SKIP_MPICXX 1 >> # include >> #endif > > Is my understanding correct that if I want to use HDF5 and one of MPICH > or MPI with the C++ interface, I have lost? Could be, I hadn't thought through all the unintended consequences yet. On the flip side, the way it is now if I want to compile C++ with just HDF5, I have to link in libraries that I don't really need. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#687349: openblas: program fails to load libopenblas.so.0 because ldconfig was not run on install
Source: openblas
Version: 0.1.1-6
Severity: normal
When installing both libopenblas-base and libopenblas-dev with the libblas
alternatives set to auto, I see the following:
$ gcc -o blastest blastest.c -lblas
$ ./blastest 1
0.00 1.00 2.00 3.00 4.00 5.00 6.00 7.00
$ sudo apt-get -yqq install libopenblas-dev
Selecting previously unselected package libopenblas-base.
(Reading database ... 297113 files and directories currently installed.)
Unpacking libopenblas-base (from .../libopenblas-base_0.1.1-6_amd64.deb) ...
Selecting previously unselected package libopenblas-dev.
Unpacking libopenblas-dev (from .../libopenblas-dev_0.1.1-6_amd64.deb) ...
Setting up libopenblas-base (0.1.1-6) ...
update-alternatives: using /usr/lib/openblas-base/libopenblas.so.0 to provide
/usr/lib/libblas.so.3 (libblas.so.3) in auto mode
Setting up libopenblas-dev (0.1.1-6) ...
update-alternatives: using /usr/lib/openblas-base/libopenblas.so to provide
/usr/lib/libblas.so (libblas.so) in auto mode
$ gcc -o blastest blastest.c -lblas
$ ./blastest 1
../blastest: error while loading shared libraries: libopenblas.so.0: cannot open
shared object file: No such file or directory
I think this is because ldconfig is not being run when the openblas packages
are installed, due to
DEB_DH_MAKESHLIBS_ARGS_libopenblas-base = -n
in debian/rules. If I run ldconfig the program runs fine.
I don't think this is too serious because no packages depend on libopenblas-
dev, and if I had not manually installed it there would have been no error.
-- System Information:
Debian Release: wheezy/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental'), (1, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.5-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
#include
#include
#include
int main(int argc, char *argv[])
{
double x[8] = { 0, 1, 2, 3, 4, 5, 6, 7 };
double y[8] = { 0 };
double a = 0;
int i;
if (argc > 1)
a = atof(argv[1]);
cblas_daxpy(8, a, x, 1, y, 1);
for (i = 0; i < 8; i++)
printf("%.2f ", y[i]);
printf("\n");
return 0;
}
Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
CC'ing pkg-octave-devel since this impacts Octave packaging as well.
Bradley M. Froehle wrote:
> The fix for this bug provided in 1.8.9-1~exp2 has cause me a good deal of
> headache today.
>
> For me, the issue is triggered as some C++ code containing:
>
> #include// sets OMPI_SKIP_MPICXX 1
> #include // MPI C++ namespace now is NOT available
>
> Note that even trying to unset OMPI_SKIP_MPICXX before including mpi.h
> won't work
> because OMPI_MPI_H will still be defined and the mpi.h header won't be
> processed again.
If you switch the order so mpi.h is included first does that fix it?
I'm not dismissing, just making sure I understand the problem.
> I respectfully request that this patch be backed out until a better
> solution can be
> worked out. Totally disabling the MPI C++ bindings when including HDF5 is
> not
> an acceptable side effect.
>
> I've looked into this bug a bit today and I'd suggest that instead the
> `mkoctfile-mpi.diff` patch in src:octave (from bug #598227) be modified to
> be something more like:
>
> -: ${XTRA_CXXFLAGS=%OCTAVE_CONF_XTRA_CXXFLAGS%}
> +: ${XTRA_CXXFLAGS=-I/usr/include/mpi -DOMPI_SKIP_MPICXX=1
> -DMPICH_SKIP_MPICXX=1 %OCTAVE_CONF_XTRA_CXXFLAGS%}
>
> That would contain the bug fix to Octave (which is the only place where the
> bug seems to have surfaced).
Reverting this patch and moving the fix into Octave would be one
acceptable solution that should have the same effect as far as Octave
is concerned. IMHO this is still an HDF5 bug, see below.
> Normally this is not an issue --- a developer would use mpicc or mpicxx to
> do the compilation
> and linking and this would automatically ensure that the correct mpi
> libraries are used. Octave
> is broken because it is using g++ and hacking in the MPI include directory
> without following it
> up with the necessary link flags.
Octave is not broken, it is simply using HDF5 in a C++ source file and
does not care about or use MPI. However we do want to support
co-installation for users that do want both Octave and MPI. Octave
shouldn't have to care which flavor of HDF5 is installed. Consider
these simple examples:
$ cat hdf5test.c
#include
// C source file follows
main() {}
$ cat hdf5test.cc
#include
// C++ source file follows
main() {}
$ gcc -o hdf5test hdf5test.c -lhdf5
$ g++ -o hdf5test hdf5test.cc -lhdf5
Works if libhdf5-7 and libhdf5-dev are installed. If HDF5 were
providing a consistent interface this would also work with
libhdf5-openmpi-7 and libhdf5-openmpi-dev installed. As it stands now,
however, I need to compile with (assuming the patch is reverted)
$ gcc -I/usr/include/mpi -o hdf5test hdf5test.c -lhdf5
$ g++ -I/usr/include/mpi -DOMPI_SKIP_MPICXX -o hdf5test hdf5test.cc -lhdf5
or
$ g++ -I/usr/include/mpi -o hdf5test hdf5test.cc -lhdf5 -lmpi++ -lmpi
Not ideal and could certainly affect users other than Octave.
--
mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#686926: liboctave-dev: creates broken .oct files when the OpenMPI flavor of HDF5 (libhdf5-openmpi-dev) is installed
On Sun, Mar 31, 2013 at 05:52:03PM -0700, Bradley M. Froehle wrote:
> As an example of how confounding this is, just consider a simple example:
>
> $ cat test.cpp
> #include
> #include
> int main() {
> MPI::Init();
> printf("I'm %d of %d\n", MPI::COMM_WORLD.Get_rank(),
> MPI::COMM_WORLD.Get_size());
> MPI::Finalize();
> }
>
> $ mpicxx -o test test.cpp
> test.cpp: In function ‘int main()’:
> test.cpp:4:3: error: ‘MPI’ has not been declared
> test.cpp:5:28: error: ‘MPI’ has not been declared
> test.cpp:5:56: error: ‘MPI’ has not been declared
> test.cpp:6:3: error: ‘MPI’ has not been declared
>
> Reversing the order of the includes as you suggest does allow the
> compilation to succeed. My objection is primarily to the confusing nature
> of the failure --- it's not at all clear what went wrong or why. I had to
> run the compiler with -E and search through the preprocessed source to see
> that the mpicxx.h header wasn't being included, then look to see the
> condition by which it would be included, and then track down why those
> conditions were not being met. A lot of grepping led to the H5public.h
> header which I eventually tracked back to this issue. (Obviously the case
> where I hit this was a lot more complicated than the toy example above and
> it wasn't even clear initially that I should look into HDF5).
I agree, that is a confusing side-effect of this change.
> > > Normally this is not an issue --- a developer would use mpicc or mpicxx
> > to
> > > do the compilation
> > > and linking and this would automatically ensure that the correct mpi
> > > libraries are used. Octave
> > > is broken because it is using g++ and hacking in the MPI include
> > directory
> > > without following it
> > > up with the necessary link flags.
> >
> > Octave is not broken, it is simply using HDF5 in a C++ source file and
> > does not care about or use MPI. However we do want to support
> > co-installation for users that do want both Octave and MPI. Octave
> > shouldn't have to care which flavor of HDF5 is installed. Consider
> > these simple examples:
> >
> > $ cat hdf5test.c
> > #include
> > // C source file follows
> > main() {}
> >
> > $ cat hdf5test.cc
> > #include
> > // C++ source file follows
> > main() {}
> >
> > $ gcc -o hdf5test hdf5test.c -lhdf5
> > $ g++ -o hdf5test hdf5test.cc -lhdf5
> >
>
> Yes, that is correct.
>
>
> > Works if libhdf5-7 and libhdf5-dev are installed. If HDF5 were
> > providing a consistent interface this would also work with
> > libhdf5-openmpi-7 and libhdf5-openmpi-dev installed. As it stands now,
> > however, I need to compile with (assuming the patch is reverted)
> >
> > $ gcc -I/usr/include/mpi -o hdf5test hdf5test.c -lhdf5
> > $ g++ -I/usr/include/mpi -DOMPI_SKIP_MPICXX -o hdf5test hdf5test.cc -lhdf5
> > or
> > $ g++ -I/usr/include/mpi -o hdf5test hdf5test.cc -lhdf5 -lmpi++ -lmpi
> >
>
> No, I believe this is wrong. Since hdf5-openmpi needs MPI, you should be
> compiling with
> $ mpicc -o hdf5test hdf5test.c -lhdf5
> $ mpicxx -o hdf5test hdf5test.cc -lhdf5
>
> This means that another solution to the mkoctfile problem would be to
> invoke it as
> CXX=mpicx mkoctfile ...
> when compiling C++ code which directly (or indirectly) uses MPI.
I agree with you that my workaround is wrong, but I think your solution
is equally wrong, theoretically speaking. I am not (yet) an MPI user and
I am not really an HDF5 user either, except via Octave. But I would hope
for a set of HDF5 libraries that are true ABI-compatible drop-in
replacements for each other. I should ideally not even have to know
which HDF5 is installed when I compile a program that uses it, no matter
whether it's extra flags or a different compiler wrapper. Maybe this is
technically impossible, I don't know enough about MPI to say.
More practically, and more importantly, Octave users who are compiling
extensions from within Octave are yet another step removed from both the
compiler and the HDF5 library. They may not even be aware of HDF5 but
the compilation and linking of their oct-file will be affected.
Mkoctfile simply compiles extensions using the same set of flags and
libraries that Octave itself was built with. And those extensions should
work without needing to recompile if the HDF5 library is switched out.
Compiling them with CXX=mpicxx has the opposite effect.
--
mike
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#547171: yum-utils update
Just noting that I am indeed working on this package despite a long delay due to the freeze and other priorities. Packaging work in progress is available at git://anonscm.debian.org/users/mtmiller-guest/yum-utils.git http://anonscm.debian.org/gitweb/?p=users/mtmiller-guest/yum-utils.git Other than some missing man pages, packaging is mostly complete. -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#673958: createrepo update
Just noting that I am indeed working on this package despite a long delay due to the freeze and other priorities. Packaging work in progress is available at git://anonscm.debian.org/users/mtmiller-guest/createrepo.git http://anonscm.debian.org/git/users/mtmiller-guest/createrepo.git -- mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
