Bug#794875: appstream-dep11: Inconsistent capitalization (typo) in package description
Source: appstream-dep11 Version: 0.1.0-1 Severity: minor Tags: patch Very simple typo, you wrote that it can create an HTMl report. Patch follows: --- a/debian/control +++ b/debian/control @@ -43,7 +43,7 @@ Description: Tools to generate and validate DEP-11 AppStream metadata DEP-11 is Debian's YAML-based implementation of the AppStream specification. . This package contains the dep11-generator tool to generate AppStream-DEP-11 - metadata for any mirror of a Debian archive. It is also able to create an HTMl + metadata for any mirror of a Debian archive. It is also able to create an HTML report of the issues found while extracting AppStream metadata. The dep11-validate tool can validate DEP-11 metadata for compliance with the specification. -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.0.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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Fabian Greffrath dijo [Mon, May 18, 2015 at 03:33:37PM +0200]: Am Montag, den 18.05.2015, 15:06 +0200 schrieb Fabian Greffrath: Some 17 hours, maybe. But I was so nervous... ;) No, wait a moment. I have just seen that the key has been moved from the DM keyring to the DD keyring on May 10, i.e. 7 days before I got the confirmation email that my account has been created and thus 8 days before I tried to upload that package. Umh, 17 hours should be more than enough IMO. As for the Git commits: That's the time it hit our Git working tree, but all updates were pushed together at 2015.05.17. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#785618: [rt.debian.org #5802] Account for Fabian Greffrath
Fabian Greffrath dijo [Mon, May 18, 2015 at 02:04:07PM +0200]: Am Montag, den 18.05.2015, 12:51 +0100 schrieb Jonathan McDowell: noodles@kaufmann:~$ gpg --no-default-keyring \ --keyring /srv/keyring.debian.org/keyrings/debian-keyring.gpg \ --list-key 0xCBEA8E970CCD59DF pub 4096R/0CCD59DF 2014-10-23 [expires: 2016-10-22] uid Fabian Greffrath fab...@greffrath.com uid Fabian Greffrath fabian+deb...@greffrath.com sub 4096R/8E377AA0 2014-10-23 [expires: 2016-10-22] Ah, I have set the Uploaders field to my fab...@debian.org account and the updated key which contains this added uid has not yet been merged into debian-keyring. Does this make sense? It should not make any difference, we deal with the key, and put the key as a whole in the keyring. Having or lacking specific identities should make no difference. How long did you wait after the keyring was pushed before attempting your upload? Maybe the changes had not yet propagated. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779196: breaks on non-existing license file
Sorry for the long time in processing your simple patch — You happened to file it two days before my twins were born ;-) Uploaded. I have not backported it; it would have made sense to backport to Wheezy at that point; nowadays that Jessie is stable, I am not yet backporting this as it is a minor reliability fix — but in case there's anything bigger, I'll provide backports. Greetings! signature.asc Description: Digital signature
Bug#785269: drupal7: Can't setup: Unicode library Error. Check php.ini mbstring.http_input setting
Hi,
Your report strikes me as quite weird, as I recently did the same
without any trouble. Does your Apache installation allow for
directives to be specified via .htcaccess? (look for AllowOverride
in your Apache configurations)
You mention:
Tried everything under the sun:
modified /etc/php5/cli/php.ini (input_encoding, mbstring.http_input others)
modified /etc/drupal/7/htaccess
kept restarting apache and update.php ing.
How do you have configured the Apache↔PHP interface? You most likely
do so via libapache2-mod-php5; if so, editing /etc/php5/cli/php.ini
will have no effect, you have to edit /etc/php5/apache2/php.ini
instead. The directives that should be added there are:
ini_set('mbstring.http_input', 'pass');
ini_set('mbstring.http_output', 'pass');
You might want to refer to the following Drupal issues — Quite old
(2006 and 2008), but relevant to the issue at hand:
https://www.drupal.org/node/87138
https://www.drupal.org/node/211648
Particularly, there's one extra line one user mentions as useful to
him (and that's part of the .htaccess we ship):
php_value mbstring.encoding_translation 0
One further comment (#40) comments about this problem while using
Debian Jessie, and mentions the problem having disappeared after
adding the ini_set(...) lines in the
[drupal_folder]/sites/default/settings.php file.
Please do confirm if any of the above fix the problem for you!
signature.asc
Description: Digital signature
Bug#784005: [Pkg-postgresql-public] Bug#784005: postgresql-9.4: Cluster upgrade from 9.1 to 9.4 results in broken configuration
Christoph Berg dijo [Thu, May 14, 2015 at 10:11:44PM +0200]: Hi Gunnar, I'd call it a LXC bug if it doesn't support POSIX shared memory. That said, I've been bitten by this problem as well - in my case, /dev/shm was simply not mounted and a cluster with no explicit dynamic_shared_memory_type setting defaulted to posix didn't start. If you create a new cluster in such an environment, initdb will probe the various shared memory types and pick one that works. I'm not really happy with this auto-probing because it hides the real problem, but atm that's what upstream has designed. We'll document the gotcha in README.Debian. Hi! I asked a PostgreSQL developer friend of mine, and he answered (in Spanish, translation bugs are mine): Hmm, if I understand correctly, the problem is that the postgresql.conf is copied from the old server to the new one, right? I think that, by itself, is a bug... The configuration files are attempted to be kept reasonably compatible, but there is no promise that it will always work. Particularly, with parameters such as the shared memory type, initdb should take care of setting the right values. I think it's a pg_upgradecluster bug (which is part of the Debian packaging, not of Postgres) I guess LXC does provide shared memory, but it might be that my configuration does not allow it. I am newbie-ish on its specifics. Greetings! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#784005: postgresql-9.4: Cluster upgrade from 9.1 to 9.4 results in broken configuration
Source: postgresql-9.4 Version: 9.4.1-1 Severity: important I upgraded a server (a LXC-based container) from Wheezy to Jessie. After installing, everything looked OK, with the (live) 9.1 and (empty) 9.4 clusters running. Now, following the instructions at /usr/share/doc/postgresql-common/README.Debian.gz (section Default clusters and upgrading) led to a seemingly correct cluster migration — Just at the final step, at the cluster restart time, I got: 2015-05-02 01:27:01 GMT FATAL: could not open shared memory segment /PostgreSQL.1804289383: Function not implemented Increasing the log verbosity to DEBUG5 yielded: 2015-05-02 01:57:55 GMT DEBUG: postgres: PostmasterMain: initial environment dump: 2015-05-02 01:57:55 GMT DEBUG: - 2015-05-02 01:57:55 GMT DEBUG: PG_GRANDPARENT_PID=2343 2015-05-02 01:57:55 GMT DEBUG: PGLOCALEDIR=/usr/share/locale 2015-05-02 01:57:55 GMT DEBUG: PGSYSCONFDIR=/etc/postgresql-common 2015-05-02 01:57:55 GMT DEBUG: LANG=en_US.UTF-8 2015-05-02 01:57:55 GMT DEBUG: PWD=/var/lib/postgresql 2015-05-02 01:57:55 GMT DEBUG: PGDATA=/var/lib/postgresql/9.4/main 2015-05-02 01:57:55 GMT DEBUG: LC_COLLATE=en_US.UTF-8 2015-05-02 01:57:55 GMT DEBUG: LC_CTYPE=en_US.UTF-8 2015-05-02 01:57:55 GMT DEBUG: LC_MESSAGES=en_US.UTF-8 2015-05-02 01:57:55 GMT DEBUG: LC_MONETARY=C 2015-05-02 01:57:55 GMT DEBUG: LC_NUMERIC=C 2015-05-02 01:57:55 GMT DEBUG: LC_TIME=C 2015-05-02 01:57:55 GMT DEBUG: - 2015-05-02 01:57:56 GMT DEBUG: invoking IpcMemoryCreate(size=23822336) 2015-05-02 01:57:56 GMT DEBUG: mmap with MAP_HUGETLB failed, huge pages disabled: Cannot allocate memory 2015-05-02 01:57:56 GMT DEBUG: SlruScanDirectory invoking callback on pg_notify/ 2015-05-02 01:57:56 GMT DEBUG: removing file pg_notify/ 2015-05-02 01:57:56 GMT DEBUG: dynamic shared memory system will support 288 segments 2015-05-02 01:57:56 GMT FATAL: could not open shared memory segment /PostgreSQL.1804289383: Function not implemented 2015-05-02 01:57:56 GMT DEBUG: shmem_exit(1): 0 before_shmem_exit callbacks to make 2015-05-02 01:57:56 GMT DEBUG: shmem_exit(1): 3 on_shmem_exit callbacks to make 2015-05-02 01:57:56 GMT DEBUG: proc_exit(1): 2 callbacks to make 2015-05-02 01:57:56 GMT DEBUG: exit(1) 2015-05-02 01:57:56 GMT DEBUG: shmem_exit(-1): 0 before_shmem_exit callbacks to make 2015-05-02 01:57:56 GMT DEBUG: shmem_exit(-1): 0 on_shmem_exit callbacks to make 2015-05-02 01:57:56 GMT DEBUG: proc_exit(-1): 0 callbacks to make Now, looking through the Web, this page gave me the needed insight: http://postgresql.nabble.com/Shared-memory-changes-in-9-4-td5804919.html The problem apparently happened because pg_upgradecluster uses my 9.1 config for 9.4, which does not include a part of the configuration. And following on the quoted webpage, I had to specify: dynamic_shared_memory_type = sysv As posix semantics seem not to work under LXC (or not under its default configuration). Thanks! -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-eudyptula5d12e3524822-00194-gd799964 (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 Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783816: RFP: thefuck -- Correct your misbehavior on the command line
Ming-ting Yao Wei dijo [Thu, Apr 30, 2015 at 08:48:15PM +0800]: Description : Correct your misbehavior on the command line The package tries to fix your command line error, such as missing sudo or typo. Ugh. I'd fear having an automated tool that tried to call sudo for every action I do by mistake :-| Also wondering if the name is too offensive to upload. I'd prefer not having a package by that name in Debian. I would not oppose too much, anyway; i. e. we do have Brainfuck, and it would be unwise to rename it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#600148: pidgin: Crashes when mouse goes over a very long URL
Peter Spiess-Knafl dijo [Wed, Apr 29, 2015 at 08:17:03PM +0200]: Hi Gunnar, Does this bug still affect you in the latest version of pidgin (2.10.11)? Hi, This was a *very* old bug! I haven't seen this behaviour in a long time. I think it's safe to mark it as closed. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781414: Embedded code copies
David Prévot dijo [Thu, Apr 02, 2015 at 02:07:06AM -0400]: Sorry for the lateness - I'm currently devoid of free time, and my package maintainance status has suffered :( It’s not even been a week since that bug was filed, so no need to apologize (and yay, double happy event may drag one into other activities, cheers! ;). Oh, yes, I cannot say I'm sorry for not having the same amount of time I traditionally had ;-) I’ve introduced php-seclib in the archive to get rid of the embedded code copy from ownCloud, and must admit I’ve never notice any BC break: I’m happy to track the latest php-seclib upstream release for almost two years now, it seems to behave correctly ;). (...) Simply requiring 'HTMLPurifier.autoload.php' (or 'HTMLPurifier.includes.php', or 'HTMLPurifier.safe-includes.php', or…) instead of the standalone file should do the trick. Done and uploaded. For the curious: http://anonscm.debian.org/cgit/collab-maint/collabtive.git/commit/?id=6fcd7f38b71d73bae003d290d735de8234ddc8ad http://anonscm.debian.org/cgit/collab-maint/collabtive.git/commit/?id=687e69463fb46e6b49d60c9ca3be39cd404cde67 Feel free to bug php-htmlpurifier if you really want it to provide a big standalone file, but I’m not sure that’s necessary (nor a good idea at first sight). Please, note I only team-uploaded this package once, so I may not be the best person to provide more insight. If this one works, I won't complain :) I agree the standalone file does not seem so attractive from a distribution PoV. I prefered symlinking as it requires less patching of the upstream code. But, of course, if the PHP packaging group's best practices are to patch, I will do so. Just please confirm! I’m a bit new in the PHP PEAR Maintainers team, other members may provide more insight here. My short experience with ownCloud packaging is that previous maintainers did it that way, and it looks a lot less hackish. E.g., if a file is added in an updated PHP class, as long as that file is not (yet) symlinked from the webapp using it, you may shoot yourself in the foot if this file is called from an existing one… As you can see, I did this in a hybrid fashion ;-) I might clean up later on. But I prefer to patch upstream as little as possible in general. Thanks for the report! (+hugs!) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#781414: Embedded code copies
Hi David! Sorry for the lateness - I'm currently devoid of free time, and my package maintainance status has suffered :( I just noticed that the collabtive package embeds its own copy of (at least) HTMLPurifier (as available in the php-htmlpurifier package) and phpseclib (as available in the php-seclib package). Right. Just please help me with this. There are two different questions I have on those libraries: - For php-seclib, after a quick diff, the version I currently have in Sid (0.3.8-1) seems clearly newer (and quite clearly, consisting mainly of bugfixes) than the one I'm shipping with Collabtive. I am unfamiliar with this library, so... In your experience, how incompatible would you expect a new version to be? Do you think I could just drop in the new one and not suffer too much? - As for php-htmlpurifier, it seems we are lucky as both packages carry 4.6.0. However, the one in Collabtive is a standalone file, stating in its header: * This file was auto-generated by generate-includes.php and includes all of * the core files required by HTML Purifier. Use this if performance is a * primary concern and you are using an opcode cache. PLEASE DO NOT EDIT THIS * FILE, changes will be overwritten the next time the script is run. So... Do you know what'd be the best way for this file to be replaced (or generated) from the package we are shipping? It looks like most existing PHP classes used as dependencies are currently symlinked. You may consider including them from where they belong instead. I prefered symlinking as it requires less patching of the upstream code. But, of course, if the PHP packaging group's best practices are to patch, I will do so. Just please confirm! signature.asc Description: Digital signature
Bug#774193: Found the problem, I think (dh-make-drupal version table parsing broken)
Matthew Gabeler-Lee dijo [Tue, Mar 24, 2015 at 08:03:00PM -0400]: On 03/24/2015 07:46 PM, Matthew Gabeler-Lee wrote: I've attached a patch that includes the above debug messages and my ugly(?) fix for it, which works for me. This is the first time I've ever tried to write ruby code, so apologies if I'm missing some ruby-isms. Mainly I guessed the syntax by reading other parts of this script :) Found one more related bug -- esp. when version mangling is in effect, the duplicates detection loop needs to also compare the drupal version. Updated patch attached. Thanks a lot, and sorry for the long time without a reply! I'm applying your patch and uploading a new version right away! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780419: tzdata: Please add the new Mexico/Sureste timezone to the Debian-specific package information
Christian PERRIER dijo [Fri, Mar 13, 2015 at 06:38:48PM +0100]: The state of Quintana Roo, in South-Eastern Mexico, has its own timezone since this February: Hello Gunnar (and family...;-)) , So, it actually means that a change is also needed to the tzsetup component of D-I, so that Mexican users can choose Mexico/Sureste in addition to Mexico/General, Mexico, BajaSur and Mexico/BajaNorte, right? My dear and bubbly friend! As usual, you are right: The installer should display our four timezones. And actually... It's not four — It's five :-P I don't know whether to file this as a new bug, or this one should suffice, but according to our official information: http://www.cenam.mx/Hora_oficial/ First issue: The BajaNorte and BajaSur names are not official. They should rather be: México/Noroeste México/Pacífico México/Centro México/Sureste And second, Sonora State (shaded in the map) does not do summer daylight savings, so it only makes sense to separate it from México/Pacífico. Note that, if chosen by city, it does exist as America/Hermosillo, and its information is correct. But IIRC, the installer does show the four timezone names (and not the bunch of localities). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#780419: tzdata: Please add the new Mexico/Sureste timezone to the Debian-specific package information
Package: tzdata Version: 2015a-1 Severity: normal Tags: patch The state of Quintana Roo, in South-Eastern Mexico, has its own timezone since this February: http://www.worldtimezone.com/dst_news/dst_news_mexico11.html http://www.cenam.mx/Hora_oficial/ (Spanish) https://en.wikipedia.org/wiki/Time_in_Mexico This timezone change is already reflected in the 2015a release of tzdata; my patch just adds the relevant information to the debian/tzdata.config and backward files. Please note I am unfamiliar with this package, but it does *seem* like necessary to be shown in the system. The patch is trivial, so I'm inlining it. Disregard if I'm mistaken here. If the patch is accepted, I'd ask it to be considered for Jessie installs! diff --git a/backward b/backward index 3ceda88..cc3ec36 100644 --- a/backward +++ b/backward @@ -89,6 +89,7 @@ Link Africa/Tripoli Libya Link America/Tijuana Mexico/BajaNorte Link America/MazatlanMexico/BajaSur Link America/Mexico_City Mexico/General +Link America/Cancun Mexico/Sureste Link Pacific/AucklandNZ Link Pacific/Chatham NZ-CHAT Link America/Denver Navajo diff --git a/debian/tzdata.config b/debian/tzdata.config index 67bcb0b..022139e 100644 --- a/debian/tzdata.config +++ b/debian/tzdata.config @@ -218,6 +218,9 @@ convert_timezone() Mexico/General) echo America/Mexico_City ;; +Mexico/Sureste) +echo America/Cancun +;; Mideast/Riyadh87) echo Asia/Riyadh87 ;; -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.19.0-eudyptula5d12e3524822-00194-gd799964 (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 Init: systemd (via /run/systemd/system) Versions of packages tzdata depends on: ii debconf [debconf-2.0] 1.5.55 tzdata recommends no packages. tzdata suggests no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778527: ITP: libfile-mktemp-perl -- Make temporary filename from template
Raoul Gunnar Borenius dijo [Mon, Feb 16, 2015 at 11:30:24AM +0100]: File::MkTemp and File::MkTempO provides functions to create unique strings for use as file/directory names based on an user specified template. The package would be very useful for Nagios/Icinga-Installations using the optional Kerberos-Check-Plugin from http://exchange.nagios.org/directory/Plugins/Security/check_krb5/details This plugin is implemented in Perl and needs File::MkTemp which is not in Debian yet. Umh, what does it provide beyond what File::Temp (which is in the standard library) already does? $ perl -e 'use File::Temp; $f=File::Temp-new(TEMPLATE=FooBar, DIR=/tmp, SUFFIX=.foo); print $f-filename,\n;' /tmp/FooBarM1Xo.foo File::Temp not only creates unique strings, but also automatically handles the file or directory creation and remotion. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777743: ITP: wallpaperd -- X wallpaper changing daemon
Dmitry Bogatov dijo [Thu, Feb 12, 2015 at 10:43:17AM +0300]: - why is this package useful/relevant? It follows unix way and manages wallpapers without connection to your DE, WM or anything. (...) if there are other packages providing similar functionality, how does it compare? Such functionality exists in GNOME and KDE, at least. But I know nothing similar for bare WM. I guess I do this the ugliest possible way, but my .xsession has: BGDIR=/home/gwolf/.backgrounds while /bin/true do feh --bg-max $BGDIR/$(xscreensaver-getimage-file $BGDIR) sleep 60 done I guess there's more to wallpaperd than this, right? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#777310: debian-keyring: please make the build reproducible
While working on the reproducible builds effort [1], we have noticed that debian-keyring could not be built reproducibly. The attached patch removes timestamps from the build system. Once applied, debian-keyring can be built reproducibly in our current experimental framework. Added to our working tree, will include it in the next keyring push that includes a package upload. signature.asc Description: Digital signature
Bug#774193: Minor followup
...Just to report I'm not just sitting on this bug report; it does not affect all Drupal modules (although I'm sure you stumbled on a pretty common one!). The problem is not AFAICT on the tables parsing (that one already bit us some time ago) but on some other artifact. I spent some time poking the sources to understand this and did minor improvements, but wasn't able to pinpoint and fix the problem. I've been quite busy in the last few weeks, but I hope/expect to be able to dig into this soon. signature.asc Description: Digital signature
Bug#695348: collabtive: XSS and CSRF issues
Moritz Mühlenhoff dijo [Tue, Dec 09, 2014 at 10:17:14PM +0100]: I'm getting in touch with the authors right now. Thanks! http://collabtive.o-dyn.de/forum/viewtopic.php?f=11t=8479 Gunnar, is this fixed in the version in jessie? Sorry for the delay for this reply! I can confirm you that, from the three attacks mentioned in exploit-db¹, attacks 1 and 3 do not work. As for attack 2 (the CSRF), the description just reads: Technically, attacker can create a specially crafted page and force collabtive administrators to visit it and can gain administrative privilege. For prevention from CSRF vulnerabilities, application needs anti-csrf token, captcha and asking old password for critical actions. The refered site for the POC exploit² no longer exists, so I cannot confirm whether it has been fixed or not. I can see from the forum post you linked to that the author does not believe it to be a realistic, important enough issue to worry about. ¹ http://www.exploit-db.com/exploits/15240/ ² http://www.anatoliasecurity.com/exploits/collabtive-csrf-xploit.txt signature.asc Description: Digital signature
Bug#770609: unblock: drupal7/7.32-1+deb8u1 (pre-approval)
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package drupal7
My upload includes two important security fixes plus several minor
reliability fixes, backported respectively from versions 7.33 and
7.34.
Debdiff attached, or available via anonscm:
https://anonscm.debian.org/cgit/collab-maint/drupal7.git/diff/?id=debian/7.32-1%2bdeb8u1id2=debian/7.32-1
I don't know how rigurous this pre-approval is, but I checked this
with jmw yesterday on IRC.
Thanks!
unblock drupal7/7.32-1+deb8u1
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-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
diff -Nru drupal7-7.32/debian/changelog drupal7-7.32/debian/changelog
--- drupal7-7.32/debian/changelog 2014-10-15 11:34:54.0 -0500
+++ drupal7-7.32/debian/changelog 2014-11-21 13:28:18.0 -0600
@@ -1,3 +1,14 @@
+drupal7 (7.32-1+deb8u1) unstable; urgency=high
+
+ * Updated the VCS URL in debian/control as git.debian.org is deprecated
+ * Debian has frozen! We will start backporting the important fixes to
+7.32
+ * Backported from 7.34: SA-CORE-2014-006 (Session hijacking CVE-2014-
+9015, Denial of service CVE-2014-9016)
+ * Several minor reliability fixes backported from 7.33
+
+ -- Gunnar Wolf gw...@debian.org Wed, 15 Oct 2014 12:45:29 -0500
+
drupal7 (7.32-1) unstable; urgency=critical
* New upstream release
diff -Nru drupal7-7.32/debian/control drupal7-7.32/debian/control
--- drupal7-7.32/debian/control 2014-10-15 11:34:54.0 -0500
+++ drupal7-7.32/debian/control 2014-11-21 13:28:18.0 -0600
@@ -6,7 +6,7 @@
Build-Depends: debhelper (= 7.0.50~), yui-compressor
Homepage: http://www.drupal.org/
Standards-Version: 3.9.6.0
-Vcs-Git: git://git.debian.org/git/collab-maint/drupal7.git
+Vcs-Git: git://anonscm.debian.org/collab-maint/drupal7.git
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/drupal7.git
Package: drupal7
diff -Nru drupal7-7.32/debian/patches/ajax_throbber_align
drupal7-7.32/debian/patches/ajax_throbber_align
--- drupal7-7.32/debian/patches/ajax_throbber_align 1969-12-31
18:00:00.0 -0600
+++ drupal7-7.32/debian/patches/ajax_throbber_align 2014-11-21
13:28:18.0 -0600
@@ -0,0 +1,112 @@
+Origin: vendor
+Forwarded: not-needed
+From: Gunnar Wolf gw...@debian.org
+Last-Update: 2014-11-21
+Description: Fixes alignment issue in the Ajax progress throbber
+ Fixed a bug which caused the Ajax progress throbber to appear misaligned in
+ many situatons (minor styling change).
+ .
+ Fixes Drupal issue #1069152
+ .
+ Backported from 7.33.
+Index: drupal7/modules/system/system.base-rtl.css
+===
+--- drupal7.orig/modules/system/system.base-rtl.css
drupal7/modules/system/system.base-rtl.css
+@@ -9,10 +9,10 @@
+ */
+ /* Animated throbber */
+ html.js input.form-autocomplete {
+- background-position: 0% 2px;
++ background-position: 0% center;
+ }
+ html.js input.throbbing {
+- background-position: 0% -18px;
++ background-position: 0% center;
+ }
+
+ /**
+Index: drupal7/modules/system/system.base.css
+===
+--- drupal7.orig/modules/system/system.base.css
drupal7/modules/system/system.base.css
+@@ -31,12 +31,13 @@
+ }
+ /* Animated throbber */
+ html.js input.form-autocomplete {
+- background-image: url(../../misc/throbber.gif);
+- background-position: 100% 2px; /* LTR */
++ background-image: url(../../misc/throbber-inactive.png);
++ background-position: 100% center; /* LTR */
+ background-repeat: no-repeat;
+ }
+ html.js input.throbbing {
+- background-position: 100% -18px; /* LTR */
++ background-image: url(../../misc/throbber-active.gif);
++ background-position: 100% center; /* LTR */
+ }
+
+ /**
+@@ -164,7 +165,7 @@ table.sticky-header {
+ display: inline-block;
+ }
+ .ajax-progress .throbber {
+- background: transparent url(../../misc/throbber.gif) no-repeat 0px -18px;
++ background: transparent url(../../misc/throbber-active.gif) no-repeat 0px
center;
+ float: left; /* LTR */
+ height: 15px;
+ margin: 2px;
+Index: drupal7/themes/bartik/css/style.css
+===
+--- drupal7.orig/themes/bartik/css/style.css
drupal7/themes/bartik/css/style.css
+@@ -1326,14 +1326,6 @@ input.form-button-disabled:active,
+ color: #717171;
+ }
+
+-/* Animated throbber */
+-html.js input.form-autocomplete {
+- background-position: 100% 4px; /* LTR */
+-}
+-html.js input.throbbing {
+- background-position: 100% -16px; /* LTR */
+-}
+-
+ /* Comment form */
+ .comment-form label {
+ float: left; /* LTR */
+Index: drupal7/themes/seven/style.css
Bug#769907: general: non-sysvinit init systems are made of fail
Before anything else, Michal: Please remember Debian is a volunteer-run project. It is sometimes tempting to reply mails in a haste and making ironic remarks to drive your points further. But mails such as this one are not welcome in Debian. Please assume good faith, and treat everybody with respect. Michal Suchanek dijo [Wed, Nov 19, 2014 at 09:34:22AM +0100]: Sure, it's always user error when something fails. Systems upgraded from Ubuntu are not supported, systems upgraded from Debian are not supported, nor are systems freshly bootstrapped and booted inside qemu. Because all these fail. Upgrading from Ubuntu to Debian is not supported. The two distributions share a lot, but differ also a lot, and there will be cruft left that can get in the way for anything repeatable. Having repeatable results is key for bug resolution. Ubuntu has several package versions which have never been in a Debian Stable release. Upgrades are only supported from Debian - Be it from a stable to a newer stable release, or between points in time in testing and unstable. We have strict policies to ensure version madness will not bite us, but we cannot cover the range of combinations that will bite you if you sidegrade from Ubuntu — Or from any other derived distribution. However, I had this biased personal opinion that the goal of the Debian project should to remove Debian bugs on systems that do run Debian. Please corect me if this is too disconnected from reality. You are right. But we can only do so in a way that is connected to what the policies dictate. We can only do so while keeping sanity. If, for example, you run this script: for i in $(find /usr/lib) do echo FOO $i if $RANDOM 25000 done I can assure you nobody will attempt to support your system.¹ If the user breaks it beyond what we can provide and support, we cannot support it. Again: There are only so many resources available in a volunteer project. Of course, you can provide the funding for somebody to get in your computer and fix the breakage. But Debian does not support such a use case. ¹ Yes, such trivial modifications can be detectable, and we could tell you to reinstall the affected packages, and But I guess you get my point! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#763956: Account name of Hannes von Haugwitz is misspelled
tags 763956 + pending thanks Sorry! I have fixed it in our working tree; it will be included in the next upload. Thanks, signature.asc Description: Digital signature
Bug#758722: cifs-utils: Installed README useless for Debian (describes compiling from Git tree)
Package: cifs-utils Version: 2:6.4-1 Severity: minor The file shipped as /usr/share/doc/cifs-utils/README is useless in a Debian system, as its main content is the build instructions when building from the Git tree. It does have pointers to project resources, but I do not feel they are worth the README. (Just nitpicking, I know :) That's why I labeled the bug as minor) -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.14-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 cifs-utils depends on: ii libc6 2.19-3 ii libcap-ng00.7.3-1.1 ii libkeyutils1 1.5.9-4 ii libkrb5-3 1.12.1+dfsg-3 ii libtalloc22.1.1-1 ii libwbclient0 2:4.1.11+dfsg-1 ii samba-common 2:4.1.11+dfsg-1 Versions of packages cifs-utils recommends: ii keyutils 1.5.9-5 ii winbind 2:4.1.11+dfsg-1 Versions of packages cifs-utils suggests: ii smbclient 2:4.1.11+dfsg-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#756305: ITP: drupal8 -- fully-featured content management framework
Package: wnpp Severity: wishlist Owner: Gunnar Wolf gw...@gwolf.org * Package name: drupal8 Version : 8.0 Upstream Author : Dries Buytaert dr...@drupal.org * URL : http://www.drupal.org/ * License : GPLv2 Programming Lang: PHP Description : fully-featured content management framework Drupal is a dynamic web site platform which allows an individual or community of users to publish, manage and organize a variety of content, Drupal integrates many popular features of content management systems, weblogs, collaborative tools and discussion-based community software into one easy-to-use package. . This package contains version 8 of Drupal. Please note the description is basically a copy of Drupal 7's. Drupal does not really provide an automated upgrade path between releases (and there are *deep* changes that can lead to hair loss when upgrading; just look at a recent photo of myself to fully comprehend the problematic), but several versions can be concurrently installed. They should be regarded as independent pieces of software. Jessie shipped with both drupal6 and drupal7. Drupal 8.0 is not yet shipped, but I want to start preparing the package, as they are committed to shipping before our freeze — And I do want to try to have it available in Jessie. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754315: lintian: Recommends obsolete solution on python-depends-but-no-python-helper
Package: lintian
Version: 2.5.24
Severity: normal
When Lintian finds a Python package using dh has a ${python:Depends}
dependency, it suggests adding a build-dependency on
python-support. However, adding said build-dependency results on
build-depends-on-obsolete-package, suggesting to use dh_python2
instead.
The advice should be updated to suggest straight to call dh --with
python2 and build-depend on python.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.14-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 lintian depends on:
ii binutils 2.24.51.20140617-1
ii bzip2 1.0.6-5
ii diffstat 1.58-1
ii file 1:5.19-1
ii gettext0.18.3.2-2
ii hardening-includes 2.5
ii intltool-debian0.35.0+20060710.1
ii libapt-pkg-perl0.1.29+b1
ii libarchive-zip-perl1.37-2
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.37-1
ii libdigest-sha-perl 5.92-1
ii libdpkg-perl 1.17.10
ii libemail-valid-perl1.194-1
ii libfile-basedir-perl 0.03-1
ii libipc-run-perl0.92-1
ii liblist-moreutils-perl 0.33-2
ii libparse-debianchangelog-perl 1.2.0-1
ii libtext-levenshtein-perl 0.09-1
ii libtimedate-perl 2.3000-2
ii liburi-perl1.60-1
ii man-db 2.6.7.1-1
ii patchutils 0.3.3-1
ii perl [libdigest-sha-perl] 5.18.2-4
ii t1utils1.37-2
Versions of packages lintian recommends:
ii libautodie-perl 2.25-1
ii libperlio-gzip-perl 0.18-3
ii perl-modules [libautodie-perl] 5.18.2-4
Versions of packages lintian suggests:
pn binutils-multiarch none
ii dpkg-dev 1.17.10
ii libhtml-parser-perl3.71-1+b1
ii libtext-template-perl 1.46-1
ii libyaml-perl 0.95-1
ii xz-utils 5.1.1alpha+20120614-2
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#747736: FTBFS: Test ruby2.1 failed. Exiting.
tags 747736 + unreproducible thanks Hi, I have attempted to build this package on a clean chroot, and found no problem (and thus would like to confirm with you whether this RC bug report can be closed). What I found in your failure build log is that all of the failing tests I checked mention: 1) Error: HTTPAccess2::TestClient#test_agent_name: Errno::EADDRINUSE: Address already in use - listen(2) Now, the tests bind to a port in localhost — The setup_server function in test_http-access2.rb begins with: def setup_server @server = WEBrick::HTTPServer.new( :BindAddress = localhost, :Logger = @logger, :Port = 0, :AccessLog = [], :DocumentRoot = File.dirname(File.expand_path(__FILE__)) ) @serverport = @server.config[:Port] I do feel odd the fact that it declares :Port = 0 — But then again, it fails to make the build fail either in my regular work environment or in a clean chroot. signature.asc Description: Digital signature
Bug#751480: debian-keyring: Distribute recent version via stable-updates
tags 751480 wontfix thanks Simon Hollenbach dijo [Fri, Jun 13, 2014 at 01:57:21PM +0200]: Dear Maintainer, At debian-u...@lists.debian.org, it was discussed [ https://lists.debian.org/debian-user/2014/06/msg00856.html ff] that the current linux source package for wheezy could not be verified using $ dpkg-source -x linux[...] It was suggested on list to wish for a recent d-k to be distributed via stable-updates, which I am hereby doing. If there is something I can help with to make this possible, please let me know. Hi, I would even argue in the opposite way :) The debian-keyring package is not always updated when we upload a new keyring, and it's a never-dying source of confusion. Given we have a public Git tree, which is up-to-date with the live keyring, I guess that should suffice — And maybe distributing the package as a static thing never to be updated is no longer useful. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#751397: ITP: drmips -- Educational MIPS simulator - DrMIPS
Hi Bruno, * Package name: drmips Version : 1.2.1 Upstream Author : Bruno Nova brunomb.n...@gmail.com * URL : https://bitbucket.org/brunonova/drmips/ * License : GPL Programming Lang: Java Description : Educational MIPS simulator - DrMIPS (...) I am the author of the program. Above was the general description of the software. This simulator is to be used mostly in Computer Architecture classes where the MIPS architecture is studied. It simulates some MIPS code and shows, step-by-step: the assembled code, the registers, the data memory and a graphical representation of the datapath (unicycle or pipeline). I intend to package the PC version of the simulator (obviously). As a teacher (although I teach Operating Systems, but for some things, I'm sure it's needed for my students to understand Computer Architecture, and it's good to have tools to point them to), I am interested in seeing this tool. Now, I know this is a very specific program, and useless to most people. Also, besides the University where it was created, probably almost no one else uses it (1 or 2 other universities, at maximum). So, I'm perfectly fine if the package is not accepted. After all, no one requested this package. But this would also be the first package I would send to Debian, so it would be useful for me to learn how to submit packages to Debian and Ubuntu repositories. I have a package for Ubuntu in a PPA, though (ppa:brunonova/ppa). Most packaes are requested only by the person uploading and maintaining them, and only later are found to be useful for others. I would say your package is welcome; even more so knowing that you as the upstream author are interested in having it in Debian. I'd only ask what does your package provide that existing packages don't - I know, for example, we have SPIM. SPIM is quite old, and has had a slow upload history. Its last new upstream release is eight years already. But for the task it fulfills, it is a good tool. How would you compare DrMIPS with SPIM? signature.asc Description: Digital signature
Bug#750964: remove from stable too (+oldstable?)
Holger Levsen dijo [Mon, Jun 09, 2014 at 01:20:13PM +0200]: Hi Gunnar, will you also ask for the removal of imsniff from stable and oldstable? As long as there is still a final oldstable pointrelease scheduled, I think this makes sense. Right... It is a useless package. I did not think modifying a stable release would be warranted, but I'll mention it in my other report. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750965: remove from stable too (+oldstable?)
Holger Levsen replied to my bug report on imsniff suggesting my removal request should also be extensive to stable and oldstable: will you also ask for the removal of imsniff from stable and oldstable? As long as there is still a final oldstable pointrelease scheduled, I think this makes sense. I don't see why not. So please, remove it as well! signature.asc Description: Digital signature
Bug#750964: imsniff: Useless after the MSN chat network is shut down
Package: imsniff Version: 0.04-6 Severity: grave Justification: renders package unusable In March 2013, Microsoft dropped support for the MSN chat protocol. This package deals only with this protocol, which is no longer used. I will be filing a request for package removal given this package has seen no new uploads since 2011 and is no longer useful; this report is to notify the maintainer about this. Greetings, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-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#750965: RM: imsniff -- RoQA; Not useful since March 2013, when Microsoft killed MSN Messenger
Package: ftp.debian.org Severity: normal Note that I'm not part of the QA team, so am unsure if this request should be RoQA — But am doing it because of QA. imsniff's description reads: The imsniff program can be used to log IM activity on the network. It uses libpcap to capture packets and analyzes them, logging conversation, contact lists, etc. This could surely seem interesting. However, after a couple of paragraph, it closes by saying: imsniff is beta software, for now, only MSN is supported. Others could follow. imsniff has not seen a Debian upload since February 2011 (and the upstream vesion never evolved beyond 0.04, uploaded initially in 2004. I have (perhaps redundantly?) filed an RC bug on it (#750964) stating this issue. I believe the package should not be part of any future Debian releases. Thanks, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750966: ITP: pcredz -- Extract authentication information from a pcap file or from a live interface
Package: wnpp Severity: wishlist Owner: Gunnar Wolf gw...@gwolf.org * Package name: pcredz Version : 20140606 Upstream Author : Laurent Gaffie laurent.gaf...@gmail.com * URL : http://github.com/lgandx/PCredz * License : GPLv3+ Programming Lang: Python Description : Extract authentication information from a pcap file or from a live interface This package listens to a live network interface or reads from a pcap file, and extracts different authentication information, including POP, SMTP, IMAP, SNMP community string, FTP, HTTP Basic, NTLM v1/v2, Kerberos and credit card numbers. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750662: SV: MATE 1.8 has now fully arrived in Debian
Package: mate-desktop-environment Version: 1.8.0+2~bpo70+1 Following up on the thread in the mailing list: are there any reasons for the »strange« package description in mate-desktop-environment (and more) The MATE Desktop Environment, a non-intuitive and unattractive desktop for users, using traditional computing desktop metaphor. bye Joe Danish I have adopted this a little self-ironic description from the meta package mate-desktop-environment that has been provided on the upstream package site so far [1]. If you feel we should change that, please file a bug report against that package in Debian. Being self-ironic is not a service to our users, who might be interested in a traditional, lightweight desktop environment (and will not choose to suffer with a non-intuitive and unattractive solution instead). Cheers, and thanks for the work! (...waiting for it to be compiled for armhf...) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#748828: collabtive: CVE-2014-3246 CVE-2014-3247
Salvatore Bonaccorso dijo [Wed, May 21, 2014 at 07:18:46AM +0200]: the following vulnerabilities were published for collabtive. CVE-2014-3246[0]: | SQL injection vulnerability in Collabtive 1.2 allows remote | authenticated users to execute arbitrary SQL commands via the folder | parameter in a fileview_list action to manageajax.php. CVE-2014-3247[1]: | Cross-site scripting (XSS) vulnerability in Collabtive 1.2 allows | remote authenticated users to inject arbitrary web script or HTML via | the desc parameter in an Add project (addpro) action to admin.php. If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities Exposures) ids in your changelog entry. Hi Salvatore, Thanks a lot for the heads-up! I have uploaded a new release fixing CVE-2014-3246; I have not been able to look into CVE-2014-3247; any help will be most appreciated! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746993: description could indicate it also includes Maintainers keyring
tags 746993 + pending thanks Fixed in our working tree. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#745743: lintian: Report when a Files-Excluded field is specified without a proper copyright-format
Package: lintian
Version: 2.5.22.1
Severity: minor
Tags: patch
The Files-Excluded field in debian/copyright is used to exclude files
from our not-so-pristine upstream source. It is meant to discard
non-DFSG files. The field will be ignored by uscan if the copyright
file is not declared as following the format 1.0.
Note that I have not tested the patch I'm sending, I just somehow hope
it works ;-)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.13-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 lintian depends on:
ii binutils 2.24-5
ii bzip2 1.0.6-5
ii diffstat 1.58-1
ii file 1:5.17-1
ii gettext0.18.3.2-1
ii hardening-includes 2.5
ii intltool-debian0.35.0+20060710.1
ii libapt-pkg-perl0.1.29+b1
ii libarchive-zip-perl1.37-2
ii libclass-accessor-perl 0.34-1
ii libclone-perl 0.36-1
ii libdigest-sha-perl 5.88-1
ii libdpkg-perl 1.17.6
ii libemail-valid-perl1.192-1
ii libfile-basedir-perl 0.03-1
ii libipc-run-perl0.92-1
ii liblist-moreutils-perl 0.33-2
ii libparse-debianchangelog-perl 1.2.0-1
ii libtext-levenshtein-perl 0.06~01-2
ii libtimedate-perl 2.3000-1
ii liburi-perl1.60-1
ii man-db 2.6.6-1
ii patchutils 0.3.2-3
ii perl [libdigest-sha-perl] 5.18.2-2+b1
ii t1utils1.37-2
Versions of packages lintian recommends:
ii libautodie-perl 2.25-1
ii libperlio-gzip-perl 0.18-2
ii perl-modules [libautodie-perl] 5.18.2-2
Versions of packages lintian suggests:
pn binutils-multiarch none
ii dpkg-dev 1.17.6
ii libhtml-parser-perl3.71-1+b1
ii libtext-template-perl 1.46-1
ii libyaml-perl 0.84-1
ii xz-utils 5.1.1alpha+20120614-2
-- no debconf information
diff --git a/copyright-file.desc b/copyright-file.desc
index 28683aa..0bbeef3 100644
--- a/copyright-file.desc
+++ b/copyright-file.desc
@@ -420,3 +420,17 @@ Info: The copyright file has lines ending in CRLF instead of just LF.
ttCR/tt character in the file:
.
ttsed -i 's/\r//g' path/to/file/tt
+
+Tag: files-excluded-ignored-without-copyright-format-1.0
+Severity: serious
+Certainty: certain
+Info: You have included a Files-Excluded field in your
+ debian/copyright, but the copyright format is not declared as the
+ finalised 1.0 revision. Uscan will ignore this field.
+ .
+ Make sure your debian/copyright starts with the following line:
+ .
+ Format: http://www.debian.org/doc/packaging-manuals/copyright-format/1.0/
+ .
+ Of course, you will have to use the format throughout (that is, list
+ the licenses in a programatically readable way)
diff --git a/copyright-file.pm b/copyright-file.pm
index d910fca..43f5940 100644
--- a/copyright-file.pm
+++ b/copyright-file.pm
@@ -338,6 +338,18 @@ sub run {
}
}
+# debian/copyright has, via the Files-Excluded field, the ability
+# to alter uscan's behaviour. uscan will ignore, though, this file
+# if the format is not declared as copyright-format 1.0
+#
+# Note: I'm unsure whether it checks for version 1.0 or higher,
+# this should probably be checked against uscan's source.
+if (m/^Files-Excluded:/ and
+! m!^Format:.*doc/packaging-manuals/copyright-format/1.0!
+) {
+tag 'files-excluded-ignored-without-copyright-format-1.0';
+}
+
return;
} # /run
Bug#699286: Make Drupal7 use the systemwide jquery
reopen 699286 severity 699286 wishlist tags 699286 wontfix thanks I'm very sorry, this bug... does not seem ever likely to go away. I uploaded 7.27+dfsg-1, which did away with this embedded copy, but horribly broke Drupal for everyone. Turns out, they have a hard dependency on the 1.4.4 version. So, this will remain a wishlist, wontfix bug for the forseeable future :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744888: owncloud: Configuration via web interface and activation of bookmarks plugin fails
David Prévot dijo [Tue, Apr 15, 2014 at 04:25:47PM -0400]: Hi Mark, Package: owncloud Version: 5.0.14.a+dfsg-1~bpo70+2 (...) The package may need a dependency against php-mdb2-driver-mysql (= 1.5.0b4-1), can you please confirm the install goes smoothly with a more recent php-mdb2-driver-mysql package? Furthermore, there are security issues with this owncloud version, and some of its dependencies currently in backports, so I can only encourage upgrading the (backports) packages ASAP (or remove them from backports if thats not sustainable). Hi, I was recently contacted asking for a backports upload for OwnCloud. I must recognize I was quite naïve regarding the work that OwnCloud requires — While I am not the only one that pushed for OwnCloud to be backported (and I didn't do most of the needed work!), I have to recognize I don't have the time to keep up with it, and unless somebody else (Mike?) wants to continue pushing it, I would recommend for dropping it from Backports. signature.asc Description: Digital signature
Bug#738921: drupal7: Installation for PostgreSQL: script does not install the php-PostgreSQL driver
tags 738921 + wontfix thanks Hi, Drupal currently depends on you having installed either php5-mysql or php5-pgsql, either of them is enough to get a successful Drupal installation. Of course, it would be desireable not to prompt you for a DB driver that's currently not available... But we don't want to diverge much from upstream. But anyway, now that you got me thinking on this topic: Drupal is _slowly_ working towards really supporting PostgreSQL, but I still cannot recommend it to you. The issue was terrible under Drupal6, where even parts of the core Drupal died under any DB driver different than MySQL. Nowadays, thanks to the DB abstraction done for the 7.x releases, a Drupal install is much more likely to succed with PostgreSQL — but still, many modules will not be happy with it (as they specifically use some MySQL quirks). At least until Drupal8 is out (and then we shall discuss it again!), I strongly suggest you (with all the heartache this brings to me!) to stick to MySQL. PostgreSQL is vastly superior, but it will bring you problems. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#738918: Installation: invalid relative path to Apache configuration
tags 738918 + pending thanks Thanks for bringing this to our attention, and (at the same time) a big apology for not noting this earlier! I have fixed this in our working tree; please bear a bit with an updated package, as I'm looking into another important bug that has to be fixed soon. Just please note that, after installing Drupal, it will still be necessary to enable Drupal's configuration snippet, by calling: # /usr/sbin/a2enconf drupal7 Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744985: lintian: Privacy breach should not complain about links to example.org
Package: lintian Version: 2.5.22.1 Severity: minor Drupal7 triggers two Lintian checks in the W privacy-breach-generic category. The messages are: usr/share/drupal7/modules/aggregator/tests/aggregator_test_atom.xml example.org/ usr/share/drupal7/modules/aggregator/tests/aggregator_test_atom.xml example.org/2003/12/13/atom03 The 'example.org' domain has been reserved by IANA¹ as an example second-level domain precisely for this use. ¹ https://www.rfc-editor.org/rfc/rfc2606.txt -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-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 lintian depends on: ii binutils 2.24-5 ii bzip2 1.0.6-5 ii diffstat 1.58-1 ii file 1:5.17-1 ii gettext0.18.3.2-1 ii hardening-includes 2.5 ii intltool-debian0.35.0+20060710.1 ii libapt-pkg-perl0.1.29+b1 ii libarchive-zip-perl1.37-2 ii libclass-accessor-perl 0.34-1 ii libclone-perl 0.36-1 ii libdigest-sha-perl 5.88-1 ii libdpkg-perl 1.17.6 ii libemail-valid-perl1.192-1 ii libfile-basedir-perl 0.03-1 ii libipc-run-perl0.92-1 ii liblist-moreutils-perl 0.33-2 ii libparse-debianchangelog-perl 1.2.0-1 ii libtext-levenshtein-perl 0.06~01-2 ii libtimedate-perl 2.3000-1 ii liburi-perl1.60-1 ii man-db 2.6.6-1 ii patchutils 0.3.2-3 ii perl [libdigest-sha-perl] 5.18.2-2+b1 ii t1utils1.37-2 Versions of packages lintian recommends: ii libautodie-perl 2.25-1 ii libperlio-gzip-perl 0.18-2 ii perl-modules [libautodie-perl] 5.18.2-2 Versions of packages lintian suggests: pn binutils-multiarch none ii dpkg-dev 1.17.6 ii libhtml-parser-perl3.71-1+b1 ii libtext-template-perl 1.46-1 ii libyaml-perl 0.84-1 ii xz-utils 5.1.1alpha+20120614-2 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744286: [collabtive] [DFSG] Missing source
Hi, I will try to contact upstream to fix this bug ASAP. I cannot, however, find the files you mention in tinymce: $ apt-get source tinymce $ cd tinymce-3.4.8+dfsg-0 $ find . -name jsval.js $ find . -name mycalendar.js $ find . -name window.js How did you find them to be a part of tinymce? FWIW, digging (quickly) in the source directory, I see there is a include/js/mycalendar_orig.js, which seems to be used to derive mycalendar.js (from a quick look, the defined functions I found in the first one do appear in the second). I *do* see some other minified javascripts in the same directory: prototype.php includes Prototype 1.6.0.3 (we currently ship 1.7.1), although I don't understand why it has a PHP header... There is also lytebox.php, with a similar PHP header; lytebox is not part of Debian, but is in GitHub under a CC-BY 3.0 license: https://github.com/tnederveld/Lytebox The source is (again, at a first look) similar to what I found at https://github.com/tnederveld/Lytebox/blob/master/src/lytebox.js, although I have not checked whether this is the exact same minified output. Thanks, signature.asc Description: Digital signature
Bug#744286: [collabtive] [DFSG] Missing source
Gunnar Wolf dijo [Sat, Apr 12, 2014 at 10:44:52AM -0500]: (...) I *do* see some other minified javascripts in the same directory: prototype.php includes Prototype 1.6.0.3 (we currently ship 1.7.1), although I don't understand why it has a PHP header... (...) OK, and I see in debian/copyright that somewhere along the history we did have a include/js/uncompressed directory, and we had more identifiable information regarding the files you mention: Files: include/js/calendar.js Copyright: © Michael Loesler License: GPL-3+ Files: include/js/jsval.js Copyright: © 2003, 2005 Timo Haberkern, Karl Seguin License: LGPL-2+ Files: include/js/uncrompressed/lytebox.js include/js/lytebox.js Copyright: © 2007 Markus F. Hay License: CC-BY-3.0 ...So I'll dig into the history, and check with the authors on why the directory is no longer included. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Drupal7 - minified JavaScript
Daniel Pocock dijo [Thu, Apr 10, 2014 at 12:40:27PM +0200]: Hi Gunnar, I just saw your comment on this bug from February 18 Personally, I don't think it is enough to say that a package is not using some artifacts from the source tarball - while it is a technically valid argument, it would make it far more difficult for FTP masters to inspect source packages and badness could start to creep in as a consequence of any generosity they show in this area. Repackaging upstream tarballs is becoming a common problem with minified JavaScript, maybe we need to have some automated way of doing this. For upstreams who use git and who release the exact contents of their tags (without any autotools bootstrapping, etc), it should be fairly easy to create some system on alioth that mirrors all the upstreams and pro-actively generates +dfsg versions of their tags ready for maintainers to work with. Right. This bug was opened before the relevant discussion in d-devel, and I am also convinced the minified js should be removed from the source tarball. I have not had time to look into this, and any help you can give will be appreciated; a simple (or as simple as possible, at least) repack.sh script should do. Automating this sounds interesting, but I cannot do more than just say it sounds interesting right now :( signature.asc Description: Digital signature
Bug#735769: Drupal7 - minified JavaScript
FWIW, this list might prove useful, and also point at libraries not
yet packaged:
drupal7$ for js in $(find . -name *.min.js); do
js=$(basename $js)
echo -n $js ⇒
found=$(apt-file search $js|cut -f 1 -d :|grep -v ^drupal7)
if [ -z $found ]; then
nonmin=$(apt-file search ${js/.min/}|cut -f 1 -d :);
if [ -z $nonmin ]; then
echo NOT PACKAGED;
else
echo $nonmin (NON MINIMIZED);
fi
else
echo $found
fi
done
jquery.ui.position.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.slide.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.autocomplete.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.core.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.clip.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.highlight.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.core.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.explode.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.tabs.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.progressbar.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.shake.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.draggable.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.droppable.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.accordion.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.scale.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.datepicker.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.dialog.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.drop.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.blind.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.resizable.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.bounce.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.transfer.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.effects.pulsate.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.mouse.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.slider.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.selectable.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.fade.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.button.min.js ⇒ libjs-jquery-ui wordpress
jquery.ui.sortable.min.js ⇒ libjs-jquery-ui wordpress
jquery.effects.fold.min.js ⇒ mediawiki (NON MINIMIZED)
jquery.ui.widget.min.js ⇒ libjs-jquery-ui wordpress
So,
• Wordpress has at least the same duplication Drupal7 has WRT
libjs-jquery-ui (which should be the canonical source for .min.js
files)
• Many of the files we need are provided by Mediawiki. Should they
rather be split?
• Of course, it's not just a matter of finding the right filename, but
ensuring they are compatible and do not produce regressions :-/
Something that Javascript has a bad fame about...
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
Matteo F. Vescovi dijo [Fri, Mar 28, 2014 at 08:47:31AM +0100]: I didn't forget you... the simple answer is that I don't know how to fix this, if there's a fix ;-) Anyhow, given that it's a python-related issue (iirc), could you please test if v2.70 release (now in experimental) changes this still situation? I haven't uploaded it to unstable yet because of libav10 transition, but there are no additional b-deps to build it smoothly compared to v2.69. Let me know something about it; then I can contact some blender upstream devels to dig deeper into this issue, even if they are not so confident with ARM architecture right now ;-P Right, I think that the bug at some point will be reassigned to Python... But I understand about this way less than you do ;-) The package is not yet available on armhf¹ (nor armel, FWIW). I will check again during the weekend. There are many architectures where the build failed, I just hope it succeeds on armhf. Otherwise... Well, I'll try to get the HDD working again to build on something faster than my SD :) ¹ https://buildd.debian.org/status/package.php?p=blendersuite=experimental -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742813: pitivi: Video rendering halts (with error) when one of the files finishes
Package: pitivi Version: 0.15.2-0.2 Severity: normal I am trying to make a video out of several files. As is often the case, the different parts of the video overlap in time, but some finish before others. I know a bug report should be self-contained, but OTOH I cannot paste here 300MB of data for you to reproduce this bug, so I'll leave the needed files available at: https://nube.gwolf.org/public.php?service=filest=368628c8829be0303e6f2444e09860ef I try to render the Chema_Serralde_todo_webm.xptv file with the following settings: - General - Preset: HTML5 - Container format: WebM - Video: - Scale 100% (640x480) - Frame rate:23.976 fps - Codec: On2 VP8 - Audio: - Channels: mono - Sample rate: 44.1KHz - Sample depth: 16 bit - Codec: Vorbis The render starts (although the target file gets generated, but stays at 0). However, when the render reaches 20% (0:28:58.203, that is, when the clip P3190002.webm finishes), rendering just stops advancing, and the preview window stays still. I get the following messages sent to the invoking console: ERROR [ 6877] [0x7f7e757e3700] Pipeline at 0x7f7e5a414e50 pipeline Mar 27 12:31:59 _handleErrorMessage: error from /GstPipeline:pipeline0/GstBin:bin0/GnlComposition:gnlcomposition0/GnlSource:gnlsource: FileSourceFactory3/GstBin:bin6/pitivi+elements+singledecodebin+SingleDecodeBin:pitivi+elements+singledecodebin+singledecodebin3/GstMatroskaDemux:matroskademux3 (__main__.GstMatroskaDemux): GStreamer encountered a general stream error. (matroska-demux.c(4492): gst_matroska_demux_loop (): /GstPipeline:pipeline0/GstBin:bin0/GnlComposition:gnlcomposition0/GnlSource:gnlsource: FileSourceFactory3/GstBin:bin6/pitivi+elements+singledecodebin+SingleDecodeBin:pitivi+elements+singledecodebin+singledecodebin3/GstMatroskaDemux:matroskademux3: stream stopped, reason not-negotiated) (/usr/lib/pitivi/python/pitivi/pipeline.py:858) Traceback (most recent call last): File /usr/lib/pitivi/python/pitivi/pipeline.py, line 918, in _binPadAddedCb handled |= action.handleNewStream(factory, stream) File /usr/lib/pitivi/python/pitivi/action.py, line 502, in handleNewStream prodstream, consstream, init=False) File /usr/lib/pitivi/python/pitivi/action.py, line 640, in _activateLink tee.link(queue) gst.LinkError: failed to link tee5 with queue36 ERROR [ 6877] [0x7f7e757e3700] Pipeline at 0x7f7e5a414e50 pipeline Mar 27 12:31:59 _handleErrorMessage: error from /GstPipeline:pipeline0/GstBin:bin0/GnlComposition:gnlcomposition0/GnlSource:gnlsource: FileSourceFactory0/GstBin:bin1/pitivi+elements+singledecodebin+SingleDecodeBin:pitivi+elements+singledecodebin+singledecodebin0/GstQTDemux:qtdemux17 (__main__.GstQTDemux): GStreamer encountered a general stream error. (qtdemux.c(3891): gst_qtdemux_loop (): /GstPipeline:pipeline0/GstBin:bin0/GnlComposition:gnlcomposition0/GnlSource:gnlsource: FileSourceFactory0/GstBin:bin1/pitivi+elements+singledecodebin+SingleDecodeBin:pitivi+elements+singledecodebin+singledecodebin0/GstQTDemux:qtdemux17: streaming stopped, reason not-negotiated) (/usr/lib/pitivi/python/pitivi/pipeline.py:858) Thanks a lot for any help solving this issue. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.13-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 pitivi depends on: ii gnome-icon-theme 3.10.0-1 ii gstreamer0.10-alsa [gstreamer0.10-audiosink] 0.10.36-1.1 ii gstreamer0.10-gnonlin 0.10.17-2 ii gstreamer0.10-plugins-bad [gstreamer0.10-videosink] 0.10.23-7.2 ii gstreamer0.10-plugins-base0.10.36-1.1 ii gstreamer0.10-plugins-good [gstreamer0.10-videosink] 0.10.31-3+nmu2 ii gstreamer0.10-pulseaudio [gstreamer0.10-audiosink]0.10.31-3+nmu2 ii gstreamer0.10-x [gstreamer0.10-videosink] 0.10.36-1.1 ii libgstreamer-plugins-base0.10-0 0.10.36-1.1 ii libgstreamer0.10-00.10.36-1.2 ii python2.7.5-5 ii python-cairo 1.8.8-1+b2 ii python-dbus 1.2.0-2+b2 ii python-gconf 2.28.1+dfsg-1 ii python-glade2 2.24.0-3+b1 ii python-gst0.100.10.22-3 ii python-gtk2 2.24.0-3+b1 ii python-pkg-resources 3.3-1 ii python-pygoocanvas0.14.1-1+b3 ii python-xdg0.25-4 ii python-zope.interface
Bug#739194: blender: Segfaults at startup on armhf
Forgot to comment about this for too long — Blender does /not/ run either on armel. But it also fails to die — I left it (apparently) running for over a full day, and it didn't seem to make anything. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#730960: Does not (or no longer?) depend on Ruby 1.8
reopen 730960 tags 730960 + pending thanks David Suárez dijo [Fri, Mar 14, 2014 at 07:29:52PM +0100]: Maybe I miss something, but on current unstable version (0.6.5-7), we have: Vcs-Browser: http://git.debian.org/?p=pkg-ruby-extras/ruby-bdb.git;a=summary Homepage: https://rubyforge.org/projects/bdb/ XS-Ruby-Versions: ruby1.8 Ugh, I'm sorry - I guess I just checked on the changelog entry in the git tree, and it seemed to have been uploaded already! I'm reopening the bug, but tagging it as pending. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#741576: ruby-bdb: FTBFS (on AMD64): Test failures
Source: ruby-bdb Version: 0.6.6-1 Severity: serious Justification: FTBFS on amd64 Attempting to build this package on AMD64, I got the following results: 88 /usr/bin/install -c -m 0755 bdb.so ./.gem.20140313-22704-1exw4lh make[1]: Leaving directory `/home/gwolf/vcs/build-area/ruby-bdb-0.6.6/src' Running tests for ruby1.9.1 using debian/ruby-tests.rb... VERSION of BDB is Berkeley DB 5.3.28: (September 9, 2013) Run options: # Running tests: Finished tests in 0.561218s, 21.3821 tests/s, 4124.9583 assertions/s. 12 tests, 2315 assertions, 0 failures, 0 errors, 0 skips VERSION of BDB is Berkeley DB 5.3.28: (September 9, 2013) Run options: # Running tests: ... Finished tests in 4.073800s, 5.6458 tests/s, 1880.0627 assertions/s. 1) Error: test_18_hash_delete(TestHash): RangeError: integer -1893907612379325628 too small to convert to `unsigned int' tests/hash.rb:387:in `initialize' tests/hash.rb:387:in `new' tests/hash.rb:387:in `open' tests/hash.rb:387:in `test_18_hash_delete' 2) Error: test_18_index(TestHash): BDB::Fatal: closed DB tests/hash.rb:400:in `index' tests/hash.rb:400:in `block in test_18_index' tests/hash.rb:397:in `times' tests/hash.rb:397:in `test_18_index' 3) Error: test_19_convert(TestHash): BDB::Fatal: closed DB tests/hash.rb:409:in `to_hash' tests/hash.rb:409:in `test_19_convert' 4) Error: test_20_blurb(TestHash): BDB::Fatal: closed DB tests/hash.rb:426:in `each' tests/hash.rb:426:in `test_20_blurb' 23 tests, 7659 assertions, 0 failures, 4 errors, 0 skips ERROR: Test ruby1.9.1 failed. Exiting. dh_auto_install: dh_ruby --install /home/gwolf/vcs/build-area/ruby-bdb-0.6.6/debian/ruby-bdb returned exit code 1 make: *** [binary] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 88 Setting $VERBOSE=1 in tests/hash.rb yields the following results with Ruby 1.9.1: 88 $ ruby1.9.1 -e '$:../../build-area/ruby-bdb-0.6.6/debian/ruby-bdb/usr/lib/ruby/vendor_ruby/1.9.1//x86_64-linux/; require ./tests/hash' VERSION of BDB is Berkeley DB 5.3.28: (September 9, 2013) Run options: # Running tests: ..E/home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:400: warning: Hash#index is deprecated; use Hash#key EE. Finished tests in 3.898375s, 5.6434 tests/s, 1967.7432 assertions/s. 1) Error: test_18_hash_delete(TestHash): RangeError: integer -3058836581575265859 too small to convert to `unsigned int' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `initialize' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `new' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `open' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `test_18_hash_delete' 2) Error: test_18_index(TestHash): BDB::Fatal: closed DB /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:400:in `index' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:400:in `block in test_18_index' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:397:in `times' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:397:in `test_18_index' 3) Error: test_19_convert(TestHash): BDB::Fatal: closed DB /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:409:in `to_hash' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:409:in `test_19_convert' 22 tests, 7671 assertions, 0 failures, 3 errors, 0 skips 88 And with Ruby 2.0: 88 $ ruby2.0 -e '$:../../build-area/ruby-bdb-0.6.6/debian/ruby-bdb/usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.0.0/; require ./tests/hash' VERSION of BDB is Berkeley DB 5.3.28: (September 9, 2013) Run options: # Running tests: [19/22] TestHash#test_18_hash_delete = 0.00 s 1) Error: test_18_hash_delete(TestHash): RangeError: integer 3180312599820893546 too big to convert to `unsigned int' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `initialize' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `new' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `open' /home/gwolf/vcs/pkg-ruby-extras/ruby-bdb/tests/hash.rb:387:in `test_18_hash_delete' /usr/lib/ruby/2.0.0/minitest/unit.rb:1301:in `run' /usr/lib/ruby/2.0.0/test/unit/testcase.rb:17:in `run' /usr/lib/ruby/2.0.0/minitest/unit.rb:919:in `block in _run_suite' /usr/lib/ruby/2.0.0/minitest/unit.rb:912:in `map' /usr/lib/ruby/2.0.0/minitest/unit.rb:912:in `_run_suite' /usr/lib/ruby/2.0.0/test/unit.rb:657:in `block in _run_suites' /usr/lib/ruby/2.0.0/test/unit.rb:655:in `each' /usr/lib/ruby/2.0.0/test/unit.rb:655:in
Bug#741040: devscripts: Add a switch, variable to ask debcommit to gpg-sign commits
Package: devscripts
Version: 2.14.1
Severity: normal
Tags: patch
For keyring-maint work, we gpg-sign each individual commit to the
repository. We were until now using a Bazaar repository, but as we are
switching to Git, we can no longer specify that commit messages should
be signed by default.
I usually do my keyring-maint commits via debcommit; this simple patch
solves our use case (and you see here included my ~/.devscripts
putting it in action).
Ah, and FWIW: I chose to leave the configuration variable as
DEBCOMMIT_SIGN_COMMITS, because its meaning is in plural (always
sign the commits), but the command line switch in singular
(--sign-commit), because it only applies to the current case.
-- Package-specific info:
--- /etc/devscripts.conf ---
--- ~/.devscripts ---
DEBSIGN_KEYID=C1DB921F
DEBCOMMIT_SIGN_COMMITS=yes
-- 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/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 devscripts depends on:
ii dpkg-dev 1.17.6
ii libc62.18-3
ii perl 5.18.2-2
ii python3 3.3.4-1
pn python3:any none
Versions of packages devscripts recommends:
ii at 3.1.14-1
ii curl7.35.0-1
ii dctrl-tools 2.23
pn debian-keyring none
ii dput0.9.6.4
ii equivs 2.0.9
ii fakeroot1.20-3
ii gnupg 1.4.16-1.1
ii libdistro-info-perl 0.12
ii libencode-locale-perl 1.03-1
ii libjson-perl2.61-1
ii liblwp-protocol-https-perl 6.04-2
ii libparse-debcontrol-perl2.005-4
ii libsoap-lite-perl 1.10-1
ii liburi-perl 1.60-1
ii libwww-perl 6.05-2
ii lintian 2.5.21
ii man-db 2.6.6-1
ii patch 2.7.1-4
ii patchutils 0.3.2-3
ii python3-debian 0.1.21+nmu2
ii python3-magic 1:5.17-0.1
ii sensible-utils 0.0.9
ii strace 4.5.20-2.3
ii unzip 6.0-10
ii wdiff 1.2.1-2
ii wget1.15-1
ii xz-utils5.1.1alpha+20120614-2
Versions of packages devscripts suggests:
ii bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii build-essential 11.6
ii cvs-buildpackage 5.23
ii devscripts-el35.11
ii gnuplot 4.6.4-2
ii gpgv 1.4.16-1.1
ii libauthen-sasl-perl 2.1500-1
ii libfile-desktopentry-perl0.07-1
ii libnet-smtp-ssl-perl 1.01-3
ii libterm-size-perl0.207-1+b1
ii libtimedate-perl 2.3000-1
ii libyaml-syck-perl1.27-2+b1
ii mutt 1.5.21-6.4
ii openssh-client [ssh-client] 1:6.5p1-4
ii svn-buildpackage 0.8.5
ii w3m 0.5.3-15
-- no debconf information
--- /usr/bin/debcommit 2014-01-25 21:17:55.0 -0600
+++ /tmp/debcommit 2014-03-07 12:43:33.0 -0600
@@ -82,6 +82,11 @@
This option is set by default and ignored if more than one line of
the message begins with [*+-] .
+=item B--sign-commit, B--no-sign-commit
+
+If this option is set, then the commits that debcommit creates will be
+signed using gnupg. Currently this is only supported by git.
+
=item B--sign-tags, B--no-sign-tags
If this option is set, then tags that debcommit creates will be signed
@@ -116,6 +121,11 @@
If this is set to Iyes, then it is the same as the B--sign-tags command
line parameter being used. The default is Ino.
+=item BDEBCOMMIT_SIGN_COMMITS
+
+If this is set to Iyes, then it is the same as the B--sign-commit
+command line parameter being used. The default is Ino.
+
=item BDEBCOMMIT_RELEASE_USE_CHANGELOG
If this is set to Iyes, then it is the same as the B--release-use-changelog
@@ -204,6 +214,8 @@
-a --allCommit all files (default except for git)
-s --strip-message Strip the leading '* ' from the commit message
--no-strip-message Do not strip a leading '* ' (default)
+ --sign-commit Enable signing of the commit (git only)
+ --no-sign-commitDo not sign the commit (default)
--sign-tags Enable signing of tags (git only)
--no-sign-tags Do not sign tags (default)
--changelog-infoUse author and date information from the changelog
@@ -240,6 +252,7 @@
my $edit=0;
my $all=0;
my $stripmessage=1;
+my $signcommit=0;
my $signtags=0;
my $changelog;
my $changelog_info=0;
@@ -257,6 +270,7 @@
my @config_files = ('/etc/devscripts.conf', '~/.devscripts');
my %config_vars = (
'DEBCOMMIT_STRIP_MESSAGE' = 'yes',
+ 'DEBCOMMIT_SIGN_COMMITS'
Bug#741040: devscripts: Add a switch, variable to ask debcommit to gpg-sign commits
tags 741040 + pending thanks I have just pushed my patch in the Git repo. signature.asc Description: Digital signature
Bug#684514: rhythmbox: When playing off Last.fm, two tracks are played and rhythmbox stops and becomes crash-prone
althaser dijo [Mon, Mar 03, 2014 at 09:40:54PM +]: Hey Gunnar, Could you please still reproduce this issue with newer rhythmbox version like 3.0.1-1+b1 ? Hi, Last.fm no longer supports service to my country, so I am not able to check it :-( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
One more data point: I installed an armel chroot in the same machine where Blender is segfaulting on me, and it seems to work fine. That means, Blender is currently running and trying to render an image... I guess it will take quite a bit to succeed, having (the software) no hardfloat support. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
found 739194 2.69-4 thanks I did a clean Sid reinstall, and the bug is still present in the current version. Blender now attempts to generate a file to aid debugging, although it crashed too early for this file ot be of use: $ blender -noaudio -b Color management: using fallback mode for management Writing: /tmp/blender.crash.txt Segmentation fault $ cat /tmp/blender.crash.txt # Blender 2.69 (sub 0), Revision: unknown # backtrace $ The output from gdb is quite different, so I'm including it again: $ gdb --args blender -noaudio -b GNU gdb (GDB) 7.6.2 (Debian 7.6.2-1) Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabihf. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/blender...Reading symbols from /usr/lib/debug/.build-id/98/59f5bff4ae8dd86cf6c93855cbfde406dd6d98.debug...done. done. (gdb) run Starting program: /usr/bin/blender -noaudio -b [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. [New Thread 0x306fd240 (LWP 3002)] [New Thread 0x30efd240 (LWP 3003)] [New Thread 0x316fd240 (LWP 3004)] [New Thread 0x31efd240 (LWP 3005)] [New Thread 0x326fd240 (LWP 3006)] Color management: using fallback mode for management Program received signal SIGSEGV, Segmentation fault. 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 (gdb) bt #0 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #1 0x2acd8c9a in PyErr_Format () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #2 0x2ac8262c in PyType_Ready () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #3 0x2ac55052 in _PyExc_Init () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #4 0x2ace95e2 in _Py_InitializeEx_Private () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/python/intern/bpy_interface.c:274 #6 0x0044a1ca in WM_init (C=C@entry=0x1d83220, argc=argc@entry=3, argv=argv@entry=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/windowmanager/intern/wm_init_exit.c:176 #7 0x0042e4de in main (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/creator/creator.c:1597 (gdb) The segfault no longer follows an error in ./Python/errors.c (but it still happens in PyErr_SetObject). I am a real gdb newbie, so I'm just repeating what I've been told to do ;-) But a full backtrace gives: (gdb) bt full #0 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #1 0x2acd8c9a in PyErr_Format () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #2 0x2ac8262c in PyType_Ready () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #3 0x2ac55052 in _PyExc_Init () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #4 0x2ace95e2 in _Py_InitializeEx_Private () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/python/intern/bpy_interface.c:274 py_tstate = 0x0 py_path_bundle = 0x0 program_path_wchar = L/usr/bin/blender, '\000' repeats 1007 times #6 0x0044a1ca in WM_init (C=C@entry=0x1d83220, argc=argc@entry=3, argv=argv@entry=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/blender/windowmanager/intern/wm_init_exit.c:176 No locals. #7 0x0042e4de in main (argc=3, argv=0x7efff8d4) at /build/blender-dPxPUD/blender-2.69/source/creator/creator.c:1597 C = 0x1d83220 syshandle = 0x1d8a338 ba = 0x1d8a840 (gdb) #5 looks very odd to me. Why would /usr/bin/blender be repeated 1007 times? That does look like a stack overflow... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
While I continue to learn the basics of gdb, this seems to confirm a stack overflow: Several of the threads have corrupt stacks. (gdb) thread apply all backtrace Thread 6 (Thread 0x326fd240 (LWP 4977)): #0 0x2b1adf94 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 #1 0x2b1ab3f2 in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0 #2 0x2b1ab466 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 #3 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 #4 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 5 (Thread 0x31efd240 (LWP 4976)): #0 0x2b1adf94 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 #1 0x2b1ab3f2 in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0 #2 0x2b1ab466 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 #3 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 #4 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 4 (Thread 0x316fd240 (LWP 4975)): #0 0x2b1adf94 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 #1 0x2b1ab3f2 in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0 #2 0x2b1ab466 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 #3 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 #4 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 3 (Thread 0x30efd240 (LWP 4974)): #0 0x2b1adf94 in __libc_do_syscall () from /lib/arm-linux-gnueabihf/libpthread.so.0 #1 0x2b1ab3f2 in do_futex_wait () from /lib/arm-linux-gnueabihf/libpthread.so.0 #2 0x2b1ab466 in sem_wait@@GLIBC_2.4 () from /lib/arm-linux-gnueabihf/libpthread.so.0 #3 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 #4 0x2b8fc99e in ?? () from /usr/lib/arm-linux-gnueabihf/libIlmThread.so.6 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 2 (Thread 0x306fd240 (LWP 4973)): #0 0x2c645914 in poll () from /lib/arm-linux-gnueabihf/libc.so.6 #1 0x2fbbf578 in ?? () from /lib/arm-linux-gnueabihf/libusb-1.0.so.0 #2 0x2fbbf578 in ?? () from /lib/arm-linux-gnueabihf/libusb-1.0.so.0 Backtrace stopped: previous frame identical to this frame (corrupt stack?) Thread 1 (Thread 0x2fef8430 (LWP 4970)): #0 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #1 0x2acd8c9a in PyErr_Format () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #2 0x2ac8262c in PyType_Ready () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #3 0x2ac55052 in _PyExc_Init () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #4 0x2ace95e2 in _Py_InitializeEx_Private () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff734) at /build/blender-dPxPUD/blender-2.69/source/blender/python/intern/bpy_interface.c:274 #6 0x0044a1ca in WM_init (C=C@entry=0x1d83220, argc=argc@entry=3, argv=argv@entry=0x7efff734) at /build/blender-dPxPUD/blender-2.69/source/blender/windowmanager/intern/wm_init_exit.c:176 #7 0x0042e4de in main (argc=3, argv=0x7efff734) at /build/blender-dPxPUD/blender-2.69/source/creator/creator.c:1597 (gdb) bt full #0 0x2acd8cce in PyErr_SetObject () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #1 0x2acd8c9a in PyErr_Format () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #2 0x2ac8262c in PyType_Ready () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #3 0x2ac55052 in _PyExc_Init () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #4 0x2ace95e2 in _Py_InitializeEx_Private () from /usr/lib/arm-linux-gnueabihf/libpython3.3m.so.1.0 No symbol table info available. #5 0x00697898 in BPY_python_start (argc=3, argv=0x7efff734) (gdb) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
I'm providing some further data points, guided by the kind souls in #debian-arm ;-) After installing gdb, blender-dbg and python3.2-dbg, I ran blender through gdb, and got the following output: $ gdb --args blender -b -noaudio GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as arm-linux-gnueabihf. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from /usr/bin/blender...Reading symbols from /usr/lib/debug/usr/bin/blender...(no debugging symbols found)...done. (no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/blender -b -noaudio [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/arm-linux-gnueabihf/libthread_db.so.1. [New Thread 0x2d9ff3e0 (LWP 10385)] [New Thread 0x2e1ff3e0 (LWP 10386)] [New Thread 0x2e9ff3e0 (LWP 10387)] [New Thread 0x2f1ff3e0 (LWP 10388)] Program received signal SIGSEGV, Segmentation fault. PyErr_SetObject (exception=0x2ae1acb4, value=0x2f3d5520) at ../Python/errors.c:59 59 ../Python/errors.c: No such file or directory. (gdb) bt #0 PyErr_SetObject (exception=0x2ae1acb4, value=0x2f3d5520) at ../Python/errors.c:59 #1 0x2ace318c in PyErr_Format (exception=0x2ae1acb4, format= 0x2ad5c0e4 type '%.100s' participates in gc and is a base type but has inappropriate tp_free slot) at ../Python/errors.c:612 #2 0x2acead0e in PyType_Ready.part.39 (type=0x2ae1b9b8) at ../Objects/typeobject.c:3964 #3 PyType_Ready (type=0x2ae1b9b8) at ../Objects/typeobject.c:3851 #4 0x2acc9acc in _PyExc_Init () at ../Objects/exceptions.c:1984 #5 0x2acca140 in Py_InitializeEx.part.9 (install_sigs=1) at ../Python/pythonrun.c:272 #6 Py_InitializeEx (install_sigs=1) at ../Python/pythonrun.c:183 #7 0x004f9950 in BPY_python_start () #8 0x003034ea in WM_init () #9 0x002f6878 in main () (gdb) I'll try to peek a bit more into it, will post if I get anywhere further. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#735769: Sourceless file
Hi Bastien, I am still not finished fixing this bug (and have not yet tested if my changes will work fine as they are), but would like your (+ftpmasters') input on whether what I'm doing is enough — I hope to avoid needing to repackage upstream's sources. Please refer to my commit in the Drupal7 repository: http://anonscm.debian.org/gitweb/?p=collab-maint/drupal7.git;a=commitdiff;h=91cdae2a901f275cb156de32515f12fc93e17160;hp=f2aa61e2697d1f3da43097e9549e94aeeb31e6dd In short: We are already packaging the different libjs-jquery modules (at a higher version than the one shipped in Drupal7). Yes, we don't carry the sources for the minified Javascript files, but they *are* DFSG-free, and they allow for distribution in non-source format (they are MIT-licensed). So, am I patching in the right direction? Or would it be preferrable to do a repack and use +dfsg versions? Greetings, -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739194: blender: Segfaults at startup on armhf
Subject: blender: Segfaults at startup on armhf Package: blender Version: 2.63a-1 Severity: important I'm trying to test Blender's performance under an armhf machine; sadly, whatever I do to try and start Blender up results in a segfault. Either starting Blender up with a file to process or starting it up with no arguments results in an immediate segfault: $ blender -b -noaudio Segmentation fault I will try installing the version in unstable (the system is currently a pure Wheezy one). I'm not using a Debian-provided kernel, as I understand support for the specific subarchitecture is not yet mainline. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: armhf (armv7l) Kernel: Linux 3.0.35-8 (SMP w/4 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory ANSI_X3.4-1968) Shell: /bin/sh linked to /bin/dash Versions of packages blender depends on: ii fonts-droid 20111207+git-1 ii libavcodec53 6:0.8.10-1 ii libavdevice53 6:0.8.10-1 ii libavformat53 6:0.8.10-1 ii libavutil51 6:0.8.10-1 ii libc6 2.13-38+deb7u1 ii libfftw3-33.3.2-3.1 ii libfontconfig12.9.0-7.1 ii libfreetype6 2.4.9-1.1 ii libgcc1 1:4.7.2-5 ii libgl1-mesa-glx [libgl1] 8.0.5-4+deb7u2 ii libglew1.71.7.0-3 ii libglu1-mesa [libglu1]8.0.5-4+deb7u2 ii libgomp1 4.7.2-5 ii libilmbase6 1.0.1-4 ii libjack-jackd2-0 [libjack-0.116] 1.9.8~dfsg.4+20120529git007cdc37-5 ii libjpeg8 8d-1 ii libopenal11:1.14-4 ii libopenexr6 1.6.1-6 ii libopenjpeg2 1.3+dfsg-4.7 ii libpng12-01.2.49-1 ii libpython3.2 3.2.3-7 ii libsdl1.2debian 1.2.15-5 ii libsndfile1 1.0.25-5 ii libstdc++64.7.2-5 ii libswscale2 6:0.8.10-1 ii libtiff4 3.9.6-11 ii libx11-6 2:1.5.0-1+deb7u1 ii libxi62:1.6.1-1+deb7u1 ii python3.2 3.2.3-7 ii zlib1g1:1.2.7.dfsg-13 blender recommends no packages. Versions of packages blender suggests: pn yafaray none -- debconf information: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = en_US.UTF-8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#737563: ITP: telegram-cli -- Command-line interface for Telegram
Cleto Martín dijo [Mon, Feb 03, 2014 at 08:52:41PM +]: Package: wnpp Severity: wishlist Owner: Cleto Martín cl...@debian.org * Package name: telegram-cli Version : 0.1 Upstream Author : Vitaly Valtman * URL : https://github.com/vysheng/tg * License : GPL Programming Lang: C Description : Command-line interface for Telegram messenger Also, please look at Martín Ferrari's blog post¹ before doing work that will promote the use of Telegram. Granted, the Telegram client *is* free software (barring the already mentioned GPL/SSL license compatibility issue) and has legitimate uses, but Martín's analysis seems quite thorough and interesting! ¹ http://blog.tincho.org/posts/Telegram/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736454: README.gz should document nonupload
About to upload the package with this correction, thanks to Ian for noticing it! Ian: I do not believe this is worth a stable update, but if you insist, please insist me on doing so, and I'll most probably push it. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736325: dh-make-drupal: Developer versions are detected as recommended
tags 736325 + confirmed thanks Arne Nordmark dijo [Wed, Jan 22, 2014 at 10:55:01AM +0100]: Package: dh-make-drupal Version: 1.7-1 Severity: normal Developer versions of modules are detected as both recommended and developer, and selected over recommended versions, when scanning the Drupal site. Right. From a quick look, this is caused because of the Drupal page having the wrong (semantic) structure... Maybe in an effort to achieve aesthetic improvement :-/ I'm currently looking for the versions inside the view-project-release-download-table element, searching for rows in the view-display-id-(.+) class. But... view-display-id-development (and the other possible levels) are inside view-display-id-recommended :-| ...I'm writing to the bug report in part to leave a trace of what I've found. It seems easy to get to a fix having found this, but I have to go. Will continue to work on it soon! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736424: collabtive: Symlinks are shipped to the package maintainer's home directory
Package: collabtive Version: 1.2-1 Severity: important I'm quoting here a mail sent directly to me by David López. This clear mistake of mine clearly makes several components of Collabtive unusable by anybody but myself :-| First of all my apologies for this message but I'm not sure if I must write to debian bug system or directly to the maintainer. If I must send it to Debian bugs system please let me know. I tried to install collabtive in diferent flavours (stable/testing) and I have found an strange behaviour. In the installlation folder you can find lots of symbolic links to your home folder example: /usr/share/collabtive/www/include/include# ls -lisa total 40 2103250 4 drwxr-xr-x 3 root root 4096 ene 23 11:49 . 2103218 4 drwxr-xr-x 8 root root 4096 ene 23 15:04 .. 2103251 4 drwxr-xr-x 2 root root 4096 ene 23 11:49 barcodes 2103326 4 lrwxrwxrwx 1 root root 96 oct 29 01:56 sRGB.icc - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/sRGB.icc 2103327 4 lrwxrwxrwx 1 root root 104 oct 29 01:56 tcpdf_colors.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_colors.php 2103324 4 lrwxrwxrwx 1 root root 105 oct 29 01:56 tcpdf_filters.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_filters.php 2103325 4 lrwxrwxrwx 1 root root 107 oct 29 01:56 tcpdf_font_data.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_font_data.php 2103323 4 lrwxrwxrwx 1 root root 103 oct 29 01:56 tcpdf_fonts.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_fonts.php 2103329 4 lrwxrwxrwx 1 root root 104 oct 29 01:56 tcpdf_images.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_images.php 2103328 4 lrwxrwxrwx 1 root root 104 oct 29 01:56 tcpdf_static.php - /home/gwolf/vcs/build-area/collabtive-1.1/debian/collabtive/usr/share/php/tcpdf/include/tcpdf_static.php This is just a sample you can find a lot of them in every class. I found the same behaviuor in both flavours Stable 0.7.6-1 and testing 1.1-1. This makes a lot of warnings|errors in apache logs and an strange behaviour in the app. If this is not the rigth place my apologies. Cheers, David Thanks a lot for this report, David. I'll work on it as soon as possible — But am submitting it as a bug report to ensure it does not get trampled by my regular life activities :-| -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) 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 collabtive depends on: ii apache2 2.4.6-3 ii apache2-bin [httpd] 2.4.6-3 ii libjs-prototype 1.7.1-3 ii libphp-pclzip2.8.2-2 ii libphp-phpmailer 5.1-1 ii php-tcpdf6.0.021+dfsg-1 ii php5 5.5.6+dfsg-1 ii php5-mcrypt 5.5.6+dfsg-1 ii php5-mysql 5.5.6+dfsg-1 ii php5-pgsql 5.5.6+dfsg-1 ii smarty3 3.1.13-1 ii tinymce 3.4.8+dfsg0-1 ii wwwconfig-common 0.2.2 Versions of packages collabtive recommends: ii apache2 2.4.6-3 ii apache2-bin [httpd] 2.4.6-3 Versions of packages collabtive suggests: ii wget 1.14-5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731462: flvtool2: Please update to allow for Ruby 1.8 deprecation
Package: flvtool2 Version: 1.0.6-4 Severity: important Tags: patch Hi, Your package is built using the obsolete setup.rb framework, and depends on the ruby1.8. Ruby1.8 is scheduled to be removed before the Jessie release. You can apply the patch I am inlining here to make it work under Ruby1.9.1 (which will be Jessie's default), but you should also look into making it not depend on a specific version of the Ruby interpreter, to ease the migration for the 2.0 release (which is already packaged in Debian, and will most probably be the default in Jessie+1). I did just a very basic check that the packaged continued to function (just called it from the command line, didn't specify any real work to be performed). Thanks, diff --git a/debian/control b/debian/control index 460856b..b16d9da 100644 --- a/debian/control +++ b/debian/control @@ -2,13 +2,13 @@ Source: flvtool2 Section: utils Priority: extra Maintainer: Todd Troxell ttrox...@debian.org -Build-Depends: debhelper (= 5), ruby1.8 +Build-Depends: debhelper (= 5), ruby1.9.1 Standards-Version: 3.7.2 XS-Vcs-Hg: http://code.rapidpacket.com/flvtool2/ Package: flvtool2 Architecture: any -Depends: ruby1.8 +Depends: ruby1.9.1 Description: a manipulation tool for flash video files flvtool2 can display and modify various metadata on flash video files It can also add cue points, cut, and debug flv files. It can output diff --git a/debian/rules b/debian/rules index 351ddad..e2e09fc 100755 --- a/debian/rules +++ b/debian/rules @@ -3,7 +3,7 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 -RUBY=/usr/bin/ruby1.8 +RUBY=/usr/bin/ruby1.9.1 ifneq (,$(findstring noopt,$(DEB_BUILD_OPTIONS))) CFLAGS += -O0 @@ -14,8 +14,8 @@ endif configure: configure-stamp configure-stamp: dh_testdir - #$(RUBY) setup.rb config --libdir=/usr/lib/ruby/1.8/ - $(RUBY) setup.rb config --siterubyver=/usr/lib/ruby/1.8/ + #$(RUBY) setup.rb config --libdir=/usr/lib/ruby/1.9.1/ + $(RUBY) setup.rb config --siterubyver=/usr/lib/ruby/1.9.1/ touch configure-stamp build: build-stamp -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) 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 flvtool2 depends on: ii ruby 1:1.9.3 ii ruby1.8 [ruby-interpreter]1.8.7.358-8 ii ruby1.9.1 [ruby-interpreter] 1.9.3.448-1 ii ruby2.0 [ruby-interpreter]2.0.0.343-1 flvtool2 recommends no packages. flvtool2 suggests no packages. -- debconf-show failed -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731465: ecasound: Please update to allow for Ruby 1.8 deprecation
Package: ecasound
Version: 2.9.0-1
Severity: important
Tags: patch
Hi,
Your package depends on the obsolete 1.8 version of Ruby.
Ruby1.8 is scheduled to be removed before the Jessie release. You can
apply the trivial patch I am inlining here to make it work under newer
Ruby releases (including 1.9.1, which will be Jessie's default).
This patch also drops the transitional libecasound-ruby1.8 package,
as, since it was introduced pre-wheezy, it's no longer necessary.
Please note that I did *not* check the package works fine with this
change made — It just makes the dependency go away. Several packages
are known to use a syntax that clashes with Ruby = 1.9.1; please test
before uploading!
Thanks!
diff --git a/debian/control b/debian/control
index 69cc9a7..9e5a1b4 100644
--- a/debian/control
+++ b/debian/control
@@ -192,10 +192,7 @@ Description: transitional dummy package for python-ecasound
Package: ruby-ecasound
Architecture: all
Section: ruby
-Depends: ${misc:Depends}, ruby1.8, ecasound
-Provides: libecasound-ruby
-Replaces: libecasound-ruby1.8 ( 2.8.1-6)
-Breaks: libecasound-ruby1.8 ( 2.8.1-6)
+Depends: ${misc:Depends}, ruby | ruby-interpreters, ecasound
Description: multitrack-capable audio recorder and effect processor (ruby
bindings)
Ecasound is a software package designed for multitrack audio processing. It
can be used for simple tasks like audio playback, recording and format
@@ -208,16 +205,6 @@ Description: multitrack-capable audio recorder and effect
processor (ruby bindin
.
This package provides ecasound's Ruby bindings.
-Package: libecasound-ruby1.8
-Architecture: all
-Section: oldlibs
-Depends: ${misc:Depends}, ruby-ecasound
-Description: transitional dummy package for ruby-ecasound
- This dummy package is provided for a smooth transition from the previous
- libecasound-ruby1.8 package to the ruby-ecasound package.
- .
- It may be safely removed after installation.
-
Package: ecasound-el
Architecture: all
Section: lisp
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731465: ecasound: Please update to allow for Ruby 1.8 deprecation
Alessandro Ghedini dijo [Thu, Dec 05, 2013 at 07:16:50PM +0100]:
Ruby1.8 is scheduled to be removed before the Jessie release. You can
apply the trivial patch I am inlining here to make it work under newer
Ruby releases (including 1.9.1, which will be Jessie's default).
This patch also drops the transitional libecasound-ruby1.8 package,
as, since it was introduced pre-wheezy, it's no longer necessary.
ruby-ecasound was introduced *in* wheezy, and the transitional package is
still
necessary for proper upgrades from squeeze (not that I expect to be many users
of the package, let alone in squeeze, but still).
Right — Users upgrading from Squeeze will get to Wheezy (with
pre-wheezy, I meant during the Wheezy release cycle) and will have
the ruby-ecasound package installed. When they upgrade from Wheezy to
Jessie, the transitional package will no longer be necessary. So, it's
safe to remove it now.
Debian does not support directly upgrading from release x to x+2, so
users upgrading from Squeeze will anyway go through Wheezy.
Please note that I did *not* check the package works fine with this
change made — It just makes the dependency go away. Several packages
are known to use a syntax that clashes with Ruby = 1.9.1; please test
before uploading!
Looks good to me (at least the tests seem to run fine).
+Depends: ${misc:Depends}, ruby | ruby-interpreters, ecasound
Shouldn't it be ruby-interpreter (without final 's')?
Oops! Of course it should. Shame on me for suggesting a buggy patch
:-) Glad you checked
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#729974: Patch: Adding a 'status' target to the initscript
Package: thin
Version: 1.3.1-3
Severity: normal
Tags: patch
I added a 'status' target to the initscript, which gives useful
information (i.e. which Thin servers went down if any). I decided to
implement it against the output of netstat and not against the running
processes as I have at least found one case where an instance was
running but somehow not listening to the right socket — But I know
this might be polemic/dirty.
Read: I'm not uploading this yet, please comment!
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
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 thin depends on:
ii libc6 2.17-93
ii libruby1.81.8.7.358-8
ii libruby1.9.1 1.9.3.448-1
ii ruby 1:1.9.3
ii ruby-daemons 1.1.5-2
ii ruby-eventmachine 1.0.3-3
ii ruby-rack 1.5.2-1
ii ruby1.8 [ruby-interpreter]1.8.7.358-8
ii ruby1.9.1 [ruby-interpreter] 1.9.3.448-1
ii ruby2.0 [ruby-interpreter]2.0.0.299-2
thin recommends no packages.
thin suggests no packages.
-- debconf-show failed
From 984ff8a1a01e01d3510733388338bc6d409b1fba Mon Sep 17 00:00:00 2001
From: Gunnar Wolf gw...@debian.org
Date: Tue, 19 Nov 2013 11:54:14 -0600
Subject: [PATCH] Added a status target to the initscript
---
debian/changelog | 7 +
debian/control | 2 +-
debian/patches/fix-init-script | 63 ++
3 files changed, 66 insertions(+), 6 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 6e74d9a..dda5de9 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+thin (1.3.1-4) UNRELEASED; urgency=low
+
+ * Team upload
+ * Added a status target to the initscript
+
+ -- Gunnar Wolf gw...@debian.org Tue, 19 Nov 2013 11:48:22 -0600
+
thin (1.3.1-3) unstable; urgency=low
* Team upload.
diff --git a/debian/control b/debian/control
index 999c30f..617e045 100644
--- a/debian/control
+++ b/debian/control
@@ -13,7 +13,7 @@ XS-Ruby-Versions: all
Package: thin
Architecture: any
XB-Ruby-Versions: ${ruby:Versions}
-Depends: ${shlibs:Depends}, ${misc:Depends}, ruby | ruby-interpreter, ruby-rack (= 1.0.0), ruby-eventmachine (= 0.12.10), ruby-daemons (= 1.0.9)
+Depends: ${shlibs:Depends}, ${misc:Depends}, ruby | ruby-interpreter, ruby-rack (= 1.0.0), ruby-eventmachine (= 0.12.10), ruby-daemons (= 1.0.9), lsb-base
Replaces: thin1.8 ( 1.3.1-1)
Breaks: thin1.8 ( 1.3.1-1)
Provides: thin1.8
diff --git a/debian/patches/fix-init-script b/debian/patches/fix-init-script
index 249f261..adab242 100644
--- a/debian/patches/fix-init-script
+++ b/debian/patches/fix-init-script
@@ -1,9 +1,9 @@
# (better) lsb compliance
-Index: ruby-thin/lib/thin/controllers/service.sh.erb
+Index: thin/lib/thin/controllers/service.sh.erb
===
ruby-thin.orig/lib/thin/controllers/service.sh.erb 2012-01-10 01:15:50.0 -0800
-+++ ruby-thin/lib/thin/controllers/service.sh.erb 2012-01-10 01:17:56.0 -0800
+--- thin.orig/lib/thin/controllers/service.sh.erb 2013-11-19 11:40:33.0 -0600
thin/lib/thin/controllers/service.sh.erb 2013-11-19 11:43:17.0 -0600
@@ -4,7 +4,7 @@
# Required-Start:$local_fs $remote_fs
# Required-Stop: $local_fs $remote_fs
@@ -13,11 +13,13 @@ Index: ruby-thin/lib/thin/controllers/service.sh.erb
# Short-Description: thin initscript
# Description: thin
### END INIT INFO
-@@ -15,20 +15,28 @@
+@@ -15,23 +15,80 @@
DAEMON=%= Command.script %
SCRIPT_NAME=%= INITD_PATH %
-CONFIG_PATH=%= config_files_path %
++
++. /lib/lsb/init-functions
# Exit if the package is not installed
[ -x $DAEMON ] || exit 0
@@ -31,6 +33,23 @@ Index: ruby-thin/lib/thin/controllers/service.sh.erb
+ % end %
+}
+
++parse_config() {
++# Thin configuration files are expressed as flat YAML; implement a very
++# simplistic parser, good enough for our limited purposes.
++#
++# This parser interprets each YAML declaration used in this script
++# in the current shell environment; of course, it should be used
++# with care, as a crafted expression could lead to arbitrary code
++# execution. Some care is taken to sanitize it.
++CONFIG=$1
++if [ ! -f $CONFIG -o ! -r $CONFIG ]; then
++echo Thin configuration file $CONFIG not readable
++exit 3
++fi
++`ruby -ne 'next unless /^(port|servers|address|tag)\s*:\s*([\.\-\_\d\w]+)$/ ;puts export %s=%s % [$1,$2]' $CONFIG`
++}
++
++
case $1 in
start)
- $DAEMON start --all $CONFIG_PATH
@@ -45,5 +64,39 @@ Index: ruby-thin/lib/thin/controllers/service.sh.erb
+ restart|force-reload|reload)
+ run_action restart
;;
++ status
Bug#729974: Acknowledgement (Patch: Adding a 'status' target to the initscript)
FWIW, this patch includes fixing the Lintian warning (init.d-script-does-not-source-init-functions) currently reported for this package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722242: debian-maintainers: Please add James Hunt as a Debian Maintainer
James Hunt dijo [Mon, Oct 28, 2013 at 09:35:37AM +]: Thanks Jonathan, However, it appears the updated package hasn't hit the archive yet? Hi James, According to what I see, your key was uploaded to the Debian keyring servers on October 7. Not every keyring upload is accompanied by a package upload — But it will be included in the next upload we make. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#717387: mirrors: Primary Debian mirror site DOWN of Mexico
Simon Paillard dijo [Mon, Oct 14, 2013 at 09:16:19PM +0200]: While ftp.mx is managed by mmc.geofisica.unam.mx since July, I cannot access http://debian.unam.mx/debian/project/trace/ Could you fix it ? Hi Simon, As I have said to the relevant people several times... I don't understand why we have two mirrors on the same university network — That means, almost, two mirrors on the same LAN. I don't know what prompted the mirror change from nisamox to mmc; I supposed you had marked it as the main mirror. Anyway, Sergio, do you happen to know more about this? Is nisamox down for a known reason? Should we continue to duplicate efforts (and hardware expenses) having two separately-owned, separately-managed mirrors in UNAM? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722375: [DRE-maint] Bug#722375: Updating the Ruby packaging policy for your package «libposixlock-ruby»
Tomas Pospisek dijo [Fri, Oct 11, 2013 at 03:46:32PM +0200]: according to popcon there are a few user using the package. I don't know if the number there is statistically relevant - or in other words if those users really *are* using the package. If we leave the package in Debian as is, then at least we serve those few users. I'm not sure what we gain by dropping the package. But please proceed as you judge right. Hi Tomas, The problem is that, as this bug is not compatible with Ruby ≥ 1.9.1, and upstream no longer supports it, it would not allow us to drop Ruby 1.8 (which is planned to happen during this release cycle). Jessie will ship with support for Ruby 1.9.1 and 2.0, but 1.8 will be dropped. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725115: ruby-inline: Does not work under Ruby 2.0
Package: ruby-inline Version: 3.11.2-2 Severity: important Tags: upstream Although ruby-inline can be required from Ruby2.0 code, trying to actually use it fails: $ irb2.0 require 'inline' = true Inline = Inline Inline.inline :C do;end RuntimeError: unsupported ruby version: 2.0.0 from /usr/lib/ruby/vendor_ruby/inline.rb:149:in `directory' from /usr/lib/ruby/vendor_ruby/inline.rb:393:in `so_name' from /usr/lib/ruby/vendor_ruby/inline.rb:516:in `load_cache' from /usr/lib/ruby/vendor_ruby/inline.rb:842:in `inline' from (irb):3 from /usr/bin/irb2.0:12:in `main' Compared to: $ irb1.9.1 require 'inline' = true Inline = Inline Inline.inline :C do;end = true This renders all packages depending on ruby-inline (that ship tests, so they actually do work) FTBFS. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.8-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages ruby-inline depends on: ii rake 10.0.4-1 ii ruby 1:1.9.3 ii ruby1.8 [ruby-interpreter]1.8.7.358-8 ii ruby1.8-dev 1.8.7.358-8 ii ruby1.9.1 [ruby-interpreter] 1.9.3.448-1 ii ruby1.9.1-dev 1.9.3.448-1 ii ruby2.0 [ruby-interpreter]2.0.0.299-2 Versions of packages ruby-inline recommends: ii gcc [c-compiler] 4:4.8.1-3 ii gcc-4.4 [c-compiler] 4.4.7-4 ii gcc-4.6 [c-compiler] 4.6.4-4 ii gcc-4.7 [c-compiler] 4.7.3-7 ii gcc-4.8 [c-compiler] 4.8.1-10 ii rubygems 1.8.24-1 ruby-inline 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#720250: ruby-image-science: FTBFS with ruby2.0: ERROR: Test ruby2.0 failed: /usr/lib/ruby/vendor_ruby/inline.rb:149:in `directory': unsupported ruby version: 2.0.0 (RuntimeError)
tags 720250 + confirmed thanks Hi, I confirm I stumbled upon this problem as well. It is caused by ruby-inline, where I filed it as #725115. I am not just reassigning as there are subtleties to both sides of the problem :-| -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725115: ruby-inline: Does not work under Ruby 2.0
I tried to upload to the newest upstream release, 3.12.2, but the bug behaviour persists. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#725062: ruby-rmagick: FTBFS when specifying hardening parameters
Package: ruby-rmagick
Version: 2.13.2-1
Severity: normal
When building this package (minor revision that adds support under
Ruby 2.0), the package builds successfully, but spews the following
Lintian warnings:
| W: ruby-rmagick: hardening-no-relro
usr/lib/ruby/vendor_ruby/1.9.1/x86_64-linux/RMagick2.so
| N:
| N:This package provides an ELF binary that lacks the read-only
| N:relocation link flag. This package was likely not built with the
| N:default Debian compiler flags defined by dpkg-buildflags. If built
using
| N:dpkg-buildflags directly, be sure to import LDFLAGS.
| N:
| N:Refer to http://wiki.debian.org/Hardening for details.
| N:
| N:Severity: normal, Certainty: certain
| N:
| N:Check: binaries, Type: binary, udeb
| N:
| W: ruby-rmagick: hardening-no-relro
usr/lib/x86_64-linux-gnu/ruby/vendor_ruby/2.0.0/RMagick2.so
Following the above advice, I tried by adding the following patch, but
failed as the C code turned some warnings into errors — Particularly,
I got (at least) two format not a string literal and no format
arguments complaints in rmutil.c, i.e. at:
| void
| rm_fatal_error_handler(const ExceptionType severity, const char *reason,
const char *description)
| {
|rb_raise(Class_FatalImageMagickError,
GetLocaleExceptionMessage(severity, reason));
|description = description;
| }
I was unable to dig deeper into this, and decided to ask for somebody
else's help to fix it :-} Hence this bug.
Thanks for any help,
diff --git a/debian/changelog b/debian/changelog
index f72a755..595e2fe 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,6 +1,8 @@
ruby-rmagick (2.13.2-1) unstable; urgency=low
* New upstream release
+ * Bumped up dh_compat level to 9; added dependency on dpkg-dev to
+include build-hardening flags
-- Gunnar Wolf gw...@debian.org Mon, 30 Sep 2013 17:32:27 -0500
diff --git a/debian/compat b/debian/compat
index 7f8f011..ec63514 100644
--- a/debian/compat
+++ b/debian/compat
@@ -1 +1 @@
-7
+9
diff --git a/debian/control b/debian/control
index ad89013..2e2be56 100644
--- a/debian/control
+++ b/debian/control
@@ -3,9 +3,9 @@ Section: ruby
Priority: optional
Maintainer: Debian Ruby Extras Maintainers
pkg-ruby-extras-maintain...@lists.alioth.debian.org
Uploaders: Antonio Terceiro terce...@softwarelivre.org, Gunnar Wolf
gw...@debian.org, Vincent Fourmond fourm...@debian.org
-Build-Depends: debhelper (= 7.0.50~), gem2deb (= 0.3.0~),
+Build-Depends: debhelper (= 9), gem2deb (= 0.3.0~),
libmagickcore-dev (= 7:6.6.0.4-2~), libwmf-bin,
- ghostscript, gsfonts, libmagickwand-dev
+ ghostscript, gsfonts, libmagickwand-dev, dpkg-dev (= 1.16.1~)
Standards-Version: 3.9.4
Vcs-Git: git://anonscm.debian.org/pkg-ruby-extras/ruby-rmagick.git
Vcs-Browser:
http://anonscm.debian.org/gitweb?p=pkg-ruby-extras/ruby-rmagick.git;a=summary
diff --git a/debian/rules b/debian/rules
index 38f1f63..5d5f444 100755
--- a/debian/rules
+++ b/debian/rules
@@ -11,6 +11,9 @@
# If you need to specify the .gemspec (eg there is more than one)
#export DH_RUBY_GEMSPEC=gem.gemspec
+DPKG_EXPORT_BUILDFLAGS = 1
+include /usr/share/dpkg/buildflags.mk
+
%:
dh $@ --buildsystem=rubysetuprb --with ruby
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.8-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages ruby-rmagick depends on:
ii libc6 2.17-93
ii libmagickcore58:6.7.7.10-6
ii libruby1.9.1 1.9.3.448-1
ii libruby2.02.0.0.299-2
ii ruby1.8 [ruby-interpreter]1.8.7.358-8
ii ruby1.9.1 [ruby-interpreter] 1.9.3.448-1
ii ruby2.0 [ruby-interpreter]2.0.0.299-2
ruby-rmagick recommends no packages.
ruby-rmagick 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#722375: [DRE-maint] Bug#722375: Updating the Ruby packaging policy for your package «libposixlock-ruby»
Tomas Pospisek dijo [Sat, Sep 14, 2013 at 12:52:52PM +0200]: Hello Gunnar and dear Ruby maintainers, I'm currently off, travelling the world. Possibly I will try to bring my Ruby package up to speed, but more probably I won't. Finding the time and calm, internet and AC current is too much of a rare coincidence. So please if anybody feels like fixing my package up, the please do so, thanks a lot and greets to you all, *t Hi Tomas, I downloaded your package to take a stab at repackaging it, but found you had this in your README: The upstream posixlock gem has not been ported and doesn't compile under ruby 1.9. -- Tomas Pospisek tpo_...@sourcepole.ch Tue, 03 Jul 2012 The last time upstream appears to have touched the code is in 2009, but Web references I found to it seem to be from 2005-2007 (maybe the http://www.codeforpeople.com/ server was installed in 2009?); the code is really tied into the C structures of Ruby objects, and I agree with your comment: It fails to build for 1.9.3. Now, although this functionality seems important, the package has no reverse dependencies, and has a very low popcon index. So, I'd suggest filing a bug for its removal. It would be best if you could file this bug; otherwise, I can do it, but please tell me if I should proceed (or, of course, if I should _not_ do so). rant Also I own a HP 6710 series laptop that contains an AMD Seymour Radeon HD 6400M/7400M Series discrete gfx chip that aparently can't be switched off and completely randomly switches itself on and sucks all power out of the batteries, so working off grid over more than an hour is practically impossible. A true piece of shit hw. /rant Ugh. :( signature.asc Description: Digital signature
Bug#722729: moodle: Please provide a Wheezy backport
Package: moodle Version: 2.5.1-2 Severity: wishlist Moodle has long been packaged for Debian, but it was pulled out of Wheezy back in March. Moodle is still being packaged, with versions currently in testing and unstable. I would be very very very very very grateful were Moodle to be offered for the stable release via backports, and I'm sure many other users would as well! Thanks, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.8-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- Gunnar Wolf • gw...@gwolf.org • (+52-55)5623-0154 / 1451-2244 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722378: [DRE-maint] Bug#722378: Updating the Ruby packaging policy for your package «libsnmp-ruby»
tags 722378 + pending thanks Thank you very much for your work! I'm tagging this bug as 'pending'. Once 722437 is dealt with, can I ask you to close 722378? Of course, in some time I'll go over the list and close whatever needs to be closed... But given you will get notice for this, you might be able to answer faster. I am unsure whether the bug will be auto-closed once the package it affects is removed. Thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722387: Updating the Ruby packaging policy for your package «libroot-bindings-ruby-dev»
Package: libroot-bindings-ruby-dev Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Debian Science Maintainers, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libroot-bindings-ruby-dev I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722388: Updating the Ruby packaging policy for your package «libamrita2-ruby»
Package: libamrita2-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi TANIGUCHI Takaki, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libamrita2-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722389: Updating the Ruby packaging policy for your package «libneedle-extras-ruby1.8»
Package: libneedle-extras-ruby1.8 Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Tatsuki Sugiura, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libneedle-extras-ruby1.8 I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722394: Updating the Ruby packaging policy for your package «libmapscript-ruby»
Package: libmapscript-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Debian GIS Project, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libmapscript-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722390: Updating the Ruby packaging policy for your package «libobexftp-ruby»
Package: libobexftp-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Hendrik Sattler, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libobexftp-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722393: Updating the Ruby packaging policy for your package «libsvn-ruby»
Package: libsvn-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Peter Samuelson, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libsvn-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722395: Updating the Ruby packaging policy for your package «libwebapp-ruby»
Package: libwebapp-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi NIIBE Yutaka, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libwebapp-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722392: Updating the Ruby packaging policy for your package «libabstract-ruby»
Package: libabstract-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Bryan McLellan, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libabstract-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722391: Updating the Ruby packaging policy for your package «libsuikyo-ruby1.8»
Package: libsuikyo-ruby1.8 Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Masahito Omote, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libsuikyo-ruby1.8 I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722396: Updating the Ruby packaging policy for your package «libgv-ruby»
Package: libgv-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi David Claughton, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libgv-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722377: Updating the Ruby packaging policy for your package «librrd-ruby»
Package: librrd-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Debian RRDtool Team, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: librrd-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722385: Updating the Ruby packaging policy for your package «libescape-ruby»
Package: libescape-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi NIIBE Yutaka, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libescape-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722384: Updating the Ruby packaging policy for your package «libtcltk-ruby»
Package: libtcltk-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi akira yamada, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libtcltk-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722375: Updating the Ruby packaging policy for your package «libposixlock-ruby»
Package: libposixlock-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Tomas Pospisek, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libposixlock-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722371: Updating the Ruby packaging policy for your package «libhtree-ruby1.8»
Package: libhtree-ruby1.8 Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi NIIBE Yutaka, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libhtree-ruby1.8 I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722367: Updating the Ruby packaging policy for your package «libzip-ruby1.8»
Package: libzip-ruby1.8 Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Tatsuki Sugiura, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libzip-ruby1.8 I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722372: Updating the Ruby packaging policy for your package «libvorbisfile-ruby»
Package: libvorbisfile-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Tatsuki Sugiura, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libvorbisfile-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722370: Updating the Ruby packaging policy for your package «liblangscan-ruby»
Package: liblangscan-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi NIIBE Yutaka, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: liblangscan-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722373: Updating the Ruby packaging policy for your package «libmp3info-ruby1.8»
Package: libmp3info-ruby1.8 Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Gustavo Franco, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libmp3info-ruby1.8 I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722374: Updating the Ruby packaging policy for your package «libraspell-ruby»
Package: libraspell-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Alex Pennace, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libraspell-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722365: Updating the Ruby packaging policy for your package «libmaruku-ruby»
Package: libmaruku-ruby Severity: normal Usertags: ruby18-removal, update-ruby-policy Hi Debian Ruby Extras Maintainers, As you may know, during the Wheezy release cycle, the pkg-ruby-extras team¹ has worked to update the Ruby libraries/modules/gems packages to follow a new policy, much easier for the maintainers (as we no longer require a separate package for each interpreter version), to the archive (as it strongly reduces code duplication), and much more sensical to the users (as they no longer require to fiddle with which among many almost-identical binary packages to install). While we achieved a quite good success level during the Wheezy cycle², we decided to act only on the packages maintained by the group — There are many Ruby library packages maintained by kind people (like yourself!) which have not yet adopted this new style. According to our records, you are currently maintaining the package: libmaruku-ruby I am sending this report as part of a mass-bug-filing.³ Some useful information you might find useful: • Guidelines for Ruby packaging⁴ https://wiki.debian.org/Teams/Ruby/Packaging#Guidelines_for_Ruby_packaging • Ruby team release goals for Jessie⁵ https://wiki.debian.org/Teams/Ruby/Jessie • About the Ruby team — Please consider joining!⁶ https://wiki.debian.org/Teams/Ruby • Part of the new policy involves running the package's tests. Here is a swift introduction on what it means and how to do it: https://wiki.debian.org/Teams/Ruby/Packaging/Tests Thanks a lot for your attention! -- ¹ alioth.debian.org/projects/pkg-ruby-extras/ ² http://pkg-ruby-extras.alioth.debian.org/wheezy/ ³ https://lists.debian.org/debian-devel/2013/09/msg00196.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
