Bug#774122: [rt.debian.org #5651] AutoReply: Please add Alexander Alemayhu's key to the DM keyring
On Mon, Dec 29, 2014 at 04:04:32PM +1100, Aníbal Monsalve Salazar wrote: Hello Alexander Alemayhu, Hei Aníbal Salazar, Your DM application was accepted and the corresponding RT ticket is posted at https://rt.debian.org/Ticket/Display.html?id=5651 \o/ Currently, rt.debian.org isn't accessible for the general public. It was sometime ago. Maybe one of your advocates will look at your RT ticket for you, after it has been taken by a keyring maintainer. See http://wiki.debian.org/rt.debian.org Will do. Not urgent but please try to get more OpenPGP signatures from DDs and sign theirs keys as well. :-) I plan on attending FOSDEM next year, so hopefully I will meet more DDs there and on future conferences :) Thanks. pgpQ3Fy7e7d_8.pgp Description: PGP signature
Bug#774127: game-data-packager: changelog.gz is installed twice
Package: game-data-packager Version: 38 Severity: minor Dear Maintainer, ls -l /usr/share/doc/game-data-packager/changelog.gz /usr/share/games/game- data-packager/changelog.gz -rw-r--r-- 1 root root 5068 déc 29 08:15 /usr/share/doc/game-data- packager/changelog.gz -rw-r--r-- 1 root root 5078 déc 29 08:30 /usr/share/games/game-data- packager/changelog.gz dpkg -S /usr/share/doc/game-data-packager/changelog.gz /usr/share/games/game- data-packager/changelog.gz game-data-packager: /usr/share/doc/game-data-packager/changelog.gz game-data-packager: /usr/share/games/game-data-packager/changelog.gz zdiff /usr/share/doc/game-data-packager/changelog.gz /usr/share/games/game- data-packager/changelog.gz - no difference The 10 bytes difference is due to use of gzip -c9. I guess these two lines in Makefile should go away: gzip -c9 debian/changelog ./out/changelog.gz chmod 0644 ./out/changelog.gz But I don't know what was their purpose; so maybe this is wrong :-| maybe a symlink would do. Alexandre Detiste -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing'), (210, 'experimental'), (210, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/6 CPU cores) Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages game-data-packager depends on: ii dynamite0.1.1-2 ii fakeroot1.20.2-1 ii p7zip-full 9.20.1~dfsg.1-4.1 ii unzip 6.0-12+b1 game-data-packager recommends no packages. Versions of packages game-data-packager suggests: ii binutils 2.24.90.20141023-1 ii cdparanoia 3.10.2+debian-11 ii gcc4:4.9.1-5 pn lgc-pg none pn lhasa | jlha-utils | lhz-archiver none ii make 4.0-8 ii vorbis-tools 1.4.0-6 -- 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#774128: cyrus-caldav: [PATCH] dav: Fails with virtual domain for non-default domain users
Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch
When cyrus is configured with virtual domains and you attempt to create/use
calendars
for users on domains other than the default domain, one gets a mailbox not
found error
due to the way the dav code constructs mailbox names for the calendars and
addressbooks.
The following patch fixes three such issues and gets virtual domains working
for me.
Description: Fix CalDAV/CardDAV with Virtual Domains
Fix CalDAV/CardDAV when user is in a virtual domain so that the virtual
domain gets used in the mailbox name. This fixes CalDAV failing
to create/open mailbox for calendars when user is not in default
or only domain.
There were three issues. The first was that if you specify a domain
in the calendar URI it is converted as if it it were a mailbox name
instead of cyrus domain part (e.g. with '.' separator '.' in domain
is converted to '^') of mailbox name.
This second was that in calendar lookups for scheduling the userid
part of the mailbox name got the domain part truncated due to
'@' being replaced by NUL (string terminator) in calendar lookup
function (caladdress_lookup).
The third was that in some cases mailboxname creation functions
didn't even consider the domain part of the userid and therefore
didn't handle domain mailbox name construction correctly
.
Author: Daniel Dickinson deb...@daniel.thecshore.com
---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:
Origin: vendor|upstream|other, url of original patch
Bug: url in upstream bugtracker
Bug-Debian: https://bugs.debian.org/bugnumber
Bug-Ubuntu: https://launchpad.net/bugs/bugnumber
Forwarded: no|not-needed|url proving that it has been forwarded
Reviewed-By: name and email of someone who approved the patch
Last-Update: -MM-DD
Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/http_caldav.c
===
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/http_caldav.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/http_caldav.c
@@ -632,7 +632,7 @@ static void my_caldav_auth(const char *u
/* Auto-provision calendars for 'userid' */
strlcpy(ident, userid, sizeof(ident));
-mboxname_hiersep_toexternal(httpd_namespace, ident, 0);
+//mboxname_hiersep_toexternal(httpd_namespace, ident, 0);
/* calendar-home-set */
r = mboxlist_lookup(mailboxname, mbentry, NULL);
@@ -761,6 +761,10 @@ static int caldav_parse_path(const char
char *p;
size_t len, siz;
static const char *prefix = NULL;
+char userid[MAX_MAILBOX_BUFFER];
+char userdomain[MAX_MAILBOX_BUFFER];
+char *domain_start;
+int userlen, domainlen;
/* Make a working copy of target path */
strlcpy(tgt-path, path, sizeof(tgt-path));
@@ -857,13 +861,19 @@ static int caldav_parse_path(const char
p = tgt-mboxname;
siz = MAX_MAILBOX_BUFFER;
if (tgt-user) {
- len = snprintf(p, siz, user);
- p += len;
- siz -= len;
-
if (tgt-userlen) {
- len = snprintf(p, siz, .%.*s, (int) tgt-userlen, tgt-user);
- mboxname_hiersep_tointernal(httpd_namespace, p+1, tgt-userlen);
+ domain_start = strchr(tgt-user, '@');
+ if (domain_start != NULL) {
+ userlen = domain_start - tgt-user + 1;
+ domain_start++;
+ domainlen = tgt-userlen - userlen + 1;
+ strlcpy(userid, tgt-user, userlen);
+ strlcpy(userdomain, domain_start, domainlen);
+ len = snprintf(p, siz, %.*s!user.%.*s, (int) domainlen,
userdomain, (int) userlen, userid);
+} else {
+ len = snprintf(p, siz, user.%.*s, (int) tgt-userlen,
tgt-user);
+}
+ // mboxname_hiersep_tointernal(httpd_namespace, p+1, tgt-userlen);
p += len;
siz -= len;
}
@@ -1918,7 +1928,7 @@ static int caldav_post(struct transactio
if (!caladdress_lookup(organizer, sparam)
!(sparam.flags SCHEDTYPE_REMOTE)) {
strlcpy(orgid, sparam.userid, sizeof(orgid));
- mboxname_hiersep_toexternal(httpd_namespace, orgid, 0);
+ //mboxname_hiersep_toexternal(httpd_namespace, orgid, 0);
}
}
@@ -2134,7 +2144,7 @@ static int caldav_put(struct transaction
char ext_userid[MAX_MAILBOX_NAME+1];
strlcpy(ext_userid, userid, sizeof(ext_userid));
- mboxname_hiersep_toexternal(httpd_namespace, ext_userid, 0);
+ //mboxname_hiersep_toexternal(httpd_namespace, ext_userid, 0);
txn-error.precond = CALDAV_UNIQUE_OBJECT;
assert(!buf_len(txn-buf));
@@ -3909,7 +3919,7 @@ static int store_resource(struct transac
Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
Package: dpkg-dev Version: 1.17.23 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Some packages need extra Build-Depends when they are cross compiled. Here are some examples: * src:guile-2.0 needs guile-2.0 to cross-build * src:glib2.0 needs libglib2.0-dev:any to cross-build * src:autogen needs autogen to cross-build * src:flex runs help2man and an easy way to do that is to use the build arch flex * src:bison also runs help2man and can benefit from build arch bison A way to address this need is to use the cross build profile[1]. Now I am wondering whether dpkg-buildpackage should set the cross build profile automatically. The logic for doing so is as simple as: if the host architecture differs from the build architecture, enable that profile. Johannes Schauer pointed out that since there currently is no way to disable automatically enabled profiles, this can hamper debugging. A side effect of this change is that cross built packages would be reliably recognizable by looking at their Built-For-Profiles header. Arguably, adding a new header to record the build architecture would be a better facility. Also apt (and every other tool that installs Build-Depends) would need to set this profile automatically. If dpkg is not the place to add this facility, the place that invokes dpkg-buildpackage needs to enable this profile explicitly. That probably means that sbuild needs to do this. Thoughts? Helmut [1] https://wiki.debian.org/BuildProfileSpec -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773742: ITP: rtcw-sp -- military/occult WWII first-person shooter game - single player version
Hi,
I've tested this too, but I've been more happy with iortcw fork:
it has been ported to SDL2; and development is more active.
https://code.google.com/p/iortcw/
I can help for the game-data-packager script too...
The dialogs in the SP game have been dubbed, so mind there are several
valid different md5sums .
There is a also a runtime checksum in the code;
I guess we could patch this ask upstream to apply it too.
https://code.google.com/p/iortcw/source/browse/trunk/SP/code/qcommon/files.c
static const unsigned int sppak_checksums[] = {
#ifdef BUILD_FRENCH
2183777857u,
#else
2837138611u,
#endif
3033901371u,
483593179u
};
Alexandre Detiste
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774130: cyrus-caldav: [PATCH] dav: Fails when multiple accounts accessing private calendars from same client
Package: cyrus-caldav
Version: 2.4.17+caldav~beta10-13~dfd2
Severity: normal
Tags: patch
Due to strict interpretation/implementation of HTTP Auth RFC having private
calendars
from multiple accounts accessed by the same instance of a client (e.g. Icedove)
fails
with 403 Forbidden for any accounts accessed after the first.
This issue is why Mozilla added the about:config option
calendars.network.multirealm
option (which apparently is also apparently iCal's default behavior).
In short it is required to have HTTP Auth occur for different URI's not just
different
server names because calendars are not differentied by server name but instead
by
URI.
This attached patch is a hack that that re-requests HTTP Auth if the current
http userid
does not match the userid in the calender URI and HTTP header does not have a an
Authorization field.
Description: Fix CalDAV/CardDAV for multiple user's calendars from same client
Workaround for accessing different users' collections on the same server
with same hostname. Without this fix, this fails because HTTP auth is
only done once. This is the same issue that had Mozilla Lightning add
the calendar.network.multream option.
Basically interpretation of RFC's such that HTTP Auth is only done once
hostname:port reqardless of the URI causes CalDAV/CardDAV to fail when
one does not have a unique hostname:port per user and access to multiple
users' calendars is done from the same client, unless one opens up the
ACLS so that the calendars are all accessible from a single user (in
addition to the owner of the calendar)
This workaround forces an authentication request if the userid does not
match the user portion of the calendar/addressbook URI. It does require
that the client know enough to not use the same authorization for the
different calenders (e.g. Mozilla Lightning with multirealm enabled
or, apparently, iCal)
Index: cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
===
--- cyrus-imapd-2.4-2.4.17+caldav~beta10.new.orig/imap/httpd.c
+++ cyrus-imapd-2.4-2.4.17+caldav~beta10.new/imap/httpd.c
@@ -919,6 +919,9 @@ static void cmdloop(void)
const struct namespace_t *namespace;
const struct method_t *meth_t;
struct request_line_t *req_line = txn.req_line;
+char collection_userid[MAX_MAILBOX_BUFFER];
+char *user_loc;
+ int has_authorization = 0;
/* Reset txn state */
txn.meth = METH_UNKNOWN;
@@ -1200,6 +1203,7 @@ static void cmdloop(void)
/* Perform authentication, if necessary */
if ((hdr = spool_getheader(txn.req_hdrs, Authorization))) {
+ has_authorization = 1;
if (httpd_userid) {
/* Reauth - reinitialize */
syslog(LOG_DEBUG, reauth - reinit);
@@ -1244,6 +1248,33 @@ static void cmdloop(void)
}
}
+ /* Workaround for accessing different users' collections on the same
server
+ with same hostname. Without this fix, this fails because HTTP auth
is
+ only done once. This is the same issue that had Mozilla Lightning
add
+ the calendar.network.multream option.
+ Basically interpretation of RFC's such that HTTP Auth is only done
once
+ hostname:port reqardless of the URI causes CalDAV/CardDAV to fail
when
+ one does not have a unique hostname:port per user and access to
multiple
+ users' calendars is done from the same client, unless one opens up
the
+ ACLS so that the calendars are all accessible from a single user (in
+ addition to the owner of the calendar)
+ This workaround forces an authentication request if the userid does
not
+ match the user portion of the calendar/addressbook URI. It does
require
+ that the client know enough to not use the same authorization for
the
+ different calenders (e.g. Mozilla Lightning with multirealm enabled
+ or, apparently, iCal)
+*/
+ if (!has_authorization httpd_userid) {
+ user_loc = strstr(txn.req_uri-path, /user/);
+ if (user_loc != NULL) {
+ user_loc += 6;
+ strlcpy(collection_userid, user_loc, strcspn(user_loc, /));
+ if (strcmp(collection_userid, httpd_userid)) {
+ *httpd_userid = 0;
+ }
+ }
+ }
+
/* Request authentication, if necessary */
switch (txn.meth) {
case METH_GET:
-- System Information:
Debian Release: 8.0
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/5 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cyrus-caldav depends on:
ii
Bug#774131: Missing kernel modules (mini.iso / Jessie / amd64)
Package: Installer (mini.iso) Version: 02-Oct-2014 09:01 (Jessie) Severity: important When I try to install a Debian testing version using http://ftp.ch.debian.org/debian/dists/testing/main/installer-amd64/current/images/netboot/mini.iso I always get an error message about missing kernel modules as shown at http://beilagen.dreael.ch/Diverses/Details_Debian_8_Jessie_29141229/Jessie_mini_iso_Fehler_Kernelversion.png When I try to continue without kernel modules then the setup process cannot continued on the installation target selection: http://beilagen.dreael.ch/Diverses/Details_Debian_8_Jessie_29141229/Jessie_mini_iso_Folgefehler_keine_HD.png This error still appears when using a primary mirror as installation source. I believe there was done a kernel version change in the meantime without updating mini.iso accordingly so simply recompose mini.iso would fix this issue. Note: uname -a reports 3.16-2-amd64 as kernel version. Andreas -- meile.biz IT solutions, Hauptstrasse 63, CH-8242 Hofen SH PC/Netzwerk-Support, Web-Entwicklung und -Hosting Tel. +41 52 640 04 72 * Fax +41 52 640 04 73 * Mobile +41 79 334 05 67 Postfach 169, CH-8240 Thayngen * i...@meile.biz * http://www.meile.biz smime.p7s Description: S/MIME cryptographic signature
Bug#772016: sqlitebrowser: When i install sqlitebrowser from apt-get i get the error: segmentation fault
Control: tags +moreinfo +unreproducible There isn't enough information in this report for me to even verify the existence of a bug. Please repond to the questions included in the reportbug template: * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? You could additionally include the full commands that you ran, and their output. Also based on the kernel version you are running (Kernel: Linux 3.17-4.towo-siduction-amd64 (SMP w/2 CPU cores; PREEMPT)) it's possible you aren't running Debian, but siduction instead. Is that the case, or is the kernel the only changed component? In the later case, can you retry with the standard Debian kernel? -- Arto Jantunen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774132: ITP: ruby-rails-assets-jquery -- provide jquery via asset pipeline for rails apps
Package: wnpp Severity: wishlist Owner: Pirate Praveen prav...@debian.org * Package name: ruby-rails-assets-jquery Version : 0.2.3 Upstream Author : jQuery Foundation, Inc * URL : http://rails-assets.org * License : Expat Programming Lang: ruby Description : provide jquery via asset pipeline for rails apps signature.asc Description: OpenPGP digital signature
Bug#773766: systemd: Real problem is lack of information when service fails
On 26/12/14 08:48 PM, Michael Biebl wrote: Am 26.12.2014 um 06:11 schrieb Daniel Dickinson: On 25/12/14 01:27 PM, Michael Biebl wrote: Messages appeared in journal (journalctl) however there was no output in syslog. I have noticed that *none* of the boxes / vms I have upgraded from wheezy to jessie output the journal to syslog. I suppose this may be a systemd upgrade bug. Which syslogger do you have installed, rsyslog, syslog-ng? rsyslog with config that had been edited but reverted to defaults (however probably detected as changed and therefore new defaults not installed). What is the output of systemctl status syslog.socket syslog.service Er, sorry, no longer have the non-working configs. Reverted rsyslog configs completely to defaults using dpkg -i --force-confnew and it all works now. Regards, Daniel smime.p7s Description: S/MIME Cryptographic Signature
Bug#774100: [debhelper-devel] Bug#774100: debhelper: please ensure a stable order in shlibs files
Control: tags -1 confirmed stretch sid On 2014-12-28 18:54, Jérémy Bobbio wrote: Package: debhelper Version: 9.20141222 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain fileordering Hi! While working on the “reproducible builds” effort [1], we have noticed that some packages failed to build reproducibly because the order of libraries listed in shlibs varies depending on the order of files on the filesystem. The attached patch modifies dh_makeshlibs to sort the files, resulting in a stable order in shlibs files. This allows more packages to build reproducibly. [1]: https://wiki.debian.org/ReproducibleBuilds [...] Hi Jérémy, Thanks for the patch. :) We will apply this for stretch. Would it be helpful to you if we uploaded this sooner to experimental? Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774102: [debhelper-devel] Bug#774102: debhelper: please ensure a stable order of icons list
Control: tags -1 confirmed stretch sid On 2014-12-28 18:58, Jérémy Bobbio wrote: Package: debhelper Version: 9.20141222 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: toolchain fileordering Hi! While working on the “reproducible builds” effort [1], we have noticed that some packages failed to build reproducibly because the order of icons listed in dh_icons output varies depending on the order of files on the filesystem. The attached patch modifies dh_icons to sort the icon list, resulting in a stable order in postinst and postrm files. This allows more packages to build reproducibly. [1]: https://wiki.debian.org/ReproducibleBuilds [...] Hi Jérémy, Thanks for the patch. We will apply this for stretch. Would it be helpful to you if we uploaded this sooner to experimental? Thanks, ~Niels -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774133: debian-maintainers: Trouble replacing short key for Thomas Friedrichsmeier
Package: debian-maintainers Severity: normal Apologies if this is not the right place to bring this request. But my current key (as a DM) is about to be removed from the keyring for being too short (1024 bits), and I am having trouble meeting the formal requirements for my replacement key. The two reasons for this ticket, then are: - Hoping to get some help with the problem itself. - Publicly recording my intent to replace the old key, while that is still considered valid. Below is a copy of the request I sent to keyr...@rt.debian.org, with additional detail. Unfortunately (but understandably) it was turned down. Thanks for your attention. Thomas Friedrichsmeier --- Hi! Following your prompt to replace my old key (1024 bits) with a longer key, I am submitting this request to replace my old key id 90D53618 old fingerprint 0D86 778C 9DDF C460 0BBB DB17 10A4 6FFB 90D5 3618 with new key id 1858CBB6 new fingerprint 6F2D C0C0 830C EA38 90FF 22CF 3915 91DF 1858 CBB6 new key attached, below. You will note that I did not manage to get my new key signed by any DDs (let alone two DDs). Neither does it carry too many non-DD signatures, thus far. Here, I'll give some reasons for this shortcoming, and some additional evidence for the validity of the new key, hoping this will be enough to accept it: Key reasons for lack of signatures: - I am not networked with active Debian Developers in my real life. Marcus Brinkmann, who signed my old key, is no longer active in Debian, and has retired his keys. - Similarly many of my real life contacts seem to have abandoned GPG for the most part. - Being a father of small kids, my opportunities for meeting other developers or DDs face-to-face are strictly limited. - I am merely a Debian Maintainer. My upload rights (and my current ambitions in the project) concern exactly one (leaf-) package rkward. I'll admit I have invested only an estimated six hours into generating and getting signatures on my new key. Considering the scope of the associated rights, and the fact that there is no strong reason _today_ to consider my old key compromised, this still felt like a considerable effort to me. Further evidence supporting the validity of my new key: - I am the lead developer of the upstream package in question. - You will find my new key in use on the primary development mailing list, here: http://www.mail-archive.com/rkward-devel@lists.sourceforge.net/ (check any recent mail from Thomas Friedrichsmeier) - The key is also listed at https://rkward.kde.org/User:Tfry , and https://launchpad.net/~tfry . - Thus, while there may be no convincing evidence, that I really am a natural person named Thomas Friedrichsmeier, I am obviously the same entity, who is in control of central parts of the rkward upstream infrastructure. The additional risk of allowing me to package rkward for debian should be limited. Thanks for your attention, awaiting your verdict Thomas Friedrichsmeier - - New key: - -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1 mQINBFQdxcIBEADbSWvTWHOvFnaNlKYo0UUvVAgSiKbWcP5BH9DjpWbpBWnVewmF 2T24kdkp4YSj80hoBX8NsBpv20fW6qwZ1TpDqPOJzkoAi7j1m6hadFNhyrooGuQq PwicUqOfhQ8nX48g6FhbT+DREjvGmowHBr9oGJx/6gbysuCcyjMgPL+JvfTDG7vU E5jCFDHtLcGq/3moSMr10+3n1kALNtD/Dn+/0iG3MUHci/dG3JlNUne8EaMf17Uf juePB07kUFdNrQN7VNsdYvxjLK75LJlIG15CnaW6iGG6xKgkGDoxFjKSxsSnbykN w0BJipugwlGN3SI5q51v/B1jy9ZpOVN/OjYTIL1JDBWgM/qSAB0W4k8SHfycxGPX Q/5Ptzf6MqlusyQrraeXbaWKsrojf0NSbgkyKuWEDKH67I9y8pViNImPUATvPlTZ qJcTM0iv/4p6ScyKeQwsr2YKlDogpDrgzBXeQt5evFoVf8F7ghLest20+3OBJaXX 8zCB+vfqg44tESF+J41/AmqBkK7VAg83vG0a8wf4J9p7vViMJBjkKS7qfXC6kpI2 JwTY7EAAIeAN1BNvJPDpegSbtHdSJOqs2YzFqN9L0isoaJtuQcL+MzGEPZKkKpRu rl0fi0AccrSn1oBCyFTIxtXqhozcXiF8fe/RZNKfqCujP86/+SPqte15JQARAQAB tEJUaG9tYXMgRnJpZWRyaWNoc21laWVyIDx0aG9tYXMuZnJpZWRyaWNoc21laWVy QHJ1aHItdW5pLWJvY2h1bS5kZT6JAjoEEwEIACQCGwMFCwkIBwMFFQoJCAsFFgID AQACHgECF4AFAlQdyPYCGQEACgkQORWR3xhYy7ZGUxAAsAmCU8joHcQ+zRQu9u6p HAG3JUGRlosHpN6oWR1ZVWOuxiuyTbTWVseERTfBAH0R21Tdx4ywTdX9M5HJnoni vmLNlKZJDkSUCvhMv+X06luJmY5ZxTdtQMCY+HDgs7VKDbAYW2AySIyDcRsQlim3 CQXhVDbmKFzO05qG9I+M8RvN2scOHRvu1ax5QkgjSvKjsCDSIgAc/zEb+5/m5SyA QpYXavWeasNy/ouNh/nFQmj4gxRpbFRzsverdv2aR8UrpjFLw+7kWh8gCoBx8gvJ cH6ItJI6jD6AydJjppQyB/eLPsTDBa5eHGQ1KFp4kvzSpSRU3c5Q05H5HPw5bJkq w2MtKq37Wk0z0gAfU0UZUzyEELklxGVy2NXqyuUxnl8sUb+h8m7m8XiFnamR4f+I 4WfrYqvl1E8/4glaEdc/E1EAJyNHTDGgbfstnBBS4AqLkh7RgtugZ+31sTsZ8W5i XKqLJrokTcC/gsDOmpSEpGKDn0BA7Xrx76pJwRKCiDvUVQ8sOfGr9HqhbJFN8+xn lZsTeMBB3gN9978pImGmNytoYqI2d2Lmgz4WD0nwfsqOey3rLm7qZ5SQspizprJ+ 049L3SlHqF2+sPaPOBE49KFqNAvTcEc862nV+S7ub1YwqKu8WxyKX8LUQPeIvkxz J0MLty1LnqYAT7Pt5E3ZMUiIRgQQEQgABgUCVB3JNAAKCRAQpG/7kNU2GJUqAKC5 RJ6JDIQfvZ4416WdF6QUU0qv7gCaAmzlpkVyzsM07AOlyL/bU+pB95eJAhwEEAEC AAYFAlQpt48ACgkQ+DFcy3vauo5w7hAAgZIjBgb5s/4RzunDY49bAqds3MFOpDtt J6kjwvxnCBG00hoO1YnvlbDIseXQOgiNOCqpX9Idh7mFfe3iglz7IyQT9/uDn5+k 0kM+gUeC2oDbEA09L/IXg0cmSJEKI7IKnzwJuWWcKQX8oBGttVdxykksEbZ9ZBd/
Bug#747141: [debhelper-devel] Bug#747141: Bug#747141: dh_installdocs --link-doc forces source-version dependencies (Was: Re: Bug#747141: closed by Niels Thykier ni...@thykier.net (Bug#747141: fixed
On 2014-12-22 20:28, Stephen Kitt wrote:
Hi Niels,
On Mon, 22 Dec 2014 08:25:03 +0100, Niels Thykier ni...@thykier.net wrote:
[...]
Okay, I guess I realise what happens now that breaks your case. We use
dpkg-parsechangelog -l. During a binNMU this returns the binNMU
version (i.e. source version plus +bX), but I guess you set your own
binary version? The best I can give you is the eqv. of a pkg (=
${binary:Version}).
This minor modification (from our PoV) should not change the output in
the general case, and /may/ fix your case.
It should indeed, and it seems better to me generally speaking, since the
dependency should be on the binary version anyway. There are other packages
in the archive which produce binary packages with versions other than the
source version!
Ok, will do for Stretch.
However, if that does not work, then I am afraid your self-chosen
version scheme cannot be handled automatically by debhelper and you
would have to do the link-doc manually. AFAICT for this to work, you
*must* use identical versions for the binary packages that are affected
by the --link-doc parameter.
In that case (and perhaps in general), what would be nice would be to have
dh_installdocs allow the version to be specified; currently I run
dh_installdocs then sed the substvars to remove the dependency
added by dh_installdocs.
Possibly, but I am not convinced. The goal for debhelper is to make
common tasks easier and not to support every possible way of doing things.
Regarding the arch: any to arch: all and vice-versa cases you fixed, what
about transitional and/or metapackages? Given that they are empty, I
don't see anything in Policy or in practice which would prevent arch: all
metapackages depending on arch: any binary packages without a strict
versioned dependency to provide their changelog and copyright...
You cannot have a correct match between an arch:all and an arch:any
package during a binNMU (or at least, not until debhelper started
extracting the binNMU changelog parts into a separate file). But then
you can only safely do it with an arch:all linking to an arch:any.
However, with the interface debhelper provided, this never worked,
because we would generate a pkg (= ${bVersion}) and after a binNMU the
arch:all version would still depend on the old ${bVersion} (since it
is not rebuilt).
Instead of succeeding such a build and allow broken packages
(uninstallable) packages to reach the archive, we now error out[1].
This is especially helpful, since a lot of people seem to get these work.
Yup, I understand the reasoning behind the change. (I'm guessing
s/work/wrong/ in that last sentence!)
Silly typo on my part indeed.
(gcc-mingw-w64 does this in a binNMU-friendly way.)
Except, you are (at least, in theory) doing it very very wrong! Your
metadata package does not force the exact version between itself and the
link-doc target packages. This allows the versions to go out of sync
and we could (in theory) end up in a situation where the copyright file
do not accurately reflect the copyright/license statements of the
metapackage[2].
Admittedly, for an empty metapackage, this example is a bit
contrived (as the non-content is hardly copyrightable). However,
people might cargo-cult your setup into another package breaking theirs
(from a legal PoV).
It's the empty part I'm relying on ;-). That's why I was asking only about
transitional and metapackages.
I would strongly recommend getting this particular use-case (arch:all
metapackage - arch:any non-metapackage) officially sanctioned before
using it. Primarily to say it is in fact a valid use and secondarily to
highlight the cases, where it *is* valid (which is definitely far from
all cases).
That makes sense, I'll do that...
Even then, I doubt this is a scenario that debhelper will support out
of the box. As mentioned, a fair share of debhelper users have gotten
this wrong, so I will go with the safe-rather-than-sorry approach here.
Yes, that seems perfectly sensible. As long as debhelper doesn't actively
prevent it I won't complain!
Regards,
Stephen
[...]
I doubt we will actively prevent it from happening, but you will have to
implement link-doc manually for unsupported cases.
Thanks,
~Niels
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774057: support for arm64 / aarch64
A user submitted the attached patch for partial support for arm64 on Debian/Ubuntu. It only enables cgc, 3m still hangs during compilation. If the patch makes sense to you, perhaps you'd like to apply it upstream. d From 7b5acfba9a1df00f0427d1d2e1a92570da3ab2d1 Mon Sep 17 00:00:00 2001 From: Yvan Roux yvan.r...@linaro.org Date: Wed, 23 Jan 2013 23:15:57 +0400 Subject: [PATCH] Add AArch64 (64-bit ARM) target support * include/private/gcconfig.h (AARCH64): New macro (defined only if __aarch64__). * include/private/gcconfig.h (mach_type_known): Update comment adding ARM AArch64 target. * include/private/gcconfig.h (NOSYS, mach_type_known, CPP_WORDSZ, MACH_TYPE, ALIGNMENT, HBLKSIZE, OS_TYPE, LINUX_STACKBOTTOM, DYNAMIC_LOADING, DATASTART, DATAEND, STACKBOTTOM): Define for AArch64. --- include/private/gcconfig.h | 37 + 1 file changed, 37 insertions(+) --- a/src/racket/gc/include/private/gcconfig.h +++ b/src/racket/gc/include/private/gcconfig.h @@ -76,6 +76,13 @@ # endif /* Determine the machine type: */ +# if defined(__aarch64__) +#define AARCH64 +#if !defined(LINUX) +# define NOSYS +# define mach_type_known +#endif +# endif # if defined(__arm__) || defined(__thumb__) #define ARM32 #if !defined(LINUX) !defined(NETBSD) !defined(OPENBSD) @@ -249,6 +256,10 @@ #define IA64 #define mach_type_known # endif +# if defined(LINUX) defined(__aarch64__) +#define AARCH64 +#define mach_type_known +# endif # if defined(LINUX) defined(__arm__) #define ARM32 #define mach_type_known @@ -529,6 +540,7 @@ /* running Amdahl UTS4 */ /* S390 == 390-like machine */ /* running LINUX */ + /* AARCH64== ARM AArch64 */ /* ARM32 == Intel StrongARM */ /* IA64 == Intel IPF */ /* (e.g. Itanium) */ @@ -1818,6 +1830,31 @@ # endif # endif +# ifdef AARCH64 +# define CPP_WORDSZ 64 +# define MACH_TYPE AARCH64 +# define ALIGNMENT 8 +# ifndef HBLKSIZE +# define HBLKSIZE 4096 +# endif +# ifdef LINUX +# define OS_TYPE LINUX +# define LINUX_STACKBOTTOM +# define DYNAMIC_LOADING + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern char _end[]; +# define DATAEND ((ptr_t)(_end)) +# endif +# ifdef NOSYS + /* __data_start is usually defined in the target linker script. */ + extern int __data_start[]; +# define DATASTART ((ptr_t)__data_start) + extern void *__stack_base__; +# define STACKBOTTOM ((ptr_t)__stack_base__) +# endif +# endif + # ifdef ARM32 # define CPP_WORDSZ 32 # define MACH_TYPE ARM32
Bug#774134: pre-approval: unblock: wader/0.5.12-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock unblock wader/0.5.12-1.1 Hi release team Please consider the attached debdiff to fix a FTBFS in wader (bug #768756). Wader was removed from Jessie on 2014-12-08, however I only became aware of the problem after bug #774098 was filed. I am not the maintainer of wader, so I seek pre-approval before I start the NMU process. Regards Graham wader-nmu.debdiff Description: Binary data
Bug#773992: RFS: xmlrpc-c/1.33.15+svn20141223~2672-1 [ITA]
Control: owner -1 ! Hi Jörg, On 26-12-14 20:48, Jörg Frings-Fürst wrote: I am looking for a sponsor for my package xmlrpc-c I am willing to help, review below is incomplete yet though (just scanned the changes once). Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/x/xmlrpc-c/xmlrpc-c_1.33.15+svn20141223~2672-1.dsc I use the git repository. I assume it is the same. Ironically, upstream just (15 hours ago) seems to have released 1.33.15 as tar ball. * New debian/patches/200-test_port.diff: - Change port for testing from 8080 to 7890 (Closes: #722503). I am missing some background, either in the bug or in the patch file. Why do you think hard coding 7890 is any better than 8080? And why do you consider this Forwarded: not-needed? Michael suggested to try multiple ports instead of relying on one port and I think upstream should be interested in such a patch. * New debian/patches/005-xmlrpc_example.diff: - Backport from upstream release 1.34.0 (Closes: #524550). If you still want me to upload your current package, could you add a source URL to the DEP5 header? The bts seems to say it should be here: http://sourceforge.net/p/xmlrpc-c/code/2491 but with that commit I don't see any content there. At least mention the proper revision in the headers. Also, the patch seems to fix more than just the bug in the bts. Please document what it is supposed to fix. * New missing debian/xmlrpc-c-config.man and debian/xmlrpc.man. You created these files with help2man. I prefer it when you do this at build time, so that the man page stays up-to-date. I think you can tweak the settings of help2man to not add the date and your name. Other (random) remarks: Please target experimental during the freeze, unless you are fixing something that needs to go into jessie. Just wondering (haven't check yet), but you only add symbols files for amd64 and i386. Is this working correctly with the other archs? Or are they going to be more strict as a result? Please separate your commits to git to ease review and understanding. I don't understand why you created a new upstream release. As far as I see it the only change is the version number and the distclean target in the Makefile. No further changes in the files that you decided to keep around. Paul signature.asc Description: OpenPGP digital signature
Bug#774135: mc: segfault for SFTP VFS
Package: mc Version: 3:4.8.13-3 Severity: important I just was trying to use SFTP by entering “cd /sftp://user@host” into the mc command line. I got a red pop-up window saying: Error 11: sftp: an error occurred while reading ~/.ssh/config: Resource temporarily unavailable Then I acknowledged it and mc segfaulted. The core dump is not helpful due to lack of debug symbols, of course. -- System Information: Debian Release: 8.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'buildd-unstable'), (500, 'unstable') Architecture: x32 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) Versions of packages mc depends on: ii e2fslibs 1.42.12-1 ii libc6 2.19-13 ii libglib2.0-0 2.42.1-1 ii libgpm2 1.20.4-6.1+b2 ii libslang2 2.3.0-2 ii libssh2-1 1.4.3-4 ii mc-data 3:4.8.13-3 Versions of packages mc recommends: ii mime-support 3.57 ii perl 5.20.1-4 ii unzip 6.0-13 Versions of packages mc suggests: ii arj 3.10.22-12 ii bzip21.0.6-7+b2 pn dbview none pn djvulibre-binnone ii file 1:5.21+15-1 pn genisoimage none pn gv none ii imagemagick 8:6.8.9.9-4 pn links | w3m | lynx none ii mupdf [pdf-viewer] 1.6-1 pn odt2txt none ii okular [pdf-viewer] 4:4.14.2-2 ii poppler-utils0.26.5-2 ii python 2.7.8-2 pn python-boto none ii python-tz2012c+dfsg-0.1 ii texlive-binaries 2014.20140926.35254-4 ii zip 3.0-8 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774136: gcompris: Can you package Gcompris 14.12 mostly translation updates
Package: gcompris Version: 14.07-2 Severity: wishlist Dear Maintainer, I know we are in a freeze but can gcompris be upgraded/uploaded to 14.12 ? These are the fixes and translation updates as shared below :- Fixed Hangman to fit keyboards with many letters. (by Fòram na Gàidhlig) - Add of a set of Kannada word dataset file (by Shambu K) - Wordsgame: minor fixes for french wordlist (by Holger Kaelberer) - tuxpaint, added support for the new --fullscreen option (by Pere Pujal i Carabantes) - core, added kannada in the language selector (by Bruno Coudoin) - erase, made the square less transparent (by Bruno Coudoin) - scale, added missing translation (by Bruno Coudoin) - Updated kannada translation (by Shankar Prasad) - Updated Czech translation (by Marek Černocký) - Updated Brazilian Portuguese translation (by Enrico Nicoletto) - Updated Greek translation (by Yannis Kaskamanidis) - Updated Scottish Gaelic translation (by GNOME Translation Robot) - Updated Brazilian Portuguese translation (by Enrico Nicoletto) - Updated Swedish translation (by Anders Jonsson) - Updated Russian translation: (by Yuri Myasoedov) - Updated Czech translation (by Marek Černocký) - Updated Greek translation (by Yannis Kaskamanidis) - Finnish translation update (by Lasse Liehu) - Update Catalan translation (by Pau Iranzo) - Updated kannada translation (by Shambu K) - Updated Dutch translation gcompris Master (by Hannie Dumoleyn) - Updated Czech translation (by Marek Černocký) This was the changelog shared by Bruno Coudin on 23rd December 2014. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (600, 'testing'), (500, 'testing-updates'), (1, 'experimental'), (1, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gcompris depends on: ii gcompris-data 14.07-2 ii gstreamer0.10-alsa [gstreamer0.10-audiosink] 0.10.36-2 ii gstreamer0.10-plugins-bad [gstreamer0.10-audiosink] 0.10.23-7.4 ii gstreamer0.10-plugins-base0.10.36-2 ii gstreamer0.10-plugins-good [gstreamer0.10-audiosink] 0.10.31-3+nmu4+b1 ii gstreamer0.10-pulseaudio [gstreamer0.10-audiosink]0.10.31-3+nmu4+b1 ii libatk1.0-0 2.14.0-1 ii libc6 2.19-13 ii libcairo2 1.14.0-2.1 ii libfontconfig12.11.0-6.3 ii libfreetype6 2.5.2-2 ii libgdk-pixbuf2.0-02.31.1-2+b1 ii libglib2.0-0 2.42.1-1 ii libgstreamer0.10-00.10.36-1.5 ii libgtk2.0-0 2.24.25-1 ii libpango-1.0-01.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-0 1.36.8-3 ii libpython2.7 2.7.8-11 ii librsvg2-22.40.5-1 ii librsvg2-common 2.40.5-1 ii libsqlite3-0 3.8.7.1-1 ii libx11-6 2:1.6.2-3 ii libxml2 2.9.1+dfsg1-4 ii python-cairo 1.8.8-1+b2 ii python-gtk2 2.24.0-4 ii python-pysqlite2 2.6.3-3 gcompris recommends no packages. Versions of packages gcompris suggests: ii gnucap1:0.36~20091207-2 ii tuxpaint 1:0.9.22-1 -- no debconf information -- Regards, Shirish Agarwal शिरीष अग्रवाल My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com EB80 462B 08E1 A0DE A73A 2C2F 9F3D C7A4 E1C4 D2D8 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774137: tor: Tor fails to manage obfsproxy
Package: tor Version: 0.2.6.1-alpha-1 Severity: normal (Note: I tried the version of Tor in testing first.) Here is the config line from my torrc: ClientTransportPlugin obfs3 exec /usr/bin/obfsproxy --log-min-severity info --log-file /tmp/obfsproxy.log managed And here is what I get in /var/log/tor/log on every restart: The communication stream of managed proxy '/usr/bin/obfsproxy' is 'closed'. Most probably the managed proxy stopped running. etc Then I added the logging bits in the ClientTransportPlugin line above. But, no /tmp/obfsproxy.log file is created. However, if I run /usr/bin/obfsproxy --log-min-severity info --log-file /tmp/obfsproxy.log managed straight from the command line, a /tmp/obfsproxy.log is created. From this I infer that Tor is never getting to the point of starting obfsproxy. Perhaps there is an issue with the Debian environment? -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (800, 'testing'), (700, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-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) Versions of packages tor depends on: ii adduser 3.113+nmu3 ii libc6 2.19-13 ii libevent-2.0-5 2.0.21-stable-1.1 ii libseccomp2 2.1.1-1 ii libssl1.0.0 1.0.1j-1 ii lsb-base4.1+Debian13+nmu1 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages tor recommends: ii logrotate3.8.7-1+b1 ii tor-geoipdb 0.2.5.10-1 ii torsocks 2.0.0-3 Versions of packages tor suggests: pn apparmor-utils none pn mixmaster none ii obfsproxy 0.2.12-1 ii privoxy3.0.21-4 pn socat none pn tor-armnone pn xul-ext-torbutton none -- Configuration Files: /etc/tor/torrc changed [not included] -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 - 19})
Package: grub-efi-amd64 Version: 2.02~beta2-19 Severity: important Dear Maintainer, * What led up to the situation? Usual daily upgrade. Including grub-efi-amd64: 2.02~beta2-18 - 2.02~beta2-19~i * What exactly did you do (or not do) that was effective (or ineffective)? The effect of the upgrade is a freeze of the entire computer after a few tens of seconds when the aforementionned package is configured, the process hangs while it's saying Installing for x86_64-efi platform. several kernel oops'es appeared in the logs (see below), after 20-30 seconds the system hanged: the mouse is unresponsive, I cannot change the tty, caps lock cannot be toggled, processes seem still running (continue to hear music) and sysreq keys are working, I can safely sync and reboot. At this point, when I reboot the package is still not configured, thus I can reproduce the bug indefinitely by running: sudo dpkg --configure -a If I interrupt the configuration with ^C before any kernel oops appeared, my computer doesn't crash, but the package remain unconfigured. I could downgrade to beta2-18 without any problem and everything is working as beforehand. I re-upgraded and can still confirm the issue remains. ** The output of dpkg --configure: sudo dpkg --configure -a Setting up grub-efi-amd64 (2.02~beta2-19) ... Installing for x86_64-efi platform. ^ last message before freeze ** The content of kern.log during the upgrade (after the Installing message): Dec 29 10:56:51 nyx kernel: [ 677.520408] general protection fault: [#1] SMP Dec 29 10:56:51 nyx kernel: [ 677.520425] Modules linked in: btrfs xor raid6_pq ufs qnx4 hfsplus hfs minix ntfs msdos jfs xfs libcrc32c rpcsec_gss_krb5 nfsv4 dns_resolver cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_stats nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc tun it87 hwmon_vid nls_utf8 nls_cp437 vfat fat loop fuse parport_pc ppdev lp parport snd_hda_codec_realtek snd_hda_codec_hdmi snd_hda_codec_generic x86_pkg_temp_thermal intel_powerclamp intel_rapl arc4 coretemp kvm_intel kvm crc32_pclmul ghash_clmulni_intel iwldvm aesni_intel aes_x86_64 mac80211 lrw iTCO_wdt snd_hda_intel radeon i915 gf128mul evdev iTCO_vendor_support glue_helper efi_pstore iwlwifi ttm ablk_helper snd_hda_controller drm_kms_helper cryptd snd_hda_codec cfg80211 psmouse pcspkr snd_hwdep drm serio_raw efivars i2c_i801 rfkill mei_me lpc_ich i2c_algo_bit snd_pcm mfd_core mei i2c_core snd_timer snd tpm_infineon tpm_tis soundcore tpm shpchp processor video button battery ext4 crc16 mbcache jbd2 hid_generic usbhid hid dm_mod sg sd_mod crc_t10dif crct10dif_generic ahci libahci crct10dif_pclmul crct10dif_common libata crc32c_intel ehci_pci xhci_hcd ehci_hcd scsi_mod alx mdio e1000e usbcore ptp thermal fan pps_core usb_common thermal_sys Dec 29 10:56:51 nyx kernel: [ 677.520768] CPU: 7 PID: 13729 Comm: efibootmgr Not tainted 3.16.0-4-amd64 #1 Debian 3.16.7-ckt2-1 Dec 29 10:56:51 nyx kernel: [ 677.520785] Hardware name: Gigabyte Technology Co., Ltd. Z87N-WIFI/Z87N-WIFI, BIOS F4 08/03/2013 Dec 29 10:56:51 nyx kernel: [ 677.520802] task: 88043cc43530 ti: 8800a7cd4000 task.ti: 8800a7cd4000 Dec 29 10:56:51 nyx kernel: [ 677.520817] RIP: 0010:[8105fafc] [8105fafc] efi_call+0x7c/0x100 Dec 29 10:56:51 nyx kernel: [ 677.520835] RSP: 0018:8800a7cd7d70 EFLAGS: 00010002 Dec 29 10:56:51 nyx kernel: [ 677.520845] RAX: 88043b9d6000 RBX: 88043b9d6000 RCX: 88043b9d6000 Dec 29 10:56:51 nyx kernel: [ 677.520859] RDX: 88043b9d6400 RSI: 88043b9d6000 RDI: 0f6a210041005400 Dec 29 10:56:51 nyx kernel: [ 677.520873] RBP: 88043b9d6400 R08: 88043b9d6820 R09: 88043b9d6410 Dec 29 10:56:51 nyx kernel: [ 677.520886] R10: 1000 R11: 0246 R12: 88043b9d6820 Dec 29 10:56:51 nyx kernel: [ 677.520900] R13: 88043b9d6410 R14: 88043b9d6418 R15: 0009a000 Dec 29 10:56:51 nyx kernel: [ 677.520913] FS: 7f74ed9b8700() GS:88044f3c() knlGS: Dec 29 10:56:51 nyx kernel: [ 677.520929] CS: 0010 DS: ES: CR0: 80050033 Dec 29 10:56:51 nyx kernel: [ 677.520939] CR2: 7f74ece4b110 CR3: 0009a000 CR4: 001407e0 Dec 29 10:56:51 nyx kernel: [ 677.520953] Stack: Dec 29 10:56:51 nyx kernel: [ 677.520958] 8803 01ff8800a7cd7f3c 880433223b48 88044e418198 Dec 29 10:56:51 nyx kernel: [ 677.520974] 88043b9d6418 88043b9d6000 8800a7cd7e18 80050033 Dec 29 10:56:51 nyx kernel: [ 677.520991] Dec 29 10:56:51 nyx kernel: [ 677.521008] Call Trace: Dec 29 10:56:51 nyx kernel: [ 677.521015] [8105f12b] ?
Bug#774139: ITP: ruby-rails-assets-jquery-colorbox -- provide jquery-colorbox via asset pipeline for rails apps
Package: wnpp Severity: wishlist Owner: Pirate Praveen prav...@debian.org * Package name: ruby-rails-assets-jquery-colorbox Version : 0.2.3 Upstream Author : Jack L Moore * URL : http://www.jacklmoore.com/colorbox/ * License : Expat Programming Lang: ruby Description : provide jquery-colorbox via asset pipeline for rails apps signature.asc Description: OpenPGP digital signature
Bug#739486: game-data-packager: Please add support for Tyrian data using following patch.
On 29/12/14 07:19, Alexandre Detiste wrote: my patch still applies automatically. Thanks, I'll merge it. Here is a review; I'll probably fix some of this myself. You're mixing hard tabs (U+0009) and 4-space units for indentation. Please be consistent within each file, and consider configuring your editor to display hard tabs. + if [ $CHECKSUM != $ZIPSUM ]; then + echo warning: checksum is not what we expected 2 + fi Is there any reason why you would want to continue with incorrect data, or more than one version of tyrian21.zip floating around? I would prefer this to be a fatal error. Does Tyrian have a non-shareware version? If it does, I would prefer to treat it like Quake 1 and produce tyrian-registered-data (or tyrian-full-data or just tyrian-data) for the full game, or tyrian-shareware-data or something for the shareware version. +for file in $files; do +slipstream_file $file usr/share/games/tyrian/$file +done This will do all the work of repacking the .deb once for each of the 50ish files you're adding to it. It would be better to unpack it once (or, perhaps preferably, just ship the necessary files unpacked like quake2 does), then copy in all the files, then finally pack it up. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774140: libisofs: typo: explicite - explicit
Source: libisofs Version: 1.3.2-1.1 Severity: minor $ grep -rwoE 'Explicite [^.]+' libisofs-1.3.2 libisofs-1.3.2/Makefile.am:Explicite dynamic library configuration failed libisofs-1.3.2/Makefile.in:Explicite dynamic library configuration failed libisofs-1.3.2/Makefile:Explicite dynamic library configuration failed It should be s/Explicite/Explicit/g. -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739486: game-data-packager: Please add support for Tyrian data using following patch.
On 29/12/14 10:34, Simon McVittie wrote: +for file in $files; do +slipstream_file $file usr/share/games/tyrian/$file +done This will do all the work of repacking the .deb once for each of the 50ish files you're adding to it. Please ignore this bit, I was thinking of multiple invocations of 'slipstream'. What you're doing here is fine. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774141: kdevelop-python should be renamed kdevelop-python3
Package: kdevelop-python Version: 1.7.0-1 https://packages.debian.org/sid/kdevelop-python gives the description of this package as Python 3 plugin for KDevelop. Normally IIUC python3 related packages are marked as python3 and not just as python. I submit that it would be advisable to rename the package as kdevelop-python3 and instead package the Python 2 plugin as kdevelop-python. (Should I report a separate bug asking for Py 2 plugin?) Downstream Kubuntu has already independently packaged the Python 2 plugin as kdev-python since last two releases (http://packages.ubuntu.com/search?keywords=kdev-pythonsearchon=names), and is also now inheriting the kdevelop-python package from Debian (http://packages.ubuntu.com/source/vivid/kdevelop-python) which leads to an infelicitous naming situation there i.e. kdev-python for Py 2 vs kdevelop-python for Py 3. While I am going to report a separate bug downstream to align with Debian on the naming issue, I believe Debian should also rename the kdevelop-python package to kdevelop-python3 to make way for kdevelop-python for a Py 2 package. Thanks. -- Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774127: game-data-packager: changelog.gz is installed twice
On 29/12/14 08:41, Alexandre Detiste wrote: -rw-r--r-- 1 root root 5068 déc 29 08:15 /usr/share/doc/game-data- packager/changelog.gz This exists because Debian policy says it must. -rw-r--r-- 1 root root 5078 déc 29 08:30 /usr/share/games/game-data- packager/changelog.gz This exists so we can include it in quake2-*.deb. (It is also duplicated in each of /usr/share/games/game-data-packager/*.deb, but you can't immediately see that without unpacking them.) We can't use /usr/share/doc/game-data-packager/changelog.gz for this purpose because Policy says packages must continue to work if you delete some or all of /usr/share/doc. If all the template .deb files were stored in unpacked form, like the quake2 ones already are, then they could all share one copy of changelog.gz. That's what I plan to do for all subsequent games that I add, and I'll probably migrate existing games (or at least those for which I have a copy) to that structure over time. maybe a symlink would do. Maybe, but I don't think Policy allows /usr/share/doc/PACKAGE/changelog.gz to be a symlink? S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774038: xbmc: When going fullscreen watching through xbmc-pvr-tvheadend-hts makes video stays black
Hello Bálint, I was successful in creating a package for kodi from you git and some ffmpeg packages from unstable, and then building and using axbmc-pvr-addons zip from it. The issue I described I could not reproduce with kodi-14. From the logfile I assume that vdpau is in use: VDPAU::CreateContext - creating decoder context And by getting to fullscreen the decoder is still destroyed, but later recreated: OnKey: backslash (0xf05c) pressed, action is ToggleFullScreen ... CVDPAU::OnLostDevice event (VDPAU) FiniVDPAUOutput ... CWinSystemX11::RefreshGlxContext: refreshing context CVDPAU::OnResetDevice event ... VDPAU::CreateContext - creating decoder context I attached a debugger to see where we come from for this OnResetDevice: (gdb) bt #0 VDPAU::CDecoder::OnResetDevice (this=0x7f5c180017e0) at VDPAU.cpp:694 #1 0x00e88458 in CWinSystemX11::SetWindow (this=this@entry=0x1b39a80, width=1680, height=optimized out, fullscreen=fullscreen@entry=true, output=DVI-D-0) at WinSystemX11.cpp:1234 #2 0x00e89235 in CWinSystemX11::SetFullScreen (this=this@entry=0x1b39a80, fullScreen=fullScreen@entry=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11.cpp:313 #3 0x00e8f5ff in CWinSystemX11GL::SetFullScreen (this=0x1b39a80, fullScreen=true, res=..., blankOtherDisplays=optimized out) at WinSystemX11GL.cpp:212 #4 0x007ce58e in CGraphicContext::SetVideoResolutionInternal (this=this@entry=0x1b387a0, res=optimized out, res@entry=RES_DESKTOP, forceUpdate=forceUpdate@entry=false) at GraphicContext.cpp:466 #5 0x007cee56 in CGraphicContext::SetVideoResolution (this=0x1b387a0, res=RES_DESKTOP, forceUpdate=optimized out) at GraphicContext.cpp:371 #6 0x006ffa24 in CDisplaySettings::OnSettingChanging (this=0x18e90c0 CDisplaySettings::Get()::sDisplaySettings, setting=0x10) at DisplaySettings.cpp:248 #7 0x00c66a91 in CSettingsManager::OnSettingChanging (this=optimized out, setting=0x1d087a0) at SettingsManager.cpp:732 #8 0x00c5172c in CSettingString::SetValue (this=0x1d087a0, value=DESKTOP) at Setting.cpp:1272 #9 0x00c643d8 in CSettingsManager::SetString (this=0x1bb2410, id=videoscreen.screenmode, value=DESKTOP) at SettingsManager.cpp:601 #10 0x006ee169 in CSettings::SetString (this=optimized out, id=videoscreen.screenmode, value=DESKTOP) at Settings.cpp:396 #11 0x006fe083 in CDisplaySettings::SetCurrentResolution (this=0x18e90c0 CDisplaySettings::Get()::sDisplaySettings, resolution=resolution@entry=RES_DESKTOP, save=save@entry=true) at DisplaySettings.cpp:358 #12 0x007cf1df in CGraphicContext::ToggleFullScreenRoot (this=0x1b387a0) at GraphicContext.cpp:1004 #13 0x00cb3ea2 in CApplication::OnAction (this=0x1b35c90, action=...) at Application.cpp:2541 ... This kodi-14 stack is nearly equal to the stack of xbmc-13 when we call the VDPAU::CDecoder::FiniVDPAUOutput. The difference starts in CWinSystemX11::SetFullScreen. Will do some more testing, probably we need only to make a call to CWinSystemX11::SetWindow too ... --- The commit message for xbmc-13 you mentioned reads like the exact opposite what I observed? --- I build a package xbmc-13 with these changes to debian/rules: - --enable-xrandr \ + --disable-xrandr \ And indeed, this version works like expected, for my short test. Kind regards, Bernhard Am 28.12.2014 um 16:32 schrieb Bálint Réczey: Hi Bernhard, 2014-12-28 14:28 GMT+01:00 Bernhard Ãbelacker bernha...@vr-web.de: Hello Bálint Réczey, thanks for your fast response. One thing I am uncomfortable with my proposal is, if it would affect people using some low spec computer which are not able to decode fast enough in software and not having vdpau at all. Well, if this was OK for DVD streams, it should be OK for PVR streams as well. BTW the original commit adding hint.software = true;: commit d75a46a9f9626be12cc486c8e7c7d9be9d216922 Author: elupus elupus@svn Date: Fri Apr 9 18:59:15 2010 + changed: only use libmpeg2 for dvd playback Side effect that vaapi/vdpau is now allowed for all mpeg2 content. git-svn-id: https://xbmc.svn.sourceforge.net/svnroot/xbmc/trunk@29147 568bbfeb-2a22-0410-94d2-cc84cf5bfa90 ... I will try to build a kodi package from your repo and report back. It would also be interesting to check an xbmc build using FFmpeg, it may make a difference: http://snapshot.debian.org/package/xbmc/2%3A13.2%2Bdfsg1-2~exp1/ Kind regards, Bernhard One think were I am undecided is, my proposal is to set set software=true. But I don't know if then someone would still be able to watch via xbmc-pvr-tvheadend-hts on e.g. on a raspberry I'm hesitant a bit, too to upload the change. You may have hit a different manifestation of #769057. Looking at the code it seems compiling with xrandr disabled may make XBMC skip the
Bug#773742: ITP: rtcw-sp -- military/occult WWII first-person shooter game - single player version
On 29/12/14 09:09, Alexandre Detiste wrote: I've tested this too, but I've been more happy with iortcw fork: it has been ported to SDL2; and development is more active. https://code.google.com/p/iortcw/ It's in svn? e... But yes, if it's SDL2 and development is active, that's probably a better fork to go for. At the moment I'm using my own fork of https://github.com/hexameron/RTCW-SP-linux but I can convert the changes for iortcw. iortcw seems to be one unified hierarchy for both SP and MP, so I suppose this means I get to deal with MP security after all :-( I can help for the game-data-packager script too... I already have the majority of a gdp script written. I finally got frustrated enough with writing fragile shell scripts to prototype a new data-driven gdp implementation using Python and YAML, which should make it a lot easier to do things like you need the patch, unless you are importing from the fully-patched Steam release in which case you need to pass one file through dos2unix without writing too much repetitive shell code. Jonathan tried to do something similar 5 years ago, but we have a broader range of supported games now, with varying requirements. The dialogs in the SP game have been dubbed, so mind there are several valid different md5sums Do you have a dubbed version? If you do, please send the name, size, md5, sha1, sha256 of each pk3 in that version after it has been fully patched. I'm trying to use better checksums for new games in gdp. S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774142: unblock: mime-support/3.58
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mime-support to fix CVE-2014-0666 in Jessie.
unblock mime-support/3.58
Have a nice day,
and a BIG THANK YOU for your outstanding work.
--
Charles Plessy
Tsurumi, Kanagawa, Japan
diff -Nru mime-support-3.57/debian/changelog mime-support-3.58/debian/changelog
--- mime-support-3.57/debian/changelog 2014-10-04 20:29:52.0 +0900
+++ mime-support-3.58/debian/changelog 2014-12-28 15:06:43.0 +0900
@@ -1,3 +1,17 @@
+mime-support (3.58) unstable; urgency=high
+
+ * CVE-2014-7209: run-mailcap shell command injection.
+Thanks to Timothy D. Morgan for the report.
+
+ d156797 Escape file name also when not passed through %s. This
+ avoids command injections using for instance semicolons.
+ b585022 Resolve file name to an absolute path to avoid injection of
+ command arguments with file names starting with dashes etc.
+ Use File::Spec to avoid race conditions with temporary files.
+ Thanks, Salvatore Bonaccorso for the patch.
+
+ -- Charles Plessy ple...@debian.org Sun, 28 Dec 2014 14:45:59 +0900
+
mime-support (3.57) unstable; urgency=medium
* Media types added:
diff -Nru mime-support-3.57/run-mailcap mime-support-3.58/run-mailcap
--- mime-support-3.57/run-mailcap 2014-05-25 09:49:18.0 +0900
+++ mime-support-3.58/run-mailcap 2014-12-28 15:06:43.0 +0900
@@ -11,7 +11,7 @@
use Encode qw(decode);
use I18N::Langinfo qw(langinfo CODESET);
-
+use File::Spec;
$debug=($ENV{RUN_MAILCAP_DEBUG} || 0);
$norun=0;
@@ -469,27 +469,22 @@
}
if ($file ne -) {
-if ($comm =~ m/[^%]%s/) {
-if (decode(langinfo(CODESET()), $file) =~ m![^[:alnum:],.:/@%^+=_-]!i) {
-$match =~ m/nametemplate=(.*?)\s*($|;)/;
-my $prefix = $1;
-my $linked = 0;
-while (!$linked) {
-$tmplink = TempFile($prefix);
-unlink($tmplink);
-if ($file =~ m!^/!) {
-$linked = symlink($file,$tmplink);
-} else {
-my $pwd = `/bin/pwd`;
-chomp($pwd);
-$linked = symlink($pwd/$file,$tmplink);
-}
-}
-print STDERR - filename contains shell meta-characters; aliased to '$tmplink'\n if $debug;
-$comm =~ s/([^%])%s/$1$tmplink/g;
-} else {
-$comm =~ s/([^%])%s/$1$file/g;
+# Resolve file name to an absolute path
+$file = File::Spec-rel2abs($file);
+if (decode(langinfo(CODESET()), $file) =~ m![^[:alnum:],.:/@%^+=_-]!i) {
+$match =~ m/nametemplate=(.*?)\s*($|;)/;
+my $prefix = $1;
+my $linked = 0;
+while (!$linked) {
+$tmplink = TempFile($prefix);
+unlink($tmplink);
+$linked = symlink($file,$tmplink);
}
+$file = $tmplink;
+print STDERR - filename contains shell meta-characters; aliased to '$tmplink'\n if $debug;
+}
+if ($comm =~ m/[^%]%s/) {
+$comm =~ s/([^%])%s/$1$file/g;
} else {
if ($comm =~ m/\|/) {
$comm =~ s/\|/\Q$file\E \|/;
Bug#774143: malicious HTTP request kills gearmand
Package: gearman-job-server Version: 1.0.6-4 Status: install ok installed Installed-Size: 268 Architecture: amd64 Severity: serious A bad HTTP request force gearmand (=0.33 AFAIK) to run in in endless loop until memory out. See bug report https://bugs.launchpad.net/gearmand/+bug/1348865 Bug fixing was commited here http://bazaar.launchpad.net/~1-infe-w/gearmand/1.0/revision/802#libgearman-server/plugins/protocol/http/protocol.cc Regards, Alexei -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774144: NO worker result HTTP-response content
Package: gearman-job-server Version: 1.0.6-4 Status: install ok installed Installed-Size: 268 Architecture: amd64 Severity: important there is a bug in HTTP plugin implementation: gearmand doesn't return worker result to the client HTTP response as expected. See bug report https://bugs.launchpad.net/gearmand/+bug/1152707 Here is bug fixing solution in gearman-1 http://bazaar.launchpad.net/~1-infe-w/gearmand/1.0/revision/802#libgearman-server/plugins/protocol/http/protocol.cc Regards, Alexei -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774140: libisofs: typo: explicite - explicit
Hi, thank you for reporting. Fixed now upstream by http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1179 Further in libburn and libisoburn http://libburnia-project.org/changeset/5403 http://libburnia-project.org/changeset/5402 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767227: [oss-security] Re: CVE request: lsyncd command injection
On Mon, Dec 29, 2014 at 02:34:40AM +0100, Moritz Mühlenhoff wrote:
On Wed, Nov 26, 2014 at 12:18:13AM +0100, Ángel González wrote:
On 20-11-2014 Mitre wrote:
There is a command injection flaw in lsyncd, a file change monitoring
and synchronization daemon:
https://github.com/axkibe/lsyncd/issues/220
https://github.com/creshal/lsyncd/commit/18f02ad013b41a72753912155ae2ba72f2a53e52
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767227
Use CVE-2014-8990. The scope of this CVE ID includes both:
What's the status for jessie?
Hello,
I just finished packages for Wheezy and Jessie but did not upload them yet.
Attached are the .dsc's, the debian.tar.{gz,xz} and debdiffs for
convenience.
I'll ask the release team for a pre-approval for a Jessie unblock before
uploading to unstable.
Best regards
Jan
--
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD
https://portfolio.debian.net/ - https://people.debian.org/~jandd/
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Format: 3.0 (quilt)
Source: lsyncd
Binary: lsyncd
Architecture: any
Version: 2.1.5-2
Maintainer: Jan Dittberner ja...@debian.org
Homepage: https://github.com/axkibe/lsyncd
Standards-Version: 3.9.4
Vcs-Browser: http://anonscm.debian.org/gitweb/?p=collab-maint/lsyncd.git
Vcs-Git: git://anonscm.debian.org/collab-maint/lsyncd.git
Build-Depends: debhelper (= 7.0.50~), libxml2-dev, automake, liblua5.1-0-dev,
lua5.1, pkg-config, asciidoc, xsltproc, docbook-xml, docbook-xsl,
autotools-dev, dpkg-dev (= 1.16.1~)
Package-List:
lsyncd deb admin optional arch=any
Checksums-Sha1:
5be0a65956837d8e621b711bc7f96c6429d9da50 149873 lsyncd_2.1.5.orig.tar.gz
a5e2176e3f1c40849933c92a637d8aed5553a372 5492 lsyncd_2.1.5-2.debian.tar.xz
Checksums-Sha256:
4a793056c4ed833edb59436d7711bb65f7e38a4d8d44371cc9dc5eb91fbc461f 149873
lsyncd_2.1.5.orig.tar.gz
33de0865276248db19734029a33ebf4e8085ace860c7324e5f76347b5d5ae64a 5492
lsyncd_2.1.5-2.debian.tar.xz
Files:
fb10547494ec5ec662fe88343047c364 149873 lsyncd_2.1.5.orig.tar.gz
9805dd5c92ba7a19584cb6ce4cc721ef 5492 lsyncd_2.1.5-2.debian.tar.xz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iQEcBAEBCgAGBQJUoTGKAAoJEA15HcjXN8HZgMEH/iNMXZl43TRTnI4saeTJlCCD
qlFKx0FiXLtk24OT0gChkWYkx0C4fwaUMKzhJdyAs4XFY2en6fho40N/sagY2/Ia
yC3aoViDTlBgaYq09UP0QygVcrOgIceb/rj33OQ4PLxkZCJrj69khk40km3fMTV7
OJs/f45teoX/CUtdE4knGobfeiCWWphmyFYI29PCNmqHbUpPqjFMyr3RrIqTYdQk
ATUDlDToLA2qfOugxb0mE5k1I0PZUulBjbsIMTY2Uh15wgOPr1uK/k823om5HJYw
f7MqtpctEDyk3q5wvlpb/KYesLXOJCvE0KlQ/rWu7I2jClmGJ1ef4T3rEV491ko=
=Cvyh
-END PGP SIGNATURE-
lsyncd_2.1.5-2.debian.tar.xz
Description: application/xz
diff -Nru lsyncd-2.1.5/debian/changelog lsyncd-2.1.5/debian/changelog
--- lsyncd-2.1.5/debian/changelog 2013-06-22 23:15:08.0 +0200
+++ lsyncd-2.1.5/debian/changelog 2014-12-29 11:37:06.0 +0100
@@ -1,3 +1,11 @@
+lsyncd (2.1.5-2) unstable; urgency=high
+
+ * fix security issue CVE-2014-8990 that allows code execution via shell
+characters in file names and denial of service scenarios by applying
+debian/patches/fix-CVE-2014-8990-shell-escapes.patch (Closes: #767227)
+
+ -- Jan Dittberner ja...@debian.org Mon, 29 Dec 2014 11:36:43 +0100
+
lsyncd (2.1.5-1) unstable; urgency=low
* New upstream version (Closes: #707328).
diff -Nru lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
--- lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
1970-01-01 01:00:00.0 +0100
+++ lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
2014-12-29 11:37:06.0 +0100
@@ -0,0 +1,39 @@
+Author: Ángel González an...@16bits.net
+Bug: https://github.com/axkibe/lsyncd/issues/220
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767227
+Subject: Properly sanitize mv parameters (CVE-2014-8990)
+ Sanitize mv arguments:
+ .
+ 1. Fixes crashes on file names containing `, $ or
+ 2. Also prevents shell execution of ``, $() … in file names, which can be
+used to gain remote shell access as lsyncd's (target) user.
+--- a/default-rsyncssh.lua
b/default-rsyncssh.lua
+@@ -74,6 +74,11 @@
+ -- makes move local on target host
+ -- if the move fails, it deletes the source
+ if event.etype == 'Move' then
++ local path1 = config.targetdir .. event.path
++ local path2 = config.targetdir .. event2.path
++ path1 = ' .. path1:gsub ('\'', '\'\'\'') .. '
++ path2 = ' .. path2:gsub ('\'', '\'\'\'') .. '
++
+ log('Normal', 'Moving ',event.path,' - ',event2.path)
+
+ spawn(
+@@ -82,10 +87,12 @@
+ config.ssh._computed,
+ config.host,
+ 'mv',
+- '\' .. config.targetdir .. event.path .. '\',
+- '\'
Bug#759886: [debhelper-devel] Bug#759886: debhelper: please make mtimes of packaged files deterministic
* Jérémy Bobbio lu...@debian.org [141228 22:06]: Joey Hess: Jérémy Bobbio wrote: Joey Hess: My other idea is to make dh_fixmtimes set something that a later command (eg, dh_builddeb) could use and warn if it was not run. Maybe it should be integrated to dh_builddeb, then? I don't think it belongs in dh_builddeb directly. Unfortunately, while trying to understand why r-cran-gbm was not building reproducibly [1], I noticed that there might be a compelling reason to merge dh_fixmtimes in dh_builddeb. When DH_ALWAYS_EXCLUDE is specified, dh_builddeb might delete files. When this happens, parent directories get their mtime updated, reverting dh_fixmtimes work. So the ideal moment to set deterministic mtimes is after that pass. Which means integrating the find+xargs+touch in dh_builddeb… May I suggest to just duplicate the DH_ALWAYS_EXCLUDE handling in dh_fixmtimes for the time being? If they are already removed then dh_builddeb should not do any new harm and this way you keep more control over dh_fixmtimes so there is less chances debhelper will ship outdated code. Those two can then still later be merged if that still looks sensible then. Bernhard R. Link -- F8AC 04D5 0B9B 064B 3383 C3DA AFFC 96D1 151D FFDC -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774100: debhelper: please ensure a stable order in shlibs files
Niels Thykier: We will apply this for stretch. Would it be helpful to you if we uploaded this sooner to experimental? Good news! :) Given we have our own repository for experimental toolchain related to reproducible builds, I don't think it's worth the hassle of an upload to experimental. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#774102: debhelper: please ensure a stable order of icons list
Niels Thykier: We will apply this for stretch. Would it be helpful to you if we uploaded this sooner to experimental? Good news! :) Given we have our own repository for experimental toolchain related to reproducible builds, I don't think it's worth the hassle of an upload to experimental. -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#774141: kdevelop-python should be renamed kdevelop-python3
severity 774141 wishlist tag 774141 + wontfix thanks On 2014-12-29 11:41, Shriramana Sharma wrote: https://packages.debian.org/sid/kdevelop-python gives the description of this package as Python 3 plugin for KDevelop. Normally IIUC python3 related packages are marked as python3 and not just as python. kdevelop-python is a kdevelop plugin, not a Python module. I submit that it would be advisable to rename the package as kdevelop-python3 The plugin is named after python, not python3, hence the current package naming. So no, there will not be any package rename. and instead package the Python 2 plugin as kdevelop-python. (Should I report a separate bug asking for Py 2 plugin?) There will not be any Python 2 version in Debian, since it used an embedded (and modified) copy of python which is totally no-no for the archive. Thanks for your report, -- Pino Toscano -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739486: game-data-packager: Please add support for Tyrian data using following patch.
You're mixing hard tabs (U+0009) and 4-space units for indentation. Please be consistent within each file, and consider configuring your editor to display hard tabs. Ok, some of this dates back from april; I've since been bitten hard by this in some python project. Some of those dispredencies might come from the wolf3d script I used as example. + if [ $CHECKSUM != $ZIPSUM ]; then + echo warning: checksum is not what we expected 2 + fi This comes from the wolf3d example. I guess there is a reason for wolf3d, because there are various versions avaible. (BTW the one I have for 20 years trigger this warning) this to be a fatal error. Yes, this would make sense here. Does Tyrian have a non-shareware version? If it does, I would prefer to treat it like Quake 1 and produce tyrian-registered-data (or tyrian-full-data or just tyrian-data) for the full game, or tyrian-shareware-data or something for the shareware version. This is the full game, it is just non-distribuable. The license: Feel free to play it all you want and share it with friends, but for the moment I'd like to just have a central backup place (here) for the game. In the future I might not mind other sites sharing it, but I do enjoy amusing fans. :) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628689 opentyrian doesn't work with the shareware version. https://code.google.com/p/opentyrian/wiki/FAQ Alexandre Detiste -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774145: amarok: crashes sometimes when shutting down the system while playing
Package: amarok Version: 2.6~beta1+75.g47e75df-1 Severity: normal The system was shut down while amarok was still playing a track. The shutdown was done intentionally by a lid close event of the laptop. Amarok crashes sometimes during this process instead of closing properly. The KDE Crash Report then interrupts the shutdown process. Instead of crashing, Amarok should close without an error and the shut down of the system should proceed. A backtrace is attached below. Regards, Adrian Application: Amarok (amarok), signal: Segmentation fault Using host libthread_db library /lib/x86_64-linux-gnu/libthread_db.so.1. [Current thread is 1 (Thread 0x7fa9a8455780 (LWP 3895))] Thread 10 (Thread 0x7fa97ef18700 (LWP 3928)): #0 constBegin (this=0x1413250) at .../../include/QtCore/../../src/corelib/tools/qlist.h:269 #1 QTimerInfoList::timerWait (this=0x1413250, tm=...) at kernel/qeventdispatcher_unix.cpp:455 #2 0x7fa9a56b494c in timerSourcePrepareHelper (src=optimized out, timeout=0x7fa97ef17c4c) at kernel/qeventdispatcher_glib.cpp:136 #3 0x7fa9a56b49f5 in timerSourcePrepare (source=optimized out, timeout=optimized out) at kernel/qeventdispatcher_glib.cpp:169 #4 0x7fa99e704e5f in g_main_context_prepare () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #5 0x7fa99e70554b in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7fa99e705744 in g_main_context_iteration () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #7 0x7fa9a56b5296 in QEventDispatcherGlib::processEvents (this=0x14118b0, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #8 0x7fa9a56858af in QEventLoop::processEvents (this=this@entry=0x7fa97ef17df0, flags=...) at kernel/qeventloop.cpp:149 #9 0x7fa9a5685b38 in QEventLoop::exec (this=0x7fa97ef17df0, flags=...) at kernel/qeventloop.cpp:204 #10 0x7fa9a5588d70 in QThread::exec (this=optimized out) at thread/qthread.cpp:501 #11 0x7fa9a56661bf in QInotifyFileSystemWatcherEngine::run (this=0x1410d30) at io/qfilesystemwatcher_inotify.cpp:248 #12 0x7fa9a558bd0b in QThreadPrivate::start (arg=0x1410d30) at thread/qthread_unix.cpp:307 #13 0x7fa9a1557b50 in start_thread (arg=optimized out) at pthread_create.c:304 #14 0x7fa9a4d3d7bd in clone () at .../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #15 0x in ?? () Thread 9 (Thread 0x7fa973fff700 (LWP 3929)): #0 0x7fa9a155a275 in __pthread_mutex_lock (mutex=0x14cdfc0) at pthread_mutex_lock.c:92 #1 0x7fa99e741421 in g_mutex_lock () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #2 0x7fa99e705730 in g_main_context_iteration () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #3 0x7fa9a56b5296 in QEventDispatcherGlib::processEvents (this=0x14cdb20, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #4 0x7fa9a56858af in QEventLoop::processEvents (this=this@entry=0x7fa973ffee20, flags=...) at kernel/qeventloop.cpp:149 #5 0x7fa9a5685b38 in QEventLoop::exec (this=0x7fa973ffee20, flags=...) at kernel/qeventloop.cpp:204 #6 0x7fa9a5588d70 in QThread::exec (this=optimized out) at thread/qthread.cpp:501 #7 0x7fa9a558bd0b in QThreadPrivate::start (arg=0x14cd320) at thread/qthread_unix.cpp:307 #8 0x7fa9a1557b50 in start_thread (arg=optimized out) at pthread_create.c:304 #9 0x7fa9a4d3d7bd in clone () at .../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #10 0x in ?? () Thread 8 (Thread 0x7fa972b2a700 (LWP 3930)): #0 0x7fa99e7411a0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #1 0x7fa99e741449 in g_mutex_unlock () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #2 0x7fa99e704816 in g_main_context_acquire () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #3 0x7fa99e705504 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fa99e705744 in g_main_context_iteration () from /lib/x86_64-linux- gnu/libglib-2.0.so.0 #5 0x7fa9a56b5296 in QEventDispatcherGlib::processEvents (this=0x14ce930, flags=...) at kernel/qeventdispatcher_glib.cpp:426 #6 0x7fa9a56858af in QEventLoop::processEvents (this=this@entry=0x7fa972b29e20, flags=...) at kernel/qeventloop.cpp:149 #7 0x7fa9a5685b38 in QEventLoop::exec (this=0x7fa972b29e20, flags=...) at kernel/qeventloop.cpp:204 #8 0x7fa9a5588d70 in QThread::exec (this=optimized out) at thread/qthread.cpp:501 #9 0x7fa9a558bd0b in QThreadPrivate::start (arg=0x7fa974074200) at thread/qthread_unix.cpp:307 #10 0x7fa9a1557b50 in start_thread (arg=optimized out) at pthread_create.c:304 #11 0x7fa9a4d3d7bd in clone () at .../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #12 0x in ?? () Thread 7 (Thread 0x7fa97151d700 (LWP 3932)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at .../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x7fa9a558c20b in wait (time=18446744073709551615, this=0x1596df0) at thread/qwaitcondition_unix.cpp:86 #2 QWaitCondition::wait (this=optimized out, mutex=0x1597920, time=18446744073709551615) at
Bug#774138: More details
During this upgrade, several other packages may be of interest, because some are related to EFI handling: efibootmgr:amd64 (0.9.0-2, 0.11.0-3) especially this one grub2-common:amd64 (2.02~beta2-18, 2.02~beta2-19) grub-common:amd64 (2.02~beta2-18, 2.02~beta2-19) grub-efi:amd64 (2.02~beta2-18, 2.02~beta2-19) grub-efi-amd64:amd64 (2.02~beta2-18, 2.02~beta2-19) grub-efi-amd64-bin:amd64 (2.02~beta2-18, 2.02~beta2-19) libefivar0:amd64 (0.15-2, 0.15-3) and this one The bug may be related to the use of new features in these new versions, probably in libefivar0, but this is only my guess. signature.asc Description: Digital signature
Bug#773671: [Pkg-javascript-devel] Bug#773671: libv8-3.14: multiple security issues
Hi Moritz, 2014-12-29 3:01 GMT+01:00 Moritz Mühlenhoff j...@inutil.org: On Sun, Dec 21, 2014 at 03:19:42PM -0500, Michael Gilbert wrote: package: src:libv8-3.14 severity: grave tags: security Hi, the following vulnerabilities were published for libv8-3.14. So if I'm understanding the discussion on debian-devel correctly the libv8 maintainers want to see this treated as an RC-bug. Please clarify your intentions, do you a) intent to fix these issues with patches and if that's not possible remove libv8 along with its rev deps? b) want to keep this with RC severity and tag it jessie-ignore. I would consider that rather broken since foo-ignore is used for issues which are ignored for once, but which will be addressed in release+1. I don't see the libv8 situation change upstream... The rationale behind opening the RC bugs was improving transparency on my side. I think more people follow bugs than the security tracker. I think the call between a) and b) is up to release management, but my interpretation for b) is a bit different. There are RC bugs ignored for several releases thus I think foo-ignore is not strictly for one-off issues and b) would be the proper way of letting liv8 released with Jessie if the security issues stay open. Cheers, Balint c) plan something else I'm missing Cheers, Moritz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774146: pre-approval: unblock: lsyncd/2.1.5-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
unblock lsyncd/2.1.5-2
Dear release team,
I prepared a new lsyncd version that fixes a security issue (#767227,
CVE-2014-8990). I attach the debdiff for the new version to this report.
Please tell me whether I should upload the package to unstable.
Best regards
Jan Dittberner
--
Jan Dittberner - Debian Developer
GPG-key: 4096R/558FB8DD 2009-05-10
B2FF 1D95 CE8F 7A22 DF4C F09B A73E 0055 558F B8DD
https://portfolio.debian.net/ - https://people.debian.org/~jandd/
diff -Nru lsyncd-2.1.5/debian/changelog lsyncd-2.1.5/debian/changelog
--- lsyncd-2.1.5/debian/changelog 2013-06-22 23:15:08.0 +0200
+++ lsyncd-2.1.5/debian/changelog 2014-12-29 11:37:06.0 +0100
@@ -1,3 +1,11 @@
+lsyncd (2.1.5-2) unstable; urgency=high
+
+ * fix security issue CVE-2014-8990 that allows code execution via shell
+characters in file names and denial of service scenarios by applying
+debian/patches/fix-CVE-2014-8990-shell-escapes.patch (Closes: #767227)
+
+ -- Jan Dittberner ja...@debian.org Mon, 29 Dec 2014 11:36:43 +0100
+
lsyncd (2.1.5-1) unstable; urgency=low
* New upstream version (Closes: #707328).
diff -Nru lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
--- lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
1970-01-01 01:00:00.0 +0100
+++ lsyncd-2.1.5/debian/patches/fix-CVE-2014-8990-shell-escapes.patch
2014-12-29 11:37:06.0 +0100
@@ -0,0 +1,39 @@
+Author: Ángel González an...@16bits.net
+Bug: https://github.com/axkibe/lsyncd/issues/220
+Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767227
+Subject: Properly sanitize mv parameters (CVE-2014-8990)
+ Sanitize mv arguments:
+ .
+ 1. Fixes crashes on file names containing `, $ or
+ 2. Also prevents shell execution of ``, $() … in file names, which can be
+used to gain remote shell access as lsyncd's (target) user.
+--- a/default-rsyncssh.lua
b/default-rsyncssh.lua
+@@ -74,6 +74,11 @@
+ -- makes move local on target host
+ -- if the move fails, it deletes the source
+ if event.etype == 'Move' then
++ local path1 = config.targetdir .. event.path
++ local path2 = config.targetdir .. event2.path
++ path1 = ' .. path1:gsub ('\'', '\'\'\'') .. '
++ path2 = ' .. path2:gsub ('\'', '\'\'\'') .. '
++
+ log('Normal', 'Moving ',event.path,' - ',event2.path)
+
+ spawn(
+@@ -82,10 +87,12 @@
+ config.ssh._computed,
+ config.host,
+ 'mv',
+- '\' .. config.targetdir .. event.path .. '\',
+- '\' .. config.targetdir .. event2.path .. '\',
++ path1,
++ path2
+ '||', 'rm', '-rf',
+- '\' .. config.targetdir .. event.path .. '\')
++ path1
++ )
++
+ return
+ end
+
diff -Nru lsyncd-2.1.5/debian/patches/series lsyncd-2.1.5/debian/patches/series
--- lsyncd-2.1.5/debian/patches/series 2013-06-22 23:15:08.0 +0200
+++ lsyncd-2.1.5/debian/patches/series 2014-12-29 11:37:06.0 +0100
@@ -1 +1,2 @@
+fix-CVE-2014-8990-shell-escapes.patch
dont_install_lua_as_docs.patch
signature.asc
Description: Digital signature
Bug#771669: segfaults with trivial usage
On 12/01/2014 02:38 PM, Lionel Elie Mamane wrote: Hi Christian, May I draw your attention on Debian bug number 771669, which I quote below and which can be read in full at http://bugs.debian.org/771669 ? It was reported against 0.992, but I have reproduced it with 0.999 (which I'm shortly going to upload to Debian). ... Hey Lionel, should be fixed with version 0.9991, please update. Best regards, Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#768756: wader: FTBFS in jessie: Tests failures
I intend NMU-ing a fix for this, as per the attached debdff, pending its unblock pre-approval (bug #774134). wader-nmu.debdiff Description: Binary data
Bug#773742: ITP: rtcw-sp -- military/occult WWII first-person shooter game - single player version
iortcw seems to be one unified hierarchy for both SP and MP, so I suppose this means I get to deal with MP security after all :-( The SP MP game are in the same repository, but kept separate. Upstream allways do doubble-work when a change applies to both SP MP it's possible to only builld SP. new data-driven gdp implementation using Python Oh yes, that would be nice ! That would also solve #691772: Inconsistent from game to game Steam This game is on Steam but Windons only ?! It's the same for ROTT, I guess some generic support for reading Steam data would make sense. Do you have a dubbed version? If you do, please send the name, size, md5, sha1, sha256 of each pk3 in that version after it has been fully patched. I'm trying to use better checksums for new games in gdp. The only file that is localised is sp_pak1.pk3 The patchs were never localised. I've found the same md5 online, but can't find the other languages. (maybe is Google filtering this irrelevant data for me) http://www.zeden.net/jeu/Return-to-Castle-Wolfenstein/fichier/209 tchet@antec:/usr/local/games/wolfenstein/main$ ls -l *.pk3 -rw-r--r-- 1 root root760207 mai 22 2011 mp_bin.pk3 -rw-r--r-- 1 root root 63211149 jun 24 2006 mp_pak0.pk3 -rw-r--r-- 1 root root 4449596 mai 22 2011 mp_pak1.pk3 -rw-r--r-- 1 root root 1118 mai 22 2011 mp_pak2.pk3 -rw-r--r-- 1 root root159762 mai 22 2011 mp_pak3.pk3 -rw-r--r-- 1 root root 7799 mai 22 2011 mp_pak4.pk3 -rw-r--r-- 1 root root167075 mai 22 2011 mp_pak5.pk3 -rw-r--r-- 1 root root 3485134 mai 22 2011 mp_pakmaps0.pk3 -rw-r--r-- 1 root root 3765933 mai 22 2011 mp_pakmaps1.pk3 -rw-r--r-- 1 root root 7408542 mai 22 2011 mp_pakmaps2.pk3 -rw-r--r-- 1 root root 10780146 mai 22 2011 mp_pakmaps3.pk3 -rw-r--r-- 1 root root 24171802 mai 22 2011 mp_pakmaps4.pk3 -rw-r--r-- 1 root root 20024689 mai 22 2011 mp_pakmaps5.pk3 -rw-r--r-- 1 root root 10080181 mai 22 2011 mp_pakmaps6.pk3 -rw-r--r-- 1 root root 315823656 jun 24 2006 pak0.pk3 -rw-r--r-- 1 root root 256811934 jun 24 2006 sp_pak1.pk3 -rw-r--r-- 1 root root 11026123 mai 22 2011 sp_pak2.pk3 -rw-r--r-- 1 root root152544 mai 22 2011 sp_pak3.pk3 md5sum: f19c389fe6310c24e664bc0fc84fdd95 sp_pak1.pk3 sha1sum: 0867395305426cc9374aa1d6e49b091f9b281cce sp_pak1.pk3 sha256sum: d8825aa5b7fb0b03f6956da4e6bf822db5dd50153a8e2f87dfedefb434b78e54 sp_pak1.pk3 I can provide the others sums if you need it. The pk3 are zips files themselves do they are protected against trivial corruption. I'll try to find the original media anyway. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774147: libisofs: buffer overflow in demo.c
Source: libisofs Version: 1.3.2-1.1 Tags: patch The attached patch fixes buffer overflow in the demo. -- Jakub Wilk --- a/demo/demo.c +++ b/demo/demo.c @@ -445,7 +445,8 @@ sp[i+1] = ' '; } -sp[level * 2-1] = '-'; +if (level 0) +sp[level * 2-1] = '-'; sp[level * 2] = '\0'; ret = iso_file_source_open(dir);
Bug#774148: fontforge: please propagate creation and modification times to generated ttf files
Package: fontforge
Version: 1:2.0.20140101-1
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: toolchain timestamps
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that packages using fontforge to generate TrueType fonts could not
be build reproducibly.
fontforge currently writes the current time as creation time and
modification time when generating TrueType fonts. With the attached
patch these fields will be populated with the data read from the source
file, enabling TrueType fonts to be build reproducibly.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From e97db74ba8765613a35572d7a7e96f1b0b5b20ce Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Mon, 29 Dec 2014 11:07:52 +
Subject: [PATCH] Add a patch to propagate creation and modification times to
TTF files
This enable TrueType Font to be built reproducibly.
---
...te-creation-and-modification-times-to-ttf.patch | 31 ++
debian/patches/series | 1 +
2 files changed, 32 insertions(+)
create mode 100644 debian/patches/propagate-creation-and-modification-times-to-ttf.patch
diff --git a/debian/patches/propagate-creation-and-modification-times-to-ttf.patch b/debian/patches/propagate-creation-and-modification-times-to-ttf.patch
new file mode 100644
index 000..0eb7f52
--- /dev/null
+++ b/debian/patches/propagate-creation-and-modification-times-to-ttf.patch
@@ -0,0 +1,31 @@
+Description: propagate creation and modification times to TTF
+ Instead of using the current time as creation and modification
+ times when writing a TrueType Font file, we now propagate those
+ coming from the source. This enables TrueType Font to be built
+ reproducibly.
+
+diff --git a/fontforge/tottf.c b/fontforge/tottf.c
+index a980610..3d488b0 100644
+--- a/fontforge/tottf.c
b/fontforge/tottf.c
+@@ -2812,7 +2812,6 @@ void cvt_unix_to_1904( long time, int32 result[2]) {
+
+ static void sethead(struct head *head,SplineFont *sf,struct alltabs *at,
+ enum fontformat format, int32 *bsizes) {
+-time_t now;
+ int i, lr, rl, indic_rearrange, arabic;
+ ASM *sm;
+ struct ttflangname *useng;
+@@ -2920,10 +2919,8 @@ static void sethead(struct head *head,SplineFont *sf,struct alltabs *at,
+ head-flags |= (19); /* Apple documents this */
+ /* if there are any indic characters, set bit 10 */
+
+-time(now); /* seconds since 1970, need to convert to seconds since 1904 */
+-cvt_unix_to_1904(now,head-modtime);
+-memcpy(head-createtime,head-modtime,sizeof(head-modtime));
+-
++cvt_unix_to_1904(sf-modificationtime,head-modtime);
++cvt_unix_to_1904(sf-creationtime,head-createtime);
+ }
+
+ static void sethhead(struct hhead *hhead,struct hhead *vhead,struct alltabs *at, SplineFont *sf) {
diff --git a/debian/patches/series b/debian/patches/series
index 6a8916c..f540e01 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -8,3 +8,4 @@
gitignore
set_fontforge_package_name.patch
fix-spelling-error.patch
+propagate-creation-and-modification-times-to-ttf.patch
--
2.1.3
signature.asc
Description: Digital signature
Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
+++ Helmut Grohne [2014-12-29 10:00 +0100]: Package: dpkg-dev Version: 1.17.23 Severity: wishlist User: helm...@debian.org Usertags: rebootstrap Some packages need extra Build-Depends when they are cross compiled. Here are some examples: * src:guile-2.0 needs guile-2.0 to cross-build * src:glib2.0 needs libglib2.0-dev:any to cross-build * src:autogen needs autogen to cross-build * src:flex runs help2man and an easy way to do that is to use the build arch flex * src:bison also runs help2man and can benefit from build arch bison A way to address this need is to use the cross build profile[1]. Now I am wondering whether dpkg-buildpackage should set the cross build profile automatically. The logic for doing so is as simple as: if the host architecture differs from the build architecture, enable that profile. If dpkg is not the place to add this facility, the place that invokes dpkg-buildpackage needs to enable this profile explicitly. That probably means that sbuild needs to do this. Thoughts? The thinking to date has been that this is not a job for the low-level tool dpkg-buildpackage. That provides the mechanism to set it but the environment sets things up. So yes, sbuild probably should do this, and pbuilder, and possibly debuild could/should do this, but I'm leery of dpkg-buildpackage doing it. But I could be wrong, and as we integrate this stuff more tightly, maybe it makes sense to move such functionality into lower-level tools. I have a feeling that dpkg-buildpackage should do 'policy' level build things so if the above became policy then dpkg-buildpackage should probably make sure it gets done. Perhaps the biggest disadvantage is indeed that if even the low-level build tool does this automatically then how do you turn it off? Is there is fact no good reason to ever want to? Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773867: no sources.lists in bootstraped foreign chroots
Hi Vagrant, On Montag, 29. Dezember 2014, Vagrant Cascadian wrote: I can reproduce this with debootstrap 1.0.66 in Jessie, building both armel and armhf chroots. Results in an empty sources.list. good :) FWIW, qemu-user-static ships a wrapper called qemu-debootstrap that handles several of the above steps automagically: qemu-debootstrap --arch=armel jessie ./jessie http://ftp.de.debian.org/debian nice, thanks for that pointer! does it do sources.list correctly? cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
Hi, On 28/12/14 14:22, Guido Günther a...@sigxcpu.org wrote: On Tue, Dec 16, 2014 at 10:09:15AM +0200, Markus Lehtonen wrote: On Fri, 2014-12-05 at 15:50 +0100, Guido Günther wrote: Hi Markus, On Tue, Dec 02, 2014 at 04:47:58PM +0200, Markus Lehtonen wrote: Hello, On Fri, 2014-11-28 at 14:55 +0100, Guido Günther wrote: On Fri, Nov 28, 2014 at 12:11:01PM +0200, Markus Lehtonen wrote: [..snip..] If you're willing to wait for few days I could look into this and provide a patchset with minimal pq-rpm implementation (i.e. all the new cmdline options, even configurable branch names, removed). What I'd like to have there are the unit tests. That would be awesome! I'd be great to have a second tool merged. The attached series implements an initial version of the pq-rpm tool. The first four patches (0001-0004) are required to make the actual pq-rpm tool to work correctly. The next four patches (0005-0008) are requirements for the unit tests. The last patch finally implements gbp-pq-rpm tool itself. This series (plus some additional features) is also available in feature/pq-rpm branch in my Github repository: git clone git://github.com/marquiz/git-buildpackage-rpm.git -b feature/pq-rpm I had a look at this branch an it looks great. I'd feel more comfortable if we'd had a unit test for dump_tree with recursive though (af39e32692ebedb4316b28851e10f737bf176105) - can you add that, I can pull in the rest then. You can find a patch with updated unit tests attached. I also updated and rebased my feature/pq-rpm branch in Github. I've pulled in the patches up to but the tests fail with: == ERROR: test suite for class 'tests.component.rpm.test_pq_rpm.TestPqRpm' -- Traceback (most recent call last): File /usr/lib/python2.7/dist-packages/nose/suite.py, line 209, in run self.setUp() File /usr/lib/python2.7/dist-packages/nose/suite.py, line 292, in setUp self.setupContext(ancestor) File /usr/lib/python2.7/dist-packages/nose/suite.py, line 315, in setupContext try_run(context, names) File /usr/lib/python2.7/dist-packages/nose/util.py, line 470, in try_run return func() File /var/scratch/src/git-buildpackage/git-buildpackage/tests/component/rpm/__ init__.py, line 93, in setup_class repo.create_branch(branch, rev) File /var/scratch/src/git-buildpackage/git-buildpackage/gbp/git/repository.py , line 311, in create_branch self._git_command(branch, args.args) File /var/scratch/src/git-buildpackage/git-buildpackage/gbp/git/repository.py , line 207, in _git_command raise GitRepositoryError(Error running git %s: %s % (command, stderr)) GitRepositoryError: Error running git branch: fatal: Not a valid branch point: 'b82fd1a61db4221263b2c110f60c6d07cb0203df'. I assume that the subproject commit of tests/component/rpm/data in 63a5a1aedb5e14e6d32a942b2a4c6de42b14a8f2 is incorrect? The pq-rpm unit tests utilize many refs (refs/gbp-test*/*) from the submodule repository. The problem probably is that my testdata repo was in inconsistent state at the time you ran git-submodule update and some refs in your local copy are out-of-date. Re-running git-submodule update now won't fetch them as the submodule HEAD is already up-to-date. Try doing git submodule foreach git fetch origin and re-running the tests. I didn't want to clone/fetch from the remote repo inside the tests in order to not depend on network connection. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771770: haskell-mode copiously displays its documentation
Robbie Harwood rharw...@club.cc.cmu.edu writes: Makes sense. The problem I'm having is that it's not clear how to turn it off, especially since I don't want any indentation. I think what you want then is to turn off electric-indent-mode, perhaps in a hook of haskell-mode. I have a vague memory that the default for this mode changed in 24.4. UNTESTED: (add-hook 'haskell-mode-hook (lambda () (electric-indent-local-mode -1))) d -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767261: xen-netback changes in #767261 break Mini-OS netfront
(Cc-ing debian-kernel, note I am not subscribed to this list, please Cc me on replies) Hi, after updating linux-image-3.16.0-4-amd64 from 3.16.7-2 to the latest 3.16.7-ckt2-1 networking on my rumprun-xen [1] domUs stopped working. Here is an excerpt of the failure during Mini-OS boot: net TX ring size 256 net RX ring size 256 netfront: node=device/vif/0 backend=/local/domain/0/backend/vif/21/0 netfront: MAC b2:11:11:11:11:11 backend not avalable, state=5 creating xenif0 failed: 22 It looks like the changes made in the fix for #767261, as mentioned in the Debian changelog are the likely culprit: [ Ian Campbell ] * [xen] Backport various netback fixes (Closes: #767261). However, I can't find a full final list of which fixes were backported. Given that the last traffic on #767261 was on November 9th, I suspect at least this upstream change from December 18 did NOT make it into the new linux-image package: xen-netback: support frontends without feature-rx-notify again 26c0e102585d5a4d311f5d6eb7f524d288e7f6b7 [2] I can't verify this 100% as I don't know where in the archive I can find the original 3.16.7-2 linux-image to downgrade to/compare the Debian diffs. Should I reopen #767261 or file a new bug for this? Thanks, Martin [1] http://repo.rumpkernel.org/rumprun-xen [2] http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=26c0e102585d5a4d311f5d6eb7f524d288e7f6b7 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774075: libdvdnav4: breaks mplayer2 from wheezy
On Mon, Dec 29, 2014 at 4:02 AM, Fabian Greffrath fab...@greffrath.com wrote: Am Sonntag, den 28.12.2014, 16:52 +0400 schrieb Stepan Golosunov: mplayer2 2.0-554-gf63dbad-1+b1 no longer starts after upgrading libdvdnav4 from 4.2.0+20120524-2 to 5.0.1-1: This is the mplayer2 package from stable and the libdvdnav4 package from testing. Generally, partial upgrades are not supported, but ... Partial upgrades are very much supported. Otherwise we wouldn't bother with dependencies so much. That does not mean every possible combination is supported. Just that apt should not leave your programs unusable. % mplayer mplayer: error while loading shared libraries: libdvdnavmini.so.4: cannot open shared object file: No such file or directory ... since this specific issue gets reported every now and then, and it has also been reported that adding a libdvdnavmini.so.4 - libdvdnav.so.4 symlink will fix it. So, shouldn't we just add this link to the libdvdnav4 package and be done with it? The maintenance burden will be a single line in debian/links and the gain would be better upgrade robustness (for an otherwise unsupported scenario, though). Or are there any objections against this way of support for a deprecated interface? I would instead add a Breaks: mplayer2 ( X) on libdvdnav, to force upgrade of mplayer2 alongside libdvdnav. -- Saludos, Felipe Sateler -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774129: should dpkg-buildpackage set the cross build profile automatically?
Hi, Quoting Wookey (2014-12-29 13:14:20) I have a feeling that dpkg-buildpackage should do 'policy' level build things so if the above became policy then dpkg-buildpackage should probably make sure it gets done. Perhaps the biggest disadvantage is indeed that if even the low-level build tool does this automatically then how do you turn it off? Is there is fact no good reason to ever want to? on the topic of who should automatically set a certain build profile and how to deactivate it (if desired for whatever reason), my message to d-devel might be of interest: http://lists.debian.org/20141212114840.15300.27739@hoothoot It explores the idea of allowing an architecture or distribution dependent set of profiles which are activated by default to remove the architecture lists currently attached to many dependencies as well as to minimize the diff between packaging of different vendors. I don't want to conflate these two discussions, but maybe it is worth keeping this possible future use case of build profiles in mind when discussing who should activate the cross profile in particular and how it could be deactivated if desired. So just my 2 cents. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767261: xen-netback changes in #767261 break Mini-OS netfront
On Mon, 2014-12-29 at 13:42 +0100, Martin Lucina wrote: However, I can't find a full final list of which fixes were backported. FWIW they are in the source package in debian/patches/series. Given that the last traffic on #767261 was on November 9th, I suspect at least this upstream change from December 18 did NOT make it into the new linux-image package: xen-netback: support frontends without feature-rx-notify again 26c0e102585d5a4d311f5d6eb7f524d288e7f6b7 [2] Yes, I very much suspect this is needed too and will fix your problem. I'll look into it shortly. I can't verify this 100% as I don't know where in the archive I can find the original 3.16.7-2 linux-image to downgrade to/compare the Debian diffs. snapshot.debian.org has all historical versions of all packages. Should I reopen #767261 or file a new bug for this? A new bug would be best please. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Mon, 2014-12-29 at 10:17 +0800, Chen Baozi wrote: On Dec 28, 2014, at 17:08, Ian Campbell i...@debian.org wrote: On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote: With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Do you know if phy-ti-pipe3 is used exclusively by USB or just only within the set of things used in the d-i context? Likewise the two regulators added to mmc? So far as I can tell from DTS, there are two types of modules use phy-ti-pipe3, which are ‘usb3’ and ‘sata’. But I am not quite sure how the hardware modules are connected. And pbias seems be only meaningful to mmc, and palmas relates to many other devices of the board. Thanks. I think palmas is a candidate to be built in then. I'll do that. I'm not entirely sure what to do about phy-ti-pipe3, you've added it to usb-modules but I suppose SATA won't necessarily work if we do that. I think I'd be inclined to build it in for now rather than make drastic changes to the udebs for Jessie. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774036: linux-image-3.16.0-4-amd64: Untainted Kernel shows similar issue
Hello Rainer, The below procedure would give more information: Add the following line to the top of the file /usr/lib/pm-utils/pm-functions. export PM_DEBUG=true Then suspend with: echo 1 /sys/power/pm_trace echo mem /sys/power/state Post dmesg and the contents of /var/log/pm-suspend.log. Have you tried disabling the mac80211 module? Best regards, Emil Goode -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#744753: Fix for anacron (running on resume under systemd)
Hi Ivo, I see that you uploaded a fix for #744753, using a unit file called anacron-resume: [Unit] Description=Run anacron jobs at resume After=suspend.target After=hibernate.target After=hybrid-sleep.target [Service] ExecStart=/bin/systemctl --no-block --fail start anacron.service [Install] WantedBy=suspend.target WantedBy=hibernate.target WantedBy=hybrid-sleep.target I don't think, this fixes the issue in a proper way, because ordering that service After=suspend.target, doesn't mean the unit is actually run on resume. Take a look at systemd-suspend.service, which is responsible for putting the system to sleep: [Unit] Description=Suspend Documentation=man:systemd-suspend.service(8) DefaultDependencies=no Requires=sleep.target After=sleep.target [Service] Type=oneshot ExecStart=/lib/systemd/systemd-sleep suspend It *also* has After=sleep.target. That means, depending on the timing, anacron-resume.service might be triggered just before suspend not on resume, and it's not guaranteed that anacron has finished before systemd-sleep is called. I don't think the patch was intended this way? Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, 2014-12-28 at 23:02 -0600, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 10:00 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Robert Nelson wrote:
On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org
wrote:
On 2014-12-28, Ian Campbell wrote:
OOI, do you know how broken the white is when booting with the black's
DTB? Completely unusable, missing some minor peripheral or somewhere in
the middle?
...
Oh you definitely don't want to run the wrong *.dtb on the black/white..
In u-boot the findfdt function will correctly set the fdtfile variable.
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176
Notice:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2
IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI
transceiver after a dozen boots with an uSD card inserted because LDO
will be at 3.3V instead of 1.8.
Also the 'white' uses DDR2, while the 'black uses DDR3
Ok, so given that it might actually damage hardware to run with the
wrong dtb, I've written up a few UNTESTED patches to support multiple
DTB-Id entries:
* copy a .dtb file to /boot in addition to the /boot/dtb-${version}
file, named using the ${fdtfile} variable.
While reviewing I noticed one little gottcha.. This is more of a blame
squarely at u-boot..
imx targets use:
fdt_file
http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/wandboard.h;h=809017c5fe225278c87619e237fd0905b9c1dcf1;hb=HEAD#l140
omap targets use:
fdtfile
Isn't that awesome. ;)
According to u-boot's README imx is in the wrong here, since only
fdtfile is documented. I think f-k should follow that lead and only
worry about fdtfile, at least until we have a concrete reason to worry
about the imx one.
Ian.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). [...] These might be a bit invasive for this point in the release cycle, but they also aren't terribly large patches... I can do some further testing if it seems like the approach is worth pursuing at this point. It is a little bit invasive, I was hoping not to be making large changes (i.e. anything more than db updates) to f-k at this point. But perhaps it is the best we can do. Given the beaglebone specific findfdt which Robert links to above could we add a check to bootscr.beaglebone which refuses to boot on a white? (looks like we can look at $board_name directly). Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774149: usbmount: Can't mount ntfs drive
Package: usbmount Version: 0.0.22 Severity: important Dear Maintainer, I'm trying to use usbmount to automount my pendrive formatted as ntfs. For that I only added ntfs to list of filesystems to /etc/usbmount config. Unfortunately, it doesn't work. After plugging in the device what I get is: [carramba@~]$ ls -la /media ls: cannot access /media/usb0: Transport endpoint is not connected total 1 drwxr-xr-x 13 root root 336 gru 28 13:30 . drwxr-xr-x 24 root root 712 gru 29 13:23 .. drwxr-xr-x 2 root root 88 sty 2 2010 hdc drwxr-xr-x 2 root root 88 gru 26 21:05 sdb1 drwxr-xr-x 2 root root 88 mar 5 2012 sr0 lrwxrwxrwx 1 root root 4 gru 28 13:30 usb - usb0 ?? ? ?? ?? usb0 drwxr-xr-x 2 root root 48 gru 28 13:30 usb1 drwxr-xr-x 2 root root 48 gru 28 13:30 usb2 drwxr-xr-x 2 root root 48 maj 17 2014 usb3 drwxr-xr-x 2 root root 48 gru 28 13:30 usb4 drwxr-xr-x 2 root root 48 gru 28 13:30 usb5 drwxr-xr-x 2 root root 48 gru 28 13:30 usb6 drwxr-xr-x 2 root root 48 gru 28 13:30 usb7 The device seems to be mounted, though: /dev/sdb1 on /media/usb0 type fuseblk (rw,nodev,noexec,noatime,user_id=0,group_id=0,allow_other,blksize=4096) /var/log/user.log contains the following (don't know why the device is present twice): Dec 28 13:55:50 dom mtp-probe: checking bus 2, device 3: /sys/devices/pci:00/:00:06.1/usb2/2-3 Dec 28 13:55:50 dom mtp-probe: bus: 2, device: 3 was not an MTP device Dec 28 13:55:52 dom usbmount[2330]: /dev/sdc does not contain a filesystem or disklabel Dec 28 13:55:52 dom usbmount[2360]: executing command: mount -tntfs -onoexec,nodev,noatime,nodiratime /dev/sdc1 /media/usb1 Dec 28 13:55:52 dom usbmount[2360]: executing command: run-parts /etc/usbmount/mount.d Dec 28 13:57:37 dom mtp-probe: checking bus 2, device 4: /sys/devices/pci:00/:00:06.1/usb2/2-3 Dec 28 13:57:37 dom mtp-probe: bus: 2, device: 4 was not an MTP device Dec 28 13:57:38 dom usbmount[2479]: /dev/sdb does not contain a filesystem or disklabel Dec 28 13:57:39 dom usbmount[2509]: executing command: mount -tntfs -onoexec,nodev,noatime,nodiratime /dev/sdb1 /media/usb0 Dec 28 13:57:39 dom usbmount[2509]: executing command: run-parts /etc/usbmount/mount.d When executing the command above manually (after umount/pumount) (mount -tntfs -onoexec,nodev,noatime,nodiratime /dev/sdb1 /media/usb0) everything is fine. The device is reported by dmesg as: [3.454987] scsi 6:0:0:0: Direct-Access Generic Flash Disk 8.07 PQ: 0 ANSI: 4 [3.456324] sd 6:0:0:0: Attached scsi generic sg2 type 0 [3.457985] sd 6:0:0:0: [sdb] 15687680 512-byte logical blocks: (8.03 GB/7.48 GiB) [3.459325] sd 6:0:0:0: [sdb] Write Protect is off [3.459334] sd 6:0:0:0: [sdb] Mode Sense: 23 00 00 00 [3.461438] sd 6:0:0:0: [sdb] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA [3.481088] sdb: sdb1 [3.487444] sd 6:0:0:0: [sdb] Attached SCSI removable disk Best regards, Robert -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.16.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=pl_PL.UTF-8, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages usbmount depends on: ii lockfile-progs 0.1.17 ii udev215-8 ii util-linux 2.25.2-4 Versions of packages usbmount recommends: ii pmount 0.9.23-3+b1 usbmount suggests no packages. -- Configuration Files: /etc/usbmount/usbmount.conf changed: ENABLED=1 MOUNTPOINTS=/media/usb0 /media/usb1 /media/usb2 /media/usb3 /media/usb4 /media/usb5 /media/usb6 /media/usb7 FILESYSTEMS=vfat ext2 ext3 ext4 hfsplus ntfs MOUNTOPTIONS=noexec,nodev,noatime,nodiratime FS_MOUNTOPTIONS= VERBOSE=yes -- no debconf information
Bug#761170: upstream
Control: tags -1 patch Hi, On Tue, Nov 25, 2014 at 10:38:44PM +0100, Lucas Nussbaum wrote: Note that the build now fails on i386 too. Trying to reproduce it locally, I run into yet another problem: 1) Failure: repo::iterator::fs_preserves_error [/tmp/libgit2-0.21.1/tests/repo/iterator.c:952] Expected function call to fail: git_iterator_advance(e, i) This problem is only occurs when running is root (the test chmods a file to 000 and checks if accessing it fails). It would probably be a good idea to add another test to check if the test is running as root, and fail in that case (because the tests assume they aren't). The failure that happens on the i386 buildd is this one: 1) Failure: clone::nonetwork::local_absolute_path [/«PKGBUILDDIR»/tests/clone/nonetwork.c:91] Function call failed: (git_clone(g_repo, local_src, ./foo, g_options)) error -1 - git_path_direach callback returned -1 I can reproduce this in my test environment on i386 and amd64. It only happens when the builddir and /tmp are on different filesystems. It seems the local clone tries to create a hard link, which fails across filesystems (the fact that this happens without fallback is an error in itself, so the test actually discovered a problem here). When setting the TMPDIR to a directory on the same filesystem, the test doesn't hit this issue, and the build works fine. It's unclear to me why this only happens on i386, but I suspect that the setup of the buildd chroots isn't the same everywhere. In any case, adding this patch fixes it in my environment. I can do an NMU if necessary. diff --git a/debian/rules b/debian/rules index 0d82de1..75b792d 100755 --- a/debian/rules +++ b/debian/rules @@ -36,6 +36,12 @@ override_dh_auto_install : dh_auto_install --builddirectory=build-debian-release dh_auto_install --builddirectory=build-debian-devel +override_dh_auto_test : + mkdir -p build-debian-release/tmp + TMPDIR=$(PWD)/build-debian-release/tmp dh_auto_test --builddirectory=build-debian-release + mkdir -p build-debian-devel/tmp + TMPDIR=$(PWD)/build-debian-devel/tmp dh_auto_test --builddirectory=build-debian-devel + override_dh_strip: dh_strip --dbg-package=libgit2-dbg Cheers, Ivo -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774075: libdvdnav4: breaks mplayer2 from wheezy
Am Montag, den 29.12.2014, 09:48 -0300 schrieb Felipe Sateler: Partial upgrades are very much supported. Otherwise we wouldn't bother with dependencies so much. Not across stable releases, AFAICT, which is the situation we have here (i.e. we will have here once testing has become jessie). I would instead add a Breaks: mplayer2 ( X) on libdvdnav, to force upgrade of mplayer2 alongside libdvdnav. -ETOOEASY? No, sure, don't know why I didn't think of this myself, but it appears to be the right thing to do. - Fabian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771857: caff: Please support GnuPG 2.1
This is due to GnuPG 2.1 ignoring --secret-keyring: --secret-keyring file This is an obsolete option and ignored. All secret keys are stored in the private-keys-v1.d directory below the GnuPG home directory. But caff has its own GnuPG home (~/.caff/gnupghome by default), and there is currently no configuration option to specify ‘~/.gnupg/private-keys-v1.d’ as the location for private keys. I'll file a wishlist bug for that. A dirty fix in the meantime is to symlink the directory: rmdir ~/.caff/gnupghome/private-keys-v1.d ln -s ~/.gnupg/private-keys-v1.d ~/.caff/gnupghome -- Guilhem. signature.asc Description: Digital signature
Bug#744753: Fix for anacron (running on resume under systemd)
Hi, It *also* has After=sleep.target. That means, depending on the timing, anacron-resume.service might be triggered just before suspend not on resume, and it's not guaranteed that anacron has finished before systemd-sleep is called. I don't think the patch was intended this way? I was told once to use a file like this: [Unit] Description=hdparm resume actions After=suspend.target After=hibernate.target After=hybrid-sleep.target [Service] Type=simple ExecStart=/usr/lib/pm-utils/power.d/95hdparm-apm resume [Install] WantedBy=suspend.target WantedBy=hibernate.target WantedBy=hybrid-sleep.target That's working fine for me. Kind regards, Ralf -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772687: Bug#772687: Bug#772687: Bug#772687: fonts-droid: fallback font is installed too early to fontconfig
On Sun, 28 Dec 2014 20:10:16 +0530 Vasudev Kamath vasu...@copyninja.info wrote: Indeed it is not ... should be 69 ;-) Is it sufficient just to increase the priority from 65 to 69? or something else needs to be changed to fix this?. Thanks! :) fontconfig design is... well, a bit strange and it sometimes confuse our desktop, but just dropping priority would be enough for this time. -- Regards, Hideki Yamane henrich @ debian.or.jp/org http://wiki.debian.org/HidekiYamane -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote: I wonder if flash-kernel should be smart enough to load the module itself. I think it should. I think all which is needed is to add modprobe -q mtdblock into the mtdblock function. I believe anything which uses an mtdblock device passes through that function to translate the name into a device node. What do you think? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773528: Fwd: Re: [systemd-devel] Quiesce audit message flood from 218
For the record, this is the response and kernel bug link from upstream. I propose we keep the don't enable audit patch in Debian until we get the kernel fix. Martin - Forwarded message from Lennart Poettering lenn...@poettering.net - Date: Mon, 29 Dec 2014 14:22:46 +0100 From: Lennart Poettering lenn...@poettering.net To: systemd-de...@lists.freedesktop.org Subject: Re: [systemd-devel] Quiesce audit message flood from 218 X-Spam-Status: No, score=-1.9 required=3.4 tests=BAYES_00 autolearn=no version=3.3.2 On Sun, 28.12.14 12:45, Martin Pitt (martin.p...@ubuntu.com) wrote: Hello all, systemd 218 now enables audit in the kernel unconditionally [1]. While these messages might be nice to have in the journal, they literally flood dmesg and thus /var/log/syslog and friends with messages like [39098.129349] audit: type=1105 audit(1419765421.403:4233): pid=25633 uid=0 auid=0 ses=20 msg='op=PAM:session_open acct=root exe=/usr/sbin/cron hostname=? addr=? terminal=cron res=success' $ dmesg |grep -c audit 786 and more importantly, eats a lot of real kernel/daemon messages due to rate limiting: I have many dozen messages like [37444.978307] audit_printk_skb: 222 callbacks suppressed and they demonstrably cause e. g. AppArmor violations to not get shown due to this. Is there a way to make the audit messages *only* go to the journal, but not to dmesg and sysloggers? If not, could we perhaps add a ./configure or config file option for this, to disable audit on systems where we don't need it? This is a known limitation of the in-kernel audit code, and is being tracked here. Needs to be fixed in the kernel. https://bugzilla.redhat.com/show_bug.cgi?id=1160046 Fix should be easy enough, but so far nobody looked into this yet. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-de...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel - End forwarded message - -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774150: gnome-core: dconf-tools is transitional package
Package: gnome-core Version: 1:3.14+3 Severity: normal Dear Maintainer, Although gnome-core depends dconf-tools (= 0.22), dconf-tools becomes transitional package. --- Package: dconf-tools Depends: dconf-cli, dconf-editor Description-en: transitional dummy package DConf is a low-level key/value database designed for storing desktop environment settings. . This package is a transitional package installing dconf-cli and dconf-editor, it can safely be removed --- Thanks, -- Kenshi Muto km...@debian.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771770: haskell-mode copiously displays its documentation
David Bremner da...@tethera.net writes: Robbie Harwood rharw...@club.cc.cmu.edu writes: Makes sense. The problem I'm having is that it's not clear how to turn it off, especially since I don't want any indentation. I think what you want then is to turn off electric-indent-mode, perhaps in a hook of haskell-mode. I have a vague memory that the default for this mode changed in 24.4. UNTESTED: (add-hook 'haskell-mode-hook (lambda () (electric-indent-local-mode -1))) That is exactly what I want, thanks! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
On Mon, 2014-12-29 at 13:24 +, Ian Campbell wrote: On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote: I wonder if flash-kernel should be smart enough to load the module itself. I think it should. I think all which is needed is to add modprobe -q mtdblock into the mtdblock function. I believe anything which uses an mtdblock device passes through that function to translate the name into a device node. What do you think? You also need 'udevadm settle' to wait for the device nodes to appear. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 13:13 +, Ian Campbell wrote: [...] Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). [...] Beaglebone wasn't supported upstream in 3.2 and we didn't backport anything for it. Ben. -- Ben Hutchings Anthony's Law of Force: Don't force it, get a larger hammer. signature.asc Description: This is a digitally signed message part
Bug#773528: Fwd: Re: [systemd-devel] Quiesce audit message flood from 218
Am 29.12.2014 um 14:26 schrieb Martin Pitt: For the record, this is the response and kernel bug link from upstream. I propose we keep the don't enable audit patch in Debian until we get the kernel fix. Fine with me. Logging the audit logs to the journal is after all a goodie and not critical functionality. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
On Mon, 2014-12-29 at 14:50 +0100, Ben Hutchings wrote: On Mon, 2014-12-29 at 13:24 +, Ian Campbell wrote: On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote: I wonder if flash-kernel should be smart enough to load the module itself. I think it should. I think all which is needed is to add modprobe -q mtdblock into the mtdblock function. I believe anything which uses an mtdblock device passes through that function to translate the name into a device node. What do you think? You also need 'udevadm settle' to wait for the device nodes to appear. Good point, thanks. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769918: Acknowledgement (therion-viewer: On opening window is completely frozen with no file displayed)
Well glxgears works again, and so does aven and loch, so this can be closed, thanks Andrew On 17/11/14 16:27, Debian Bug Tracking System wrote: Thank you for filing a new Bug report with Debian. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to a...@wotcc.org.uk (after having been given a Bug report number, if it did not have one). Your message has been sent to the package maintainer(s): Wookey woo...@debian.org If you wish to submit further information on this problem, please send it to 769...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#769917: survex-aven: No Display and/or controls on opening 3d file
Well glxgears works again, and so does aven and loch, so this can be closed, let's hope this does not happen too often, but no more updates for me until I have delivered the surveying course on the 10th Andrew On 17/11/14 23:36, Olly Betts wrote: On Mon, Nov 17, 2014 at 04:32:51PM +, Andrew Atkinson wrote: Also submitted Bug#769918 therion-viewer that is displaying similar behaviour. I also tried glxgears which as this is what you suggested last time. This brought up the gears, but they were static, on resizing the gears window, the window went blank. This suggests it's a problem with OpenGL support, rather than bugs in survex-aven and therion-viewer as such. What does this report: glxinfo|grep OpenGL Cheers, Olly -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774147: libisofs: typo: explicite - explicit
Hi, good catch. Fixed now upstream by http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1180 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774069: debootstrap: please use a deterministic mtime for devices.tar members
Control: tag -1 pending Jérémy Bobbio lu...@debian.org (2014-12-28): Source: debootstrap Version: 1.0.66 Severity: wishlist Tags: patch User: reproducible-bui...@lists.alioth.debian.org Usertags: timestamps Hi! While working on the “reproducible builds” effort [1], we have noticed that debootstrap could not be built reproducibly. The current build process captures the build time when devices.tar.gz is created. The attached patch will use the time of the latest debian/changelog entry as the mtime for devices.tar members, and remove the timestamp from the gzip header of devices.tar.gz. debootstrap can then be built reproducibly within our current framework. Thanks! Pushed to git master. Mraw, KiBi. signature.asc Description: Digital signature
Bug#700630: packaging of gitorious started
Control: retitle -1 ITP: gitorious -- Git based web collaboration tool Control: owner -1 mike.gabr...@das-netzwerkteam.de For the record... I have just created a package repo at [1]. Mike [1] http://anonscm.debian.org/cgit/collab-maint/gitorious.git/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.xfb pgp1hGSmksBCh.pgp Description: Digitale PGP-Signatur
Bug#774138: grub-efi-amd64: Update freeze with kernel oops for EFI (2.02~beta2-{18 - 19})
On Mon, 2014-12-29 at 11:30 +0100, Axel wrote: Package: grub-efi-amd64 Version: 2.02~beta2-19 Severity: important Dear Maintainer, * What led up to the situation? Usual daily upgrade. Including grub-efi-amd64: 2.02~beta2-18 - 2.02~beta2-19~i (is ~i a typo here?) The functional changes between -18 and -19 were pretty minor, just: + * Handle case insensitivity of VFAT filesystem on /boot/EFI when installing +extra cpoy of grub-efi to the removable media path +/boot/efi/EFI/BOOT/BOOT$ARCH.EFI (Closes: #773092) + * Make the force_efi_extra_removable debconf prompt only show up when +configuring grub-*efi*. Closes: #773004 plus a boatload of translation updates. The second on is obviously not the problem and since your debconf data contains : grub2/force_efi_extra_removable: false I think none of the code involved in the first case will be getting run for you. So I think you are probably correct to consider other things which have been upgraded as in your follow up. Could you try running grub-install -v please. Please could you also try downgrading this and some of the other packages which you think might be at fault one at a time to see if you can nail the culprit. Another possibility is that the firmware is a bit b0rked wrt efivars handling (I've heard some nasty things about some firmwares in this regard) and its just a coincidence that this was the upgrade which triggered it. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774151: vlogger - mysql_create.sql fix
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Subject: vlogger: mysql_create.sql fix Package: vlogger Version: 1.3-4 Severity: normal Dear Maintainer, the sample schema database (mysql_create.sql) uses UPPERCASE table name and fields that produce these errors on my system (Apache error.log): DBD::mysql::st execute failed: Table 'vlogger.wwwusage' doesn't exist at /usr/sbin/vlogger line 517, STDIN line 2102. DBD::mysql::db do failed: Table 'vlogger.wwwusage' doesn't exist at /usr/sbin/vlogger line 524, STDIN line 2102. after changed table name and fields in lovercase all seems works fine ;-) I suggest to change mysql_create.sql into: === CREATE TABLE wwwusage ( vhost VARCHAR(128) NOT NULL, ldate INT(8) UNSIGNED NOT NULL, bytes INT(32) UNSIGNED NOT NULL DEFAULT '0' ); === TIA Alessandro De Zorzi - lota -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJUoWZdAAoJEMH4AagsOpqywyoIALhAMf9PFNaAVwNL8TJQhD78 nYyb7hG7QDeVezfyOgp0cWW7fCLrAga7+rUguez4E8/kmyiCa73QWC4grw62dWO3 V7Lqn+uHHZg1es0CTQ7cvD+nOs4BDIHPrNuEUosS5TZ27rCzuX1iLvh/RLgAGqOA VBosqReGxbYwr77KE/BMz+Z5sX7U9RhqHExFDtFWM6Vx2wixhc1dLW0w6TlFVcto 1Ax5ZZyhgMk/3S3IXT6h02QrJqXQnVRvk2SxU+0RYGmGL9vCw0MoSTCjziwo4yGB 3CM2oMVt15QOOS7x4x9omb2tZg5MXR7HY1qd4gZXOAWSSVI9usoYNwj/NnIG1iw= =IqZ9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, Dec 29, 2014 at 7:13 AM, Ian Campbell i...@debian.org wrote: On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? A quick scan of the dtb's.. The microSD would be limited to 1.8v (3.3v removed), so users could find themselves with a broken boot if they booted am335x-boneblack on a classic bone. In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Officially by beagleboard.org they've always been called: BeagleBone : am335x-bone.dtb BeagleBone Black : am335x-boneblack.dtb Unofficially, the community started calling the original BeagleBone as the 'white' as the number of users with 'Black''s massively out number the 'white'... Confusion entailed.. There's also the blue oem version, which is just the black with a few oem changes, but uses the black's eeprom id... Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). The beaglebone's were not truly usable on mainline till v3.11-rc or so, due to the edma/dma engine changes needed to support the mmc interface. Regards, -- Robert Nelson http://www.rcn-ee.com/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772687: [Pkg-fonts-devel] Bug#772687: Bug#772687: Bug#772687: Bug#772687: fonts-droid: fallback font is installed too early to fontconfig
Norbert Preining prein...@logic.at writes:
On Mon, 29 Dec 2014, Vasudev Kamath wrote:
I've included mv_conffile change you suggested and changes
reflected back in git. And piuparts test shows no obsolete files left
back which is good :).
Hmm, did you rewrite the history of the git repo? Pulling into master
suddently gives merge conflicts?
Yeah I overwrote the history, not recommended but didn't wanted to
create multiple commits of related changes.
And, I *THINK* the version number in
debian/maintscript
is wrong... You put
1:4.4.4r2-6~
for the release that will be -5.
man dpkg-maintscript-helper tells me that
For example, for a conffile removed in version 2.0-1 of a pack‐
age, prior-version should be set to 2.0-1~. This will cause the
which would mean that we have to set it to
...-5~
But actually, we are renaming conffile in -6 so this should be -6~
right?. I re-read that paragraph
For example, for a conffile removed in version 2.0-1 of a package,
prior-version should be set to 2.0-1~.
We are droping -6 so it should be -6~ right? Or am I confusing it with
something else?.
The version is defined as:
prior-version
Defines the latest version of the package whose upgrade should
trigger the operation. It is important to calculate prior-ver‐
with -6~ we would mean that an
upgrade -5 - -6
would also trigger the action, right?
Cheers,
--
Vasudev Kamath
http://copyninja.info
Connect on ~friendica: copyni...@samsargika.copyninja.info
IRC nick: copyninja | vasudev {irc.oftc.net | irc.freenode.net}
GPG Key: C517 C25D E408 759D 98A4 C96B 6C8F 74AE 8770 0B7E
signature.asc
Description: PGP signature
Bug#773991: flash-kernel: Fails when mtdblock kernel module isn't loaded
On Mon, 2014-12-29 at 13:58 +, Ian Campbell wrote:
On Mon, 2014-12-29 at 14:50 +0100, Ben Hutchings wrote:
On Mon, 2014-12-29 at 13:24 +, Ian Campbell wrote:
On Fri, 2014-12-26 at 20:30 +0100, Uwe Kleine-König wrote:
I wonder if flash-kernel should be smart enough to
load the module itself.
I think it should.
I think all which is needed is to add modprobe -q mtdblock into the
mtdblock function. I believe anything which uses an mtdblock device
passes through that function to translate the name into a device node.
What do you think?
You also need 'udevadm settle' to wait for the device nodes to appear.
Good point, thanks.
Uwe, any chance you could try this please:
diff --git a/functions b/functions
index d45a4e6..a7ff6de 100644
--- a/functions
+++ b/functions
@@ -41,7 +41,11 @@ error() {
mtdblock() {
local mtdname=$1
- sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p $PROC_MTD
+ local dev=`sed -rn s,^mtd([^:]*).*\$mtdname\\$,/dev/mtdblock\\1,p
$PROC_MTD`
+
+ modprobe -q mtdblock udevadm settle --exit-if-exists=$dev || :
+
+ echo $dev
}
check_block_dev() {
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774136: Freeze exception request for gcompris 14.12
Hi FTP masters, The following upstream update to gcompris has been suggested, and after checking it seems to be to be good material, with extremely limited-scope code-level bugfixes (which could be filtered-out if we really want that, although I'd think it would be better to have them in as well). I'm thus requesting pre-approval for a 14.12 package. Details follow: On Mon, Dec 29, 2014 at 03:52:37PM +0530, shirish शिरीष wrote: Package: gcompris Version: 14.07-2 Severity: wishlist Dear Maintainer, I know we are in a freeze but can gcompris be upgraded/uploaded to 14.12 ? These are the fixes and translation updates as shared below :- I did a diff[1] between the 2 versions, and aside from translation updates, the diffs are really: * fixes in english messages and french wordlists * hangman.py changes which can probably be trusted to be the 1st fix in the changelog * tagging of some messages as translatable * a more elaborate fix for #769339, which gives compatibility with both old and new versions of tuxpaint (which also at last gives a nice message to the user when tuxpaint is not installed) * addition of Kannada language (included voices, which will create another binary package) For an educational app, it would be great to have this mostly-message update. Given the freeze, I would understand if the hangman and tuxpaint changes would not be accepted - but then, it'd be a bit of work to just bring eveything-but-those in 14.07. If the other updates are accepted but not those, I would rather revert those 2 changes from 14.12 (making it a 14.12~something). [1] diff -ru gcompris-14.07 gcompris-14.12 | filterdiff -x '*/Makefile.in' -x '*/debian/*' -x '*/po/*' Fixed Hangman to fit keyboards with many letters. (by Fòram na Gàidhlig) - Add of a set of Kannada word dataset file (by Shambu K) - Wordsgame: minor fixes for french wordlist (by Holger Kaelberer) - tuxpaint, added support for the new --fullscreen option (by Pere Pujal i Carabantes) - core, added kannada in the language selector (by Bruno Coudoin) - erase, made the square less transparent (by Bruno Coudoin) - scale, added missing translation (by Bruno Coudoin) - Updated kannada translation (by Shankar Prasad) - Updated Czech translation (by Marek Černocký) - Updated Brazilian Portuguese translation (by Enrico Nicoletto) - Updated Greek translation (by Yannis Kaskamanidis) - Updated Scottish Gaelic translation (by GNOME Translation Robot) - Updated Brazilian Portuguese translation (by Enrico Nicoletto) - Updated Swedish translation (by Anders Jonsson) - Updated Russian translation: (by Yuri Myasoedov) - Updated Czech translation (by Marek Černocký) - Updated Greek translation (by Yannis Kaskamanidis) - Finnish translation update (by Lasse Liehu) - Update Catalan translation (by Pau Iranzo) - Updated kannada translation (by Shambu K) - Updated Dutch translation gcompris Master (by Hannie Dumoleyn) - Updated Czech translation (by Marek Černocký) This was the changelog shared by Bruno Coudin on 23rd December 2014. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774152: libisofs6: null pointer dereference
Package: libisofs6 Version: 1.3.2-1.1 Usertags: afl xorriso crashes trying to read the attached ISO 9660 image: $ xorriso -signal_handling off -dev crash.iso -ls xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project. libisoburn: WARNING : ISO image size 311s larger than readable size 308s xorriso : NOTE : Loading ISO image tree from LBA 0 Segmentation fault The crash can be reproduced using the libisofs demo, so I assume the bug lies in the library itself. GDB says it's a null pointer dereference: Program received signal SIGSEGV, Segmentation fault. 0xf7e61a3e in iso_file_source_lstat (src=0x8261b00, info=0xd490) at libisofs/fsource.c:67 67 return src-class-lstat(src, info); (gdb) print src-class $1 = (const IsoFileSourceIface *) 0x0 (gdb) bt #0 0xf7e61a3e in iso_file_source_lstat (src=0x8261b00, info=0xd490) at libisofs/fsource.c:67 #1 0xf7e68042 in iso_image_import (image=0x804c070, src=0x804c600, opts=0x804c5d8, features=0xd548) at libisofs/fs_image.c:3578 #2 0xf7edaf0d in isoburn_read_image (d=0xf7dde300 drive_array, read_opts=0x804c4f0, image=0xd5ec) at libisoburn/isofs_wrap.c:301 #3 0xf7f3311e in Xorriso_aquire_drive (xorriso=0xf77a7008, adr=0x804ba30 crash.iso, show_adr=0x804ba30 crash.iso, flag=3) at xorriso/drive_mgt.c:533 #4 0xf7f17679 in Xorriso_option_dev (xorriso=0xf77a7008, in_adr=0x804ba30 crash.iso, flag=3) at xorriso/opts_d_h.c:116 #5 0xf7f0a80c in Xorriso_interpreter (xorriso=0xf77a7008, argc=6, argv=0x804b9c0, idx=0xd79c, flag=2) at xorriso/parse_exec.c:1185 #6 0x08048b1f in main (argc=6, argv=0x804b9c0) at xorriso/xorriso_main.c:265 This bug was found using American fuzzy lop: https://packages.debian.org/experimental/afl Disclaimer: I don't have spare CPU cycles, so I fuzzed only till the first crash (which took a few minutes). It's likely that extensive fuzzing would uncover more interesting crashers. I'd encourage libisofs maintainers to perform fuzzing with AFL on their own. :-) -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (990, 'unstable'), (500, 'experimental') Architecture: i386 (x86_64) Foreign Architectures: amd64 Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=C, LC_CTYPE=pl_PL.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages libisofs6 depends on: ii libacl1 2.2.52-2 ii libc62.19-13 ii libjte1 1.20-1 ii zlib1g 1:1.2.8.dfsg-2+b1 -- Jakub Wilk crash.iso.xz Description: application/xz
Bug#291951: closed by Ola Lundqvist o...@inguza.com (Solved by latest upload)
On Sun, Dec 28, 2014 at 2:03 PM, Ola Lundqvist o...@inguza.com wrote: No. I can not see that emacs snapshot is part of any debian version. I could of course have tested emacs24 but I still run wheezy here. I see… We need bugs to be tested against Debian/sid + recent Emacs version. -- Cyril Bouthors - go-managed.com http://www.go-managed.com/ - +33-184-161-617 +1-347-294-7146 https://www.linkedin.com/in/cyrilbouthors
Bug#774104: failed installation of Debian 7.7.0
Hi Holger - Good idea; seemed hopeful. But I cannot get to the command line to add /etc/modprobe.d/disable-nouveau.conf with the recommended option for nouveau modeset. I appreciate your help, but will return to Ubuntu 14.04. It gives me an acceptable user interface that I can use to move ahead, even though it doesn't flawlessly handle the 2880 x 1620 display resolution on my ThinkPad W540. Thanks very much for your help. Gary On 2014-12-28 15:12, Holger Wansing wrote: Hi, g...@garymlewis.com wrote: Then this: [drm] nouveau :01:00.0: 0x9576i Init table command not found: 0xA9 5. Boot hung at this point. A manual power-off followed by another boot also hung at the same point. Seems similar to this one: https://lists.debian.org/debian-boot/2014/12/msg00071.html Please let us know, if the solution provided there works for you, too. Greetings Holger -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774153: wheezy-jessie: systemd-tty-ask-password-agent hung
Package: systemd Version: 215-8 Hallo I tried to upgrade from wheezy to jessie but had problems because the install hung several times e.g. when upgrading snmpd and cups. The last program in the process tree always was systemd-tty-ask-password-agent. I tried it on xterm as well as on plain tty1 console but never got any prompt for a password nor could I understand why a password query would be needed. chammers@sys-251:~$ ps faxu USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND ... chammers 18501 0.0 0.0 7360 5092 pts/1Ss 15:33 0:00 \_ /bin/bash root 20804 0.0 0.0 6240 3176 pts/1S15:33 0:00 | \_ su root 20815 0.0 0.0 5652 3432 pts/1S15:33 0:00 | \_ bash root 23011 0.1 0.3 37896 30564 pts/1S+ 15:34 0:00 | \_ apt-get -f install root 32120 0.0 0.4 40716 37648 pts/4Ss+ 15:37 0:00 | \_ /usr/bin/dpkg --status-fd 36 --force-depends --force-remove-essential --remove printer-driver-gutenprint:i386 cups:i386 libgtk2.0-dev:i386 libpango1.0- root 32121 0.0 0.0 2240 592 pts/4S+ 15:37 0:00 | \_ /bin/sh /var/lib/dpkg/info/printer-driver-gutenprint.postrm remove root 32122 0.0 0.0 2240 1528 pts/4S+ 15:37 0:00 | \_ /bin/sh /usr/sbin/invoke-rc.d cups force-reload root 32139 0.0 0.0 2240 1560 pts/4S+ 15:37 0:00 | \_ /bin/sh /etc/init.d/cups force-reload root 32160 0.0 0.0 6640 2832 pts/4S+ 15:37 0:00 | \_ /bin/systemctl force-reload cups.service root 32161 0.0 0.0 2952 1532 pts/4S+ 15:37 0:00 | \_ /bin/systemd-tty-ask-password-agent --watch chammers@sys-251:~$ date Mo 29. Dez 15:41:18 CET 2014 My upgrade attempts were as follows: * booted wheezy with linux-image-3.16-bpo into console mode as nvidia drivers were not found * added wheezy to /etc/apt/sources.list, updated and installed just the new kernel. Rebootet again into console mode. * Tried upgrading only xserver-xorg-driver-nvidia but as that had too many dependencies, went for apt-get upgrade. * Encountered the systemd-tty-ask-password-agent problem. * Managed to get X11+KDE running again and tried apt-get upgrade on xterm (konsole program). Encounred same system-tty-ask-password-agent problem again, this time on package snmpd. I temporarily solved the hanging process using killall -9 systemctl several times quickly after another. Did not yet finish the installation process... tschüss, -christian- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772687: [Pkg-fonts-devel] Bug#772687: Bug#772687: Bug#772687: Bug#772687: Bug#772687: fonts-droid: fallback font is installed too early to fontconfig
Quoting Vasudev Kamath (2014-12-29 07:13:34) Norbert Preining prein...@logic.at writes: On Sun, 28 Dec 2014, Vasudev Kamath wrote: I've prepared the package and updated maintscript file to handle now obsolete 65-droid-sans-fallback.conf file removal. Hmm, something is funny here ... building the package I see: for f in DroidSansFallback.ttf DroidSansFallbackLegacy.ttf ; \ do \ cd debian/fonts-droid/usr/share ; \ mv fonts/truetype/droid/$f \ fonts-droid/truetype/$f || true ; \ done /bin/sh: 3: cd: can't cd to debian/fonts-droid/usr/share but stil the fonts end up in /usr/share/fonts-droid/truetype/ ... One of you will know why ... It looks like Christian introduced these changes to close the bug#762296, I think the error message comes second time when the cd is executed in for loop. It still works because with first cd we are already inside the directory where fonts are present. The fix is move the cd outside the for loop. I'm not sure if we have to include this now or wait for after Jessie. Another fix would be to use non-relative path in the cd call. But (judging only from above comments) there might be another issue with that loop not handling errors correctly. Perhaps as simple as a set -e (although I seem to recall that maintainer scripts shouldn't blindly do that). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#774153: wheezy-jessie: systemd-tty-ask-password-agent hung
control: tags -1 moreinfo Am 29.12.2014 um 15:57 schrieb Christian Brunotte: Package: systemd Version: 215-8 Hallo I tried to upgrade from wheezy to jessie but had problems because the install hung several times e.g. when upgrading snmpd and cups. Are you running systemd as PID 1 while doing the upgrade? Which version of systemd did you have installed? Can you provide a journal log (ideally, boot with systemd.log_level=debug) when doing the dist-upgrade -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
Bug#767261: xen-netback changes in #767261 break Mini-OS netfront
On Mon, 2014-12-29 at 12:56 +, Ian Campbell wrote: Should I reopen #767261 or file a new bug for this? A new bug would be best please. Actually, no need for this, I've applied the fixes locally and am just building them before pushing. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773971: Update: Danish hunspell dictionary version 2.2 - 2014-12-22
On Fri, Dec 26, 2014 at 11:42:25AM +, Esben Aaberg wrote: We have just released version 2.2 of the danish hunspell dictionary, you are currently shipping version 1.6. in hunspell-da (1:3.3.0-4) And this won't change as long as this one's built out of a collection, most probably (here: openoffice.org-dictonaries) The new dic- and aff-file can be found in the “zip-file” dict-da-2.2.oxt located here: http://extensions.libreoffice.org/extension-center/stavekontrolden-danish-dictionary Please update your packet at your convenience. There's work in progress to create a libreoffice-dictionaries but that would simply ship what LibreOffice includes. (Cc'ed) Might that be uptodate or not. Best would be to find someone who packages it directly. Ideally from the source and not from a binary (.oxt) with a proper build system. Regards, Rene -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
Hi, On Mon, Dec 29, 2014 at 02:29:19PM +0200, Markus Lehtonen wrote: The pq-rpm unit tests utilize many refs (refs/gbp-test*/*) from the submodule repository. The problem probably is that my testdata repo was in inconsistent state at the time you ran git-submodule update and some refs in your local copy are out-of-date. Re-running git-submodule update now Ah, that explains it. In that case it would probably be better to have all refs in the history of the current referenced HEAD this would allow to create the refs on the fly after the git submodule update. If fetch all remote refs and the tests pass now. Cheers, -- Guido -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#771215: git-buildpackage: please merge support for gbp pq-rpm
On Mon, Dec 29, 2014 at 02:29:19PM +0200, Markus Lehtonen wrote: The pq-rpm unit tests utilize many refs (refs/gbp-test*/*) from the submodule repository. The problem probably is that my testdata repo was in inconsistent state at the time you ran git-submodule update and some refs in your local copy are out-of-date. Re-running git-submodule update now won't fetch them as the submodule HEAD is already up-to-date. Try doing git submodule foreach git fetch origin and re-running the tests. I didn't want to clone/fetch from the remote repo inside the tests in order to not depend on network connection. Thanks, Markus -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746109: (no subject)
I was able to build the package according to the suggested fix from bug #745969 (thx Edmund). Thanks for considering the attached patch. Erwan. diff -Naur a/tokens.h b/tokens.h --- a/tokens.h 2014-12-29 16:18:19.442013464 +0100 +++ b/tokens.h 2014-12-29 16:26:12.782018555 +0100 @@ -93,7 +93,6 @@ extern int clex_lineno; extern FILE * yycin; extern char * yyctext; -extern int yycleng; extern int yyclength, yycsize; extern char * yyccomment; @@ -104,7 +103,6 @@ extern int plex_lineno; extern FILE * yypin; extern char * yyptext; -extern int yypleng; extern char * yypcomment; extern int yyplex(void); @@ -114,7 +112,6 @@ extern int perllex_lineno; extern FILE * yyperlin; extern char * yyperltext; -extern int yyperlleng; extern char * yyperlcomment; extern int yyperllex(void); @@ -123,7 +120,6 @@ extern int phplex_lineno; extern FILE * yyphpin; extern char * yyphptext; -extern int yyphpleng; extern char * yyphpcomment; extern int yyphplex(void); @@ -132,7 +128,6 @@ extern int rubylex_lineno; extern FILE * yyrubyin; extern char * yyrubytext; -extern int yyrubyleng; extern char * yyrubycomment; extern int yyrubylex(void);;
Bug#772953: Enable several Kconfigs to support OMAP5432 uEVM devboard
On Fri, 2014-12-26 at 18:43 +0800, Chen Baozi wrote: On Tue, Dec 23, 2014 at 7:44 PM, Ian Campbell i...@debian.org wrote: On Tue, 2014-12-23 at 16:27 +0800, Chen Baozi wrote: I have a glance at the kernel’s installer configs and tried the netboot without any modification. Some work should be done to make debian-installer support OMAP5 uEVM (e.g., ethernet driver etc). Right, those should be listed in e.g. debian/installer/armhf/modules/armhf-armmp/nic-modules. By waiting the kernel building with some initial attempted configs added, just one question to ask. I looked through the debian/installer/armhf/modules/armhf-armmp/, but it looks like none of files is about regulator modules. However, according to my previous experience, missing regulator driver modules is the main reason that the old debian kernel doesn’t support OMAP5 uEVM. How does debian-installer deal with this situation (if it does need extra regulator drivers included?) Long term its a bit of an open question what we do wrt modules such as regulators, clocks, pinctrl etc. So far we have been a bit lucky: either such things are so central to the platform that it is acceptable (at least for now) to just build them into the main kernel binary by making them =y (e.g. CONFIG_I2C_S3C2410 which is for the main power controller on arndale) or they are closely associated with some particular device and it makes sense to put them in that udeb (e.g. phy-exynos5250-sata in sata-modules, or phy-sun4i-usb in usb-modules). Eventually I expect that we will end up creating separate udebs for these things, but I'm hoping that we can defer that until at least Stretch to avoid needing to mess around with any more new packages for Jessie. If uEVM has some module which either shouldn't be built in or isn't obviously associated with a particular device let us know what it is and we can have a think about how best to approach it. One thing I've played with, and I'm not sure if this is acceptable or not, is to put core drivers which aren't =y into the kernel-image udeb itself. I'm not really sure if that's a good idea, we don't currently do this for anything AFAIK, but it's perhaps an option. With the attached patch applied, debian installer (tested with network-console) can support OMAP5's ethernet driver and external MicroSD card. Note that I added related regulator phy entries to files that mainly writes the modules which use them, since there is no file dedicated to those modules. Here is what I went with (am build testing now, will push to svn once done): commit e05093889458a806352d3e281b2f20db098925fb Author: Ian Campbell i...@debian.org Date: Mon Dec 29 14:36:47 2014 + Updates to udebs for OMAP5432 uEVM support. Based on a patch from Chen Baozi. Added pbias-regulator to mmc-modules and ohci-omap3, ehci-omap and phy-omap-usb2 to usb-modules (dwc3-omap was already present). Enabled CONFIG_REGULATOR_PALMAS and CONFIG_TI_PIPE3 as builtin since they are used by multiple subsystems. diff --git a/debian/config/armhf/config.armmp b/debian/config/armhf/config.armmp index 8781e59..62e512f 100644 --- a/debian/config/armhf/config.armmp +++ b/debian/config/armhf/config.armmp @@ -579,7 +579,7 @@ CONFIG_PCI_MVEBU=y ## CONFIG_OMAP_CONTROL_PHY=m CONFIG_OMAP_USB2=m -CONFIG_TI_PIPE3=m +CONFIG_TI_PIPE3=y CONFIG_TWL4030_USB=m CONFIG_PHY_EXYNOS5250_SATA=m CONFIG_PHY_SUN4I_USB=m @@ -638,7 +638,7 @@ CONFIG_REGULATOR_TWL4030=y CONFIG_REGULATOR_VEXPRESS=m CONFIG_REGULATOR_PBIAS=m CONFIG_REGULATOR_TI_ABB=m -CONFIG_REGULATOR_PALMAS=m +CONFIG_REGULATOR_PALMAS=y ## ## file: drivers/rtc/Kconfig diff --git a/debian/installer/armhf/modules/armhf-armmp/mmc-modules b/debian/installer/armhf/modules/armhf-armmp/mmc-modules index 5718bd2..6ebd458 100644 --- a/debian/installer/armhf/modules/armhf-armmp/mmc-modules +++ b/debian/installer/armhf/modules/armhf-armmp/mmc-modules @@ -4,3 +4,4 @@ mmci omap_hsmmc sunxi-mmc dw_mmc-exynos +pbias-regulator diff --git a/debian/installer/armhf/modules/armhf-armmp/usb-modules b/debian/installer/armhf/modules/armhf-armmp/usb-modules index 0828c55..f00b24f 100644 --- a/debian/installer/armhf/modules/armhf-armmp/usb-modules +++ b/debian/installer/armhf/modules/armhf-armmp/usb-modules @@ -3,7 +3,10 @@ phy-sun4i-usb dwc3-exynos dwc3-omap ohci-exynos +ohci-omap3 ehci-exynos +ehci-omap phy-exynos-usb2 +phy-omap-usb2 ci_hdrc_imx phy-mxs-usb Baozi. --- diff -Nru linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules --- linux-3.16.7/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-09-21 20:04:21.0 + +++ linux-3.16.7-ckt2/debian/installer/armhf/modules/armhf-armmp/mmc-modules 2014-12-26 03:16:02.0 + @@ -4,3 +4,5 @@ omap_hsmmc sunxi-mmc dw_mmc-exynos +pbias-regulator
Bug#773890: flash-kernel: No entry for BeagleBone Black when running 3.18 kernel
On Mon, 2014-12-29 at 08:41 -0600, Robert Nelson wrote: On Mon, Dec 29, 2014 at 7:13 AM, Ian Campbell i...@debian.org wrote: On Sun, 2014-12-28 at 20:00 -0800, Vagrant Cascadian wrote: On 2014-12-28, Robert Nelson wrote: On Sun, Dec 28, 2014 at 6:26 PM, Vagrant Cascadian vagr...@debian.org wrote: On 2014-12-28, Ian Campbell wrote: OOI, do you know how broken the white is when booting with the black's DTB? Completely unusable, missing some minor peripheral or somewhere in the middle? ... Oh you definitely don't want to run the wrong *.dtb on the black/white.. Is it dangerous both way around or only dangerous to boot the black dtb on the white? A quick scan of the dtb's.. The microSD would be limited to 1.8v (3.3v removed), so users could find themselves with a broken boot if they booted am335x-boneblack on a classic bone. I'm not as worried about boot failures as I am about setting fire to the board. As I understand it: Booting with am335x-boneblack.dtb on a Beaglebone White = Might fail to boot Booting with am335x-bone.dtb on a Beaglebone Black = Might destroy the HDMI controller So if we are going to err one way or another then always using boneblack dtb is the safe option of the two. Which conveniently fits in with the fact that we so far only support the Black, and it's the one everyone has anyway. Given all that I think it would be acceptable given the freeze etc to just add the new name for the Black to the existing stanza. In u-boot the findfdt function will correctly set the fdtfile variable. http://git.denx.de/?p=u-boot.git;a=blob;f=include/configs/am335x_evm.h;hb=HEAD#l176 Notice: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-boneblack.dts?id=2ba3549352277514a8e4790adff77a783ee1b9e2 IMPORTANT: booting the existing am335x-bone.dts will blow up the HDMI transceiver after a dozen boots with an uSD card inserted because LDO will be at 3.3V instead of 1.8. Also the 'white' uses DDR2, while the 'black uses DDR3 Is white==am335x-bone.dts or is there a third unsuffixed variant too? (I think the answer is no, but I'm not sure). I'm wondering if we should try to upstream a patch to make the white also unambiguously identify itself as such, by adding White to the model and the dts name. Officially by beagleboard.org they've always been called: BeagleBone : am335x-bone.dtb BeagleBone Black : am335x-boneblack.dtb Unofficially, the community started calling the original BeagleBone as the 'white' as the number of users with 'Black''s massively out number the 'white'... Confusion entailed.. OK, so probably trying to make any changes at all would only make things worse... There's also the blue oem version, which is just the black with a few oem changes, but uses the black's eeprom id... Did we support Beaglebone* in Wheezy or is it all new in Jessie (IOW to what extent can we fudge the upgrade path and just rip the plaster off now). The beaglebone's were not truly usable on mainline till v3.11-rc or so, due to the edma/dma engine changes needed to support the mmc interface. OK, so we are only dealing with people running testing/sid and not stable upgrades, which gives us some more options if we are really stuck, but from the sounds of it we aren't really. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767261: xen-netback changes in #767261 break Mini-OS netfront
i...@debian.org said: On Mon, 2014-12-29 at 12:56 +, Ian Campbell wrote: Should I reopen #767261 or file a new bug for this? A new bug would be best please. Actually, no need for this, I've applied the fixes locally and am just building them before pushing. Thanks. I can test the packages once they're ready. Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
