Bug#782642: moc: when resized moc displays terminal's too smal when it's not
forwarded 782642 mocma...@daper.net
thanks
* Sébastien Poher sb...@volted.net [2015-04-15 16:08 +0200]:
Package: moc
Version: 1:2.5.0-1
Severity: minor
Tags: patch
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
When moc is resized, for example when using a tilling window manager, it
dislays terminal's too small while the terminal size is still big enough to
display moc correctly.
I think that the threshold of lines and columns size is too high so I changed
them. With this values I got the terminal's too small mention only when it
gets really too small.
[...]
Forwarded upstream.
*** /home/sogal/moc_interfaces_elements.c.diff
--- interface_elements.c.orig 2015-04-15 15:40:16.594245182 +0200
+++ interface_elements.c2015-04-15 15:44:57.574249398 +0200
@@ -2529,7 +2529,7 @@
/* End the program if the terminal is too small. */
static void check_term_size (struct main_win *mw, struct info_win *iw)
{
- mw-too_small = iw-too_small = COLS 59 || LINES 7;
+ mw-too_small = iw-too_small = COLS 30 || LINES 5;
}
/* Update the title with the current fill. */
@@ -2770,7 +2770,7 @@
bar_set_title (w-mixer_bar, name);
if (!w-in_entry !w-too_small) {
- bar_draw (w-mixer_bar, w-win, COLS - 37, 0);
+ bar_draw (w-mixer_bar, w-win, COLS - 27, 0);
info_win_update_curs (w);
}
}
@@ -3085,7 +3085,7 @@
bar_set_fill (w-mixer_bar, (double) value);
if (!w-in_entry !w-too_small)
- bar_draw (w-mixer_bar, w-win, COLS - 37, 0);
+ bar_draw (w-mixer_bar, w-win, COLS - 27, 0);
}
/* Draw a switch that is turned on or off in form of [TITLE]. */
@@ -3398,7 +3398,7 @@
lines.ltee, lines.rtee, lines.llcorn,
lines.lrcorn);
/* mixer frame */
- mvwaddch (w-win, 0, COLS - 38, lines.rtee);
+ mvwaddch (w-win, 0, COLS - 28, lines.rtee);
mvwaddch (w-win, 0, COLS - 17, lines.ltee);
/* playlist time frame */
@@ -3448,7 +3448,7 @@
if (w-in_entry)
entry_draw (w-entry, w-win, 1, 0);
else
- bar_draw (w-mixer_bar, w-win, COLS - 37, 0);
+ bar_draw (w-mixer_bar, w-win, COLS - 27, 0);
--
Talking much about oneself can also
be a means to conceal oneself.
-Friedrich Nietzsche
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782875: Should be fixed in Jessie if possible
BTW, as this is a simple fix I'd like to request that this be fixed in Jessie as it is an important part of the package.
Bug#741412: exim4: process crashed with signal 11 while delivering
On Thu, Mar 13, 2014 at 09:30:53AM +0100, Marc Haber wrote: tags #741412 unreproducible moreinfo thanks On Wed, Mar 12, 2014 at 10:43:14AM +0100, Leszek Dubiel wrote: After upgradading debian to woody I started to get exim crashed for some emails (a few emails for few thousand deliveries). Woody has been out of support for, IIRC, ten years. That being said, signal 11 errors usually indicate faulty hardware, most probably bad RAM or a bad CPU. Please check with memtest or other tools. I'm seeing something similar just after upgrading to jessie on an i386 system: 2015-04-19 11:34:32 1YjmYa-0004me-9S = d...@larted.org.uk U=dom P=local S=357 2015-04-19 11:34:33 1YjmYa-0004me-9S == d...@larted.org.uk d...@thyone.larted.org.uk R=smarthost T=remote_smtp_smarthost defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11 2015-04-19 11:34:33 1YjmYb-0004mk-2e = R=1YjmYa-0004me-9S U=Debian-exim P=local S=668 2015-04-19 11:34:33 1YjmYa-0004me-9S Frozen 2015-04-19 11:34:33 1YjmYb-0004mk-2e == d...@larted.org.uk postmas...@thyone.larted.org.uk R=smarthost T=remote_smtp_smarthost defer (-1): smtp transport process returned non-zero status 0x000b: terminated by signal 11 2015-04-19 11:34:33 1YjmYb-0004mk-2e Frozen What's interesting is that the messages are delivered anyway (okay, and not logged or noticed as such because of the crash), however when the queue is thawed, the messages aren't delivered as expected: 2015-04-19 11:43:53 Start queue run: pid=19664 -qff 2015-04-19 11:43:53 1YjmYa-0004me-9S Unfrozen by forced delivery 2015-04-19 11:43:53 1YjmYa-0004me-9S Completed 2015-04-19 11:43:53 1YjmYb-0004mk-2e Unfrozen by forced delivery 2015-04-19 11:43:53 1YjmYb-0004mk-2e Completed 2015-04-19 11:43:53 End queue run: pid=19664 -qff So I wonder if there is a secondary bug here, since in the second set of logs the messages which were on the queue simply disappear without trace. There is a clue about the underlying cause of the crash here: Apr 19 11:34:33 thyone kernel: [73206.710071] exim4[18397]: segfault at be50a32d ip b72ab614 sp bfa30430 error 6 in libgnutls-deb0.so.28.41.0[b71f7000+13a000] Apr 19 11:34:33 thyone kernel: [73207.469822] exim4[18403]: segfault at 96f9278d ip b72ea614 sp bfdc50d0 error 6 in libgnutls-deb0.so.28.41.0[b7236000+13a000] I will run memtest on this system overnight. In the meantime I've avoided this problem by disabling TLS, which makes me sad. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#779974: josm: invalid certificate
Hi Salvo, On 04/14/2015 12:53 AM, Sebastiaan Couwenberg wrote: On 04/13/2015 09:01 PM, Salvo Tomaselli wrote: On a Debian unstable VM without customizations the cacerts file is 207196, about half the size of my Debian unstable workstation, but still significantly larger than yours. Try reconfiguring the ca-certificates package and enable at least the COMODO/Comodo certificates because those are used for *.tile.openstreetmap.org: I only have Mozilla/Comodo, no COMODO/Comodo. And they were already enabled. Most entries start with mozilla/, I only meant the two different capitalizations of the name. It seems I have some weird certificate problem. Perhaps I should just try to reinstall the package? Reinstalling the ca-certificates package shouldn't hurt to try. Can you also check the contents of your keystore? keytool -v -list -keystore /etc/ssl/certs/java/cacerts \ -storepass changeit | less You should have an entry with an alias like equifax_secure_ca with: Certificate fingerprint (SHA1): D2:32:09:AD:23:D3:14:23:21:74:E4:0D:7F:9D:62:13:97:86:63:3A This is the root CA for the OSM tile server SSL certificate chain. Can you confirm that you've reinstalled the ca-certificates package? And can you also send the output for the keytool command? Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#759657: console-setup: suggested fix seems to work
Package: console-setup Version: 1.122 Followup-For: Bug #759657 Out-of-band I received the suggestion to create /etc/systemd/system/console-setup.service.d/wait4udev.conf with the content [Unit] Wants=systemd-udev-settle.service After=systemd-udev-settle.service which delays running console-setup.service until after udev has settled thereby making sure loading the video driver and setting the final video mode has completed before console-setup.service is run. With this fix I have not been able to provoke the forgotten setup problem anymore in about ten soft and cold reboots. Karsten -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages console-setup depends on: ii console-setup-linux 1.122 ii debconf 1.5.56 ii keyboard-configuration 1.122 ii xkb-data2.12-1 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales2.19-18 ii locales-all [locales] 2.19-18 ii lsb-base 4.1+Debian13+nmu1 Versions of packages keyboard-configuration depends on: ii debconf 1.5.56 ii initscripts 2.88dsf-59 ii liblocale-gettext-perl 1.05-8+b1 Versions of packages console-setup-linux depends on: ii kbd 1.15.5-2 ii keyboard-configuration 1.122 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common none pn console-datanone pn console-tools none ii kbd 1.15.5-2 -- debconf information: console-setup/fontsize-text47: 8x16 keyboard-configuration/switch: No temporary switch keyboard-configuration/xkb-keymap: de(nodeadkeys) * console-setup/charmap47: UTF-8 keyboard-configuration/layoutcode: de * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages keyboard-configuration/layout: keyboard-configuration/altgr: The default for the keyboard layout keyboard-configuration/store_defaults_in_debconf_db: true keyboard-configuration/toggle: No toggling console-setup/fontsize: 8x16 keyboard-configuration/unsupported_layout: true keyboard-configuration/variant: Deutsch - Deutsch (ohne Akzenttasten) debian-installer/console-setup-udeb/title: console-setup/codesetcode: Lat15 keyboard-configuration/ctrl_alt_bksp: false console-setup/use_system_font: keyboard-configuration/unsupported_options: true keyboard-configuration/unsupported_config_options: true * console-setup/fontface47: Terminus keyboard-configuration/compose: No compose key console-setup/store_defaults_in_debconf_db: true console-setup/framebuffer_only: keyboard-configuration/other: keyboard-configuration/variantcode: nodeadkeys * console-setup/fontsize-fb47: 8x16 console-setup/guess_font: keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl) keyboard-configuration/optionscode: keyboard-configuration/unsupported_config_layout: true keyboard-configuration/modelcode: pc105 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: dots in maildir names
Hi Mark and Oswald,
I was wondering if there was a solution found for the problem you described,
ie. a solution accepted and integrated by Oswald.
I've been using mbsync for quite a long time, and I had a patch since version
1.0.4 for this dots (I hesitate to talk about issue as Maildir++ format requires
them).
Anyway, if there is a solution I'll hapily use it. If not, for a reference I'm
using the patch in [1] upon isync 1.1.1, which adds a DropDots option to
maildir store.
Cheers.
--
Robert
[1] RJK's Patch
diff -ru isync-1.1.1_prerjk/src/drv_maildir.c isync-1.1.1/src/drv_maildir.c
--- isync-1.1.1_prerjk/src/drv_maildir.c2015-04-17 20:37:09.485528699
+0200
+++ isync-1.1.1/src/drv_maildir.c 2015-04-19 11:56:04.481529784 +0200
@@ -54,6 +54,8 @@
typedef struct maildir_store_conf {
store_conf_t gen;
char *inbox;
+ char *root_path;
+ int drop_dot;
#ifdef USE_DB
int alt_map;
#endif /* USE_DB */
@@ -99,11 +101,12 @@
}
static char *
-maildir_join_path( const char *prefix, const char *box )
+maildir_join_path(maildir_store_t *ctx, const char *prefix, const char *box )
{
char *out, *p;
int pl, bl, n;
char c;
+ maildir_store_conf_t *conf = (maildir_store_conf_t *)ctx-gen.conf;
pl = strlen( prefix );
for (bl = 0, n = 0; (c = box[bl]); bl++)
@@ -114,7 +117,7 @@
p = out + pl;
while ((c = *box++)) {
*p++ = c;
- if (c == '/')
+ if ((c == '/') !conf-drop_dot)
*p++ = '.';
}
*p = 0;
@@ -137,7 +140,7 @@
ctx-gen.conf = conf;
ctx-uvfd = -1;
if (conf-trash)
- ctx-trash = maildir_join_path( conf-path, conf-trash );
+ ctx-trash = maildir_join_path( ctx, conf-path, conf-trash );
cb( ctx-gen, aux );
}
@@ -199,6 +202,7 @@
int pl, nl, missing;
struct dirent *de;
struct stat st;
+ maildir_store_conf_t *conf = (maildir_store_conf_t *)gctx-conf;
if (isBox) {
path[pathLen++] = '/';
@@ -224,12 +228,13 @@
return -1;
}
} else {
- if (*ent == '.') {
- if (!isBox)
+ if ((*ent == '.') || (de-d_type DT_DIR)) {
+ if (!isBox !conf-drop_dot)
continue;
if (!ent[1] || ent[1] == '.')
continue;
- ent++;
+ if (!conf-drop_dot)
+ ent++;
} else {
if (isBox)
continue;
@@ -321,16 +326,20 @@
struct dirent *entry;
char *p;
time_t now;
- int i, bl, ret;
+ int i, bl, ret, is_root;
struct stat st;
char buf[_POSIX_PATH_MAX];
+ maildir_store_conf_t *conf = (maildir_store_conf_t *)ctx-gen.conf;
bl = nfsnprintf( buf, sizeof(buf) - 4, %s/, box );
+ is_root = !strcmp(conf-root_path, box);
+ if (is_root)
+ return 0;
if (stat( buf, st )) {
if (errno == ENOENT) {
if (create) {
p = memrchr( buf, '/', bl - 1 );
- if (*(p + 1) == '.') {
+ if (conf-drop_dot || (*(p + 1) == '.')) {
*p = 0;
if ((ret = maildir_validate( buf, 1,
ctx )) != DRV_OK)
return ret;
@@ -669,7 +678,7 @@
return DRV_BOX_BAD;
}
while ((e = readdir( d ))) {
- if (*e-d_name == '.')
+ if ((*e-d_name == '.') || (e-d_type DT_DIR))
continue;
ctx-gen.count++;
ctx-gen.recent += i;
@@ -917,8 +926,8 @@
#endif /* USE_DB */
gctx-path =
(!memcmp( gctx-name, INBOX, 5 ) (!gctx-name[5] ||
gctx-name[5] == '/')) ?
- maildir_join_path( ((maildir_store_conf_t
*)gctx-conf)-inbox, gctx-name + 5 ) :
- maildir_join_path( gctx-conf-path, gctx-name );
+ maildir_join_path( ctx, ((maildir_store_conf_t
*)gctx-conf)-inbox, gctx-name + 5 ) :
+ maildir_join_path( ctx, gctx-conf-path, gctx-name );
if ((ret = maildir_validate( gctx-path, create, ctx )) != DRV_OK) {
cb( ret, aux );
@@ -1458,12 +1467,18 @@
while (getcline( cfg ) cfg-cmd)
if (!strcasecmp( Inbox, cfg-cmd ))
Bug#782486: cross-distribution and upstream data
Hi Iain, My own feeling about this is that it is better to try and encourage each distribution to render their data using some standard formats, such as iCalendar and then there are multiple options available for using the data: a) use productivity tools such as Mozilla Lightning or GNOME Evolution to aggregate and render the data into a to-do list for a developer b) build reporting tools similar to UDD that are independent of any specific distribution, to scrape data from the distributions and from other sources like the Github API, upstream bugzilla instances, etc The benefit of this strategy is that it is more modular and people who are not involved with Debian may be more likely to contribute to a generic, high level solution. Putting too much in UDD may make it harder to maintain and keep in sync with the other distributions. Some other comments on the topic: - you can already use the iCalendar format to see a combined bug list from Debian bug tracker, Github issue list and Fedora bugzilla: http://danielpocock.com/debian-maintainer-dashboard-now-provides-icalendar-feeds - I've had applications from two GSoC students willing to work on some related concepts, having an additional mentor for this project would be really helpful. Details are here: https://wiki.debian.org/SummerOfCode2015/StudentApplications#Developer_Horizon_:_Dashboard - maybe upstreams can be encouraged to keep some metadata file in their tarballs and repositories that helps identify the relevant package names in each distribution? - maybe package maintainers could be offered some new field in debian/control that allows them to identify the corresponding Fedora packages? - extracting compiled library packages, it may be possible to identify SONAMEs and use that data to cross-reference package names - there are a couple of instances where I do think it is compelling for Debian UDD to pull data from non-Debian sources, e.g. knowing when there is a new upstream release, knowing about a security advisory and for some packages it is useful to know if the next release of Debian is carrying at least the same version of something that is in Fedora's next release. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782418: cwm: FTBFS on kfreebsd: kbfunc.c:327:18: error: 'HOST_NAME_MAX' undeclared
On Sat, Apr 18, 2015 at 08:37:00PM +0200, Jakub Wilk wrote: The patch itself looks good to me, but the patch header is no longer accurate. Fixed. -- James McDonald signature.asc Description: Digital signature
Bug#782396: sakura: Sakura running as x-terminal-emulator does not accept -T title option
Am Sonntag, den 19.04.2015, 00:57 -0400 schrieb Andrew Starr-Bochicchio: On Fri, Apr 17, 2015 at 2:03 PM, Tobias Frost t...@debian.org wrote: Checked with the release team, its too late. -- Will not upload this one. Hi Tobias, Thanks for the patch! As the release team has said it's too late, I'll try to get this accepted upstream and make an upload after the freeze. How did you contact the release team? I don't see a thread on debian-release or a bug against release.debian.org regarding this, and I'd like to keep the conversation together if possible. sakura has now been marked for removal from Jessie. I feel like this should probably get tagged as jessie-ignore, but as per https://www.debian.org/Bugs/Developer#tags only the release managers can do so. It was on IRC, #debian-release: 19:51 coldtobi Would be a oneline to fix #782396 acceptable still for an unblock? ( Patch is attached there) 19:51 -zwiebelbot:#debian-release- Debian#782396: sakura: Sakura running as x-terminal-emulator does not accept -T title option - https://bugs.debian.org/782396 19:51 nthykier coldtobi: Unless it is already in unstable and able to migrate tonight, then generally no 19:52 coldtobi nthykier: upload would be no problem, but it would need a hint to age faster. 19:52 nthykier Right, and that is the problem - the quiet period starts pretty much tonight 19:53 nthykier coldtobi: I would prefer deferring it to a point release if it is not a super-ultra-critical-blocker -- tobi signature.asc Description: This is a digitally signed message part
Bug#782849: debsources: latest openldap sources reported as woody
On Sat, Apr 18, 2015 at 09:15:15PM +0200, Helmut Grohne wrote: The reason is that the openldap version history is non-monotonic (even considering epochs). There was a time when openldap was maintained in openldap-X.Y and thus for a few releases there was no src:openldap. When reintroducing src:openldap a lower version was picked. This certainly is a corner case, but it would be nice if the latest would work nonetheless. Agreed. And thanks for this bug report. A proper, but really cumbersome, solution for this one would be introducing a table of version comparison overrides, keeping track of corner cases like this one. That would be quite gross though, and it's not even clear to me that we have a way to extract the information to feed it from the archive, short of adding entries one by one as soon as some user hit them. An easy workaround would be to sort first by release, and then by version, which would solve most occurrences of this problem, I think. Thoughts? -- Stefano Zacchiroli . . . . . . . z...@upsilon.cc . . . . o . . . o . o Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o Former Debian Project Leader . . @zack on identi.ca . . o o o . . . o . « the first rule of tautology club is the first rule of tautology club » signature.asc Description: Digital signature
Bug#782872: [Aptitude-devel] Bug#782872: aptitude: SIGSEGV got when create New Categorical Browser
Hi, (not the maintainer, I don't even have aptitude installled and have no idea what 'New Categorical Browser' means at the moment but still) On Sun, Apr 19, 2015 at 01:06:39PM +0800, Zhang Jingqiang wrote: When I try to get a New Categorical Browser from the curses menu, SYSSEGV happened. I install aptitude-dbg and run gdb aptitude, got the following output Program received signal SIGSEGV, Segmentation fault. __strcmp_sse2_unaligned () at ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S:30 30 ../sysdeps/x86_64/multiarch/strcmp-sse2-unaligned.S: No such file or directory. It's always reproducible on my laptop. Can you please run 'bt' (backtrace) in gdb as a strcmp call could (and is) everywhere in aptitude or deeper down in the stack. Does this happen 'for a while' now or did you find out about it only recently? Maybe only since an upgrade of x, y and z? That could be highly state dependent (especially if it isn't aptitude but libapt failing here) so I wanted to chirp in before this state is lost to an update/upgrade or something. Maybe make a backup of /var/lib/apt/ and /var/lib/dpkg/status somewhere, in case we find out the relevant state is dependent on those. No such bug found on my cubietruck. btw: Is cubietruck 'armhf' or 'armel'? Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#782837: [Pkg-xfce-devel] Bug#782837: xfce4-session: Fails to shutdown/reboot or logout.
On Sat, 18 Apr 2015 20:58:50 +0200 Yves-Alexis Perez cor...@debian.org wrote: Please keep the bug on CC:, this is not a support channel. On sam., 2015-04-18 at 23:30 +0500, Филипп Ð’Ð°Ñ ÑŒÐºÐ¸Ð½ wrote: Freshly installed OS. Today I installed Debian Jessie RC2 (base system), updated the system, installed the packages xserver-xorg, xfce4, xfce4-terminal, xfce4-notifyd, xfce4-xkb-plugin, gvfs, gvfs-backends, policykit-1-gnome and slim. This problem I was also able to reproduce on VirtualBox. Maybe I was missing some packages? My guess would be that slim doesn't correctly setup the session for you. It might be worth trying with lightdm and report back. Also, what loginctl gives you when logged in? Regards, -- Yves-Alexis The same with LightDM. Loginctl shows: With slim: $ loginctl SESSIONUID USER SEAT 1 1000 kron seat0 1 sessions listed. $ loginctl show-session 1 Id=1 Name=kron Timestamp=Вс 2015-04-19 11:52:37 YEKT TimestampMonotonic=16469650 VTNr=2 Display=:0.0 Remote=no RemoteUser=root Service=slim Scope=session-1.scope Leader=527 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 With lightdm: $ loginctl SESSIONUID USER SEAT c1105 lightdm seat0 1 1000 kron seat0 2 sessions listed. $ loginctl show-session c1 Id=c1 Name=lightdm Timestamp=Вс 2015-04-19 13:01:09 YEKT TimestampMonotonic=15356097 VTNr=7 Display=:0 Remote=no Service=lightdm-greeter Scope=session-c1.scope Leader=551 Audit=0 Type=x11 Class=greeter Active=no State=closing IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0 $ loginctl show-session 1 Id=1 Name=kron Timestamp=Вс 2015-04-19 13:01:16 YEKT TimestampMonotonic=22752779 VTNr=7 Display=:0 Remote=no Service=lightdm Scope=session-1.scope Leader=567 Audit=1 Type=x11 Class=user Active=yes State=active IdleHint=no IdleSinceHint=0 IdleSinceHintMonotonic=0
Bug#782874: nss: please package NSS version 3.18
Source: nss Severity: wishlist Hi there, the new Thunderbird (as known Icedove in Debian) version 38.0b2 has a package dependencie on libnss3-dev on version = 3.18. Please package the current libnss3 packages as this enables a possible packaging of Icedove 38.0~b2. Thanks! Regards Carsten -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: armhf Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782878: libscalar-defer-perl: libscalar-defer-perl: please make the build reproducible
Source: libscalar-defer-perl Version: 0.23-1 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 libscalar-defer-perl could not be built reproducibly. The attached patch removes extra timestamps from the build system and ensure a stable file order when creating the source archive. Once applied, libscalar-defer-perl can be built reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds Only in libscalar-defer-perl-0.23-new: blib diff -ur libscalar-defer-perl-0.23/debian/changelog libscalar-defer-perl-0.23-new/debian/changelog --- libscalar-defer-perl-0.23/debian/changelog 2015-04-19 10:59:01.0 + +++ libscalar-defer-perl-0.23-new/debian/changelog 2015-04-19 11:00:05.244377959 + @@ -1,3 +1,11 @@ +libscalar-defer-perl (0.23-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Set timestamp in manual page to last package change time from +changelog, to make builds reproducible. + + -- Jelmer Vernooij jel...@debian.org Sun, 19 Apr 2015 11:00:05 + + libscalar-defer-perl (0.23-1) unstable; urgency=low [ Jonathan Yu ] Only in libscalar-defer-perl-0.23-new/debian: files Only in libscalar-defer-perl-0.23-new/debian: libscalar-defer-perl Only in libscalar-defer-perl-0.23-new/debian: libscalar-defer-perl.debhelper.log Only in libscalar-defer-perl-0.23-new/debian: libscalar-defer-perl.substvars diff -ur libscalar-defer-perl-0.23/debian/rules libscalar-defer-perl-0.23-new/debian/rules --- libscalar-defer-perl-0.23/debian/rules 2015-04-19 10:59:01.0 + +++ libscalar-defer-perl-0.23-new/debian/rules 2015-04-19 10:59:38.911642206 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ Only in libscalar-defer-perl-0.23-new: Makefile Only in libscalar-defer-perl-0.23-new: MYMETA.json Only in libscalar-defer-perl-0.23-new: MYMETA.yml Only in libscalar-defer-perl-0.23-new: pm_to_blib signature.asc Description: Digital signature
Bug#782872: [Aptitude-devel] Bug#782872: Bug#782872: aptitude: SIGSEGV got when create New Categorical Browser
Control: forcemerge 686124 -1 Hi, Manuel A. Fernandez Montecelo wrote: 2015-04-19 09:06 David Kalnischkies: (not the maintainer, I don't even have aptitude installled and have no idea what 'New Categorical Browser' means at the moment but still) I think that this is a duplicate of this one, from 2012: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=686124 Yes, it it. The Categorial Browser has been replaced by the Debtags browser and is planned to be removed. We should _really_ remove it for the next release, at least from the menu. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782885: Abort when the device doesn't support the image format
Package: stopmotion Version: 0.8.0-4 As mentioned in another report, when I plug my old philips webcam, stopmotion starts without crashing and sees the device. But when I click on the icon to start/stop the device, the following appears in the console : Device doesn't support width/height There was no map allocated to be freed... Grab start process '/usr/bin/vgrabbj -f /home/jpuydt/.stopmotion/capturedfile.jpg -d /dev/video0 -b -D 0 -i vga -L250' returned code 256 and the program aborts! Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782887: release-notes: please add news from Debian Med to release notes
Package: release-notes Severity: normal Tags: patch Hi, please consider applying the attached patch to release notes. Thanks for your work for the Debian release Andreas. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash --- whats-new.dbk 2015-04-16 13:29:25.125753555 +0200 +++ whats-new.dbk_new 2015-04-17 11:14:56.085342463 +0200 @@ -542,6 +542,15 @@ ulink url=http://blends.debian.org/med/tasks;Debian Med tasks pages/ulink to see the full range of biological and medical software inside Debian. /para +section id=debian-science +titleNews from Debian Science Blend/title +paraDue to the continuous work of the Debian Science team not only new +scientific applications were added to the Debian package pool but also +applications from new fields of science are covered by certain applications. +Visit +ulink url=http://blends.debian.org/science/tasks;Debian Science tasks pages/ulink +to see the full range of scientific software inside Debian. +/para /section /section /chapter
Bug#780673: gitolite3: git-annex shell is not working: FATAL: bad git-annex-shell command - patch available
conc...@web.de writes: patch 780673 + jessie severity 780673 serious thanks I've just upgraded to Jessie and tried to download some data and now my repositories are broken and I cannot do anything with them. I only get get foo/bar (not available) Try making some of these repositories available: 52f2bae6-e67e-11e4-a474-0021ccb48233 (Note that these git remotes have annex-ignore set: origin) failed git-annex: get: 1 failed and it doesn't even want to work after I've applied the patch. New clones seem to work with the data which was already on the server but my other ones seem to be now broken and I have possible data loss. It seems more likely that the annex data is still there in the server repositories. You can check with % git annex findref HEAD as the gitolite user, in the gitolite server copy of the repository. Two things to check 1) Did you intend to have git.origin.annex-ignore set? this can happen if git-annex is convinced a remote is inaccessible (due to e.g. problems with git-annex-shell) 2) Do the annex uids match between .git/config in the local repo and the remote repo? You can check with git annex info in both places. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774300: base: modprobe radeon crashes latest jessie/testing
Control: severity -1 important Control: reassign -1 src:linux 3.16.7-ckt2-1 On Wed, Dec 31, 2014 at 13:57:38 +0100, Joerg Esser wrote: Package: base Severity: critical Justification: breaks the whole system Dear Maintainer, after modprobe readon the whole system crashes. No problems with old wheezy distro. On Wed, Dec 31, 2014 at 16:56:43 +0100, Jörg Esser wrote: Ok i found a solution I´ve added radeon.dpm=0 to the kernel boot options. This part from the radeon module has a problem. I see this is enabled since 3.11 or 3.12. Should I open a bug report on kernel.org? If this still happens with current kernels, please file a bug at https://bugs.freedesktop.org/enter_bug.cgi?product=DRIcomponent=DRM%2fRadeon and let us know the bug number for tracking. Cheers, Julien Tried different self compiled kernels up to latest stable 3.18.x with radeon modules. All have the same problem. System crashes on radeon load. Last syslog messages are: Dec 31 13:40:46 VDR kernel: [ 1568.348752] [drm] Initialized drm 1.1.0 20060810 Dec 31 13:40:46 VDR kernel: [ 1568.470916] [drm] radeon kernel modesetting enabled. Dec 31 13:40:46 VDR kernel: [ 1568.471331] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x174B:0xE157). Dec 31 13:40:46 VDR kernel: [ 1568.471351] [drm] register mmio base: 0xF7CC Dec 31 13:40:46 VDR kernel: [ 1568.471353] [drm] register mmio size: 131072 Dec 31 13:40:46 VDR kernel: [ 1568.471406] ATOM BIOS: CEDAR Dec 31 13:40:46 VDR kernel: [ 1568.471505] radeon :01:00.0: VRAM: 512M 0x - 0x1FFF (512M used) Dec 31 13:40:46 VDR kernel: [ 1568.471508] radeon :01:00.0: GTT: 1024M 0x2000 - 0x5FFF Dec 31 13:40:46 VDR kernel: [ 1568.471509] [drm] Detected VRAM RAM=512M, BAR=256M Dec 31 13:40:46 VDR kernel: [ 1568.471511] [drm] RAM width 64bits DDR Dec 31 13:40:46 VDR kernel: [ 1568.471629] [TTM] Zone kernel: Available graphics memory: 2024374 kiB Dec 31 13:40:46 VDR kernel: [ 1568.471632] [TTM] Initializing pool allocator Dec 31 13:40:46 VDR kernel: [ 1568.471646] [TTM] Initializing DMA pool allocator Dec 31 13:40:46 VDR kernel: [ 1568.471682] [drm] radeon: 512M of VRAM memory ready Dec 31 13:40:46 VDR kernel: [ 1568.471686] [drm] radeon: 1024M of GTT memory ready. Dec 31 13:40:46 VDR kernel: [ 1568.471715] [drm] Loading CEDAR Microcode Dec 31 13:40:46 VDR kernel: [ 1568.487039] radeon :01:00.0: firmware: direct-loading firmware radeon/CEDAR_pfp.bin Dec 31 13:40:46 VDR kernel: [ 1568.488583] radeon :01:00.0: firmware: direct-loading firmware radeon/CEDAR_me.bin Dec 31 13:40:46 VDR kernel: [ 1568.504933] radeon :01:00.0: firmware: direct-loading firmware radeon/CEDAR_rlc.bin Dec 31 13:40:46 VDR kernel: [ 1568.512797] radeon :01:00.0: firmware: direct-loading firmware radeon/CEDAR_smc.bin Dec 31 13:40:46 VDR kernel: [ 1568.512804] [drm] Internal thermal controller with fan control Dec 31 13:40:46 VDR kernel: [ 1568.533142] [drm] radeon: dpm initialized Dec 31 13:40:46 VDR kernel: [ 1568.550174] radeon :01:00.0: firmware: direct-loading firmware radeon/CYPRESS_uvd.bin Dec 31 13:40:46 VDR kernel: [ 1568.550211] [drm] GART: num cpu pages 262144, num gpu pages 262144 Dec 31 13:40:46 VDR kernel: [ 1568.551255] [drm] enabling PCIE gen 2 link speeds, disable with radeon.pcie_gen2=0 Dec 31 13:40:46 VDR kernel: [ 1568.564629] [drm] PCIE GART of 1024M enabled (table at 0x0025D000). Dec 31 13:40:46 VDR kernel: [ 1568.564754] radeon :01:00.0: WB enabled Dec 31 13:40:46 VDR kernel: [ 1568.564756] radeon :01:00.0: fence driver on ring 0 use gpu addr 0x2c00 and cpu addr 0x8800d8b6ec00 Dec 31 13:40:46 VDR kernel: [ 1568.564758] radeon :01:00.0: fence driver on ring 3 use gpu addr 0x2c0c and cpu addr 0x8800d8b6ec0c Dec 31 13:40:46 VDR kernel: [ 1568.570716] radeon :01:00.0: fence driver on ring 5 use gpu addr 0x0005c418 and cpu addr 0xc90004b9c418 Dec 31 13:40:46 VDR kernel: [ 1568.570718] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Dec 31 13:40:46 VDR kernel: [ 1568.570719] [drm] Driver supports precise vblank timestamp query. Dec 31 13:40:46 VDR kernel: [ 1568.570734] radeon :01:00.0: irq 49 for MSI/MSI-X Dec 31 13:40:46 VDR kernel: [ 1568.570742] radeon :01:00.0: radeon: using MSI. Dec 31 13:40:46 VDR kernel: [ 1568.570764] [drm] radeon: irq initialized. Dec 31 13:40:46 VDR kernel: [ 1568.587411] [drm] ring test on 0 succeeded in 1 usecs Dec 31 13:40:46 VDR kernel: [ 1568.587419] [drm] ring test on 3 succeeded in 3 usecs Dec 31 13:40:46 VDR kernel: [ 1568.773867] [drm] ring test on 5 succeeded in 1 usecs Dec 31 13:40:46 VDR kernel: [ 1568.773873] [drm] UVD initialized successfully. Dec 31 13:40:46 VDR kernel: [ 1568.774234] [drm] ib test on ring 0 succeeded in 0 usecs Dec 31 13:40:46 VDR kernel: [ 1568.774268] [drm] ib
Bug#773435: Bug#773992: Debian bug #773435
Thanks for updating these bugs with this information. On 18-04-15 12:15, Jörg Frings-Fürst wrote: My first attempt to contact the upstream author was on 2014-12-20. Until now I don't get any answer. So I'm waiting 4 month for any reaction from upstream. Have you considered making this (single sided) communication public? Maybe adding your attempts to the orhaned bug make sense for the next taker. Paul signature.asc Description: OpenPGP digital signature
Bug#768036: ip link: Fix crash on older kernels when show VF dev
On Wed, 14 Jan 2015 11:22:57 +0100 William Dauchy will...@gandi.net wrote: A fix was integrated upstream. commit8c29ae7cc2494e251520584e83698c1a9f1912e5 ip link: Fix crash on older kernels when show VF dev The issue was caused that ifla_vf_rate does not exist on older kernels and should be checked if it exists as nested attr. https://git.kernel.org/cgit/linux/kernel/git/shemminger/iproute2.git/commit/?id=8c29ae7cc2494e251520584e83698c1a9f1912e5 Since the fix is available and quite easy to integrate, I wonder if this will be included in the jessie release. Thanks, -- William signature.asc Description: Digital signature
Bug#773329: Incorrect Cflags line in jack.pc
On 12/17/14 02:31, Ted Felix wrote:
Package: libjack-jackd2-dev
Version: 1.9.10+20140719git3eb0ae6a~dfsg-2
The cflags from pkg-config for jack are incorrect which breaks makefiles
and configure scripts that depend on them (e.g. those for rosegarden).
I tend to disagree - more likely, rosegarden is broken, because a ton of
other software that relies on jackd compiles just fine.
The culprit is the Cflags line at the end of
/usr/lib/x86_64-linux-gnu/pkgconfig/jack.pc. This:
Cflags: -I/usr/include
...should be this:
Cflags: -I${includedir} -I${includedir}/jack
No, -I/usr/include is correct, because the appropriate include is
#include jack/jack.h
And rosegarden does exactly this:
adi@ak64:/tmp/rosegarden-14.02$ egrep -R include.*jack.h
src/sound/JackDriver.h:#include jack/jack.h
src/sound/JackCaptureClient.h:#include jack/jack.h
So wontfix?
Cheers
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782888: pinentry: please package pinentry-tty
Package: pinentry Version: 0.9.1-1 Severity: wishlist It would be awesome if you could also provide a package for pinentry-tty, the simple TTY version, no dependencies, which is included upstream and available via --enable-pinentry-tty: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=pinentry.git;a=blob;f=tty/pinentry-tty.c Thanks, and keep up the good work! -- ilf Über 80 Millionen Deutsche benutzen keine Konsole. Klick dich nicht weg! -- Eine Initiative des Bundesamtes für Tastaturbenutzung signature.asc Description: Digital signature
Bug#782889: aptitude: forget-new option doesn't work
Package: aptitude Version: 0.6.11-1+b1 Severity: normal Dear Maintainer, in my Jessie system I have five libraries (libdb5.3, libldap-2.4-2, libsasl2*) marked as new in ncurses interface of aptitude. Neither if I press f inside aptitude nor if I give forget-new outside it, I can hide these packages from the list of new packages. Thank you very much and best whishes, Domenico -- Package-specific info: $TERM not set. $DISPLAY is set. which aptitude: /usr/bin/aptitude aptitude version information: aptitude 0.6.11 compiled at Nov 8 2014 13:34:39 Compiler: g++ 4.9.1 Compiled against: apt version 4.12.0 NCurses version 5.9 libsigc++ version: 2.4.0 Gtk+ support disabled. Qt support disabled. Current library versions: NCurses version: ncurses 5.9.20140913 cwidget version: 0.5.17 Apt version: 4.12.0 aptitude linkage: linux-vdso.so.1 (0x7ffe1952d000) libapt-pkg.so.4.12 = /usr/lib/x86_64-linux-gnu/libapt-pkg.so.4.12 (0x7f1dd30c8000) libncursesw.so.5 = /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7f1dd2e92000) libtinfo.so.5 = /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7f1dd2c67000) libsigc-2.0.so.0 = /usr/lib/x86_64-linux-gnu/libsigc-2.0.so.0 (0x7f1dd2a61000) libcwidget.so.3 = /usr/lib/x86_64-linux-gnu/libcwidget.so.3 (0x7f1dd274b000) libsqlite3.so.0 = /usr/lib/x86_64-linux-gnu/libsqlite3.so.0 (0x7f1dd2482000) libboost_iostreams.so.1.55.0 = /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.55.0 (0x7f1dd226a000) libxapian.so.22 = /usr/lib/libxapian.so.22 (0x7f1dd1e59000) libpthread.so.0 = /lib/x86_64-linux-gnu/libpthread.so.0 (0x7f1dd1c3b000) libstdc++.so.6 = /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x7f1dd193) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7f1dd162f000) libgcc_s.so.1 = /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x7f1dd1418000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7f1dd106f000) libutil.so.1 = /lib/x86_64-linux-gnu/libutil.so.1 (0x7f1dd0e6c000) libdl.so.2 = /lib/x86_64-linux-gnu/libdl.so.2 (0x7f1dd0c67000) libz.so.1 = /lib/x86_64-linux-gnu/libz.so.1 (0x7f1dd0a4c000) libbz2.so.1.0 = /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7f1dd083c000) liblzma.so.5 = /lib/x86_64-linux-gnu/liblzma.so.5 (0x7f1dd0618000) librt.so.1 = /lib/x86_64-linux-gnu/librt.so.1 (0x7f1dd041) libuuid.so.1 = /lib/x86_64-linux-gnu/libuuid.so.1 (0x7f1dd020a000) /lib64/ld-linux-x86-64.so.2 (0x7f1dd3aa6000) -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=it_IT.utf8, LC_CTYPE=it_IT.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages aptitude depends on: ii aptitude-common 0.6.11-1 ii libapt-pkg4.121.0.9.8 ii libboost-iostreams1.55.0 1.55.0+dfsg-3 ii libc6 2.19-18 ii libcwidget3 0.5.17-2 ii libgcc1 1:4.9.2-10 ii libncursesw5 5.9+20140913-1+b1 ii libsigc++-2.0-0c2a2.4.0-1 ii libsqlite3-0 3.8.7.1-1 ii libstdc++64.9.2-10 ii libtinfo5 5.9+20140913-1+b1 ii libxapian22 1.2.19-1 Versions of packages aptitude recommends: ii aptitude-doc-en [aptitude-doc] 0.6.11-1 ii libparse-debianchangelog-perl 1.2.0-1.1 ii sensible-utils 0.0.9 Versions of packages aptitude suggests: pn apt-xapian-index none pn debtags none ii tasksel 3.31 -- 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#782873: missing suggests: poster
Package: kprinter4 Version: 12-1 Severity: normal kprinter4 should at least suggest poster since poster printing won't work without poster installed. Greetings Marc -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778831: Update: Udevil is not dead anymore
On 19.04.2015 10:34, Ondřej Grover wrote: Hello, I'd like to point out that udevil and SpaceFM are not dead anymore, just developed at a slower pace, but it is maintained and fixed when needed. https://igurublog.wordpress.com/2015/03/02/spacefm-and-udevil-resume-slow-development/ Kind regards, Ondřej Grover Hi, Lastest commit for udevil was a year ago: https://github.com/IgnorantGuru/udevil/tree/next Now the upstream author focuses on spacefm, udevil looks abandoned. Mateusz -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782871: apt (1.0.9.8) prevents aptitude handling forget-new properly.
Control: reassign -1 aptitude Control: forcemerge 782777 -1 Control: affects -1 apt On Sun, Apr 19, 2015 at 01:00:59PM +0900, Hae-woo Park wrote: Recently I upgraded the following packages from 1.0.9.7 to 1.0.9.8: apt, apt-utils, libapt-inst1.5, libapt-pkg4.12. (I am using sid.) After then aptitude could not handle 'forget-new' (and 'markauto'?) properly. When type 'f' (or 'M') for those instruction in aptitude, it seems working; but after restarting aptitude the status went back. Note that the 'markauto' issue was tested only with 'new' packages. So now I've rolled back those 4 packages, and aptitude properly forgets the new packages by 'forget-new'. This wierdness is discussed over at aptitude with #782777, so I am merging with it and let you guys figure it out because I can't reproduce it here with pure apt(-mark) and this aptitude thingy is pure black magic for my eyes and ears (on of these days I might start it). From what I read there it isn't clear to me that a downgrade actually fixes things. It seems more to fumble around stuff so that it pops up someplace else. My biggest problem with it is through that nothing in the vincity of the autobit handling changed in 1.0.9.8. Not even close to it. The closest is maybe parse specific-arch dependencies correctly on single-arch systems, but that just because it is the binary cache creation changed, which is state potentially shared between different versions of libapt, but is reshuffled on 'update' and at least partly with every change to the dpkg/status. I didn't invalidate the cache with a version bump, which from a (very) theoretical standpoint is incorrect, but that just means you are effected by the bug this commit is fixing until after the cache is invalidated next (given that just one package satisfying the criteria exists at all in all of Debian, that isn't as bad as it might sound – especially as the fix is for jessie and this one package is sid only). That is working the other way around, too, through as a downgrade isn't breaking it again instantly either. What I can see is that the two reporters who provided the information are single-arch systems, so they would be effected by this bug, for multi-arch systems nothing changed. Now, all that being said, this bears no relation to 'new' nor 'auto' as this is about dependencies being created incorrectly. At the most its removing packages as this bug created package structures with a bad name so they couldn't be found later, but that also means these bad packages never had a version belonging to it and I doubt aptitude considers those as new (and they are gone now, not added, so if anything, 1.0.9.8 would fix it…). But yes, its the best I got, even through I have no idea what could be it as the other fixes I would consider even less likely to influence the outcome of aptitude than the current moon phase: - apt-key changes do not effect aptitude at all - VectorizeString is called by aptitude only in mkdir_parents, which is itself never called by aptitude… - WriteApportReport is disabled in Debian by default, called only by libapt itself and only as a reaction to a dpkg error while stuff is installed. Also, its a crash fix… - pkgAcquire::Item::Mode is another crash fix, a crash theoretically not happening and indeed never happening for 5 years in C++ code. Only python3 seems to manage to trigger it. Also only acts while stuff is being fetched from the interwebs. - https is, well, a seperate binary never called directly by aptitude, nor does it see the communication with it. Used also only while fetching stuff from the (encrypted) interweb. - a typo in the commandline parsing of apt-get. And that was it, all 7 changes in 1.0.9.8. Fun fact: This mail has more lines than 2 times the amount of changed code lines (which itself counts changes twice as one line added and one line removed) in the diff between 1.0.9.7 and 1.0.9.8. Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#781557: libwine-development: upgrade failure: file overwrite
Control: found -1 1.7.41-1 * Paul Wise p...@debian.org, 2015-03-31, 07:49: dpkg: error processing archive /var/cache/apt/archives/libwine-development_1.7.39-1_amd64.deb (--unpack): trying to overwrite shared '/usr/share/wine-development/wine/fonts/sserifee.fon', which is different from other instances of package libwine-development:amd64 dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) ... Errors were encountered while processing: /var/cache/apt/archives/libwine-development_1.7.39-1_amd64.deb ... E: Sub-process /usr/bin/dpkg returned an error code (1) Here's the list of affected files and their MD5 sums: /usr/share/wine-development/wine/fonts/smae1257.fon 8267969b0b1f414d881540e665a5d590 armhf i386 kfreebsd-i386 958a8ba6366ba8d72a692b4314f38300 powerpc fe794ac6e6777eade4d6da731fdae573 amd64 /usr/share/wine-development/wine/fonts/smallee.fon 5eaf8200fe12c497f27afdbf0b83256a armhf i386 kfreebsd-i386 9a3b95209737e4602bb0bdf379701586 amd64 4cf0ece9059fe526f36f914d29f6e2e2 powerpc /usr/share/wine-development/wine/fonts/sserifee.fon 135019a81b619502e501e9836acdd169 armhf i386 kfreebsd-i386 2f96336a27ce153cd5ef0ba6c7fbef09 amd64 52a04097e44579095f32201a8926a240 powerpc /usr/share/wine-development/wine/fonts/sseriffe.fon 8ef330b81abcaca92fdf8125344c84ae armhf i386 kfreebsd-i386 f9755a26107f6e8e8cef384d3d4d1d63 amd64 984f27ef9fe9d0cb76e57386e521a12d powerpc -- 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#759657: console-setup: system state after fixing
Package: console-setup Version: 1.121 Followup-For: Bug #759657 These are the system settings - after boot showing the wrong setup - but AFTER running systemctl restart console-setup.service - after which the setup is correct in other words just after the previous report, but fixed. Maybe the system state below is any different ? I'll now test and report on the udev-settle fix that was suggested out-of-band. Karsten -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages console-setup depends on: ii console-setup-linux 1.121 ii debconf 1.5.56 ii keyboard-configuration 1.121 ii xkb-data2.12-1 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales2.19-17 ii locales-all [locales] 2.19-17 ii lsb-base 4.1+Debian13+nmu1 Versions of packages keyboard-configuration depends on: ii debconf 1.5.56 ii initscripts 2.88dsf-59 ii liblocale-gettext-perl 1.05-8+b1 Versions of packages console-setup-linux depends on: ii kbd 1.15.5-2 ii keyboard-configuration 1.121 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common none pn console-datanone pn console-tools none ii kbd 1.15.5-2 -- debconf information: keyboard-configuration/variant: Deutsch - Deutsch (ohne Akzenttasten) * console-setup/fontface47: Terminus * console-setup/fontsize-fb47: 8x16 keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl) keyboard-configuration/toggle: No toggling keyboard-configuration/compose: No compose key keyboard-configuration/ctrl_alt_bksp: false keyboard-configuration/switch: No temporary switch keyboard-configuration/unsupported_options: true console-setup/codesetcode: Lat15 keyboard-configuration/layout: keyboard-configuration/xkb-keymap: de(nodeadkeys) keyboard-configuration/altgr: The default for the keyboard layout console-setup/framebuffer_only: keyboard-configuration/optionscode: keyboard-configuration/modelcode: pc105 console-setup/store_defaults_in_debconf_db: true keyboard-configuration/variantcode: nodeadkeys console-setup/use_system_font: console-setup/fontsize-text47: 8x16 keyboard-configuration/unsupported_config_options: true keyboard-configuration/other: keyboard-configuration/layoutcode: de keyboard-configuration/unsupported_config_layout: true debian-installer/console-setup-udeb/title: * console-setup/charmap47: UTF-8 keyboard-configuration/unsupported_layout: true console-setup/guess_font: console-setup/fontsize: 8x16 * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages keyboard-configuration/store_defaults_in_debconf_db: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#758172: isync: dots in maildir names
On Sun, Apr 19, 2015 at 01:33:48PM +0200, Robert Jarzmik wrote: I was wondering if there was a solution found for the problem you described, ie. a solution accepted and integrated by Oswald. I've never seen any useful response t the report. I've been using mbsync for quite a long time, and I had a patch since version 1.0.4 for this dots (I hesitate to talk about issue as Maildir++ format requires them). Anyway, if there is a solution I'll hapily use it. If not, for a reference I'm using the patch in [1] upon isync 1.1.1, which adds a DropDots option to maildir store. Thanks, that looks really helpful! signature.asc Description: Digital signature
Bug#779187: w3m-data-retrieve: Invalid base64 data
Control: tags -1 + moreinfo On February 25, 2015 at 10:38AM +0100, Pierre (at crescenzo.nom.fr) wrote: With w3m-el-snapshot 1.4.538+0.20141022-1 in testing, some mails give an error in *Messages* of emacs24 24.4+1-4.1: ** w3m-data-retrieve: Invalid base64 data Error running timer `w3m-idle-images-show': (wrong-type-argument timerp nil) w3m-data-retrieve: Invalid base64 data Could you please provide more information (sample data and step-by-step procedure) so others can reproduce this problem? Thanks, -- Tatsuya Kinoshita pgpzHGmZCjxdJ.pgp Description: PGP signature
Bug#782824: g++-5: Compilation of application using wxWidgest produces a lot of warnings
Control: tags -1 + moreinfo On 04/18/2015 01:39 PM, TonyMi wrote: Package: g++-5 Version: 5.1~rc1-1 Severity: normal Dear Maintainer, I tried to compile my application using wxWidgets with g++-5 but I got a lot of warnings. I reported the problem on wxWidgets forum, but the developers think that bug is in the gcc. you forgot to attach the minimal example and forgot to explain why the current behaviour is supposed to be a bug. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#543162: [ncview] segfault when clicking on Axes button
Control: tags -1 confirmed Control: found -1 ncview/2.1.5+ds1-1~exp1 Hi Manolo, Thanks for reporting this issue back in 2009. Not much had happened around the ncview package in Debian since then, jessie will still ship with ncview 1.93g-1 for example. Yesterday I finished updating the ncview packaging with the 2.1.5 upstream release, but it unfortunately still suffers from this issue. Upstream doesn't use a public bug tracker to forward this issue to, but I may be able to forward it by email to the upstream developer. I forwarded some patches developed while packaging version 2.1.5, so if that establishes a line of communication I'll also ask upstream to look into this issue. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782879: libtest-log4perl-perl: libtest-log4perl-perl: please make the build reproducible
Source: libtest-log4perl-perl Version: 0.1001-3.1 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 libtest-log4perl-perl could not be built reproducibly. The attached patch removes extra timestamps from the build system and ensure a stable file order when creating the source archive. Once applied, libtest-log4perl-perl can be built reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds diff -ur libtest-log4perl-perl-0.1001/debian/changelog libtest-log4perl-perl-0.1001-new/debian/changelog --- libtest-log4perl-perl-0.1001/debian/changelog 2011-11-16 18:08:28.0 + +++ libtest-log4perl-perl-0.1001-new/debian/changelog 2015-04-19 11:04:39.452038603 + @@ -1,3 +1,11 @@ +libtest-log4perl-perl (0.1001-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Set timestamp in manual page to last package change time from +changelog, to make builds reproducible. + + -- Jelmer Vernooij jel...@debian.org Sun, 19 Apr 2015 11:04:39 + + libtest-log4perl-perl (0.1001-3) unstable; urgency=medium [ Tim Retout ] diff -ur libtest-log4perl-perl-0.1001/debian/rules libtest-log4perl-perl-0.1001-new/debian/rules --- libtest-log4perl-perl-0.1001/debian/rules 2011-11-16 18:08:28.0 + +++ libtest-log4perl-perl-0.1001-new/debian/rules 2015-04-19 11:04:14.003327699 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ signature.asc Description: Digital signature
Bug#782882: udisks2: Cannot mount any device: not authorized to preform operation
Package: udisks2 Version: 2.1.5-2 Severity: important Dear Maintainer, I am unable to perform any mounts - getting the following message: Could not mount the following device: [...] An unspecified error has occurred: not authorized to perform operation -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (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: sysvinit (via /sbin/init) Versions of packages udisks2 depends on: ii dbus 1.9.14-1 ii libacl12.2.52-2 ii libatasmart4 0.19-3 ii libc6 2.19-18 ii libglib2.0-0 2.42.1-1 ii libgudev-1.0-0 219-7 ii libpam-systemd 219-7 ii libpolkit-agent-1-00.105-8+vua1 ii libpolkit-gobject-1-0 0.105-8+vua1 ii libsystemd0219-7 ii libudisks2-0 2.1.3-5+vua1 ii parted 3.2-7 ii udev 219-7 Versions of packages udisks2 recommends: ii dosfstools 3.0.27-1 ii eject2.1.5+deb1+cvs20081104-13.1 ii gdisk0.8.10-2 ii ntfs-3g 1:2014.2.15AR.3-1 ii policykit-1 0.105-8+vua1 Versions of packages udisks2 suggests: pn btrfs-tools none ii cryptsetup-bin 2:1.6.6-5 ii exfat-utils 1.1.0-2 pn mdadm none pn reiserfsprogs none pn xfsprogsnone -- 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#782883: ircd-hybrid: upgrade question on first install
Package: ircd-hybrid Version: 1:8.2.0+dfsg.1-2 Severity: minor The message upgrade_no_services_warn is displayed on new installs, because of the faulty logic in the package config script: if dpkg --compare-versions $2 lt 1:8.0.9.dfsg.1-2; then should read if dpkg --compare-versions $2 lt-nl 1:8.0.9.dfsg.1-2; then Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#773108: Crashes
Hi, I also saw the crash on startup. Then I plugged my webcam in, and that crash disappeared : I got a window and menus. Then I had another crash, but that will require another report. Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782878: [Reproducible-builds] Bug#782879 + Bug#782878: lib{test-log4perl, scalar-defer}-perl: please make the build reproducible
Hi Axel, On Sun, Apr 19, 2015 at 02:03:44PM +0200, Axel Beckert wrote: Jelmer Vernooij wrote: diff -ur libtest-log4perl-perl-0.1001/debian/rules libtest-log4perl-perl-0.1001-new/debian/rules --- libtest-log4perl-perl-0.1001/debian/rules 2011-11-16 18:08:28.0 + +++ libtest-log4perl-perl-0.1001-new/debian/rules 2015-04-19 11:04:14.003327699 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ Jelmer Vernooij wrote: diff -ur libscalar-defer-perl-0.23/debian/rules libscalar-defer-perl-0.23-new/debian/rules --- libscalar-defer-perl-0.23/debian/rules 2015-04-19 10:59:01.0 + +++ libscalar-defer-perl-0.23-new/debian/rules 2015-04-19 10:59:38.911642206 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ Thanks for the patches. But isn't this something which should be done doing once and properly in the build system (e.g. in dh_auto_build), like setting all the file time stamps to that date? Cc'ing the reproducible builds project as well as the debhelper maintainers for input. Yeah, this was brought up on the reproducible builds mailing list as well in relation to these three patches. There are at least a few dozen (and probably more) perl packages that suffer from this, so doing this from debhelper would indeed be better (and less effort). Another option might be to do it from upstream? It could just take the timestamp of the source file. Cheers, Jelmer -- Jelmer Vernooij jel...@debian.org Debian Developer https://jelmer.uk/ signature.asc Description: Digital signature
Bug#772803: add the debian-security-support package to wheezy
On Sun, Apr 19, 2015 at 01:42:25PM +0200, Holger Levsen wrote: Hi security team, On Mittwoch, 17. Dezember 2014, Holger Levsen wrote: Julien suggested on IRC to introduce this via wheezy-security to wheezy. Sounds like a plan to me ;-) could you please upload debian-security-support to wheezy-security? It's kinda sad that this package still aint in wheezy proper :/ I already told you on IRC it will be part of the next wheezy point update. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772101: jackd2 installed on minimal debian jessie wouldn't start before manually installing dbus-x11
On 12/05/14 07:38, Jens Peter Nielsen wrote: Package: jackd2 Version: 1.9.10+20140719git3eb0ae6a~dfsg-2 Severity: normal I've recently merged a patch into jackd2 upstream to fix this. It's been known for ages. Patch in question: https://github.com/jackaudio/jack2/commit/3c05a0b36ec5a925a0020ab5d1e57fa38e9a7d09 If you want it in jessie (for no real benefit, people know how to work around it as mentioned in https://github.com/jackaudio/jack2/issues/10), just backport this fix. Otherwise, we'll sync to new upstream version after the release of jessie, that will automatically fix the issue. Cheers -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782881: circuslinux: Man page formatting broken / link incorrect / incomplete
Package: circuslinux Version: 1.0.3-31 Severity: minor I report this in one go, please clone if/where necessary: a) The formatting of the man page is broken, all options are printed in one single long line. Also the control part could use some line breaks to be actually readable. b) The man page says further information can be found in /usr/share/doc/circuslinux/README.txt.gz However, this file does not exist. You probably meant /usr/share/doc/circuslinux/README.gz c) The most important information, namely how to get the clowns going (pressing [ENTER]) is missing. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to de_DE.UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages circuslinux depends on: ii circuslinux-data 1.0.3-31 ii debconf [debconf-2.0] 1.5.56 ii libc6 2.19-18 ii libsdl-image1.21.2.12-5+b5 ii libsdl-mixer1.21.2.12-11+b1 ii libsdl1.2debian1.2.15-10+b1 circuslinux recommends no packages. circuslinux suggests no packages. -- debconf information: circuslinux/score_file_exists: circuslinux/shared_score_file: circuslinux/merge_score_files: -- Dr. Helge Kreutzmann deb...@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software libre: http://www.ffii.de/ signature.asc Description: Digital signature
Bug#258096: Re:Offer
Hello, I would like to know if you have received my proposal. Best Regards Edouard SIMONIN -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#772803: add the debian-security-support package to wheezy
Hi security team, On Mittwoch, 17. Dezember 2014, Holger Levsen wrote: Julien suggested on IRC to introduce this via wheezy-security to wheezy. Sounds like a plan to me ;-) could you please upload debian-security-support to wheezy-security? It's kinda sad that this package still aint in wheezy proper :/ If you were ok with me doing the upload, I'd be glad to do it. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#782878: Bug#782879 + Bug#782878: lib{test-log4perl,scalar-defer}-perl: please make the build reproducible
Control: tag -1 + moreinfo Hi Jelmer, Jelmer Vernooij wrote: diff -ur libtest-log4perl-perl-0.1001/debian/rules libtest-log4perl-perl-0.1001-new/debian/rules --- libtest-log4perl-perl-0.1001/debian/rules 2011-11-16 18:08:28.0 + +++ libtest-log4perl-perl-0.1001-new/debian/rules 2015-04-19 11:04:14.003327699 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ Jelmer Vernooij wrote: diff -ur libscalar-defer-perl-0.23/debian/rules libscalar-defer-perl-0.23-new/debian/rules --- libscalar-defer-perl-0.23/debian/rules2015-04-19 10:59:01.0 + +++ libscalar-defer-perl-0.23-new/debian/rules2015-04-19 10:59:38.911642206 + @@ -1,4 +1,9 @@ #!/usr/bin/make -f +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ Thanks for the patches. But isn't this something which should be done doing once and properly in the build system (e.g. in dh_auto_build), like setting all the file time stamps to that date? Cc'ing the reproducible builds project as well as the debhelper maintainers for input. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782879: [debhelper-devel] Bug#782879 + Bug#782878: lib{test-log4perl, scalar-defer}-perl: please make the build reproducible
On Sun, 19 Apr 2015 14:03:44 +0200, Axel Beckert wrote: Jelmer Vernooij wrote: +# Set man page timestamp to last package change time. +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE But isn't this something which should be done doing once and properly in the build system (e.g. in dh_auto_build), like setting all the file time stamps to that date? Right, that was my idea as well. Adding boilerplate to thousands of packages is neither technically appealing nor manageable. I vaguely remember reading something about POD_MAN_DATE recently (debian-perl@ldo? some perl bug report?), maybe someone else remembers ... But yes, debhelper would be an obvious place to do this. Cheers, gregor -- .''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06 : :' : Debian GNU/Linux user, admin, and developer - https://www.debian.org/ `. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe `- NP: The Who: Join Together signature.asc Description: Digital Signature
Bug#782886: git-import-dsc to support --upstream-vcs-tag
Package: git-buildpackage Version: 0.6.22 Severity: wishlist The --upstream-vcs-tag for git-import-orig is nice. Thanks. Also pending fix to #700411 git-import-orig should filter the upstream debian director is also nice. What about git-import-dsc to support --upstream-vcs-tag. I mean that the upstream branch is not just a copy of upstream tar but also a merge commit from tag specified by the --upstream-vcs-tag on the upstream-vcs branch. Then the master (debian) branch is commited exactly as dpkg-source -x --unapply-patches but also a merge commit from the upstream. The reast are the same as the good old git-import-dsc. Right now, if I use git-import-orig --upstream-vcs-tag, master branch has merge conflict if the upstream has debian/ directory with some changes. It should disregard changes in debian/. Yes, I manually fix this by copying debian source tree and commiting it. But having git-import-dsc with --upstream-vcs-tag should make starting the few recent packages commited to the local git which has upstream vcs clone in it very easy. Osamu -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages git-buildpackage depends on: ii devscripts2.15.3 ii git 1:2.1.4-2.1 ii man-db2.7.0.2-5 ii python2.7.9-1 ii python-dateutil 2.2-2 ii python-pkg-resources 5.5.1-1 Versions of packages git-buildpackage recommends: ii cowbuilder0.73 ii pristine-tar 1.33 Versions of packages git-buildpackage suggests: ii python-notify 0.1.1-4 ii unzip 6.0-16 -- 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#772803: add the debian-security-support package to wheezy
Hi Moritz, On Sonntag, 19. April 2015, Moritz Muehlenhoff wrote: I already told you on IRC it will be part of the next wheezy point update. For this it needs to be uploaded. Also the next wheezy point release is quite very likely to happen in the next 6 days, so please hurry up to make this happen. (And also as this bug log^w^wother irc conversations showed, the SRMs were not to keen on adding the package this way and (iirc) would prefer to have it done via -security.) And anyway, no upload, no package. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#782869: coreutils: rm,ls,cd,mkdir, etc should be set so root cant remove them.
richard jasmin wrote: Root can remove CORE commands from the system and then the system is forever borked. Yes. Root is the superuser. With great power comes great responsibility. How did you remove the coreutils from your system? 1) there should be a fix for this: apt-get reinstall coreutils? 2) this bug should never be. System should have ultimate access, not root. Root should never be allowed to shoot self in foot. In order to have done this you must have answered the force question. # dpkg --purge coreutils dpkg: error processing package coreutils (--purge): this is an essential package; it should not be removed Errors were encountered while processing: coreutils There is already protection from removing the coreutils. This is not a bug in the coreutils package. please set immutable flag (+i) by default or imbed commands into kernel or something to fix this. No. That is not appropriate. Instead you should exercise proper care when using root not to shoot yourself in the foot. If you have broken your system then I recommend using the debian-installer in rescue mode to gain control of your system and re-install the coreutuils. Bob signature.asc Description: Digital signature
Bug#780940: Problem found.
Víctor, Just running make quite likely didn't apply some of the debian patches. If it's a patch issue, `dpkg-buildpackage -us -uc` will likely produce a package that will break, you could try that too as a first attempt. You could also try applying patches selectively and see if a specific one breaks it. From what I understand, you may not have had all the libraries installed against which the standard Debian hdparm package is built when you compiled it. So perhaps you could try installing the build-dep libraries one by one and recompiling and testing until you find the one that breaks it. Kind regards, Ondřej Grover On Sun, Apr 19, 2015 at 2:43 AM, Víctor Cana Benítez vic...@openmailbox.org wrote: Dear maintainers, Finally I have found the problem to package hdparm in debian jessie. Resume: *the problem is the way that the package hdparm in debian jessie's repository is compiled*. Well, to get to that conclusion, first I compared the sources of hdparm from debian jessie and from ubuntu vivid. Unlike our colleague Niels, I didn't find differences between both. Then, I downloaded the sources of hdparm from debian jessie's repository, descompressed them, and typed in the terminal make and finally checkinstall. The utilities used to compile the sources are the default in debian jessie's package repository. Finally, I have tested and that way the problem is solved. To get sure that the package hdparm that I downloaded from jessie's repository wasn't corrupted, I typed in terminal aptitude clean and then aptitude update to finally try again to aptitude install hdparm from jessie's package repository. The result is the same, freeze's and kill of hdparm at boot time. My package repository is: deb http://ftp.debian.org/debian/ jessie main. My machine has the x86 architecture. I have also checked the md5sum of the package and it is OK. Conclusion to my tests: the way that the package hdparm in debian jessie's respository is compiled is causing problems to my system. Best regards, Víctor.
Bug#782251: python-boto: S3 upload using sigv4 crash
Hi Eric, Thanks for your reply. Not all package maintainers are as understanding as you are when it comes to bug severity, it's a subject that is easy to get into an argument about! I think it should be fixed in Jessie eventually and it seems common enough a use case that some people will hit the bug on day one. Now, is it worth delaying the release of Jessie for that? I lean toward 'no' as there are two possible workarounds (disabling multipart and installing it via pip). But it still severely affects the usability of the package. Best regards, François. On 19 April 2015 04:25:35 BST, Eric Evans eev...@sym-link.com wrote: severity 782251 important tag 782251 -patch thanks [ Francois Guerraz ] Package: python-boto Version: 2.34.0-2 Severity: normal Tags: patch upstream Using boto as a backend for duplicity with multipart upload in the Frankfurt region result in crash: TypeError: argument of type 'int' is not iterable I believe this bug was reported and fixed upstream: https://github.com/boto/boto/issues/2731 Hi Francois, Thanks for the report; I try to keep an out for upstream bug reports that effect the package, but I clearly missed this one. For posterity sake, the canonical upstream bug report seems to be: https://github.com/boto/boto/pull/2744. I think this more serious than severity 'normal', the question is: is it 'important', or 'serious' (serious would make it release-critical)? It's not entirely clear to me what it takes to exercise this code (the assignment of the integer in boto/connection.py), but I assume it's uncommon enough that 'serious' isn't warranted. Let me know if you disagree. In this meantime, I'll put together a new upstream release for upload to experimental, at least. Regards, -- Eric Evans eev...@sym-link.com -- Sent from Kaiten Mail. Please excuse my brevity.
Bug#780940: Problem found.
On 2015-04-19 02:43, Víctor Cana Benítez wrote:
Dear maintainers,
Hi,
Thanks for following up. It is indeed an interesting find.
Finally I have found the problem to package hdparm in debian jessie.
Resume: *the problem is the way that the package hdparm in debian jessie's
repository is compiled*.
As Ondrej mentioned it mind be something different that just how it
compiled. Nevertheless, it certainly confirms that the problem is
entirely on the Debian side.
I got two possible leads, Víctor do you have:
* a RAID setup?
* a block device named something like /dev/sdaa or /dev/hdaa?
- Minimum 4 /letters/ and starting with either sd or hd. All
other letters can vary in the a-z range.
If you have a RAID:
* Please provide the output of:
egrep -iq resync|repair|recover|check /proc/mdstat
cat /proc/rd/status
* Combined they should just say OK (or complain about missing
files). If not, your system is triggering the RAID resync code.
If this happens on every reboot, the issue is probably that it
takes your system is about a minute to resync them and Debians
init scripts forces you to wait for it to happen.
Well, to get to that conclusion, first I compared the sources of hdparm from
debian jessie and from ubuntu vivid. Unlike our colleague Niels, I didn't
find
differences between both. Then, I downloaded the sources of hdparm from
debian
jessie's repository, descompressed them, and typed in the terminal make and
finally checkinstall.
[...]
This /sounds/ like you just downloaded the hdparm_9.43.orig.tar.gz
file and only used that. If so, a very likely alternative to your
conclusion would be a Debian specific change causes this issue (as
Ondrej suggested).
The debian source also includes (in this case) a
hdparm_9.43-2.diff.gz, which contains the debian packaging and
possibly some changes to the source.
* Debian has *no* direct changes to the upstream code
* Ubuntu /has/ direct changes to the upstream source. However, these
are not applied upstream last I checked. Given a vanilla
upstream release just works(tm), lets whitelist all of these
changes as safe for now.
This leaves an interdiff between Ubuntu (as orig) and Debian (as
new) of [excluding the changelog]:
95hdparm-apm |5 ++---
control |5 ++---
hdparm.init |5 +
hdparm.udev |4 ++--
rules|3 ++-
5 files changed, 13 insertions(+), 9 deletions(-)
(attached as hdparm-ubuntu-debian.interdiff)
Lets spread these changes into distinct changesets:
* debian/hdparm.init = Debian has a *lock* in place for a RAID
workaround.
* debian/hdparm.udev = Change a rule to only match /dev/[sh]d[a-z]
instead of /dev/[sh]d[a-z]*
* debian/95hdparm-apm = comments only / noise
* debian/control = Add dependency on lsb-base (and some noise)
- Unlikely to be the problem as I doubt you uninstalled lsb-base
just to test this.
* debian/rules = Change to if/how the service should be started.
- My take here is that this is Ubuntu specific due to their
(previous?) use of upstart
Thanks,
~Niels
reverted:
reverted:
reverted:
diff -u hdparm-9.43/debian/hdparm.init hdparm-9.43/debian/hdparm.init
--- hdparm-9.43/debian/hdparm.init
+++ hdparm-9.43/debian/hdparm.init
@@ -94,6 +94,8 @@
if [ -f /proc/sys/dev/raid/speed_limit_max ] [ x$raid_speed_limit_max
!= x ]; then
echo $raid_speed_limit_max /proc/sys/dev/raid/speed_limit_max
fi
+
+ rm -f /var/lock/hdparm-resync.lock
}
isOnBattery() {
@@ -146,6 +148,9 @@
# Turn off RAID synchronisation if needed and asked for.
if [ $raidstat != 'OK' ] [ $RAID_WORKAROUND = yes ]; then
+ exec 200/var/lock/hdparm-resync.lock
+ # Block until lock can be acquired
+ flock 200
slow_down_raid_sync
fi
diff -u hdparm-9.43/debian/changelog hdparm-9.43/debian/changelog
diff -u hdparm-9.43/debian/hdparm.udev hdparm-9.43/debian/hdparm.udev
--- hdparm-9.43/debian/hdparm.udev
+++ hdparm-9.43/debian/hdparm.udev
@@ -1,2 +1,2 @@
-ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z], \
- RUN+=/lib/udev/hdparm
+ACTION==add, SUBSYSTEM==block, KERNEL==[sh]d[a-z]*,
RUN+=/lib/udev/hdparm
+
diff -u hdparm-9.43/debian/95hdparm-apm hdparm-9.43/debian/95hdparm-apm
--- hdparm-9.43/debian/95hdparm-apm
+++ hdparm-9.43/debian/95hdparm-apm
@@ -3,9 +3,8 @@
# This script adjusts hard drive APM settings using hdparm. The hardware
# defaults (usually hdparm -B 127) cause excessive head load/unload cycles
# on many modern hard drives. We therefore set hdparm -B 254 while on AC
-# power. On battery we set hdparm -B 128; this still does not guarantee
-# disk parking, but is safer than causing lots of mechanical wear on disks
-# as we seem to get currently with 127.
+# power. On battery we set hdparm -B 127, because the head parking is
+# very useful for shock protection.
#
# Refactored from acpi-support's 90-hdparm.sh for pm-utils
diff -u hdparm-9.43/debian/control hdparm-9.43/debian/control
Bug#782808: Acknowledgement (xorg: GUI lags and freezes after boot or resume from supsended status (both Debian GNOME3 and Ubuntu KDE))
Hi, after an upgrade from the wheezy-backports that installed the xorg-input-synaptic v. 1.8.0-1 I do not experience the problem anymore. Sorry if I opened a bug already solved by the community. Regards, franciskittu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782875: udevil: systemd devmon@.service template unit file shipped in wrong directory /$(libdir)/systemd/system/
Package: udevil Version: 0.4.3-1 Severity: important Tags: patch Dear Maintainer, the systemd devmon@.service template unit file is shipped in the wrong directory /$(libdir)/systemd/system/ which is /usr/lib/x86_64-linux-gnu/systemd/system on my system, so systemd does not see it. This prevents the devmon per user activation as described in /usr/share/doc/udevil/README.gz I think the problem is that etc/Makefile.am uses $(DESTDIR)/$(libdir)/systemd/system to install the unit file. Perhaps that Makefile should not be used at all ( and the service file should be intalled with dh --with=systemd. Kind regards, Ondřej Grover -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing'), (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 udevil depends on: ii libc6 2.19-17 ii libglib2.0-0 2.42.1-1 ii libudev1 215-14 Versions of packages udevil recommends: pn pmountnone pn udisks | udisks2 none pn zenitynone Versions of packages udevil suggests: pn cifs-utils none pn curlftpfs none ii eject 2.1.5+deb1+cvs20081104-13.1 ii sshfs 2.5-1 --- debian/rules.old 2014-01-28 14:17:13.0 +0100 +++ debian/rules 2015-04-19 11:04:22.151932036 +0200 @@ -9,8 +9,11 @@ # Uncomment this to turn on verbose mode. #export DH_VERBOSE=1 +# The etc/Makefile should not install systemd units, dh will +export ADD_SYSTEMD=0 + %: - dh $@ + dh --with systemd $@ override_dh_installman: dh_installman debian/devmon.1
Bug#778831: Update: Udevil is not dead anymore
Hello Mateusz, If you look at some of the recent issues (e.g. https://github.com/IgnorantGuru/udevil/issues/54) you will find that new features are planned and discussed. Looking at the milestones ( https://github.com/IgnorantGuru/udevil/milestones), something is going on. It may not be super alive in terms of commits, but AFAIK that is not a requirement for packages to be in Debian as long is it works reliably. Udevil is a reasonably mature piece of SW and it does what it should so it may not be developed so actively. Udevil (and devmon) is one of the few userspace (auto)mounting suites that are DE agnostic and it would be a loss for people that don't use a full DE. Kind regards, Ondřej Grover On Sun, Apr 19, 2015 at 10:56 AM, Mateusz Łukasik mat...@linuxmint.pl wrote: On 19.04.2015 10:34, Ondřej Grover wrote: Hello, I'd like to point out that udevil and SpaceFM are not dead anymore, just developed at a slower pace, but it is maintained and fixed when needed. https://igurublog.wordpress.com/2015/03/02/spacefm-and-udevil-resume-slow-development/ Kind regards, Ondřej Grover Hi, Lastest commit for udevil was a year ago: https://github.com/IgnorantGuru/udevil/tree/next Now the upstream author focuses on spacefm, udevil looks abandoned. Mateusz
Bug#780940: Problem found.
Niels, from the logs and output Víctor posted it seems it is a simple /dev/sda drive. However, it is possible that the drive that fails is not /dev/sda as the logs identify the drive by its hardware slot. The RAID lock lead sounds promising, it might explain the hang. Víctor, could you please post the output of `lsblk --all --output-all` (in a text file as the lines will be very wide) so that we have a better idea of your HDD layout? Also post the relevant lines from the system log but also in a text file because in your first message they were truncated. We need to determine which drive exactly fails. Kind regards, Ondřej Grover On Sun, Apr 19, 2015 at 10:21 AM, Niels Thykier ni...@thykier.net wrote: On 2015-04-19 02:43, Víctor Cana Benítez wrote: Dear maintainers, Hi, Thanks for following up. It is indeed an interesting find. Finally I have found the problem to package hdparm in debian jessie. Resume: *the problem is the way that the package hdparm in debian jessie's repository is compiled*. As Ondrej mentioned it mind be something different that just how it compiled. Nevertheless, it certainly confirms that the problem is entirely on the Debian side. I got two possible leads, Víctor do you have: * a RAID setup? * a block device named something like /dev/sdaa or /dev/hdaa? - Minimum 4 /letters/ and starting with either sd or hd. All other letters can vary in the a-z range. If you have a RAID: * Please provide the output of: egrep -iq resync|repair|recover|check /proc/mdstat cat /proc/rd/status * Combined they should just say OK (or complain about missing files). If not, your system is triggering the RAID resync code. If this happens on every reboot, the issue is probably that it takes your system is about a minute to resync them and Debians init scripts forces you to wait for it to happen. Well, to get to that conclusion, first I compared the sources of hdparm from debian jessie and from ubuntu vivid. Unlike our colleague Niels, I didn't find differences between both. Then, I downloaded the sources of hdparm from debian jessie's repository, descompressed them, and typed in the terminal make and finally checkinstall. [...] This /sounds/ like you just downloaded the hdparm_9.43.orig.tar.gz file and only used that. If so, a very likely alternative to your conclusion would be a Debian specific change causes this issue (as Ondrej suggested). The debian source also includes (in this case) a hdparm_9.43-2.diff.gz, which contains the debian packaging and possibly some changes to the source. * Debian has *no* direct changes to the upstream code * Ubuntu /has/ direct changes to the upstream source. However, these are not applied upstream last I checked. Given a vanilla upstream release just works(tm), lets whitelist all of these changes as safe for now. This leaves an interdiff between Ubuntu (as orig) and Debian (as new) of [excluding the changelog]: 95hdparm-apm |5 ++--- control |5 ++--- hdparm.init |5 + hdparm.udev |4 ++-- rules|3 ++- 5 files changed, 13 insertions(+), 9 deletions(-) (attached as hdparm-ubuntu-debian.interdiff) Lets spread these changes into distinct changesets: * debian/hdparm.init = Debian has a *lock* in place for a RAID workaround. * debian/hdparm.udev = Change a rule to only match /dev/[sh]d[a-z] instead of /dev/[sh]d[a-z]* * debian/95hdparm-apm = comments only / noise * debian/control = Add dependency on lsb-base (and some noise) - Unlikely to be the problem as I doubt you uninstalled lsb-base just to test this. * debian/rules = Change to if/how the service should be started. - My take here is that this is Ubuntu specific due to their (previous?) use of upstart Thanks, ~Niels
Bug#782838: gvfs
Why does gparted end up triggering that command ? -- Søren Holm signature.asc Description: This is a digitally signed message part.
Bug#759657: console-setup: document settings #1
Package: console-setup Version: 1.121 Followup-For: Bug #759657 This is just to document system information - right after boot - showing the wrong setup (forgotten font) - before fixing by reconfiguring console-setup in case it is any different from the following report. Karsten -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'testing-updates'), (500, 'stable-updates'), (500, 'stable'), (50, 'unstable'), (10, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.19.0-trunk-686-pae (SMP w/2 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages console-setup depends on: ii console-setup-linux 1.121 ii debconf 1.5.56 ii keyboard-configuration 1.121 ii xkb-data2.12-1 console-setup recommends no packages. Versions of packages console-setup suggests: ii locales2.19-17 ii locales-all [locales] 2.19-17 ii lsb-base 4.1+Debian13+nmu1 Versions of packages keyboard-configuration depends on: ii debconf 1.5.56 ii initscripts 2.88dsf-59 ii liblocale-gettext-perl 1.05-8+b1 Versions of packages console-setup-linux depends on: ii kbd 1.15.5-2 ii keyboard-configuration 1.121 console-setup-linux suggests no packages. Versions of packages console-setup is related to: pn console-common none pn console-datanone pn console-tools none ii kbd 1.15.5-2 -- debconf information: keyboard-configuration/ctrl_alt_bksp: false console-setup/codesetcode: Lat15 keyboard-configuration/model: Generische PC-Tastatur mit 105 Tasten (Intl) * console-setup/codeset47: # Latin1 and Latin5 - western Europe and Turkic languages keyboard-configuration/xkb-keymap: de(nodeadkeys) keyboard-configuration/unsupported_config_options: true keyboard-configuration/modelcode: pc105 console-setup/framebuffer_only: keyboard-configuration/variantcode: nodeadkeys * console-setup/fontface47: Terminus debian-installer/console-setup-udeb/title: keyboard-configuration/layoutcode: de keyboard-configuration/switch: No temporary switch console-setup/fontsize-text47: 8x16 keyboard-configuration/unsupported_layout: true keyboard-configuration/altgr: The default for the keyboard layout keyboard-configuration/optionscode: keyboard-configuration/other: keyboard-configuration/compose: No compose key keyboard-configuration/store_defaults_in_debconf_db: true keyboard-configuration/toggle: No toggling console-setup/use_system_font: keyboard-configuration/variant: Deutsch - Deutsch (ohne Akzenttasten) console-setup/fontsize: 8x16 keyboard-configuration/unsupported_config_layout: true console-setup/guess_font: keyboard-configuration/unsupported_options: true keyboard-configuration/layout: * console-setup/charmap47: UTF-8 * console-setup/fontsize-fb47: 8x16 console-setup/store_defaults_in_debconf_db: true -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767858: libcairo2: SIGBUS
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Dear maintainer! I experience similiar problems when using rsvg-convert on sparc (which depends on libcairo2). gdb --args rsvg-convert -w 64 -h 64 -f png -o sudoku.png debian/icons/sudoku.svg Reading symbols from rsvg-convert...(no debugging symbols found)...done. (gdb) run Starting program: /usr/bin/rsvg-convert -w 64 -h 64 -f png -o sudoku.png debian/icons/sudoku.svg [Thread debugging using libthread_db enabled] Using host libthread_db library /lib/sparc-linux-gnu/libthread_db.so.1 . Program received signal SIGBUS, Bus error. 0xf7c163c8 in ?? () from /usr/lib/sparc-linux-gnu/libcairo.so.2 Is there any progress on that? Greetings Peter -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJVM4ApAAoJED/ImGelQYVWeh8QAIR0v/MkJyB33h66sOn2cAR4 Z+f/+uDd+q2K+x+osN4vfQb/t4itP2GG2jbKKsIcZGMC+k8WzQbZ3CEHsiznKhdb BukWDsTZZIT4SSBdlWZuULh8xu1vjZYDPsorviclgMO+X8o7PbAyC7xgeJeSahF+ pLOkpfpj2Ftplnzo9oiMIsaSu3Gev1AZ/SU/5By/PbyuL+S7/l+W+igiocUot2la WhH05HawGI8JrAt30RDCSEhaxjfRfAjv0YPa9/zHu2bjvbixdU5Zuypyy/tqKXv4 YGgRsmYPWlB+l8j7ZtTzlprvwg4L1vOOB14jl+5BZdghnncxyqdWP9NBqwap0FNW 7OUsISo0EOgCRJgA1oZceIrX2hN0TaPYdLagGKWGeQljdX1UBCGcywPJiLNM3f7V b/Ozi8RDZ/YKk7rHWX4z7QwYG7s1+aSR2Ee6fGTcqPaCDnUtYq6KOrFyx9/Vj0iZ WFc2VWFGjN4u8/KAvavt/kgsFn1ugOvrGLPiOMSKYgH9vC5aAErdzmfEY+YUQLrq ZVUDyc46KIEKDh1ZrOW+6xJP/ZFf4rh/7hdPksmwqS3WuW0kDm71rNl4bDxz/qNP ul0d3DvkX4KfMA72jhBBZ4Q6r8J1FEXb53nUQkCK29hFT9DDiO1f4VuQDtItTDIV pKIFNS9oR8O8W5EKT7ll =ofvE -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#782764: r-base-dev: Make it possible for maintainers to set builttimeStamp in d/rules
On 18.04.2015 at 15:37, Dirk Eddelbuettel wrote: On 18 April 2015 at 15:22, Johannes Ranke wrote: | Am Samstag, 18. April 2015, 06:27:03 schrieb Dirk Eddelbuettel: | On 18 April 2015 at 11:15, Philip Rinn wrote: | | Hi, | | | | I think this patch is more what I wanted. | | It now sets the build-timestamp to the time of the last changelog entry if | | the maintainer does not set builttimeStamp explicitly. | | With this change almost all GNU R packages in Debian would automatically | | build reproducible. | | And I presume that is what we want? I never heard from the reproducibility | group after I made the two patches (cf old bug report) to R itself and | r-cran.mk. Yes, I think so. I asked on the #debian-reproducible IRC channel yesterday and got a looks good to me back. This change would make at least 223 [1] GNU R packages build reproducible - that's about 5% of all FTBR packages. | Without having further background information I would say that the build- | timestamp should be either set to the build time (to carry correct | information) or not at all (to have reproducible builds). Context: R _always_ puts one hin, hence the discussion in the earlier bug report and my (long-accepted) upstream ptahc to be able to override. What Philip is suggesting here is to use the hook I provided with a suitable value -- the timestamp from debian/changelog. I think I'll do that. Well, defaulting to builttimeStamp = would work too, but for me it looks better to have the timestamp when the package was modified there. Dirk, at a workshop | Johannes | | Too bad you sent me this today. I just made four uploads of R in the last | few days leading up to R 3.2.0. Yes, I saw that, but I didn't had time earlier this week. Having that set with the start of the new release cycle would have been nice but it's not mandatory I think. Philip | | Dirk | | | Best, | | Philip | | | | x[DELETED ATTACHMENT usable_builttimeStamp2.patch, text/x-patch] | | x[DELETED ATTACHMENT signature.asc, application/pgp-signature] [1] https://reproducible.debian.net/issues/unstable/timestamps_in_description_files_generated_by_r-base-dev_issue.html signature.asc Description: OpenPGP digital signature
Bug#780673: gitolite3: git-annex shell is not working: FATAL: bad git-annex-shell command - patch available
patch 780673 + jessie severity 780673 serious thanks I've just upgraded to Jessie and tried to download some data and now my repositories are broken and I cannot do anything with them. I only get get foo/bar (not available) Try making some of these repositories available: 52f2bae6-e67e-11e4-a474-0021ccb48233 (Note that these git remotes have annex-ignore set: origin) failed git-annex: get: 1 failed and it doesn't even want to work after I've applied the patch. New clones seem to work with the data which was already on the server but my other ones seem to be now broken and I have possible data loss. I will most likely spend the rest of the weekend getting the lost data out of the backups... hoping that the backup software in Jessie isn't also broken :( -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782876: modemmanager: modem-manager stops working after some time
Package: modemmanager Version: 0.5.2.0-2 Severity: normal Dear Maintainer, sometimes modem-manager stops working after some time. If kill modem-manager, everything works. file log: #modem work Apr 19 01:30:30 debian modem-manager[10837]: debug [1429381830.580635] [mm- at-serial-port.c:333] debug_log(): (ttyUSB2): -- 'CRLF^DSFLOWRPT:1126,07F2,18A8,0049DD7A,01CFE745,00107AC0,00107AC0CRLF' Apr 19 01:30:30 debian modem-manager[10837]: debug [1429381830.580724] [mm- modem-huawei-gsm.c:725] handle_status_change(): Duration: 4390 Up: 16 Kbps Down: 50 Kbps Total: 4727 Total: 29689#012 #modem fail Apr 19 01:30:30 debian modem-manager[10837]: debug [1429381830.580635] [mm- at-serial-port.c:333] debug_log(): (ttyUSB2): -- 'CRLF^DSFLOWRPT:1126,07F2,18A8,0049DD7A,01CFE745,00107AC0,00107AC0CRLF' Apr 19 01:30:30 debian modem-manager[10837]: debug [1429381830.580724] [mm- modem-huawei-gsm.c:725] handle_status_change(): Duration: 4390 Up: 16 Kbps Down: 50 Kbps Total: 4727 Total: 29689#012 Apr 19 01:30:31 debian pppd[21442]: Modem hangup Apr 19 01:30:31 debian pppd[21442]: Connect time 73.2 minutes. Apr 19 01:30:31 debian pppd[21442]: Sent 4841362 bytes, received 30410145 bytes. Apr 19 01:30:31 debian kernel: [93970.316975] usb 7-1: USB disconnect, device number 45 Apr 19 01:30:31 debian kernel: [93970.318696] option1 ttyUSB0: option_instat_callback: error -108 Apr 19 01:30:31 debian kernel: [93970.318919] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.318924] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.318926] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.318929] option1 ttyUSB0: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.319419] option1 ttyUSB0: GSM modem (1-port) converter now disconnected from ttyUSB0 Apr 19 01:30:31 debian kernel: [93970.319439] option 7-1:1.0: device disconnected Apr 19 01:30:31 debian kernel: [93970.319508] cdc_ether 7-1:1.1 wwan0: unregister 'cdc_ether' usb-:00:1d.7-1, Mobile Broadband Network Device Apr 19 01:30:31 debian avahi-daemon[3066]: Withdrawing workstation service for wwan0. Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.944640] [mm- manager.c:862] device_removed(): (tty/ttyUSB0): released by modem /sys/devices/pci:00/:00:1d.7/usb7/7-1 Apr 19 01:30:31 debian modem-manager[10837]: debug [1429381831.944701] [mm- serial-port.c:844] mm_serial_port_close(): (ttyUSB0) device open count is 0 (close) Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.944721] [mm- serial-port.c:859] mm_serial_port_close(): (ttyUSB0) closing serial port... Apr 19 01:30:31 debian modem-manager[10837]: debug [1429381831.944743] [mm- port.c:181] mm_port_set_connected(): (ttyUSB0): port now disconnected Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.944776] [mm- serial-port.c:880] mm_serial_port_close(): (ttyUSB0) serial port closed Apr 19 01:30:31 debian modem-manager[10837]: debug [1429381831.944831] [mm- modem-base.c:185] mm_modem_base_remove_port(): (ttyUSB0) type primary removed from /sys/devices/pci:00/:00:1d.7/usb7/7-1 Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.944993] [mm- modem.c:746] mm_modem_set_state(): Modem /org/freedesktop/ModemManager/Modems/16: state changed (connected - disabled) Apr 19 01:30:31 debian modem-manager[10837]: debug [1429381831.945031] [mm- manager.c:204] remove_modem(): Removed modem /sys/devices/pci:00/:00:1d.7/usb7/7-1 Apr 19 01:30:31 debian modem-manager[10837]: debug [1429381831.945133] [mm- serial-port.c:844] mm_serial_port_close(): (ttyUSB2) device open count is 0 (close) Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.945163] [mm- serial-port.c:859] mm_serial_port_close(): (ttyUSB2) closing serial port... Apr 19 01:30:31 debian NetworkManager[3129]: info (ttyUSB0): now unmanaged Apr 19 01:30:31 debian NetworkManager[3129]: info (ttyUSB0): device state change: activated - unmanaged (reason 'removed') [100 10 36] Apr 19 01:30:31 debian kernel: [93970.320802] option1 ttyUSB2: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.322671] option1 ttyUSB2: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian modem-manager[10837]: info [1429381831.947166] [mm- serial-port.c:880] mm_serial_port_close(): (ttyUSB2) serial port closed Apr 19 01:30:31 debian pppd[21442]: Connection terminated. Apr 19 01:30:31 debian avahi-daemon[3066]: Withdrawing workstation service for ppp0. Apr 19 01:30:31 debian kernel: [93970.324171] option1 ttyUSB2: usb_wwan_indat_callback: resubmit read urb failed. (-19) Apr 19 01:30:31 debian kernel: [93970.324418] option1 ttyUSB2: usb_wwan_indat_callback: resubmit read urb failed. (-19)
Bug#782794: ejabberdctl outgoing-s2s-number and incoming-s2s-number always report 0
Hi, we'll try getting this in with the first point release. Regards, -- .''`. Philipp Huebner debala...@debian.org : :' : pgp fp: 6719 25C5 B8CD E74A 5225 3DF9 E5CA 8C49 25E4 205F `. `'` `- signature.asc Description: OpenPGP digital signature
Bug#775541:
Ditto, tagging it accordingly (maybe a close would be more appropriate?). Maybe downgrading for the time being (currently it is RC)? -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782838: gvfs
Control: found -1 2.1.3-5 Control: fixed -1 2.1.5-1 On Sat, Apr 18, 2015 at 08:00:38PM -0400, Michael Gilbert wrote: [...] The following is the command in the udisks2-inhibit script that fails $ mount --move /run/udisks2/inhibit-polkit /var/lib/polkit-1/localauthority/90-mandatory.d udisks2 (2.1.5-1) experimental; urgency=medium [...] * udisks2-inhibit: Don't use mount --move, as it doesn't work under shared mounts (i. e. under systemd). (LP: #1410851) [...] Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#778831: Update: Udevil is not dead anymore
Hello, I'd like to point out that udevil and SpaceFM are not dead anymore, just developed at a slower pace, but it is maintained and fixed when needed. https://igurublog.wordpress.com/2015/03/02/spacefm-and-udevil-resume-slow-development/ Kind regards, Ondřej Grover
Bug#780599: verbiste: FTBFS on various architectures due to outdated symbols file
On 17/03/15 08:09, Tomasz Buchert wrote: Hi, [...] It turns out that the version 0.1.41-2 had *no* symbols file and for all I know, it wouldn't build on some archs just as 0.1.41-3. I decided to drop symbols file altogether since making it work with all architecture/g++/STL details is madness. This is not a big issue because libverbiste is used only by verbiste. If one day another package will use libverbiste (unlikely), I will reconsider symbols file, but for now, it just doesn't make sense to manage it. I'm uploading a new package as I write this. Tomasz signature.asc Description: Digital signature
Bug#782877: libgtk-appindicator: please make the build reproducible
Source: libgtk-appindicator Version: 0.15-1 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 libgtk-appindicator could not be built reproducibly. The attached patch removes extra timestamps from the build system and ensure a stable file order when creating the source archive. Once applied, libgtk-appindicator can be built reproducibly in our current experimental framework. [1]: https://wiki.debian.org/ReproducibleBuilds diff -ur libgtk2-appindicator-perl-0.15/debian/rules libgtk2-appindicator-perl-0.15-new/debian/rules --- libgtk2-appindicator-perl-0.15/debian/rules 2012-11-18 16:47:50.0 + +++ libgtk2-appindicator-perl-0.15-new/debian/rules 2015-04-19 10:49:16.834256296 + @@ -1,5 +1,9 @@ #!/usr/bin/make -f +BUILD_DATE = $(shell dpkg-parsechangelog -S Date) +POD_MAN_DATE = $(shell date -u +%Y-%m-%d --date=$(BUILD_DATE)) +export POD_MAN_DATE + %: dh $@ signature.asc Description: Digital signature
Bug#782880: RM: debmake/4.1.7-2
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Please remove this package since it has not so nice bug as reported by the maintainer (me) as serious: http://bugs.debian.org/782850 sloppy copyright name bunching Considering other rough edges, I think releasing to stable is not a good idea although it was useful to scan license text thoroughly. Please remove this from testing. PS: I will upload one to unstable for stetch. -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) signature.asc Description: Digital signature
Bug#763949: osmium: Pack new libosmium
Control: block 763949 by 779923 Hi Nelson, On 10/04/2014 09:13 AM, Jochen Topf wrote: On Sa, Okt 04, 2014 at 12:49:48 -0300, Nelson A. de Oliveira wrote: Is it possible to have the new libosmium (from https://github.com/osmcode/libosmium) available at experimental, please? (or with another name/namespace maybe) I am the maintainer of that software. While I eventually want this to be in Debian, I don't think it is quite ready yet. I was planning to start a proper release soon and then bring this into Debian once Jessie is out. This has since changed, and the new libosmium has been packaged and is in the NEW queue since last month. https://ftp-master.debian.org/new/libosmium_2.0.0-1.html https://ftp-master.debian.org/new/libosmium_2.1.0-1.html Once libosmium passes the NEW queue we can upload its dependents. Kind Regards, Bas -- GPG Key ID: 4096R/6750F10AE88D4AF1 Fingerprint: 8182 DE41 7056 408D 6146 50D1 6750 F10A E88D 4AF1 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782884: ruby-sqlite3: please make the package build reproducibly
Source: ruby-sqlite3
Version: 1.3.9-2
Severity: wishlist
Tags: patch
User: reproducible-bui...@lists.alioth.debian.org
Usertags: randomness
Hi!
While working on the “reproducible builds” effort [1], we have noticed
that ruby-sqlite3 could not be built reproducibly.
The attached patch changes the FAQ generator to use slugs instead of
object ids. Once applied, ruby-sqlite3 can be built reproducibly in our
current experimental framework.
[1]: https://wiki.debian.org/ReproducibleBuilds
--
Lunar.''`.
lu...@debian.org: :Ⓐ : # apt-get install anarchism
`. `'`
`-
From 7289d73c3c7a88f09822696d7f4fe4e05268f531 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Bobbio?= lu...@debian.org
Date: Sun, 19 Apr 2015 13:59:42 +0200
Subject: [PATCH] Use slugs instead of object ids for internal links in FAQ
This makes the package build reproducibly.
---
debian/changelog | 8
debian/patches/series| 1 +
debian/patches/use-slugs-in-faq.diff | 36
3 files changed, 45 insertions(+)
create mode 100644 debian/patches/use-slugs-in-faq.diff
diff --git a/debian/changelog b/debian/changelog
index e35c5cb..8f01248 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,11 @@
+ruby-sqlite3 (1.3.9-2.0~reproducible1) UNRELEASED; urgency=low
+
+ * debian/patches/use-slugs-in-faq.diff: use slugs instead of
+object ids for internal links in FAQ. This makes the package
+build reproducibly.
+
+ -- Jérémy Bobbio lu...@debian.org Sun, 19 Apr 2015 11:50:10 +
+
ruby-sqlite3 (1.3.9-2) unstable; urgency=medium
* Team upload.
diff --git a/debian/patches/series b/debian/patches/series
index 3a38c2e..c6f46f4 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1 +1,2 @@
handle-big-endian.diff
+use-slugs-in-faq.diff
diff --git a/debian/patches/use-slugs-in-faq.diff b/debian/patches/use-slugs-in-faq.diff
new file mode 100644
index 000..dd65e36
--- /dev/null
+++ b/debian/patches/use-slugs-in-faq.diff
@@ -0,0 +1,36 @@
+Description: Use slugs in FAQ instead of object_id
+ In order to make the FAQ build reproducibly we use “slugs” for
+ internal links instead of object ids.
+Author: Jérémy Bobbio lu...@debian.org
+
+--- ruby-sqlite3-1.3.9.orig/faq/faq.rb
ruby-sqlite3-1.3.9/faq/faq.rb
+@@ -1,6 +1,10 @@
+ require 'yaml'
+ require 'redcloth'
+
++def slugify( str )
++ str.downcase.strip.gsub(' ', '-').gsub(/[^\w-]/, '')
++end
++
+ def process_faq_list( faqs )
+ puts ul
+ faqs.each do |faq|
+@@ -20,7 +24,7 @@ def process_faq_list_item( faq )
+ puts question_text
+ process_faq_list answer
+ else
+-print a href='##{question.object_id}'#{question_text}/a
++print a href='##{slugify(question)}'#{question_text}/a
+ end
+
+ puts /li
+@@ -43,7 +47,7 @@ def process_faq_description( faq, path )
+ title = RedCloth.new( path ).to_html.gsub( %r{/?p}, )
+ answer = RedCloth.new( answer || )
+
+-puts a name='#{question.object_id}'/a
++puts a name='#{slugify(question)}'/a
+ puts div class='faq-title'#{title}/div
+ puts div class='faq-answer'#{add_api_links(answer.to_html)}/div
+ end
--
1.9.1
signature.asc
Description: Digital signature
Bug#782889: [Aptitude-devel] Bug#782889: aptitude: forget-new option doesn't work
Control: forcemerge -1 782777 Hi Domenico, Domenico Cufalo wrote: in my Jessie system I have five libraries (libdb5.3, libldap-2.4-2, libsasl2*) marked as new in ncurses interface of aptitude. Neither if I press f inside aptitude nor if I give forget-new outside it, I can hide these packages from the list of new packages. Thanks for the report. This already has been reported in https://bugs.debian.org/782777, but your report mentions a different set of libraries than before, so adds something. A few questions to see if previously noticed commonalities are still valid: * Do you have either experimental or also stable in the sources.list? * Did it happen immediately after upgrading apt to 1.0.9.8 or only later, after some package management actions (apt-get update, e.g. via cron, etc.) happened? Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 `-| 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782851: unzip: please make unzip build reproducibly
Santiago Vila: When looking at the different reports which I have received so far, I see that some of them have the goal of making the build reproducible in the sense of same file contents (i.e. unpackaged file tree after dpkg-deb -x), while the most recent reports seem to have the stronger goal of completely identical .deb (which involves the clever touch/BUILD_DATE debian/rules trick usually found in the most recent pacthes received). The questions: * Was identical .deb file already the goal at the very beginning, or was the goal changed to that after the project started? (possibly after realizing that it was easy to achieve). At least for me, it always have been the goal. In my dreams, maintainers would stop uploading .deb to the archive, but keep the checksums in the .changes. buildds would then perform the build, and the binary packages would only enter the archive if the buildd products match the ones from the maintainer. * Does dh really take care of the build date issue to achieve a completely identical .deb? In the case of unzip, using dh would make the changes to debian/rules unnecessary. The upstream patch would still be needed though. diff -Nru unzip-6.0/debian/patches/13-remove-build-date unzip-6.0/debian/patches/13-remove-build-date --- unzip-6.0/debian/patches/13-remove-build-date 1970-01-01 01:00:00.0 +0100 +++ unzip-6.0/debian/patches/13-remove-build-date 2015-04-18 21:59:26.0 +0200 @@ -0,0 +1,16 @@ +Description: Remove build date + In order to make unzip build reproducibly, we remove the + (already optional) build date from the binary. +Author: Jérémy Bobbio lu...@debian.org + +--- unzip-6.0.orig/unix/unix.c unzip-6.0/unix/unix.c +@@ -1705,7 +1705,7 @@ void version(__G) + #endif /* Sun */ + #endif /* SGI */ + +-#ifdef __DATE__ ++#if 0 +on , __DATE__ + #else + , I would rather undefine __DATE__ so that I don't even have to touch the source code (will find the way to do that, don't worry). In either case, I will forward this upstream because I see it as an upstream bug (maybe they remove the __DATE__ stuff altogether, who knows?) Yes! Please do take such changes upstream. They might benefit the wider free software world. :) You can redefined __DATE__ but then the pre-precosser will issue a warning: $ echo __DATE__ | cpp -D __DATE__=\Now\ # 1 stdin # 1 command-line command-line:0:0: warning: __DATE__ redefined [-Wbuiltin-macro-redefined] # 1 stdin Now Thanks for your consideration! -- Lunar.''`. lu...@debian.org: :Ⓐ : # apt-get install anarchism `. `'` `- signature.asc Description: Digital signature
Bug#782974: installation-reports: Jessie RC2 netinst - UEFI boot issues, success at 2nd attempt
Package: installation-reports Severity: normal Tags: d-i -- Package-specific info: Boot method: CD Image version: http://cdimage.debian.org/cdimage/jessie_di_rc2/amd64/iso-cd/debian-jessie-DI-rc2-amd64-netinst.iso Date: 2015-04-17 22:16 Machine: HP Pavilion 500-308ng Partitions: bjoern@suvereto:~$ sudo /sbin/parted -l /dev/sda Model: ATA WDC WD10EZEX-60M (scsi) Disk /dev/sda: 1000GB Sector size (logical/physical): 512B/4096B Partition Table: gpt Disk Flags: Number Start End SizeFile system Name Flags 1 1049kB 1074MB 1073MB ntfsBasic data partition hidden, diag 2 1074MB 1451MB 377MB fat32 EFI system partition boot, esp 3 1451MB 1585MB 134MB Microsoft reserved partition msftres 4 1585MB 265GB 264GB ntfsBasic data partition msftdata 6 265GB 265GB 19,9MB biosgrub bios_grub 7 265GB 315GB 50,0GB ext4debian_root 8 315GB 332GB 17,0GB linux-swap(v1) swap 9 332GB 986GB 654GB ext4home 5 986GB 1000GB 13,7GB ntfsBasic data partition hidden, msftdata Base System Installation Checklist: [O] = OK, [E] = Error (please elaborate below), [ ] = didn't try it Initial boot: [O] Detect network card:[O] Configure network: [O] Detect CD: [O] Load installer modules: [O] Clock/timezone setup: [O] User/password setup:[O] Detect hard drives: [O] Partition hard drives: [O] Install base system:[O] Install tasks: [E] Install boot loader:[E] Overall install:[O] Comments/Problems: Installing on a virgin x86-64 machine with UEFI BIOS for dual-booting a manually shrunk Windows 8.1 installation. Secure Boot had been disabled. At first try, the EFI boot menu did not offer the DVD drive as an EFI Boot target, but would boot d-i in legacy mode. I chose the text mode installation. The installation went along reasonably well, with the following exceptions: - task-gnome-desktop was uninstallable due to broken dependencies, so i unticked it and used XFCE as a replacement. - WISHLIST ITEM: It would be nice if one could change the size of the partitions created by the guided procedure. - The proposal to install grub into the MBR of an EFI system left me wondering. However, rebooting into the newly installed Debian failed (no GRUB menu, booting into Windows without any choice). Rebooting the d-i-CD in recue mode (kudos for offering that mode!), I saw that that grub-pc had been installed (which explains the above mentioned MBR question). I manually installed grub-efi-amd64 instead of grub-pc. This did not resolve the boot issue, but (surprise!) changed the BIOS boot menu so that I could select the DVD drive as an EFI boot target after the next reboot. I rebooted the d-i-CD again in rescue mode. After fiddling back and forth with a few steps, it somehow fell into the routine of a normal install. I then did the installation all over again. This took some patience, but rewarded me with a working GRUB menu and bootable Debian. == Installer lsb-release: == DISTRIB_ID=Debian DISTRIB_DESCRIPTION=Debian GNU/Linux installer DISTRIB_RELEASE=8 (jessie) - installer build 20150324 X_INSTALLATION_MEDIUM=cdrom == Installer hardware-summary: == uname -a: Linux suvereto 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt7-1 (2015-03-01) x86_64 GNU/Linux lspci -knn: 00:00.0 Host bridge [0600]: Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:2af7] lspci -knn: Kernel driver in use: hsw_uncore lspci -knn: 00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor PCI Express x16 Controller [8086:0c01] (rev 06) lspci -knn: Kernel driver in use: pcieport lspci -knn: 00:14.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB xHCI [8086:8c31] (rev 05) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:2af7] lspci -knn: Kernel driver in use: xhci_hcd lspci -knn: 00:16.0 Communication controller [0780]: Intel Corporation 8 Series/C220 Series Chipset Family MEI Controller #1 [8086:8c3a] (rev 04) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:2af7] lspci -knn: 00:1a.0 USB controller [0c03]: Intel Corporation 8 Series/C220 Series Chipset Family USB EHCI #2 [8086:8c2d] (rev 05) lspci -knn: Subsystem: Hewlett-Packard Company Device [103c:2af7] lspci -knn: Kernel driver in use: ehci-pci lspci -knn: 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series Chipset High Definition Audio Controller [8086:8c20]
Bug#782972: ruby2.1: FTBFS on m68k since a few uploads
* Thorsten Glaser t...@mirbsd.de [150419 23:57]: ruby2.1 has been building fine for a while, but recently FTBFSing. Please find the patch attached, for both inclusion and forwarding to upstream, which may or may not be needed, depends on whether Andreas Schwab already did so. Thanks for your report. This is upstream revision 48065. AFAICT, it's also in the 2.2 branch, but not (yet?) in 2.1. -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- pgpu6NuxbBugA.pgp Description: PGP signature
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
Package: debian-installer-netboot-images Severity: serious The RC policy states Packages must be buildable within the same release.. In this context I interpret buildable as buildable from actual sourcecode (not just package together) and the same release as the collection of stuff that Debian will be officially releasing as jessie. kfreebsd was removed from the jessie release. AIUI this means it will not be possible to build the kfreebsd debian installer on any official jessie system. As such IMO kfreebsd images should not be included in this package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782978: RM: harden -- RoQA; no longer useful
Package: ftp.debian.org Severity: normal The maintainer thinks it would be best for it to be removed: https://bugs.debian.org/760449 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782976: debian-installer-netboot-images packages kfreebsd images but kfreebsd is not in jessie.
peter green plugw...@p10link.net (2015-04-20): Package: debian-installer-netboot-images Severity: serious The RC policy states Packages must be buildable within the same release.. In this context I interpret buildable as buildable from actual sourcecode (not just package together) and the same release as the collection of stuff that Debian will be officially releasing as jessie. So you meant to file a bug against debian-installer rather than d-i-n-i? kfreebsd was removed from the jessie release. AIUI this means it will not be possible to build the kfreebsd debian installer on any official jessie system. As such IMO kfreebsd images should not be included in this package. Well, a discussion has been started about what to do with kfreebsd stuff: https://lists.debian.org/debian-release/2015/04/msg00552.html Mraw, KiBi. signature.asc Description: Digital signature
Bug#782912: RM: freedombox-setup/0.0.43
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello, The FreedomBox project is under active development but does not have the resources to make a stable release at this point and support it for a long time. There is a consensus among the developers to focus our efforts on unstable packages and not release the package in Jessie. With this bug, I request removal of Plinth and corresponding package freedombox-setup from Jessie. Thank you, -- Sunil Mohan Adapa -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782915: release-notes: please add news from Debian GIS to release notes
Package: release-notes Severity: normal Tags: patch Hi, please consider inserting the attached dbk snipped into release notes at a place of your preference (since I did not used the patch format). Thanks for your work for the Debian release Andreas. -- System Information: Debian Release: 7.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Title: News from Debian GIS Blend During the jessie development cycle many changes from UbuntuGIS were incorporated (back) into Debian GIS. The collaboration with UbuntuGIS and OSGeo-Live projects was improved, resulting in new packages and contributors. Visit Debian GIS tasks pages to see the full range of GIS software inside Debian.
Bug#764982: Backports, where is the danger (why the FUD)
Op 19-04-15 om 20:59 schreef Turbo Fredriksson: On Apr 19, 2015, at 8:25 PM, Geert Stappers wrote: What is the danger of having backports (default) enabled? From what I've seen (when I tried it a couple of years ago), is that the back porting is quite … sloppy. If the package needs a newer lib, that is back ported as well. And the newer lib that depends on etc, etc. Eventually, you end up with such a bastardizised version of dist, it simply WILL break in mysterious ways (and it have for me, which is why is stopped using it). Did you check if it really was backports? I use backports on all machines I care about, and I never had dependency problems from backports (so far I remember). The correct way is, off course, to do the back port properly, make the software work with the version of the libraries etc that's already in the repo/dist. So far I know backports are made the correct way. This type of problems are most of time coming from other repositories, outside Debian. If you don't want backports for some reason, is easy to disable them in sources.list. With regards, Paul vand er Vlis. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782968: ITP: libmuscle -- multiple alignment library for protein sequences
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: libmuscle Version : 3.7 Upstream Author : Aaron Darling darl...@cs.wisc.edu * URL : http://sourceforge.net/p/mauve/code/HEAD/tree/muscle/ * License : Public domain Programming Lang: C++ Description : multiple alignment library for protein sequences MUSCLE is a multiple alignment program for protein sequences. MUSCLE stands for multiple sequence comparison by log-expectation. In the authors tests, MUSCLE achieved the highest scores of all tested programs on several alignment accuracy benchmarks, and is also one of the fastest programs out there. . This library was derived from the original MUSCLE and turned into a library. Remark: This library is packaged as a precondition of the Mauve multiple genome alignment package by the Debian Med team at git://anonscm.debian.org/debian-med/libmuscle.git -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#764982: Backports, where is the danger (why the FUD)
Op 19-04-15 om 22:00 schreef Turbo Fredriksson: If someone wants newer version, they can (should!) upgrade to the newer distribution. OR, if they're brave, use back ports. Do you mean upgrade to testing? Nobody gets a newer version by enabling backports in sources.list, you only get a newer version by using apt-get -t The problem is about packages what are NOT in stable. If you don't want backports for some reason, is easy to disable them in sources.list. Why!? Why should _I_ adapt to YOUR opinion? What makes you think that YOUR opinion is the only, correct one?? Because this is not a RC bug. Debian GNU/Linux don't enable contrib and non-free by default (or does it now, haven't checked). And yet _I_ choose to use packages from there. Why shouldn't EVERYONE be 'forced' to disable that, just to accommodate me?! Same with back ports. They're not really part of the Debian GNU/Linux distribution. Only 'main' is. The're all provided on the Debian GNU/Linux servers, but they're not the official distribution. So only 'main' should be enabled by default by the installer. Backports main is official Debian. [1] Besides, why are you still arguing about this? The decision have been made. Live with it. If you really, really think this decision is in error, then lobby for changing it in the next release. Now, the discussion is moot and pointless - suck it up. I've waited long for this. I've published about it. For me it's a big point. And then comes Cyril who removes it at the last moment... Not OK in my opinion. With regards, Paul van der Vlis. [1] https://www.debian.org/News/2010/20100905 -- Paul van der Vlis Linux systeembeheer, Groningen http://www.vandervlis.nl -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782972: ruby2.1: FTBFS on m68k since a few uploads
Source: ruby2.1 Version: 2.1.5-3 Severity: important Tags: patch Hi, ruby2.1 has been building fine for a while, but recently FTBFSing. Please find the patch attached, for both inclusion and forwarding to upstream, which may or may not be needed, depends on whether Andreas Schwab already did so. -- System Information: Debian Release: 8.0 APT prefers unreleased APT policy: (500, 'unreleased'), (500, 'unstable') Architecture: m68k Kernel: Linux 3.16.0-4-m68k Locale: LANG=C, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/lksh Init: sysvinit (via /sbin/init) diff -Nru ruby2.1-2.1.5/debian/changelog ruby2.1-2.1.5/debian/changelog --- ruby2.1-2.1.5/debian/changelog 2015-04-17 12:50:12.0 + +++ ruby2.1-2.1.5/debian/changelog 2015-04-19 12:53:37.0 + @@ -1,3 +1,9 @@ +ruby2.1 (2.1.5-3+m68k.1) unreleased; urgency=high + + * Apply m68k patch from Andreas Schwab, fixes FTBFS + + -- Thorsten Glaser t...@mirbsd.de Sun, 19 Apr 2015 14:53:09 +0200 + ruby2.1 (2.1.5-3) unstable; urgency=high * Fix vulnerabiity with overly permissive matching of hostnames in OpenSSL diff -Nru ruby2.1-2.1.5/debian/patches/m68k-fix ruby2.1-2.1.5/debian/patches/m68k-fix --- ruby2.1-2.1.5/debian/patches/m68k-fix 1970-01-01 00:00:00.0 + +++ ruby2.1-2.1.5/debian/patches/m68k-fix 2015-04-19 12:52:31.0 + @@ -0,0 +1,37 @@ +From sch...@suse.de Mon Oct 20 11:52:21 2014 +From: Andreas Schwab sch...@suse.de +Message-ID: mvmy4sbvuia@hawking.suse.de +X-Spam-Status: No, hits=0.00 required=0.90 +To: Thorsten Glaser t...@mirbsd.de +Cc: debian-...@lists.debian.org +Date: Mon, 20 Oct 2014 13:41:01 +0200 +Subject: Re: ruby2.1 FTBFS + +Please try this patch. + +Andreas. + +--- a/gc.c b/gc.c +@@ -3497,8 +3497,8 @@ mark_current_machine_context(rb_objspace + rb_gc_mark_locations(th-machine.register_stack_start, th-machine.register_stack_end); + #endif + #if defined(__mc68000__) +-mark_locations_array(objspace, (VALUE*)((char*)STACK_END + 2), +- (STACK_START - STACK_END)); ++rb_gc_mark_locations((VALUE*)((char*)stack_start + 2), ++ (VALUE*)((char*)stack_end - 2)); + #endif + } + +@@ -3513,6 +3513,10 @@ rb_gc_mark_machine_stack(rb_thread_t *th + #ifdef __ia64 + rb_gc_mark_locations(th-machine.register_stack_start, th-machine.register_stack_end); + #endif ++#if defined(__mc68000__) ++rb_gc_mark_locations((VALUE*)((char*)stack_start + 2), ++ (VALUE*)((char*)stack_end - 2)); ++#endif + } + + void diff -Nru ruby2.1-2.1.5/debian/patches/series ruby2.1-2.1.5/debian/patches/series --- ruby2.1-2.1.5/debian/patches/series 2015-04-17 12:50:41.0 + +++ ruby2.1-2.1.5/debian/patches/series 2015-04-19 12:52:31.0 + @@ -1 +1,2 @@ debian-changes +m68k-fix
Bug#782973: ifup wlanX fails for x0 because NetworkManager starts wpa_supplicant on unmanaged interface
Package: network-manager Version: 0.9.10.0-7 Severity: normal ifup fails for a wlan interface defined in /etc/network/interfaces when the interface is not wlan0 with wpa_supplicant: /sbin/wpa_supplicant daemon failed to start - wlan5 is defined in /etc/network/interfaces (there is no wlan0) - NetworkManager is running - USB wifi inserted and driver loaded - kernel driver creates network interface on wlan0 - systemd-udevd: renames network interface wlan0 to wlan5 - NetworkManager sets state unavailable (reason 'managed') - NetworkManager starts wpa_supplicant - NetworkManager sets state unmanaged (reason 'unmanaged') - wpa_supplicant is still running - `ifup wlan5` will now fail with: wpa_supplicant: /sbin/wpa_supplicant daemon failed to start because wpa_supplicant is already running. - This does not occur if wlan0 is unmanaged by creating a dummy entry in /etc/network/interfaces - ifup will work if NetworkManager is stopped and wpa_supplicant is killed Abbreviated log oddness: Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] Apr 19 16:34:38 debian dbus[2894]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): device state change: unavailable - unmanaged (reason 'unmanaged') [20 10 3] This has been tested with two different wifi devices and the behaviour is the same. --- journal: Apr 19 16:34:37 debian kernel: usb 1-1: reset high-speed USB device number 2 using xhci_hcd Apr 19 16:34:37 debian kernel: mt7601u 1-1:1.0: ASIC revision: 76010001 MAC revision: 76010500 Apr 19 16:34:37 debian kernel: mt7601u 1-1:1.0: Warning: unsupported EEPROM version 0d Apr 19 16:34:37 debian kernel: mt7601u 1-1:1.0: EEPROM ver:0d fae:00 Apr 19 16:34:38 debian kernel: ieee80211 phy2: Selected rate control algorithm 'minstrel_ht' Apr 19 16:34:38 debian kernel: usbcore: registered new interface driver mt7601u Apr 19 16:34:38 debian kernel: mt7601u 1-1:1.0 wlan5: renamed from wlan0 Apr 19 16:34:38 debian NetworkManager[2871]: info rfkill1: found WiFi radio killswitch (at /sys/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/ieee80211/phy2/rfkill1) (driver mt7601u) Apr 19 16:34:38 debian systemd[1]: Starting Load/Save RF Kill Switch Status of rfkill1... Apr 19 16:34:38 debian systemd[1]: Started Load/Save RF Kill Switch Status of rfkill1. Apr 19 16:34:38 debian systemd-udevd[4036]: renamed network interface wlan0 to wlan5 Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): using nl80211 for WiFi device control Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): new 802.11 WiFi device (driver: 'mt7601u' ifindex: 4) Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): exported as /org/freedesktop/NetworkManager/Devices/3 Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): device state change: unmanaged - unavailable (reason 'managed') [10 20 2] Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): preparing device Apr 19 16:34:38 debian dbus[2894]: [system] Activating via systemd: service name='fi.w1.wpa_supplicant1' unit='wpa_supplicant.service' Apr 19 16:34:38 debian NetworkManager[2871]: info devices added (path: /sys/devices/pci:00/:00:14.0/usb1/1-1/1-1:1.0/net/wlan5, iface: wlan5) Apr 19 16:34:38 debian NetworkManager[2871]: info get unmanaged devices count: 2 Apr 19 16:34:38 debian NetworkManager[2871]: info (wlan5): device state change: unavailable - unmanaged (reason 'unmanaged') [20 10 3] Apr 19 16:34:38 debian systemd[1]: Starting WPA supplicant... Apr 19 16:34:38 debian dbus[2894]: [system] Successfully activated service 'fi.w1.wpa_supplicant1' Apr 19 16:34:38 debian systemd[1]: Started WPA supplicant. Apr 19 16:34:38 debian wpa_supplicant[4056]: Successfully initialized wpa_supplicant Apr 19 16:34:38 debian kernel: IPv6: ADDRCONF(NETDEV_UP): wlan5: link is not ready Apr 19 16:34:38 debian kernel: IPv6: ADDRCONF(NETDEV_UP): wlan5: link is not ready Apr 19 16:34:38 debian NetworkManager[2871]: info wpa_supplicant started --- NetworkManager debug output: NetworkManager[4782]: debug [1429479542.305521] [platform/nm-linux-platform.c:1850] event_notification(): netlink event (type 16) for link: wlan0 (5, family 0) NetworkManager[4782]: debug [1429479542.305988] [platform/nm-linux-platform.c:412] get_kernel_object(): get_kernel_object for link: wlan0 (5, family 0) NetworkManager[4782]: debug [1429479542.307262] [nm-rfkill-manager.c:354] handle_uevent(): udev rfkill event: action 'add' device 'rfkill2' NetworkManager[4782]: info rfkill2: found WiFi radio killswitch (at /sys/devices/pci:00/:00:14.0/usb1/1-3/1-3.1/1-3.1:1.0/ieee80211/phy3/rfkill2) (driver mt7601u) NetworkManager[4782]: debug [1429479542.307546] [nm-rfkill-manager.c:210] recheck_killswitches(): WiFi rfkill switch rfkill2 state now 1/0 NetworkManager[4782]: debug [1429479542.307654] [nm-rfkill-manager.c:210]
Bug#782963: Please provide a python3 module
Help indeed would be appreciated On April 19, 2015 3:06:26 PM EDT, Paul Tagliamonte paul...@debian.org wrote: Package: statsmodels Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt -- Sent from a phone which beats iPhone.
Bug#782975: spacefm adds generated files to /etc/spacefm and does not remove them after purge
Source: spacefm Severity: normal After using this package, I found it generates some files in /etc/spacefm: [gq@brick:~]$ ls -la /etc/spacefm drwxr-xr-x 1 root root 44 апр 18 01:53 . drwxr-xr-x 1 root root 3866 апр 19 18:31 .. -rw-r--r-- 1 root root 146 апр 18 01:53 gq-as-root -rw-r--r-- 1 root root 164 апр 18 01:53 spacefm.conf I think, this should go somewhere to /var/lib or /var/cache, because these files are not intended to be modified by hand. After I removed and purged the package, I've found that these files are still it /etc. This is 100% Policy violation. -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (680, 'testing'), (600, 'unstable'), (550, 'experimental'), (500, 'testing-updates') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=ru_RU.utf8, LC_CTYPE=ru_RU.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782977: gimp: Suggests packages which don't exist in jessie
Package: gimp Version: 2.8.14-1+b1 Severity: normal Dear Maintainer, Upon a new installation of jessie, I attempted to install GIMP including its suggested packages. The package suggests gimp-help-en or gimp-help of which there are no installation candidates. It seems that somehow the method of documentation GIMP is handled differently in the new version. Can these suggestions be removed? -- System Information: Debian Release: 8.0 APT prefers testing-updates APT policy: (500, 'testing-updates'), (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.16.0-4-amd64 (SMP w/4 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 gimp depends on: ii gimp-data2.8.14-1 ii libaa1 1.4p5-43 ii libatk1.0-0 2.14.0-1 ii libbabl-0.1-00.1.10-2 ii libbz2-1.0 1.0.6-7+b3 ii libc62.19-17 ii libcairo21.14.0-2.1 ii libdbus-1-3 1.8.16-1 ii libdbus-glib-1-2 0.102-1 ii libexif120.6.21-2 ii libexpat12.1.0-6+b3 ii libfontconfig1 2.11.0-6.3 ii libfreetype6 2.5.2-3 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgegl-0.2-01:0.2.0-dmo8 ii libgimp2.0 2.8.14-1+b1 ii libglib2.0-0 2.42.1-1 ii libgs9 9.06~dfsg-2 ii libgtk2.0-0 2.24.25-3 ii libgudev-1.0-0 215-14 ii libice6 2:1.0.9-1+b1 ii libjasper1 1.900.1-debian1-2.4 ii libjpeg62-turbo 1:1.3.1-12 ii liblcms2-2 2.6-3+b3 ii libmng1 1.0.10+dfsg-3.1+b3 ii libpango-1.0-0 1.36.8-3 ii libpangocairo-1.0-0 1.36.8-3 ii libpangoft2-1.0-01.36.8-3 ii libpng12-0 1.2.50-2+b2 ii libpoppler-glib8 0.26.5-2 ii librsvg2-2 2.40.5-1 ii libsm6 2:1.2.2-1+b1 ii libtiff5 4.0.3-12.3 ii libwmf0.2-7 0.2.8.4-10.3+b2 ii libx11-6 2:1.6.2-3 ii libxcursor1 1:1.1.14-1+b1 ii libxext6 2:1.3.3-1 ii libxfixes3 1:5.0.1-2+b2 ii libxmu6 2:1.1.2-1 ii libxpm4 1:3.5.11-1+b1 ii libxt6 1:1.1.4-1+b1 ii python-gtk2 2.24.0-4 ii python2.72.7.9-2 pn python:any none ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages gimp recommends: ii ghostscript 9.06~dfsg-2 Versions of packages gimp suggests: pn gimp-data-extras none pn gimp-help-en | gimp-help none pn gvfs-backends none ii libasound21.0.28-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#767858: The patch works
Control: Tags -1 patch
Dear Maintainer, Peter
The patch mentioned upstream seems to work.
(Tested on smetana.debian.org: the SIGBUS goes away.)
--
tobi
diff --git a/src/cairo-tor-scan-converter.c b/src/cairo-tor-scan-converter.c
index 14922d0..b1b5187 100644
--- a/src/cairo-tor-scan-converter.c
+++ b/src/cairo-tor-scan-converter.c
@@ -277,9 +277,14 @@ struct _pool_chunk {
* chunk in the pool header. */
struct _pool_chunk *prev_chunk;
-/* Actual data starts here. Well aligned for pointers. */
+/* Actual data starts here. Well aligned even for 64 bit types. */
+int64_t data;
};
+/* The int64_t data member of _pool_chunk just exists to enforce alignment,
+ * it shouldn't be included in the allocated size for the struct. */
+#define SIZEOF_POOL_CHUNK (sizeof(struct _pool_chunk) - sizeof(int64_t))
+
/* A memory pool. This is supposed to be embedded on the stack or
* within some other structure. It may optionally be followed by an
* embedded array from which requests are fulfilled until
@@ -299,8 +304,11 @@ struct pool {
/* Header for the sentinel chunk. Directly following the pool
* struct should be some space for embedded elements from which
- * the sentinel chunk allocates from. */
-struct _pool_chunk sentinel[1];
+ * the sentinel chunk allocates from. This is expressed as a char
+ * array so that the 'int64_t data' member of _pool_chunk isn't
+ * included. This way embedding struct pool in other structs works
+ * without wasting space. */
+char sentinel[SIZEOF_POOL_CHUNK];
};
/* A polygon edge. */
@@ -475,7 +483,7 @@ _pool_chunk_create(struct pool *pool, size_t size)
{
struct _pool_chunk *p;
-p = malloc(size + sizeof(struct _pool_chunk));
+p = malloc(SIZEOF_POOL_CHUNK + size);
if (unlikely (NULL == p))
longjmp (*pool-jmp, _cairo_error (CAIRO_STATUS_NO_MEMORY));
@@ -489,10 +497,10 @@ pool_init(struct pool *pool,
size_t embedded_capacity)
{
pool-jmp = jmp;
-pool-current = pool-sentinel;
+pool-current = (void*) pool-sentinel;
pool-first_free = NULL;
pool-default_capacity = default_capacity;
-_pool_chunk_init(pool-sentinel, NULL, embedded_capacity);
+_pool_chunk_init(pool-current, NULL, embedded_capacity);
}
static void
@@ -502,7 +510,7 @@ pool_fini(struct pool *pool)
do {
while (NULL != p) {
struct _pool_chunk *prev = p-prev_chunk;
- if (p != pool-sentinel)
+ if (p != (void *) pool-sentinel)
free(p);
p = prev;
}
@@ -542,14 +550,14 @@ _pool_alloc_from_new_chunk(
chunk = _pool_chunk_create (pool, capacity);
pool-current = chunk;
-obj = ((unsigned char*)chunk + sizeof(*chunk) + chunk-size);
+obj = ((unsigned char*)chunk-data + chunk-size);
chunk-size += size;
return obj;
}
/* Allocate size bytes from the pool. The first allocated address
- * returned from a pool is aligned to sizeof(void*). Subsequent
- * addresses will maintain alignment as long as multiples of void* are
+ * returned from a pool is aligned to 8 bytes. Subsequent
+ * addresses will maintain alignment as long as multiples of 8 are
* allocated. Returns the address of a new memory area or %NULL on
* allocation failures. The pool retains ownership of the returned
* memory. */
@@ -559,7 +567,7 @@ pool_alloc (struct pool *pool, size_t size)
struct _pool_chunk *chunk = pool-current;
if (size = chunk-capacity - chunk-size) {
- void *obj = ((unsigned char*)chunk + sizeof(*chunk) + chunk-size);
+ void *obj = ((unsigned char*)chunk-data + chunk-size);
chunk-size += size;
return obj;
} else {
@@ -573,16 +581,16 @@ pool_reset (struct pool *pool)
{
/* Transfer all used chunks to the chunk free list. */
struct _pool_chunk *chunk = pool-current;
-if (chunk != pool-sentinel) {
- while (chunk-prev_chunk != pool-sentinel) {
+if (chunk != (void *) pool-sentinel) {
+ while (chunk-prev_chunk != (void *) pool-sentinel) {
chunk = chunk-prev_chunk;
}
chunk-prev_chunk = pool-first_free;
pool-first_free = pool-current;
}
/* Reset the sentinel as the current chunk. */
-pool-current = pool-sentinel;
-pool-sentinel-size = 0;
+pool-current = (void *) pool-sentinel;
+pool-current-size = 0;
}
/* Rewinds the cell list's cursor to the beginning. After rewinding
Bug#782971: sane-utils: saned systemd config does not allow remote scanner access
Package: sane-utils Version: 1.0.24-8 Severity: important Tags: patch Hi, After an upgrade to jessie, I've been enable to access my scanner through network. Of course, I correctly enabled and started the saned.socket systemd unit. Any access try (with xsane on remote machine or even with telnet saned-server 6566) leads to the following syslog lines: Apr 19 23:20:40 kooot saned[32317]: saned (AF-indep+IPv6) from sane-backends 1.0.24 starting up Apr 19 23:20:40 kooot saned[32317]: check_host: access by remote host: localhost Apr 19 23:20:40 kooot saned[32317]: init: access by host localhost denied Apr 19 23:20:40 kooot saned[32317]: saned exiting After reading various things on Internet, I succeed in finding the configuration error in the saned manpage itself: SYSTEMD CONFIGURATION [...] StandardInput=null [...] and not StandardInput=socket as currently shipped in /lib/systemd/system/saned\@.service I put the line from the manpage into the saned\@.service unit file, called systemctl daemon-reload and now all is working perfectly. Here is a extract of my current logs: Apr 19 23:21:07 kooot saned[32344]: saned (AF-indep+IPv6+systemd) from sane-backends 1.0.24 starting up Apr 19 23:21:07 kooot saned[32344]: check_host: access by remote host: :::10.77.0.3 Apr 19 23:21:07 kooot saned[32344]: init: access granted to vdanjean@:::10.77.0.3 Apr 19 23:21:17 kooot saned[32344]: saned exiting And xsane allows me to scan my page... PS: upgrading sane-utils to 1.0.24-9 does not change anything (same problem, same solution) PPS: a fix in jessie as soon as possible seems appropriate to me. Regards Vincent -- System Information: Debian Release: 8.0 APT prefers testing APT policy: (990, 'testing'), (500, 'stable-updates'), (500, 'oldstable-updates'), (500, 'unstable'), (500, 'stable'), (500, 'oldstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/1 CPU core) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages sane-utils depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii init-system-helpers1.22 ii libavahi-client3 0.6.31-5 ii libavahi-common3 0.6.31-5 ii libc6 2.19-18 ii libieee1284-3 0.2.11-12 ii libsane1.0.24-8 ii libsystemd0215-16 ii libusb-1.0-0 2:1.0.19-1 ii update-inetd 4.43 sane-utils recommends no packages. Versions of packages sane-utils suggests: ii avahi-daemon 0.6.31-5 pn unpaper none -- Configuration Files: /etc/sane.d/saned.conf changed: 10.77.2.0/22 192.168.77.0/24 [::1] 127.0.0.1 -- debconf information: * sane-utils/saned_scanner_group: true * sane-utils/saned_run: false -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782917: [Python-modules-team] Bug#782917: Please provide a python3 module
On Mon, 20 Apr 2015 at 04:51 Paul Tagliamonte paul...@debian.org wrote: Package: django-auth-ldap Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks ... If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! To the best of my knowledge, this depends on python-ldap, which is Python 2 only - upstream issue. There is a native python-ldap3 library which has Python 3 in Debian support, however the API is different.
Bug#782910: RM: plinth/0.3.2.0.git.20140829-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Hello, The FreedomBox project is under active development but does not have the resources to make a stable release at this point and support it for a long time. There is a consensus among the developers to focus our efforts on unstable packages and not release the package in Jessie. With this bug, I request removal of Plinth and corresponding package freedombox-setup from Jessie. Thank you, -- Sunil Mohan Adapa -- System Information: Debian Release: 8.0 APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386, armhf Kernel: Linux 3.19.0-trunk-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782847: RFS: endless-sky/0.7.9-1 [ITP]
Michael Zahniser mzahni...@gmail.com writes: I agree that having the source for all the graphics available for anyone to view or modify is important. But I can't just export from Blender files: for the 3D images, I touched them up by hand in GIMP after rendering them, adding texture, scuff marks, color variation, and random shadows and highlights. That was to make them look dirty and worn rather than pristine and artificial. Similarly, a lot of the photos have been retouched, e.g. shifting the colors to make them look more like alien landscapes. That means that the source files include many large GIMP files, and add up to over 3 GB. That's large enough that I think it's better for the image source files to be available separately rather than including them in the main source distribution. (I could add a line to the read-me giving a link to the current location (Google drive) of those files.) I predict that Google Drive can and will go down sooner than you think, with little advance warning. You should never rely on services provided by an entity with a history of breaking running systems like Google. See http://web.archive.org/web/20071020051936/http://iq.org/#Selfdestructingpaper: A spy opens an envelope. Inside is a thin sheet of paper with a cryptic message. After it is read the paper spontaneously bursts into flames. The message is the communicable distillation of your hopes, dreams and imagination. The paper is the internet. The internet is self destructing paper. A place where anything written is soon destroyed by rapacious competition and the only preservation is to forever copy writing from sheet to sheet faster than they can burn. If it's worth writing, it's worth keeping. If it can be kept, it might be worth writing. Would your store your brain in a startup company's vat? If you store your writing on a 3rd party site like blogger, livejournal or even on your own site, but in the complex format used by blog/wiki software de jour you will lose it forever as soon as hypersonic wings of internet labor flows direct people's energies elsewhere. For most information published on the internet, perhaps that is not a moment to soon, but how can the muse of originality soar when immolating transience brushes every feather? -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net pgp3DisJ3fJch.pgp Description: PGP signature
Bug#782913: cewl: should be in package section web (not ruby)
Package: cewl Severity: minor -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Package section ruby is for impementations of said programming language and libraries for it. From its package description, cewl seemingly does not fit that description, but seems better suitable in section web. - Jonas -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJVM+ziAAoJECx8MUbBoAEhfNMP/Ajm+i0IjnAcTMZ2R6cwXQD4 Ntt1pByopjo+RbTLxyx/AXkF0e8D+RWFKe1Yd25jSZTTsv8jUYSazTHe0DOGc5+t QFLAEXOYnKt+e0d/C5kbxMWOVfB0zurpRv3ovnjUVILzIwRWL14jkFsPqty8TL1s akUmMKd2YmsuQF8jdJZFyJGYrhWhi/KKPf4EQNwFDc/kXKbBOJ3RtWBT9iDbaWUx B4bajvNrUvNOmM1O8vwRj6a97Hzv4irIts2OQYbbfdnfakTlr8EcOSMC0v8+MHoJ xf/Z26HCVt2RwwaN4nyYHfRBUo9sQboa52TaUcEqZLJeKqPcoskytynXwCwA9BOi G7l3UtiSOC++cnvsPoYI0NSRG7z9Op0PKPZfGLQz7hh6qNoKaUN/H4M/DSueyyd4 AQVKmBPn0n7RxWbNm0jtf9NXNVpy6SgWPiptYifJSR7O2iUVXXRGczpaKYdLq9oG tus74xLHVaH9h5S47Krpe9chA0pnr6WPKbBWZulG9g1LAuILpKsA+spwECtjWJzc zyyfTZluef3QN8Pl/s7Ss3NekYlOBJGAZlDz4IwaXI8yMSH/8YbfR9gzDQH+Ue+u r1NRS3t7AV6E5ZivVihFnmA3+ZybdZPA4kITa9rBaWyOQA/9tbWooRF1aVcOrKan aCvNiP8DlbkxMOTMeG71 =ERDN -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#764982: Backports removed from sources.list ;-(
Quoting Paul van der Vlis (p...@vandervlis.nl): Hello, I saw backports has been removed as default setting from sources.list in Jessie RC3. I am very disappointed by this last minute change, without much discussion so far I know. I did not know about this bug. In my opinion it's very good when backports is default in sources.list. With regards, Paul van der Vlis. The bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=764982 Hello, This bug is closed by the following: * Stop enabling backports by default (Closes: #764982). Rationale: - Packages in the base suite are preferred to the ones in the backports suite so one needs to specifically ask for the version from backports. - That isn't true for packages which are only available in the backports suite. This means one could possibly install such packages without even noticing they're not fetched from the base suite; and that seems a dangerous default. I think this rationale is very clear... signature.asc Description: Digital signature
Bug#782919: Please provide a python3 module
Package: execnet Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#782918: Please provide a python3 module
Package: django-authority Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#782920: Please provide a python3 module
Package: flask-wtf Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#782934: Please provide a python3 module
Package: python-couchdb Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
Bug#782251: python-boto: S3 upload using sigv4 crash
[ François Guerraz ] [ ... ] I think it should be fixed in Jessie eventually and it seems common enough a use case that some people will hit the bug on day one. I agree, the question is whether it can wait for a future point release, or whether I should approach the release team for an unblock with a little under a week left before release. Note that, even if it's the former, I think this warrants getting a fixed package into backports as quickly as possible. Given the volatile nature of boto (and AWS APIs in general), I suspect quite a lot of people go there anyway. Now, is it worth delaying the release of Jessie for that? I lean toward 'no' as there are two possible workarounds (disabling multipart and installing it via pip). But it still severely affects the usability of the package. I wasn't able to replicate this with duplicity (though my backups are using a north american region). Can you update this report with the exact steps to reproduce, and for posterity sake, what you do to work around it? Thanks, -- Eric Evans eev...@sym-link.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#782932: Please provide a python3 module
Package: pysendfile Severity: wishlist User: py3porters-de...@lists.alioth.debian.org Usertags: patchme-python3 thanks Hello there! This package contains a trove classifier[1] in its `setup.py` like Programming Language :: Python :: 3. This means that the package's upstream developers consier this package to be ready for Python 3. This is wonderful! As part of an ongoing process to migrate as much as we can to Python 3 to ensure we're ready for our glorious Python 3 future, please build a Python 3 module. If you need help doing this, please feel free to contact the Debian Python Modules Team (DPMT), and we can help! If you would welcome a NMU, please do let the team know (py3porters-de...@lists.alioth.debian.org). Please upload any new versions before Jessie's release to experimental, the Release Team has been doing such great work, it'd be a shame to see unstable out of sync before we release! If the reason you've not built a Python 3 module is due to the dependency chain below you, just let me know, and I can add it to our list, or feel free to file a bug in coordination with the team! Have a great day, and thanks for your work! Paul, on behalf of the Python 3 Embetterment Squad [1]: https://pypi.python.org/pypi?%3Aaction=list_classifiers -- .''`. Paul Tagliamonte paul...@debian.org | Proud Debian Developer : :' : 4096R / 8F04 9AD8 2C92 066C 7352 D28A 7B58 5B30 807C 2A87 `. `'` http://people.debian.org/~paultag `- http://people.debian.org/~paultag/conduct-statement.txt signature.asc Description: Digital signature
