Bug#636554: jruby: New upstream release
On 25/09/12 13:31, berta...@ptitcanardnoir.org wrote: On Wed, Aug 3, 2011 at 2:09 PM, James Healy wrote: JRuby 1.6.3 is available upstream and includes official support for ruby 1.9 syntax. Are there any plans to package 1.6.x? yes, but every helping hand is welcome! Is there a place where this plans are documented? What are they? I might be interested to help. I've already started a bit, but don't know java that much and hit some symbols not found errors at compilation time. The work was done to repackage jruby-1.6.7.2 in June: http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2012-June/039090.html It had no response. I presume that's because it re-ships the jars it requires rather than depending on existing Debian packages where they're available. If I were to suggest a starting point, it would be to get its dependencies up to date. -- Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#636554: jruby: New upstream release
On 25/09/12 19:02, berta...@ptitcanardnoir.org wrote: On Tue, Sep 25, 2012 at 02:25:04PM +0100, Alex Young wrote: The work was done to repackage jruby-1.6.7.2 in June: http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/2012-June/039090.html Yeah, I saw this message. Well done. It wasn't me, although I had a small hand in organising it :-) It had no response. I presume that's because it re-ships the jars it requires rather than depending on existing Debian packages where they're available. If I were to suggest a starting point, it would be to get its dependencies up to date. I agree, shipping the jars from the upstream source is quite a violation of Debian's policy, so this upload won't be accepted I think. It could go back into non-free until the dependencies are sorted out, surely? -- Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711079: bundler: Bundler is incompatible with chruby
Package: bundler Version: 1.1.4-6 Severity: normal Dear Maintainer, The /usr/bin/bundle binary supplied by the bundler package uses "#!/usr/bin/env ruby" as its shebang line. This means that when I run `bundle install` with a non-system ruby enabled, and I don't have the bundler gem separately installed, the `bundle install` command fails with the following output: $ bundle install /home/alex/.rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require': cannot load such file -- bundler (LoadError) from /home/alex/.rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in `require' from /usr/bin/bundle:2:in `' This is specifically a problem when using chruby (and chruby-exec) to select the activated ruby. The `bundle` package should specify the system ruby to run with, otherwise `require "bundler"` will fail to see the installed libraries at /usr/lib/ruby/vendor_ruby/bundler. Replacing the shebang line with "#!/usr/bin/ruby" fixes this. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages bundler depends on: ii ruby 1:1.9.3 ii ruby1.9.1 [ruby-interpreter] 1.9.3.194-8.1 Versions of packages bundler recommends: ii build-essential 11.5 ii less 444-4 ii ruby-dev 1:1.9.3 ii rubygems-integration 1.1 ii sudo 1.8.5p2-1+nmu1 bundler 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#701918: ruby-build: Includes definitions for unbuildable versions
Package: ruby-build Version: 20120524-1 Severity: normal Dear Maintainer, On a stock wheezy vm, I ran: $ apt-get install ruby-build $ apt-get build-dep ruby1.8 $ mkdir ~/.rubies $ ruby-build 1.8.7-p302 ~/.rubies/1.8.7-p302 This failed with the following output: Downloading http://ftp.ruby-lang.org/pub/ruby/1.8/ruby-1.8.7-p302.tar.gz... Installing ruby-1.8.7-p302... BUILD FAILED Inspect or clean up the working tree at /tmp/ruby-build.20130228181619.418 Results logged to /tmp/ruby-build.20130228181619.418.log Last 10 log lines: ossl_ssl.c:111:5: warning: initialization from incompatible pointer type [enabled by default] ossl_ssl.c:111:5: warning: (near initialization for ‘ossl_ssl_method_tab[10].func’) [enabled by default] ossl_ssl.c:112:5: warning: initialization from incompatible pointer type [enabled by default] ossl_ssl.c:112:5: warning: (near initialization for ‘ossl_ssl_method_tab[11].func’) [enabled by default] ossl_ssl.c: In function ‘ossl_ssl_get_cipher’: ossl_ssl.c:1224:12: warning: assignment discards ‘const’ qualifier from pointer target type [enabled by default] make[1]: *** [ossl_ssl.o] Error 1 make[1]: *** Waiting for unfinished jobs make[1]: Leaving directory `/tmp/ruby-build.20130228181619.418/ruby-1.8.7-p302/ext/openssl' make: *** [all] Error 1 This is due to a known problem with wheezy's SSL, which has no SSL2 support: http://bugs.ruby-lang.org/issues/4860 I would suggest that ruby definitions which are known not to be buildable on wheezy be removed from /usr/share/ruby-build/. However I would also suggest that a way be found to support this specific version of MRI, since it's the version in squeeze. -- System Information: Debian Release: 7.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE= (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby-build depends on: ii build-essential 11.5 ii curl 7.26.0-1+wheezy1 ii libreadline6-dev 6.2+dfsg-0.1 ii zlib1g-dev1:1.2.7.dfsg-13 Versions of packages ruby-build recommends: ii libsqlite3-dev 3.7.13-1 ii libssl-dev 1.0.1e-1 ii libxml2-dev 2.8.0+dfsg1-7 ii libxslt1-dev [libxslt-dev] 1.1.26-14 ii rbenv 0.3.0-1 Versions of packages ruby-build suggests: ii autoconf2.69-1 ii automake1:1.11.6-1 ii bison 1:2.5.dfsg-2.1 ii git [git-core] 1:1.7.10.4-1+wheezy1 ii git-core1:1.7.10.4-1+wheezy1 ii libtool 2.4.2-1.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#647267: debian-installer: grub-install tries to install on the wrong drive
Just to confirm that this bug still exists: I've just done an ordinary (non-expert) installation toa Thinkpad T420 with the wheezy netinst iso written to a USB drive with unetbootin, and grub was told to install to /dev/sda (the USB drive) rather than /dev/sdb (the installation target), which failed. I had selected guided partitioning with encrypted LVM. Doing the update-grub; grub-install /dev/sdb dance on the emergency console left me with a working system. Perhaps that could be added to the error screen the installer presents in case of a grub-install failure? Interestingly, I had to do the installation a second time with firmware files on a *second* USB device, and on that occasion the correct drive was picked for grub. -- Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#711079: check the Ruby LOAD_PATH
On Sat, 2013-06-15 at 14:38 +0200, Cédric Boutillier wrote: > Hi, > > > The /usr/bin/bundle binary supplied by the bundler package uses > > "#!/usr/bin/env ruby" as its shebang line. This means that when I run > > `bundle install` with a non-system ruby enabled, and I don't have the > > bundler gem separately installed, the `bundle install` command fails > > with the following output: > > > $ bundle install > > /home/alex/.rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in > > `require': cannot load such file -- bundler (LoadError) > > > from > > /home/alex/.rubies/ruby-2.0.0-p195/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:45:in > > `require' > > from /usr/bin/bundle:2:in `' > > > This is specifically a problem when using chruby (and chruby-exec) to > > select the activated ruby. > > > The `bundle` package should specify the system ruby to run with, > > otherwise `require "bundler"` will fail to see the installed libraries > > at /usr/lib/ruby/vendor_ruby/bundler. Replacing the shebang line with > > "#!/usr/bin/ruby" fixes this. > > > I think the problem you see is caused by the fact that your personal > Ruby interpreter does not know where to find system Ruby libraries. You > need to check that /usr/lib/ruby/vendor_ruby/ and related are added to > the $LOAD_PATH of your interpreter. You may need to use the RUBYLIB > environment variable for that. > I was hoping to be able to keep my personal ruby entirely isolated from the system and still be able to run system binaries without them breaking, but it looks, one way or another, like binary gems make that impossible in bundler's case. Drat. -- Alex -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#525938: Workaround
I found that removing the iceweasel adblock plugin and installing the debian package (mozilla-firefox-adblock) corrected the behavior and probably leaves your system in a better place. Just a thought.
