Bug#691902: Unable to shutdown Debian Wheezy via normal means

[Jochen Fahrner]

Am Samstag, den 31.05.2014, 11:33 +0200 schrieb Jochen Fahrner:
> some more info on this. I installed kernel 3.12 and 3.14 from wheezy 
> backports, and both don't have this shutdown problem.
> 
> Maybe it has something to do with acpi. If I boot kernel 3.2 with acpi=off, 
> system is halted on shutdown and I can manually power off. 

I have to correct: newer kernels also have this problem, but not on
_every_ shutdown.

After some googling, I found many hints that laptop-mode-tools can be
the cause of this reboots. I don't have laptop-mode-tools installed, but
since my Lenovo Ideacentre is not a laptop, I removed some other laptop
related packages:

acpi-support
acpi-support-base
pcmciautils
powertop
task-laptop

That seems to solve the problem. Shutdown was working fine now for
several times with kernel 3.2.

Ubuntu kernels also don't have this problem, but I cannot use Ubuntu
kernels because the kernel header package dependencies are not
compatible with Debian, and I need them because of virtualbox kernel
modules.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751082: nvidia-graphics-drivers: Please package 337.25 in experimental as it should support Xorg 1.16.

[Eric Valette]

Source: nvidia-graphics-drivers
Severity: wishlist

In order to test experimental Xorg 1.16, this driver is required for nvidia 
users. As Xorg 1.16 is in experimental it is sufficient to put it there.

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.12.20 (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751077: icedove: program locks up when attempting attachment, gdb no help

[Arthur Marsh]

Carsten Schoenert wrote, on 10/06/14 15:12:

Hello Arthur,

On Tue, Jun 10, 2014 at 02:04:13PM +0930, Arthur Marsh wrote:


* What led up to the situation?

attempting to attach a PDF file to an email.


If I ran icedove outside of gdb in safe mode and attempted the 
attachment of the PDF file in the local directory, I received the 
following output:



icedove -safe-mode

(process:13904): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed


(icedove:13904): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::sm-connect after class was initialised


(icedove:13904): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::show-crash-dialog after class was initialised


(icedove:13904): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::display after class was initialised


(icedove:13904): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::default-icon after class was initialised

Segmentation fault


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751077: icedove: program locks up when attempting attachment, gdb no help

[Arthur Marsh]

Carsten Schoenert wrote, on 10/06/14 15:12:

Hello Arthur,

On Tue, Jun 10, 2014 at 02:04:13PM +0930, Arthur Marsh wrote:


* What led up to the situation?

attempting to attach a PDF file to an email.


Do you have disabled all the plugins and/or started in save-mode?


Yes I tried that, same result (if started outside of gdb, it just 
terminates when I click on the "open" box for the attachment, PDF file 
in home directory).



There your attachement was laying? Local filesystem, usb storage or a
net resource? Do you have checked the permissions of this file? Is this
file currupted?


Reading symbols from icedove...(no debugging symbols found)...done.
(gdb) run


At this point there can't be more output if you trying to run the
"normal" Icedove package. Do you have installed the -dbg package?

https://wiki.debian.org/Icedove#Debugging


Somehow the instructions didn't help much:

 /usr/lib/icedove/run-mozilla.sh -g -safe-mode 
/usr/lib/icedove/icedove-bin 2>&1 | tee /tmp/icedove-gdb-$(apt-cache 
show icedove | grep Version | awk '{ print $2 }')_$(date +%F_%T).log


run-mozilla.sh: Cannot execute -safe-mode.

amarsh04@victoria:~$ /usr/lib/icedove/run-mozilla.sh -g 
/usr/lib/icedove/icedove-bin 2>&1 | tee /tmp/icedove-gdb-$(apt-cache 
show icedove | grep Version | awk '{ print $2 }')_$(date +%F_%T).log

MOZILLA_FIVE_HOME=/usr/lib/icedove

LD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove/plugins:/usr/lib/icedove
DISPLAY=:0
DYLD_LIBRARY_PATH=/usr/lib/icedove:/usr/lib/icedove
 LIBRARY_PATH=
   SHLIB_PATH=/usr/lib/icedove:/usr/lib/icedove
  LIBPATH=/usr/lib/icedove:/usr/lib/icedove
   ADDON_PATH=
  MOZ_PROGRAM=/usr/lib/icedove/icedove-bin
  MOZ_TOOLKIT=
moz_debug=1
 moz_debugger=
moz_debugger_args=
/usr/bin/gdb  --args /usr/lib/icedove/icedove-bin
GNU gdb (Debian 7.7.1-1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 


This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from /usr/lib/icedove/icedove-bin...Reading symbols from 
/usr/lib/debug//usr/lib/icedove/icedove-bin...done.

done.
(gdb) run
Starting program: /usr/lib/icedove/icedove-bin
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".


(process:13771): GLib-CRITICAL **: g_slice_set_config: assertion 
'sys_page_size == 0' failed

warning: Corrupted shared library list: 0xb7db1c00 != 0xb7d3

(icedove:13771): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::sm-connect after class was initialised


(icedove:13771): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::show-crash-dialog after class was initialised


(icedove:13771): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::display after class was initialised


(icedove:13771): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::default-icon after class was initialised

[New Thread 0xb46f1b40 (LWP 13807)]
[New Thread 0xb33ffb40 (LWP 13808)]
[New Thread 0xb27ffb40 (LWP 13809)]
[New Thread 0xb1ffeb40 (LWP 13810)]
[New Thread 0xb17fdb40 (LWP 13811)]
[New Thread 0xb0cffb40 (LWP 13812)]
[New Thread 0xb022ab40 (LWP 13815)]
[New Thread 0xafa29b40 (LWP 13816)]
[New Thread 0xaf228b40 (LWP 13817)]
[New Thread 0xaea27b40 (LWP 13818)]
[Thread 0xaf228b40 (LWP 13817) exited]
[New Thread 0xaf228b40 (LWP 13820)]
[New Thread 0xaddffb40 (LWP 13822)]
[New Thread 0xad8ffb40 (LWP 13823)]
enigmail.js: Registered components
[New Thread 0xa55ffb40 (LWP 13825)]
[New Thread 0xa4dfeb40 (LWP 13826)]
[New Thread 0xa45fdb40 (LWP 13827)]
[New Thread 0xa3dfcb40 (LWP 13828)]
[Thread 0xad8ffb40 (LWP 13823) exited]
[New Thread 0xa35fbb40 (LWP 13829)]
[Thread 0xa4dfeb40 (LWP 13826) exited]
[Thread 0xa3dfcb40 (LWP 13828) exited]
[New Thread 0xad8ffb40 (LWP 13830)]
[New Thread 0xa4dfeb40 (LWP 13831)]
[New Thread 0xa3dfcb40 (LWP 13832)]
[Thread 0xa45fdb40 (LWP 13827) exited]
[Thread 0xa3dfcb40 (LWP 13832) exited]
[Thread 0xad8ffb40 (LWP 13830) exited]
mimeVerify.jsm: module initialized
[New Thread 0xa45fdb40 (LWP 13833)]
[New Thread 0xad8ffb40 (LWP 13834)]
[Thread 0xad8ffb40 (LWP 13834) exited]
[New Thread 0xad8ffb40 (LWP 13835)]
[Thread 0xad8ffb40 (LWP 13835) exited]
[New Thread 0xad8ffb40 (LWP 13836)]
[New Thread 0xa3dfcb40 (LWP 13837)]
[New Thread 0x9f2ffb40 (LWP 13839)]
[New Thread 0x9eafeb40 (LWP 13840)]
[New Thread 0x9cbffb40 (LWP 13842)]
[New Thread 0x9

Bug#745231: [Pkg-openldap-devel] Bug#745231: openldap: Consider switching to gnutls3

[Ryan Tandy]

On 19/04/14 05:48 AM, Andreas Metzler wrote:

Hello,


Hi Andreas, thanks for starting the conversation about this!


given that gmp has been dual-licensed LGPLv3+/GPLv2+ it should be
possible to switch openldap over to the newer version of gnutls.



Upstream's 0205e83f4670d10ad3c6ae4b8fc5ec1d0c7020c0 lets the Debian
package build successfully (including testsuite).


And TLS with a server certificate seems to work, as does SASL EXTERNAL 
authentication with a client certificate. Good!



However even with patch there is still some work to be done.
libraries/libldap/tls_g.c has some gcrypt related code that should be
simply unnecessary with gnutls3, therefore it should not link against
libgcrypt either.


I see two remaining gcrypt calls in tls_g.c.

161:gcry_control (GCRYCTL_SET_THREAD_CBS, &tlsg_thread_cbs);

It sounds like nettle itself doesn't need such callbacks, but even so I 
suspect this should be replaced with a gnutls_global_set_mutex call in 
order to keep using the internal threading abstraction, as per the 
gnutls NEWS.


174:gcry_control( GCRYCTL_SET_RNDEGD_SOCKET, lo->ldo_tls_randfile ))

And for that, it looks like nettle uses a hard-coded list of possible 
locations for that socket, so I guess there's no replacement call. Well, 
the manpage already says the randfile option doesn't work under gnutls, 
I guess this will make it true again. :)



(Except for contrib/slapd-modules/smbk5pwd/smbk5pwd.c).


Right, that one actually uses gcrypt, it's not just there for gnutls. 
I'll have a look later at how much work porting that will be, and I'll 
send this information upstream too.


thanks,
Ryan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751078: qemu-system-x86: "No bootable device." with option "-machine type=q35"

[Michael Tokarev]

Control: retitle -1 legacy -cdrom/-hda options does not work with q35
Control: severity -1 wishlist
Control: tag -1 + upstream confirmed

10.06.2014 09:16, Thomas wrote:
> Package: qemu-system-x86
> Version: 2.0.0+dfsg-6
> Severity: normal
> 
> Dear Maintainer,
> 
> I want to use the Q35 qemu platform for my virtual machines.
> 
> I start qemu with the following command line:
> vimaowner@osprey:~$ qemu-system-x86_64 -enable-kvm -machine type=q35 \
> -cpu kvm32 -m 512 -balloon none -hda virtuals/fai/fai_root.img -cdrom \
> cdroms/grml96-full_2014.03.iso -boot order=d -name fai -vga qxl -spice \
> port=5900,addr=localhost,disable-ticketing -monitor stdio

With q35 machine type you have to use the "real" syntax.  The above
-cdrom and -hda becomes:

 -drive file=virtuals/fai/fai_root.img,id=d0,if=none
 -device ide-drive,drive=d0

 -drive file=cdroms/grml96-full_2014.03.iso,id=c0,media=cdrom,if=none
 -device ide-cd,drive=c0

It is just the legacy shortcuts -hda and -cdrom doesn't work. Just like
the expansion of these options (as documented in the manpage).

This is an upstream issue.  And I'm not sure upstream is very interested
in fixing it.

Retitling and lowering severity accordingly.

Thanks,

/mjt


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#711833: [supp...@mentors.debian.net: postr uploaded to mentors.debian.net]

[Alexander Alemayhu]

On Mon, Jun 09, 2014 at 08:29:51PM +0200, Yoann Gauthier wrote:
> Hello,
> 

Hei.

> I fixed the desktop-entry-lacks-keywords-entry as asked.
> Find attached the patch. I used quilt to create my patch :
> 04-fix_desktop_keywords.patch and then git format to create patch file.
> 

Good. You should also update the debian/changelog to include an entry which
mentions the patch. Please take a close look at the existing lines to get an
idea of what to write.

> 
> Regards,
> 
> PS : have access (push request) to your repository will be easier for me.
> 

Full access granted. You should now be able to push directly.

> Yoann
> 
> 
> 2014-06-03 22:50 GMT+02:00 Alexander Alemayhu :
> 
> > On Tue, Jun 03, 2014 at 11:45:27AM +0200, Yoann Gauthier wrote:
> > > Hi Alexander,
> > >
> > > What are the next tasks I can do to help for the packaging ?
> > >
> >
> > You could look at the desktop-entry-lacks-keywords-entry[0] lintian tag
> > and try
> > to fix it. I was planning on fixing it but wanted to prioritize the
> > autotools
> > warnings. Hopefully we can get some advice from David.
> >
> > It looks like you would need to create a debian patch file to modify
> > data/postr.desktop.in.in. If you are unfamiliar with quilt, take a look
> > at this
> > introduction[1].
> >
> > PS: Remember to fetch the latest changes, before making new changes. It
> > might
> > help in avoiding merge conflicts.
> >
> > PPS: desktop-entry-lacks-keywords-entry only occurs when using `lintian
> > -EvIL
> > +pedantic` on my machine.
> >
> > [0]:
> > http://lintian.debian.org/tags/desktop-entry-lacks-keywords-entry.html
> > [1]:
> >
> > http://raphaelhertzog.com/2012/08/08/how-to-use-quilt-to-manage-patches-in-debian-packages/
> >
> > > Regards,
> > >
> > > Yoann
> > >
> > >
> > > 2014-06-02 21:26 GMT+02:00 Alexander Alemayhu :
> > >
> > > > On Mon, Jun 02, 2014 at 10:30:40AM +0200, Yoann Gauthier wrote:
> > > > > Hi,
> > > > >
> > > > > For man page license, I propose to distribute it under GNU GLP (v3).
> > Do
> > > > you
> > > > > agree ?
> > > > >
> > > >
> > > > I am no license expert, but I think it is okay assuming you mean GNU
> > GPL.
> > > >
> > > > > Okay for the maintener part, I will set the maintainer to Python
> > > > > Applications Packaging Team.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Yoann
> > > > >
> > > > >
> > > > > 2014-06-01 18:26 GMT+02:00 Alexander Alemayhu :
> > > > >
> > > > > > On Sun, Jun 01, 2014 at 03:50:27PM +0200, Yoann Gauthier wrote:
> > > > > > > Le 31 mai 2014 20:00, "Alexander Alemayhu" 
> > a
> > > > > > écrit :
> > > > > > > >
> > > > > > > > On Sat, May 31, 2014 at 03:29:16PM +0200, Yoann Gauthier wrote:
> > > > > > > > > Hello,
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hei,
> > > > > > > >
> > > > > > > > > I wrote the man page (attachment). I have no access to the
> > > > repository
> > > > > > > > > today, I will upload the page to repository tomorrow.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Nice. I decided to use github as the Vcs-* since collab-maint
> > > > seems to
> > > > > > be
> > > > > > > for
> > > > > > > > people packing together with DDs. Maybe we should ask for
> > access
> > > > and
> > > > > > push
> > > > > > > our
> > > > > > > > changes there?
> > > > > > >
> > > > > > > I don't understand Vcs, what is it ?
> > > > > >
> > > > > > A akronym for Version Control System[0].
> > > > > >
> > > > > > > > I think you have a typo 'MAINTENERS' should be 'MAINTAINERS'.
> > It
> > > > could
> > > > > > be
> > > > > > > a
> > > > > > > > good idea to ask for others to review the man page. Which
> > license
> > > > do
> > > > > > you
> > > > > > > want
> > > > > > > > to distribute the man page with? we have to mention the
> > license in
> > > > > > > > debian/copyright.
> > > > > > >
> > > > > > > Agree for the typo, this evening I will read again the man page
> > and
> > > > add
> > > > > > > more information maybe. Okay for the license, i will think.
> > > > > > > >
> > > > > >
> > > > > > In order to stay consistent with the debian/control file we should
> > set
> > > > the
> > > > > > maintainer to Python Applications Packaging Team
> > > > > > 
> > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Yoann
> > > > > > > > >
> > > > > >
> > > > > > [0]: http://en.wikipedia.org/wiki/Version_control
> > > > > >
> > > > > > > > >
> > > > > > > > > 2014-05-30 12:36 GMT+02:00 Yoann Gauthier <
> > > > yoann.gauthi...@gmail.com
> > > > > > >:
> > > > > > > > >
> > > > > > > > > > Hi Alexander,
> > > > > > > > > >
> > > > > > > > > > Yes, I am going to write the man page. It will be finished
> > > > today or
> > > > > > > > > > tomorrow.
> > > > > > > > > > Okay for the RFS.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Yoann
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2014-05-30 10:43 GMT+02:00 Alexander Alemayhu <
> > > > alexan...@bitraf.no
> > > > > > >:
> > > > > > > > > >
> > > > > > > > 

Bug#724874: inspircd: 2.0.15 now available

[Jeremy Stanley]

It looks like the proposed source package has fallen off mentors.d.n
in the past month. Is this still in progress? Thanks in advance!
-- 
{ PGP( 48F9961143495829 ); FINGER( fu...@cthulhu.yuggoth.org );
WWW( http://fungi.yuggoth.org/ ); IRC( fu...@irc.yuggoth.org#ccl );
WHOIS( STANL3-ARIN ); MUD( kin...@katarsis.mudpy.org:6669 ); }


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751077: icedove: program locks up when attempting attachment, gdb no help

[Carsten Schoenert]

Hello Arthur,

On Tue, Jun 10, 2014 at 02:04:13PM +0930, Arthur Marsh wrote:
 
>* What led up to the situation?
> 
> attempting to attach a PDF file to an email.

Do you have disabled all the plugins and/or started in save-mode?
There your attachement was laying? Local filesystem, usb storage or a
net resource? Do you have checked the permissions of this file? Is this
file currupted?

> Reading symbols from icedove...(no debugging symbols found)...done.
> (gdb) run

At this point there can't be more output if you trying to run the
"normal" Icedove package. Do you have installed the -dbg package?

https://wiki.debian.org/Icedove#Debugging

But I think the debugger will not help here, I assume Icedove is not
crashing. So you please have to take a look into the JS console
(hit Ctrl + SHift + J).
Further more you can debug that Icedove is doing inside.

https://wiki.debian.org/Icedove#Debugging_Icedove_Activity

Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751081: healpix-cxx testsuite doesn't respect parallel=x build flag

[Riku Voipio]

Package: healpix-cxx
Version: 3.11.2-6
Severity: normal

healpix-cxx build log on armel:

DEB_BUILD_OPTIONS=parallel=2

-snip-

make  check-TESTS

+-+
| hpxtest v3.11.2 |
+-+

Vector math: not supported by this binary
OpenMP active: max. 4 threads.

After a while the job hanged. Surely the build
should not hang for too many threads, but also
the package needs to follow parallel build flag and
not try to autodetect amount of cores etc.

Riku


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751080: xbmc: youtube ssl connection failure

[Ritesh Raj Sarraf]

Package: xbmc
Version: 2:13.1~rc1+dfsg1-1
Severity: minor

I am filing it here just for the sake of other users, thus severity minor.

The YouTube plugin is not able to open streams. In the logs, I see:


11:07:23 T:140395820082944  NOTICE: Thread LanguageInvoker start, auto delete: 
false
11:07:23 T:140395820082944  NOTICE: -->Python Interpreter Initialized<--
11:07:23 T:140395820082944  NOTICE: Loading cookies from 
:'/home/rrs/.xbmc/userdata/addon_data/plugin.video.youtube/yt-cookiejar.txt'
11:07:23 T:140395820082944  NOTICE: YouTube-4.4.8
11:07:23 T:140395820082944  NOTICE: CommonFunctions-2.5.1
11:07:25 T:140395820082944  NOTICE: links: 'dict'
11:07:25 T:140395352643328  NOTICE: Thread GUIDialogCache start, auto delete: 
true
11:07:26 T:140397362166080   ERROR: CCurlFile::Stat - Failed: SSL connect 
error(35) for 
https://r3---sn-i5uif5t-cage.googlevideo.com/videoplayback?fexp=900504,908593,910836,913434,916611,923341,930008,932617,934026,936118&itag=43&expire=1402401025&ratebypass=yes&signature=7FCEDCC77F8BAEA537961E76C30CB461DC5B199B.06DA704CF11A3B73FACA5E802DCF1DF897645548&sver=3&id=o-AI-ih0lSlw8qvj64sZoVcgz9pduVNuqkCGOYpo8jip8A&mws=yes&ipbits=0&key=yt5&mt=1402378607&sparams=id,ip,ipbits,itag,ratebypass,requiressl,source,upn,expire&mv=m&upn=AkMgtC0Vzog&source=youtube&ms=au&requiressl=yes&ip=27.7.162.194|User-Agent=Mozilla%2F5.0+%28Windows+NT+6.2%3B+Win64%3B+x64%3B+rv%3A16.0.1%29+Gecko%2F20121011+Firefox%2F16.0.1
11:07:26 T:140397362166080  NOTICE: DVDPlayer: Opening: 
https://r3---sn-i5uif5t-cage.googlevideo.com/videoplayback?fexp=900504,908593,910836,913434,916611,923341,930008,932617,934026,936118&itag=43&expire=1402401025&ratebypass=yes&signature=7FCEDCC77F8BAEA537961E76C30CB461DC5B199B.06DA704CF11A3B73FACA5E802DCF1DF897645548&sver=3&id=o-AI-ih0lSlw8qvj64sZoVcgz9pduVNuqkCGOYpo8jip8A&mws=yes&ipbits=0&key=yt5&mt=1402378607&sparams=id,ip,ipbits,itag,ratebypass,requiressl,source,upn,expire&mv=m&upn=AkMgtC0Vzog&source=youtube&ms=au&requiressl=yes&ip=27.7.162.194|User-Agent=Mozilla%2F5.0+%28Windows+NT+6.2%3B+Win64%3B+x64%3B+rv%3A16.0.1%29+Gecko%2F20121011+Firefox%2F16.0.1
11:07:26 T:140397362166080 WARNING: CDVDMessageQueue(player)::Put 
MSGQ_NOT_INITIALIZED
11:07:26 T:140395237172992  NOTICE: Thread DVDPlayer start, auto delete: false
11:07:26 T:140395237172992  NOTICE: Creating InputStream
11:07:26 T:140395237172992   ERROR: CCurlFile::FillBuffer - Failed: SSL connect 
error(35)
11:07:26 T:140395237172992   ERROR: CCurlFile::CReadState::Connect, didn't get 
any data from stream.
11:07:26 T:140395237172992   ERROR: Open - failed to open source 

11:07:26 T:140395237172992   ERROR: CDVDPlayer::OpenInputStream - error opening 
[https://r3---sn-i5uif5t-cage.googlevideo.com/videoplayback?fexp=900504,908593,910836,913434,916611,923341,930008,932617,934026,936118&itag=43&expire=1402401025&ratebypass=yes&signature=7FCEDCC77F8BAEA537961E76C30CB461DC5B199B.06DA704CF11A3B73FACA5E802DCF1DF897645548&sver=3&id=o-AI-ih0lSlw8qvj64sZoVcgz9pduVNuqkCGOYpo8jip8A&mws=yes&ipbits=0&key=yt5&mt=1402378607&sparams=id,ip,ipbits,itag,ratebypass,requiressl,source,upn,expire&mv=m&upn=AkMgtC0Vzog&source=youtube&ms=au&requiressl=yes&ip=27.7.162.194|User-Agent=Mozilla%2F5.0+%28Windows+NT+6.2%3B+Win64%3B+x64%3B+rv%3A16.0.1%29+Gecko%2F20121011+Firefox%2F16.0.1]
11:07:26 T:140395237172992  NOTICE: CDVDPlayer::OnExit()
11:07:26 T:140395237172992  NOTICE: CDVDPlayer::OnExit() deleting input stream
11:07:26 T:140397362166080  NOTICE: CDVDPlayer::CloseFile()
11:07:26 T:140397362166080  NOTICE: DVDPlayer: waiting for threads to exit
11:07:26 T:140397362166080  NOTICE: DVDPlayer: finished waiting
11:07:26 T:140397362166080  NOTICE: CDVDPlayer::CloseFile()
11:07:26 T:140397362166080  NOTICE: DVDPlayer: waiting for threads to exit
11:07:26 T:140397362166080  NOTICE: DVDPlayer: finished waiting




-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (101, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_IN, LC_CTYPE=en_IN (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xbmc depends on:
ii  fonts-dejavu-core  2.34-1
ii  fonts-roboto   1:4.3-3
ii  libjs-iscroll  5.1.1+dfsg1-2
ii  libjs-jquery   1.7.2+dfsg-3
ii  mesa-utils 8.1.0-2+b1
ii  python-imaging 2.3.0-2
pn  pyt

Bug#751079: reportbug: newer version alert even when only for a different architecture

[Arthur Marsh]

Package: reportbug
Version: 6.5.0
Severity: normal

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

A report on icedove on i386. reportbug announced that there was a newer
version in unstable, but checking packages.debian.org showed that it was
only available on other architectures.

   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

reportbug could have said that there was a newer version in a different
architecture, therefore a newer version *may* become available soon.


*** End of the template - remove these template lines ***


-- Package-specific info:
** Environment settings:
INTERFACE="text"

** /home/amarsh04/.reportbugrc:
reportbug_version "3.5"
mode standard
ui text
realname "Arthur Marsh"
email "arthur.ma...@internode.on.net"

-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)

Kernel: Linux 3.15.0-rc8+ (SMP w/4 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages reportbug depends on:
ii  apt   1.0.3
ii  python2.7.6-2
ii  python-reportbug  6.5.0

reportbug recommends no packages.

Versions of packages reportbug suggests:
pn  claws-mail 
ii  debconf-utils  1.5.53
ii  debsums2.0.52+nmu2
pn  dlocate
ii  emacs23-bin-common 23.4+1-4.1+b1
ii  exim4  4.82.1-1
ii  exim4-daemon-light [mail-transport-agent]  4.82.1-1+b1
ii  file   1:5.18-1
ii  gnupg  1.4.16-1.1
ii  python-gtk22.24.0-3+b1
ii  python-gtkspell2.25.3-13
pn  python-urwid   
ii  python-vte 1:0.28.2-5
ii  xdg-utils  1.1.0~rc1+git20111210-7.1

Versions of packages python-reportbug depends on:
ii  apt   1.0.3
ii  python2.7.6-2
ii  python-debian 0.1.21+nmu3
ii  python-debianbts  1.11
ii  python-support1.0.15

python-reportbug suggests no packages.

-- debconf-show failed


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751078: qemu-system-x86: "No bootable device." with option "-machine type=q35"

[Thomas]

Package: qemu-system-x86
Version: 2.0.0+dfsg-6
Severity: normal

Dear Maintainer,

I want to use the Q35 qemu platform for my virtual machines.

I start qemu with the following command line:
vimaowner@osprey:~$ qemu-system-x86_64 -enable-kvm -machine type=q35 \
-cpu kvm32 -m 512 -balloon none -hda virtuals/fai/fai_root.img -cdrom \
cdroms/grml96-full_2014.03.iso -boot order=d -name fai -vga qxl -spice \
port=5900,addr=localhost,disable-ticketing -monitor stdio

I expect to see the grml isolinux boot menu if I connect via spice.

I can connect to spicy via
thomas@osprey:~/tmp$ spicy -h localhost -p 5900
and see that seabios starts, that it tries to boot from floppy and network
and that it fails with "No bootable device."
It seems that the harddisk and the cdrom are not available for booting.

I tryd all q35 machines - this means:
pc-q35-1.4
pc-q35-1.5
pc-q35-1.6
pc-q35-1.7
pc-q35-2.0

All have the same problem.

But if i change the machine type to "pc-i440fx-2.0" it works as expected.
This means the following command line works:
vimaowner@osprey:~$ qemu-system-x86_64 -enable-kvm -machine \
type=pc-i440fx-2.0 -cpu kvm32 -m 512 -balloon none -hda \
virtuals/fai/fai_root.img -cdrom cdroms/grml96-full_2014.03.iso -boot \
order=d -name fai -vga qxl -spice \
port=5900,addr=localhost,disable-ticketing -monitor stdio


The image files:
virtuals/fai/fai_root.img
is a empty qcow2 img-file created with:
vimaowner@osprey:~$ qemu-img create -f qcow2 -o \
"preallocation=metadata" fai_root.img 2G

cdroms/grml96-full_2014.03.iso
is a iso-file which one can download from



It seems qemu 1.3 in RedHat had the same problem:

but the workaround
"-acpitable file=/usr/share/seabios/q35-acpi-dsdt.aml"
does not help in my case.

What did I more?
* I tryd to start qemu as root - no difference.
* I minimalized the command line to
vimaowner@osprey:~$ qemu-system-x86_64 -machine type=q35 -hda \
virtuals/fai/fai_root.img -cdrom cdroms/grml96-full_2014.03.iso -boot \
order=d -display curses
This does not help ether.


Thomas


-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages qemu-system-x86 depends on:
ii  ipxe-qemu   1.0.0+git-2013.c3d1e78-2
ii  libaio1 0.3.109-4
ii  libasound2  1.0.27.2-4
ii  libbluetooth3   4.101-4.1
ii  libbrlapi0.65.0-2
ii  libc6   2.18-7
ii  libcurl3-gnutls 7.37.0-1
ii  libfdt1 1.4.0+dfsg-1
ii  libgcc1 1:4.9.0-4
ii  libglib2.0-02.40.0-3
ii  libgnutls28 3.2.14-1
ii  libiscsi2   1.11.0-4
ii  libjpeg88d-2
ii  libncurses5 5.9+20140118-1
ii  libpixman-1-0   0.32.4-1
ii  libpng12-0  1.2.50-1
ii  libpulse0   5.0-2
ii  librados2   0.80.1-1+b1
ii  librbd1 0.80.1-1+b1
ii  libsasl2-2  2.1.26.dfsg1-9
ii  libsdl1.2debian 1.2.15-9
ii  libseccomp2 2.1.1-1
ii  libspice-server10.12.5-1
ii  libssh2-1   1.4.3-3
ii  libtinfo5   5.9+20140118-1
ii  libusb-1.0-02:1.0.18-2
ii  libusbredirparser1  0.6-2
ii  libuuid12.20.1-5.7
ii  libvdeplug2 2.3.2-4
ii  libx11-62:1.6.2-2
ii  libxen-4.3  4.3.0-3+b1
ii  libxenstore3.0  4.3.0-3+b1
ii  qemu-keymaps2.0.0+dfsg-6
ii  qemu-system-common  2.0.0+dfsg-6
ii  seabios 1.7.5-1
ii  zlib1g  1:1.2.8.dfsg-1

Versions of packages qemu-system-x86 recommends:
ii  qemu-utils  2.0.0+dfsg-6

Versions of packages qemu-system-x86 suggests:
ii  kmod 16-2
pn  ovmf 
pn  samba
pn  sgabios  
pn  vde2 

-- 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#751042: Hint on the issue

[Julien Puydt]

Hi,

Peter Bruin bissected the problem down to a commit (8cfb9c6b, incorrect 
rounding in mulur), see comment #91 on the sage bug.


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#750026: transition: qtbase-opensource-src

[Niels Thykier]

On 2014-06-10 00:37, Emilio Pozuelo Monfort wrote:
> On 10/06/14 00:24, Emilio Pozuelo Monfort wrote:
>> On 10/06/14 00:10, Lisandro Damián Nicanor Pérez Meyer wrote:
>>> fcitx-qt5 can be binNMUed on all archs now.
>>
>> Scheduled.
> 
> BTW I just saw this. Is there anything we need to do here?
> 
> https://release.debian.org/transitions/html/auto-qtdeclarative-opensource-src.html
> 
> Emilio
> 
> 

dak[1] suggests they will need to be rebuilt/fixed or go away:

"""
Checking reverse dependencies...
# Broken Depends:
2048-qt: 2048-qt
qtdeclarative-opensource-src: qtdeclarative5-examples
qtquickcontrols-opensource-src: qtquickcontrols5-examples

"""

~Niels


[1]
$ dak rm -nR -b $(echo
'qml-module-qtquick-dialogs|qml-module-qtquick-privatewidgets|qtdeclarative5-dialogs-plugin|qtdeclarative5-folderlistmodel-plugin|qtdeclarative5-localstorage-plugin|qtdeclarative5-models-plugin|qtdeclarative5-particles-plugin|qtdeclarative5-privatewidgets-plugin|qtdeclarative5-qtquick2-plugin|qtdeclarative5-settings-plugin|qtdeclarative5-test-plugin|qtdeclarative5-window-plugin|qtdeclarative5-xmllistmodel-plugin'
| tr '|' ' ')


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751077: icedove: program locks up when attempting attachment, gdb no help

[Arthur Marsh]

Package: icedove
Version: 24.5.0-2
Severity: important

Dear Maintainer,

*** Reporter, please consider answering these questions, where appropriate ***

   * What led up to the situation?

attempting to attach a PDF file to an email.

 gdb icedove
GNU gdb (Debian 7.7.1-1) 7.7.1
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from icedove...(no debugging symbols found)...done.
(gdb) run
Starting program: /usr/bin/icedove
[Thread debugging using libthread_db enabled]
Using host libthread_db library 
"/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".

(process:8932): GLib-CRITICAL **: g_slice_set_config: assertion 'sys_page_size 
== 0' failed
warning: Corrupted shared library list: 0xb7db1c00 != 0xb7d3

(icedove:8932): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::sm-connect after class was initialised

(icedove:8932): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::show-crash-dialog after class was initialised

(icedove:8932): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::display after class was initialised

(icedove:8932): GLib-GObject-WARNING **: Attempt to add property 
GnomeProgram::default-icon after class was initialised
[New Thread 0xb46f1b40 (LWP 8944)]
[New Thread 0xb33ffb40 (LWP 8945)]
[New Thread 0xb27ffb40 (LWP 8947)]
[New Thread 0xb1ffeb40 (LWP 8948)]
[New Thread 0xb17fdb40 (LWP 8949)]
[New Thread 0xb0b33b40 (LWP 8950)]
[New Thread 0xb005eb40 (LWP 8951)]
[New Thread 0xaf85db40 (LWP 8952)]
[New Thread 0xaf05cb40 (LWP 8953)]
[New Thread 0xae85bb40 (LWP 8954)]
[Thread 0xaf05cb40 (LWP 8953) exited]
[New Thread 0xadbffb40 (LWP 8958)]
[New Thread 0xaf05cb40 (LWP 8959)]
[New Thread 0xad7ffb40 (LWP 8960)]
enigmail.js: Registered components
[New Thread 0xa54ffb40 (LWP 8961)]
[New Thread 0xa48ffb40 (LWP 8962)]
[New Thread 0xa2cffb40 (LWP 8963)]
[New Thread 0xa1f15b40 (LWP 8966)]
[Thread 0xa1f15b40 (LWP 8966) exited]
[New Thread 0xa1714b40 (LWP 8967)]
mimeVerify.jsm: module initialized
[New Thread 0xa1f15b40 (LWP 8968)]
[New Thread 0xa00ffb40 (LWP 8970)]
[New Thread 0x9f8feb40 (LWP 8971)]
[Thread 0xae85bb40 (LWP 8954) exited]
[New Thread 0xae85bb40 (LWP 8973)]
[New Thread 0x9d3ffb40 (LWP 8974)]
[New Thread 0x9cbfeb40 (LWP 8975)]
[New Thread 0x9c3fdb40 (LWP 8976)]
[New Thread 0x9b9ffb40 (LWP 8977)]
[New Thread 0x98df7b40 (LWP 8979)]
[New Thread 0x985f6b40 (LWP 8980)]
[New Thread 0x979ffb40 (LWP 8986)]
[New Thread 0x8beffb40 (LWP 8993)]
[New Thread 0x8b2ffb40 (LWP 8995)]
[New Thread 0x8b1feb40 (LWP 8996)]
[Thread 0x9c3fdb40 (LWP 8976) exited]
[Thread 0x9b9ffb40 (LWP 8977) exited]
[New Thread 0x9b9ffb40 (LWP 9003)]
[New Thread 0x9c3fdb40 (LWP 9004)]
[Thread 0x9c3fdb40 (LWP 9004) exited]
[Thread 0x8b1feb40 (LWP 8996) exited]
[New Thread 0x88affb40 (LWP 9008)]
[New Thread 0x882feb40 (LWP 9009)]
[New Thread 0x87afdb40 (LWP 9010)]
[New Thread 0x872fcb40 (LWP 9011)]
[New Thread 0x86afbb40 (LWP 9012)]
[New Thread 0x862fab40 (LWP 9013)]
[New Thread 0x85af9b40 (LWP 9014)]
[Thread 0x87afdb40 (LWP 9010) exited]
[Thread 0x872fcb40 (LWP 9011) exited]
[Thread 0x862fab40 (LWP 9013) exited]
[Thread 0x882feb40 (LWP 9009) exited]
[Thread 0x85af9b40 (LWP 9014) exited]
[New Thread 0x85af9b40 (LWP 9016)]
[Thread 0x85af9b40 (LWP 9016) exited]

(icedove:8932): GLib-CRITICAL **: Source ID 1689 was not found when attempting 
to remove it

(icedove:8932): GLib-CRITICAL **: Source ID 1801 was not found when attempting 
to remove it
[New Thread 0x85af9b40 (LWP 9018)]
[New Thread 0x882feb40 (LWP 9019)]
[Thread 0x86afbb40 (LWP 9012) exited]
[Thread 0x882feb40 (LWP 9019) exited]
[Thread 0x88affb40 (LWP 9008) exited]
[New Thread 0x88affb40 (LWP 9021)]
[New Thread 0x882feb40 (LWP 9022)]
[Thread 0x882feb40 (LWP 9022) exited]
[Thread 0x88affb40 (LWP 9021) exited]
Cannot find user-level thread for LWP 8995: generic error


   * What exactly did you do (or not do) that was effective (or
 ineffective)?
   * What was the outcome of this action?
   * What outcome did you expect instead?

*** End of the template - remove these template lines ***


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (500, 
'oldstable'), (1, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 3.15.0+ (SMP w/2 CPU cores)
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (char

Bug#750975: RM: conky-all -- ROM; merge with src:conky

[Vincent Cheng]

block 750975 by 749173
thanks

On Sun, Jun 8, 2014 at 10:55 PM, Vincent Cheng  wrote:
> Package: ftp.debian.org
> Severity: normal
>
> Hi,
>
> Now that src:nvidia-settings and libxnvctrl{0,-dev} have been moved back to
> main (#749173), there is no reason to split conky into two separate source
> packages anymore (src:conky in main and src:conky-all in contrib; rationale
> given in #579102, but essentially it comes down to the fact that 
> libxnvctrl-dev
> was in contrib and is also a build-dep for conky-all).
>
> Please remove src:conky-all from the archive. The binary "conky-all" package
> will be built from src:conky in the future.
>
> Regards,
> Vincent

Marking as blocked by #749173 (since it was re-opened).

Regards,
Vincent


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#742605: (no subject)

[Murray McAllister]

I had a brief look at this, but not enough to find the exact source of 
the issue. I think the issue may start in writeCtagsEntry(), resulting 
in lots of new_do_write() calls.


FWIW, I tried your reproducer on Red Hat Enterprise Linux 5, ctags 
5.6-1.1, and it was not affected. Fedora was affected, which uses ctags 
5.8-10.


Cheers,

--
Murray McAllister / Red Hat Security Response Team


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751031: RFP: maxemumtvguide -- Maxemum TV-Guide, a Qt5 based TV-Guide

[Andrei POPESCU]

Control: reassign -1 wnpp
Control: severity -1 wishlist

On Lu, 09 iun 14, 19:50:27, Robert Maxe wrote:
> Package: maxemumtvguide
> Severity: /wishlist/
> Download: http://sourceforge.net/projects/mtvg/files/mtvg/14.0.0/
> License: GPLv3
> 
> Maxemum TV-Guide is a Qt5 based TV-Guide. It is developed in C++ and uses
> XMLTV to grab listings.
>  Some of Maxemum TV-Guide's features are:
>  * easy-to-use user interface
>  * quick channel(s)-only selection
>  * custom channel names and icons
>  * category filter
>  * title-, actor- and description search
>  * hidden in tray while not used
>  * favourite show highlighting
>  * realtime progress with colour encoded time
>  * trigger grabbing of TV-listings
>  * a popup window alerting the user when favourite show starts
>  * favourite overview with quick removal
>  * and more..
> 

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition.txt


signature.asc
Description: Digital signature

Bug#751030: clang-3.3: Clang should (indirectly?) depend on binutils

[Andrei POPESCU]

Control: reassign -1 clang-3.3 1:3.3-16

On Lu, 09 iun 14, 19:50:06, Rogier wrote:
> Source: clang-3.3
> Version: 1:3.3-16
> Severity: normal
> 
> Dear Maintainer,
> 
> While installing clang on a relatively bare system, binutils is
> not automaticaly installed as well. The result is that
> the installation succeeds, but compilation of just a simple
> program fails because the linker can't be found.
> 
> Kind regards,
> 
> Rogier.
> 
> -
> Example output:
> 
> jessie:root ~ 7 # apt-get install clang
> Reading package lists... Done
> Building dependency tree   
> Reading state information... Done
> The following packages were automatically installed and are no longer 
> required:
>   linux-image-3.2.0-4-amd64 linux-image-amd64
> Use 'apt-get autoremove' to remove them.
> The following extra packages will be installed:
>   binfmt-support clang-3.3 gcc-4.8-base gcc-4.9-base libasan0 libatomic1
>   libc-dev-bin libc6-dev libclang-common-3.3-dev libclang1-3.3 libcloog-isl4
>   libffi-dev libgcc-4.8-dev libgcc1 libgomp1 libisl10 libitm1 libjsoncpp0
>   libllvm3.3 libobjc-4.8-dev libobjc4 libquadmath0 libstdc++-4.8-dev
>   libstdc++6 linux-libc-dev llvm-3.3 llvm-3.3-dev llvm-3.3-runtime
>   manpages-dev
> Suggested packages:
>   glibc-doc libstdc++-4.8-doc llvm-3.3-doc
> Recommended packages:
>   gcc c-compiler
> The following NEW packages will be installed:
>   binfmt-support clang clang-3.3 libasan0 libatomic1 libc-dev-bin libc6-dev
>   libclang-common-3.3-dev libclang1-3.3 libcloog-isl4 libffi-dev
>   libgcc-4.8-dev libgomp1 libisl10 libitm1 libjsoncpp0 libllvm3.3
>   libobjc-4.8-dev libobjc4 libquadmath0 libstdc++-4.8-dev linux-libc-dev
>   llvm-3.3 llvm-3.3-dev llvm-3.3-runtime manpages-dev
> The following packages will be upgraded:
>   gcc-4.8-base gcc-4.9-base libgcc1 libstdc++6
> 4 upgraded, 26 newly installed, 0 to remove and 29 not upgraded.
> Need to get 0 B/40.1 MB of archives.
> After this operation, 172 MB of additional disk space will be used.
> Do you want to continue? [Y/n] 
> 
> [package installation log deleted]
> 
> jessie:root ~ 8 # echo "int main;" | clang -v -o /tmp/null -x c /dev/stdin
> Debian clang version 3.3-16 (branches/release_33) (based on LLVM 3.3)
> Target: i386-pc-linux-gnu
> Thread model: posix
>  "/usr/bin/clang" -cc1 -triple i386-pc-linux-gnu -emit-obj -mrelax-all 
> -disable-free -disable-llvm-verifier -main-file-name stdin -mrelocation-model 
> static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
> -fuse-init-array -target-cpu pentium4 -target-linker-version 2.24 -v 
> -resource-dir /usr/bin/../lib/clang/3.3 -internal-isystem /usr/local/include 
> -internal-isystem /usr/bin/../lib/clang/3.3/include -internal-isystem 
> /usr/include/clang/3.3/include/ -internal-externc-isystem 
> /usr/include/i386-linux-gnu -internal-externc-isystem 
> /usr/include/i486-linux-gnu -internal-externc-isystem /usr/include 
> -fdebug-compilation-dir /root -ferror-limit 19 -fmessage-length 180 
> -mstackrealign -fobjc-runtime=gcc -fobjc-default-synthesize-properties 
> -fdiagnostics-show-option -fcolor-diagnostics -backend-option 
> -vectorize-loops -o /tmp/stdin-Stoljv.o -x c /dev/stdin
> clang -cc1 version 3.3 based upon LLVM 3.3 default target i386-pc-linux-gnu
> ignoring nonexistent directory "/usr/bin/../lib/clang/3.3/include"
> ignoring nonexistent directory "/usr/include/i486-linux-gnu"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>  /usr/include/clang/3.3/include
>  /usr/include/i386-linux-gnu
>  /usr/include
> End of search list.
>  "ld" --hash-style=both --build-id --eh-frame-hdr -m elf_i386 -dynamic-linker 
> /lib/ld-linux.so.2 -o /tmp/null 
> /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crt1.o 
> /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crti.o 
> /usr/lib/gcc/i486-linux-gnu/4.8/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.8 
> -L/usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu 
> -L/lib/i386-linux-gnu -L/usr/lib/i386-linux-gnu 
> -L/usr/lib/gcc/i486-linux-gnu/4.8/../../.. -L/lib -L/usr/lib 
> /tmp/stdin-Stoljv.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc 
> --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.8/crtend.o 
> /usr/lib/gcc/i486-linux-gnu/4.8/../../../i386-linux-gnu/crtn.o
> clang: error: unable to execute command: No such file or directory
> clang: error: linker command failed due to signal (use -v to see invocation)
> 
> 
> -- System Information:
> Debian Release: jessie/sid
>   APT prefers testing
>   APT policy: (500, 'testing')
> Architecture: i386 (x86_64)
> 
> Kernel: Linux 3.13-1-amd64 (SMP w/2 CPU cores)
> Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash

-- 
http://wiki.debian.org/FAQsFromDebianUser
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic
http://nuvreauspam.ro/gpg-transition

Bug#747149: duck: detect domains that have expired

[Paul Wise]

On Tue, 2014-05-06 at 07:52 +0800, Paul Wise wrote:

> A common thing that happens when domains expire is that they become for
> sale. It would be great if duck could detect this situation.

I've attached a patch for this that detects the example I mentioned and
also the situation from #751072. The whois check needs implementing too.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise
From cdf8c9b0076a832b9dd2253e01b81bd7e3a7732e Mon Sep 17 00:00:00 2001
From: Paul Wise 
Date: Tue, 10 Jun 2014 11:48:14 +0800
Subject: [PATCH] Detect domains that are for sale

---
 lib/DUCK.pm | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/DUCK.pm b/lib/DUCK.pm
index fc22fb7..7c174fe 100644
--- a/lib/DUCK.pm
+++ b/lib/DUCK.pm
@@ -246,7 +246,7 @@ sub __run_browser {
 
 my $curl = WWW::Curl::Easy->new;
 
-my @website_moved_regexs=('new homepage','update your links','we have moved');
+my @website_moved_regexs=('new homepage','update your links','we have moved','buy this domain','domain .* for sale', 'order this domain');
 my @website_moved_whitelist=('anonscm.debian.org.*duck.git');
 
 $curl->setopt(CURLOPT_HEADER,0);
-- 
2.0.0



signature.asc
Description: This is a digitally signed message part

Bug#747054: FTBFS: package javax.servlet.http does not exist

[tony mancill]

On 06/09/2014 02:28 AM, Michael Tautschnig wrote:
> Hi Niels, all,
> 
>> On 2014-05-31 07:25, Hideki Yamane wrote:
>>> control: tags -1 +unreproducible
>>>
>>> Hi,
>>>
 I've rebuilt eclipse package in current sid using pbuilder and didn't 
 encounter any error.
 Can someone please confirm this bug is still relevant?
>>>
>>>  me too (cowbuilder amd64/sid), so once tag it as unreproducible.
>>>
>>
>> Hi Michael,
>>
>> Both Jakub and Hideki has tried to rebuild eclipse and cannot reproduce
>> your issue.  Accordingly the bug is currently tagged unreproducible.  If
>> you can still reproduce the issue, I believe there is need for more
>> information.
>>
>>
>> AFAICT you were not CC'ed, so you might not have seen this before now.
>>
> 
> Indeed :-)
> 
> So it is still reproducible for me. Would anyone here have a build log for me 
> to
> help understand what might be going wrong on my end?

Hi Michael,

Due to the size, I'm not going to send the build log to the BTS, but
will send it directly to you.  It's the output of git-buildpackage on
top of a sid cowbuilder.  (Just wondering aloud if the build failure is
somehow related to the large amount of memory in your build environment
- a la the problem you uncovered in #748567...)

Cheers,
tony



signature.asc
Description: OpenPGP digital signature

Bug#751076: ITP: omi -- rich, high-performance, standards-based management stack

[Jose Miguel Parrella]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Package: wnpp
Severity: wishlist

omi is an Apache-licensed [0] management stack [1] under active
maintenance by The Open Group. v1.0.8 was released on 09APR14 [2] and
I intend to package it for Debian. Description follows:

- --8<--
OMI's primary goal is to provide a rich, high-performance,
standards-based management stack that is suitable for a wide range of
management applications. This includes cloud management, storage
management, server hardware management, device management, and network
management, on both large and small systems (embedded and mobility).
To support this goal, OMI implements DMTF CIM/WBEM standards with the
following characteristics:

  * A very small footprint
  * A provider generator model which makes the task of creating
providers very easy
  * High portability to a wide variety of hardware and software
  * High performance
  * Support for WS-Management
- --8<--

Cheers,
bureado

[0]
https://collaboration.opengroup.org/omi/pages.php?action=show&ggid=1623
[1] https://collaboration.opengroup.org/omi/
[2]
https://collaboration.opengroup.org/omi/documents.php?action=show&dcat=&gdid=30532
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlOWe14ACgkQUWAsjQBcO4KYBACeNJ97WEsf7AnEnA9ynYuEbZrU
e4kAn1MErQmyVlHloyMvgWjFZi5nPZcD
=sVUc
-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#594711: [Pkg-openldap-devel] Bug#594711: Can we close this bug?

[Ryan Tandy]

On 07/06/14 08:21 PM, Soren Stoutner wrote:

This is a fairly old bug that appears to have been resolved.  Any
reason we shouldn't close it?


It's still possible for the same problem to be introduced again; in fact 
Ubuntu did so for few days recently. So rather than just close the bug, 
let's try to fix it by adding the requested documentation. What do you 
think of this:


Database format upgrades

  When upgrading slapd to a new version where the database library's
  storage format has changed, the database has to be backed up using
  slapcat(8) before upgrading and restored using slapadd(8) afterwards.
  Normally the maintainer scripts will handle this automatically,
  performing the dump and restore as needed.

  If, after upgrading, slapd fails to start and you see the message
  "Program version doesn't match environment version" in syslog, then
  the DB version may have changed without a dump and reload. This should
  be reported as a bug in the slapd package. In this case you will have
  to downgrade slapd to the previous version as the new tools are unable
  to dump the old database, and the same error would prevent you from
  upgrading to the fixed version. Old package versions can be
  found at http://snapshot.debian.org if needed.

pkg-openldap-devel readers, any feedback on the above text? The 
second-to-last sentence is intended to specifically address this bug.


thanks,
Ryan


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751075: marco: hard to resize certain windows (e.g. devhelp)

[Ove Kaaven]

Package: marco
Version: 1.8.0+dfsg1-5
Severity: normal

If you start something like Devhelp, and move the mouse cursor to its
window borders, the resize cursor will appear as normal. But if you then
press the mouse button to try to drag that border, the window menu will
appear instead. Perhaps the window manager is confused by Devhelp having
some kind of custom title bar (so there's no window menu in it).

Fortunately, if you use that window menu and choose Resize from there,
you'll still be able to use the awkward designed-for-keyboards way of
resizing, though. But it's quite inconvenient.

-- System Information:
Debian Release: jessie/sid
  APT prefers testing
  APT policy: (900, 'testing'), (600, 'stable'), (1, 'experimental'), (1, 
'unstable')
Architecture: i386 (i686)

Kernel: Linux 3.14-1-686-pae (SMP w/8 CPU cores)
Locale: LANG=nb_NO.utf8, LC_CTYPE=nb_NO.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages marco depends on:
ii  libatk1.0-0   2.12.0-1
ii  libc6 2.18-7
ii  libcairo2 1.12.16-2
ii  libcanberra-gtk0  0.30-2
ii  libcanberra0  0.30-2
ii  libfontconfig12.11.0-5
ii  libfreetype6  2.5.2-1
ii  libgdk-pixbuf2.0-02.30.7-1
ii  libglib2.0-0  2.40.0-3
ii  libgtk2.0-0   2.24.23-1
ii  libgtop2-72.28.5-2
ii  libice6   2:1.0.8-2
ii  libmarco-private0 1.8.0+dfsg1-5
ii  libpango-1.0-01.36.3-1
ii  libpangocairo-1.0-0   1.36.3-1
ii  libpangoft2-1.0-0 1.36.3-1
ii  libsm62:1.2.1-2
ii  libstartup-notification0  0.12-3
ii  libx11-6  2:1.6.2-2
ii  libxcomposite11:0.4.4-1
ii  libxcursor1   1:1.1.14-1
ii  libxdamage1   1:1.1.4-1
ii  libxext6  2:1.3.2-1
ii  libxfixes31:5.0.1-1
ii  libxinerama1  2:1.1.3-1
ii  libxrandr22:1.4.2-1
ii  libxrender1   1:0.9.8-1
ii  marco-common  1.8.0+dfsg1-5
ii  zenity3.12.1-1

marco recommends no packages.

marco suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751074: seyon: Conflicting declarations of function DismissDirectory to shadow risk of undefined behaviour

[Michael Tautschnig]

Package: seyon
Version: 2.20c-31
Severity: minor
Usertags: goto-cc

During an analysis of all Debian packages using our research compiler tool-chain
(using tools from the cbmc package) the following error was found:

The definition of DismissDirectory requires two arguments (even though the
second is unused at present):

http://sources.debian.net/src/seyon/2.20c-31/SeDial.c?hl=356#L355

Yet the call here

http://sources.debian.net/src/seyon/2.20c-31/SeActions.c?hl=70#L70

only passes one, thus possibly causes undefined behaviour. This is due to the
wrong and incomplete declaration here:

http://sources.debian.net/src/seyon/2.20c-31/SeActions.c?hl=63#L63

Best,
Michael



pgp_lPBf95lxp.pgp
Description: PGP signature

Bug#751073: redhat-cluster: Conflicting declarations of function daemon_init to cause undefined behaviour

[Michael Tautschnig]

Package: redhat-cluster
Version: 3.1.8-1.1
Usertags: goto-cc

During an analysis of all Debian packages using our research compiler tool-chain
(using tools from the cbmc package) the following error was found:

The following declaration of function daemon_init

http://sources.debian.net/src/redhat-cluster/3.1.8-1.1/cman/qdisk/main.c?hl=39#L39

shadows the fact that this function actually doesn't return a value:

http://sources.debian.net/src/redhat-cluster/3.1.8-1.1/cman/qdisk/daemon_init.c?hl=198#L197

Hence the call here will cause undefined behaviour:

http://sources.debian.net/src/redhat-cluster/3.1.8-1.1/cman/qdisk/main.c?hl=2004#L2004

Best,
Michael



pgpDv4lh8PuwH.pgp
Description: PGP signature

Bug#703579:

[Thomas Moulard]

Please note that PCL is now in the NEW queue:
https://ftp-master.debian.org/new/pcl_1.7.1-1.html

-- 
Thomas Moulard


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751072: gtg: Upstream homepage has moved

[Olly Betts]

Source: gtg
Version: 0.3.1-1
Severity: minor

The homepage is currently set to:

http://gtg.fritalk.com/

This is now just a domain holding page - it seems the upstream homepage
is now:

http://gtgnome.net/

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750817: ITP: x265 -- x265 HEVC Encoder

[Luca Barbato]

On 10/06/14 02:06, Reinhard Tartler wrote:
> On Sun, Jun 8, 2014 at 4:25 AM, Andrei POPESCU  
> wrote:
>> Control: reassign -1 wnpp
>>
>> On Sb, 07 iun 14, 08:47:41, Rico Tzschichholz wrote:
>>> Package: x265
>>> Severity: wishlist
>>>
>>> Package: wnpp
>>> Severity: wishlist
>>>
>>>
>>> Package name: x265
>>> URL : https://bitbucket.org/multicoreware/x265/wiki/Home
>>> License : GPL2, BSD
>>> Description : free library for encoding H265/HEVC video streams.
> 
> This package is going to be maintained under the pkg-multimedia umbrella.
> 
> Since this package is probably going to be similar to x264, I guess
> it's easiest to track the github mirror of the upstream mercurial
> repo.

+1

> It seems that there is no upstream mailing list, nor other way to
> contact the upstream devs at this point. Luca, can you confirm or
> correct this?

I'm quite sure there is a mailing list.

https://mailman.videolan.org/listinfo/x265-devel


> I took a first look at the package, and it builds a shared library by
> default (good). Unfortunately, it doesn't provide a proper SONAME:
> 
> $ objdump -p libx265.so | grep SONAME
>   SONAME   libx265.so
> 
> This makes me wonder if it's worth building it as shared library in
> debian as this point, or if we wouldn't be better of with a static
> library only. I wonder what is upstream's take on this?

Upstream should be notified, I'd advise to just provide the static
library given the kind of usecase.

lu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750604: No Support in kernel-package for s390x architecture

[Stephen Powell]

On Mon, 09 Jun 2014 02:00:37 -0400 (EDT), Manoj Srivastava wrote:
> 
> I have not tried building kernels for 3390x, and don't really
> have an idea of what it needs to build a kernel (basic configuration,
> vmlinux/vmlinuz, etc).  Do you have an idea what would be required?  If
> not, I'll take a stab later of looking at the official images to see
> what they do.

s390x is very similar to s390, except that it has a 64-bit user space.
s390 has a 64-bit kernel space and a 32-bit user space.  s390x has a
64-bit kernel space and a 64-bit user space.

wheezy is the last Debian release to support s390.  It is also the first
release to support s390x.  wheezy is the only release that supports both.
Starting with jessie, only s390x is supported.

I don't know enough about the internals to know what needs to be done,
or I'd write a patch and send it to you myself.

See Debian bug number 750925 for a related bug in "make deb-pkg".
"make deb-pkg" can be made to work with a small patch or by explicitly
specifying a "make" variable.

If you don't have access to an s390x server for testing purposes, here's
how to simulate one:

   http://users.wowway.com/~zlinuxman/hercules.htm

It will be slow compared to a real mainframe.  It may take days to compile
a kernel, depending on how fast your host system is.  But it does work.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#741294: ITP: wxastrocapture -- acquisition of astronomical images with web cams

[Olly Betts]

On Mon, Mar 10, 2014 at 09:59:36PM +0100, Steffen Möller wrote:
> * Package name: wxastrocapture
> * URL : http://arnholm.org/astro/software/wxAstroCapture/
> * License : GPL-2+
>   Programming Lang: C++
>   Description : acquisition of astronomical images with web cams

I see from the NEW queue that this uses wxwidgets2.8:

https://ftp-master.debian.org/new/wxastrocapture_1.8.1+git20140303+dfsg-2.html

We're in the middle of a transition to eliminate wxwidgets2.8 from the
archive, so it's not helpful to be adding new packages which depend on
it:

https://release.debian.org/transitions/html/wxwidgets3.0.html

Have you tried building wxastrocapture against wxwidgets3.0?

Cheers,
Olly


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751069: csound: Does not recognize STK opcodes even though libstk is installed

[Felipe Sateler]

Control: reassign -1 librtaudio4 4.1.1~ds0-1
Control: retitle -1 rtaudio: breaks ABI without SONAME bump
Control: severity -1 serious
Control: affects -1 csound

Hi Forrest,

On Mon, Jun 9, 2014 at 8:58 PM, Forrest Cahoon  wrote:
> Package: csound
> Version: 1:6.03.2~dfsg-1
> Severity: normal
>
> Dear Maintainer,
>
> Every time I render a csd file, the following warning appears near the top of
> csound's output:
>
> WARNING: could not open library '/usr/lib/csound/plugins64-6.0/libstk.so'
> (/usr/lib/x86_64-linux-gnu/libstk.so.0: undefined symbol:
> _ZN7RtAudio10openStreamEPNS_16StreamParametersES1_mjPjPFiPvS3_jdjS3_ES3_PNS_13StreamOptionsEPFvN7RtError4TypeERKSsE)
>
> If I don't try to use STK opcodes, it's just a harmless warning. But if I try
> to use an STK opcode, I get an error like this:
>
> error: syntax error, unexpected T_IDENT  (token "STKTubeBell") from file
> helloSTKTubeBell.csd (1)
>  line 20:
aOut STKTubeBell <<<
> Unexpected untyped word aOut when expecting a variable
> Parsing failed due to invalid input!
>
> This looks to me like csound failed to recognize STKTubeBell as an opcode,
> which is consistent with the warning which appears to say the STK opcodes
> weren't loaded.

The problem is that rtaudio changed with the last version, and the
SONAME was not bumped.

The "gibberish" undefined symbol you quote above translates to the
following function:

RtAudio::openStream(RtAudio::StreamParameters*,
RtAudio::StreamParameters*, unsigned long, unsigned int, unsigned
int*, int (*)(void*, void*, unsigned int, double, unsigned int,
void*), void*, RtAudio::StreamOptions*, void (*)(RtError::Type,
std::basic_string, std::allocator >
const&))

And unfortunately RtError no longer exists, as it was replaced by RtAudioError.

This requires a SONAME bump in RtAudio, and a rebuild of all reverse deps.

-- 

Saludos,
Felipe Sateler


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750160: RFS: aptitude/0.6.11-1 [RC]

[Daniel Hartwig]

On 10 June 2014 04:58, Axel Beckert  wrote:
> One remark though about something I didn't notice with the previous
> version:
>
> aptitude doesn't seem to cleanly build twice in a row. After a
> non-chrooted build with "debuild" and "debclean" afterwards,
> "pdebuild" for the chrooted build initially failed as follows:
>
[…]
>  aptitude-0.6.11/doc/ru/aptitude.xml
>  aptitude-0.6.11/doc/ru/manpage.xml
> dpkg-source: error: aborting due to unexpected upstream changes, see 
> /tmp/aptitude_0.6.11-1.diff.7en63G
> dpkg-source: info: you can integrate the local changes with dpkg-source 
> --commit
> dpkg-buildpackage: error: dpkg-source -b aptitude-0.6.11 gave error exit 
> status 2
>
> The mentioned diff shows that these files are new files. So they
> should be cleaned up in the clean target.
>

Yes, this issue has been around for some time.

> Maybe adding
>
> doc/??/aptitude.xml
> doc/??/manpage.xml
>
> to debian/clean helps -- unless the source files are matched by this, too.

The source are doc/en/aptitude.xml.  Anyway, this is simple enough to fix.

Thanks


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#709053: pbuilder + /dev/shm workaround

[anarcat]

I have found that putting:

USERUNSHM=no

in my pbuilderrc works around this problem.

a.

-- 
We will create a civilization of the Mind in Cyberspace. May it be
more humane and fair than the world your governments have made
before.
 - John Perry Barlow


signature.asc
Description: Digital signature

Bug#751071: qscintilla2: FTBFS - qscintilla2-2.8.1/debian/libqt5scintilla2-11/usr/include/qt5/Qsci/*.h: No such file or directory

[Michael Tautschnig]

Package: qscintilla2
Version: 2.8.1-4
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
mv 
/srv/jenkins-slave/workspace/sid-goto-cc-qscintilla2/qscintilla2-2.8.1/debian/libqt5scintilla2-11/usr/include/qt5/Qsci/*.h
 
/srv/jenkins-slave/workspace/sid-goto-cc-qscintilla2/qscintilla2-2.8.1/debian/libqt5scintilla2-dev/usr/include/qt5/Qsci/
mv: cannot stat 
'/srv/jenkins-slave/workspace/sid-goto-cc-qscintilla2/qscintilla2-2.8.1/debian/libqt5scintilla2-11/usr/include/qt5/Qsci/*.h':
 No such file or directory
debian/rules:123: recipe for target 'install' failed
make: *** [install] Error 1
dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2

The full build log is attached; yet the same failures are also observed on the
buildds with the most recent rebuild.

Best,
Michael



qscintilla2-build-log.txt.gz
Description: application/gunzip


pgpTI5W6QihaU.pgp
Description: PGP signature

Bug#750993: developers-reference: Please mention more lint-style tools

[Paul Wise]

On Mon, 2014-06-09 at 13:06 +0200, Guillem Jover wrote:

> To the list of generic lint-style tools, I'd add:
> 
>   scan-build (clang)
> 
> and I got a (most probably outdated) list of tools here:
> 
>   

Thanks, added most of these and more to the TODO lists in c-a-t-t.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Bug#750925: "make deb-pkg" produces a non-installable package on the s390x architecture

[Stephen Powell]

On Sun, 08 Jun 2014 09:59:47 -0400 (EDT), maximilian attems wrote:
> 
> see scripts/package/builddeb:
> s390*)
> debarch=s390 ;;
> 
> this debarch setting very likely predates s390x

Thanks for the tip.  While looking at this file, I discovered
a circumvention.  Use the make variable

   KBUILD_DEBARCH=s390x

This works, even with an unmodified builddeb script.  In my test case,
I set CONFIG_LOCALVERSION to "-1custom01-s390x" during kernel configuration
(under "General Setup").  I also set CONFIG_DEBUG_INFO off.   (This is under
"Kernel Hacking".)  Then I issued

   make KDEB_PKGVERSION=3.14.4-1 KBUILD_PKG_ROOTCMD=fakeroot \
   INSTALL_MOD_STRIP=1 KBUILD_DEBARCH=s390x deb-pkg

as a non-root user.  It built a kernel image package just the way I wanted it.

-- 
  .''`. Stephen Powell
 : :'  :
 `. `'`
   `-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751070: python-setuptools: FTBFS - python3.3: Command not found

[Michael Tautschnig]

Package: python-setuptools
Version: 3.6-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
touch build-python2.7
python3.3 setup.py build
make: python3.3: Command not found
debian/rules:43: recipe for target 'build-python3.3' failed
make: *** [build-python3.3] Error 127
dpkg-buildpackage: error: debian/rules build gave error exit status 2


It seems build dependencies need to be tightened down as (see attached, full
build log) python3.4 is being installed.

Best,
Michael



python-setuptools-build-log.txt.gz
Description: application/gunzip


pgposQjyeLuuF.pgp
Description: PGP signature

Bug#751069: csound: Does not recognize STK opcodes even though libstk is installed

[Forrest Cahoon]

Package: csound
Version: 1:6.03.2~dfsg-1
Severity: normal

Dear Maintainer,

Every time I render a csd file, the following warning appears near the top of
csound's output:

WARNING: could not open library '/usr/lib/csound/plugins64-6.0/libstk.so'
(/usr/lib/x86_64-linux-gnu/libstk.so.0: undefined symbol:
_ZN7RtAudio10openStreamEPNS_16StreamParametersES1_mjPjPFiPvS3_jdjS3_ES3_PNS_13StreamOptionsEPFvN7RtError4TypeERKSsE)

If I don't try to use STK opcodes, it's just a harmless warning. But if I try
to use an STK opcode, I get an error like this:

error: syntax error, unexpected T_IDENT  (token "STKTubeBell") from file
helloSTKTubeBell.csd (1)
 line 20:
>>>aOut STKTubeBell <<<
Unexpected untyped word aOut when expecting a variable
Parsing failed due to invalid input!

This looks to me like csound failed to recognize STKTubeBell as an opcode,
which is consistent with the warning which appears to say the STK opcodes
weren't loaded.

Here are the STK packages I have installed:
root@makemake:~# dpkg -l | grep stk
ii  libstk0-dev:amd644.4.4-4   amd64 Sound
Synthesis Toolkit (development files)
ii  libstk0c2a:amd64 4.4.4-4   amd64 Sound
Synthesis Toolkit
ii  stk  4.4.4-4   amd64 Sound
Synthesis Toolkit (example applications)
ii  stk-doc  4.4.4-4   all   Sound
Synthesis Toolkit (documentation)



-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages csound depends on:
ii  libc62.19-1
ii  libcsound64-6.0  1:6.03.2~dfsg-1
ii  libgcc1  1:4.9.0-5
ii  libgomp1 4.9.0-5
ii  libstdc++6   4.9.0-5

Versions of packages csound recommends:
ii  csound-utils  1:6.03.2~dfsg-1

csound suggests no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#749942: taskcoach: segfault on quit

[Nicolas Boulenguez]

Package: taskcoach
Followup-For: Bug #749942

Hello.
An upstream author is investigating the issue, but has been unable to
reproduce the problem so far.

Would you please attach the contents of this file?
"~/.config/Task Coach/TaskCoach.ini"
In case you have activated the synchronization with an iPhone, be sure
to remove your password from these contents.

Quite unrelated, running
# python -mtrace —trace /usr/bin/taskcoach > log.txt 2>&1
then attaching the content of log.txt would be very useful.
Thanks.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751068: ocsmanager packages

[Jelmer Vernooij]

Source: openchange
Severity: wishlist

The ocsmanager python package still needs to be packaged. This will
require some apache integration code in mapiproxy, and possibly some
upstream fixes (upstream doesn't install ocsmanager by default).


-- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#738493: bumped severity

[Antoine Beaupré]

Control: severity -1 critical

I bumped the severity of this bug because it basically breaks all the
authentication of TLS certificates in Perl, so it affects other software
(for example Ikiwiki):

http://ikiwiki.info/bugs/openid_login_fails_wirth_Could_not_determine_ID_provider_from_URL/

See also:

http://www.jwz.org/blog/2014/03/apple-broke-lwp-in-a-new-and-exciting-way-on-10-9-2/

I have also filed a related bug here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744404

A.
-- 
Government is the Entertainment division of the military-industrial
complex.
- Frank Zappa


pgp4c1Y_OH_dP.pgp
Description: PGP signature

Bug#748595: irqbalance: MSI interrupts found in /proc/interrupts but none found in sysfs (kernel version mismatch)

[Ben Hutchings]

Neil, I just ran into the issue of irqbalance being broken in Debian 7
'wheezy'.  I don't know why the Debian maintainer upgraded to this
incompatible version, but downgrading would be pretty hard now.

At  you referred to
the commit that added msi_irqs in sysfs, which looks like it should be
easy to cherry-pick (as we are on 3.2 and it went into 3.3), but also
you mentioned subsequent bug fixes.  Was there anything other than this
one:

commit 424eb391596a38ddf422bee1617e4b9dea60126f
Author: Neil Horman 
Date:   Tue Jan 3 10:29:54 2012 -0500

PCI: msi: fix imbalanced refcount of msi irq sysfs objects

?

The other interesting change I see is this one:

commit 1c51b50c2995f543d145d3bce78029ac9f8ca6b3
Author: Greg Kroah-Hartman 
Date:   Thu Dec 19 12:30:17 2013 -0800

PCI/MSI: Export MSI mode using attributes, not kobjects

Does the current irqbalance work with both versions of the sysfs
interface?

Ben.

-- 
Ben Hutchings
DNRC Motto:  I can please only one person per day.
Today is not your day.  Tomorrow isn't looking good either.


signature.asc
Description: This is a digitally signed message part

Bug#750817: ITP: x265 -- x265 HEVC Encoder

[Reinhard Tartler]

On Sun, Jun 8, 2014 at 4:25 AM, Andrei POPESCU  wrote:
> Control: reassign -1 wnpp
>
> On Sb, 07 iun 14, 08:47:41, Rico Tzschichholz wrote:
>> Package: x265
>> Severity: wishlist
>>
>> Package: wnpp
>> Severity: wishlist
>>
>>
>> Package name: x265
>> URL : https://bitbucket.org/multicoreware/x265/wiki/Home
>> License : GPL2, BSD
>> Description : free library for encoding H265/HEVC video streams.

This package is going to be maintained under the pkg-multimedia umbrella.

Since this package is probably going to be similar to x264, I guess
it's easiest to track the github mirror of the upstream mercurial
repo.

It seems that there is no upstream mailing list, nor other way to
contact the upstream devs at this point. Luca, can you confirm or
correct this?

I took a first look at the package, and it builds a shared library by
default (good). Unfortunately, it doesn't provide a proper SONAME:

$ objdump -p libx265.so | grep SONAME
  SONAME   libx265.so

This makes me wonder if it's worth building it as shared library in
debian as this point, or if we wouldn't be better of with a static
library only. I wonder what is upstream's take on this?


-- 
regards,
Reinhard


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750733: Processed: bumping severity

[Thomas Dickey]

On Mon, Jun 09, 2014 at 03:49:39PM -0400, Thomas Dickey wrote:
> - Original Message -
> | From: "Sven Joachim" 
> | To: "Thomas Dickey" 
> | Cc: 750...@bugs.debian.org, "Klaus Ethgen" 
> | Sent: Monday, June 9, 2014 3:43:20 PM
> | Subject: Re: Bug#750733: Processed: bumping severity
> | 
> | On 2014-06-09 21:22 +0200, Thomas Dickey wrote:
> | 
> | > On Mon, Jun 09, 2014 at 07:12:11PM +, Debian Bug Tracking
> | > System wrote:
> | >> Processing commands for cont...@bugs.debian.org:
> | >> 
> | >> > # Not sure if the problem happens with more readable fonts than
> | >> > 5x8,
> | >> > # but better keep this xterm version out of testing
> | >> > severity 750733 serious
> | >> Bug #750733 [xterm] Newest version sets the foreground to the
> | >> background color in some cases
> | >> Severity set to 'serious' from 'normal'
> | >> > thanks
> | >> Stopping processing here.
> | >
> | > fwiw, there's a fix for this in
> | >
> | >   ftp://invisible-island.net/temp/xterm-306a.patch.gz
> | 
> | Thanks, this fixes the problem with the bold text.  However, when
> | running 16colors.sh I see that text which is supposed to be
> | underlined
> | is not, still a regression from xterm 304.
> | 
> 
> thanks (I had not noticed that).  I will work on that next...

fixed in

ftp://invisible-island.net/temp/xterm-306b.patch.gz

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


signature.asc
Description: Digital signature

Bug#703456: [Pkg-fonts-devel] Bug#703456: Bug#703456: Bug#703456: Bug#703456: Please add Nafees Nastaleeq

[Paul Wise]

On Mon, Jun 9, 2014 at 10:43 PM, Nicolas Spalinger wrote:
> On 09/06/14 09:07, Paul Wise wrote:
>>
>> I'm not sure what all this
>> means in terms of the DFSG but it is probably OK.
>
> May I suggest helping upstream to come up with reproducible buildpath
> instead of creating a Debian-specific one ? A much better long-term strategy
> for everyone.

That would be great but since upstream are using Microsoft Windows I'm
not sure they would appreciate us telling them to completely switch
around their workflows and or platform without clear arguments about
the benefits from their PoV. Personally I don't know enough about the
upstream side of font production to be able to provide those
arguments.

> You can look into libfont-ttf-scripts-perl (and newer repository version)
> which contain the volt2ttf and related utilities and can work with
> text-based representations of the smart features. (vtp files).
>
> Type designers are increasingly moving towards using the .fea features files
> format.

Thanks for the info, I wasn't aware these existed. It would be great
to add some info about the various upstream font technologies,
non-standard sfnt tables and how to work with them in Debian to the
wiki page or a sub-page of the wiki page.

https://wiki.debian.org/Fonts

> BTW, if you haven't noticed yet, there are significant issues with the
> licensing of this font that still need fixing (it's sadly a non-standard
> mishmash of licenses with little coherence, legal validity or practical use
> cases: http://www.cle.org.pk/software/license/Nafees_Nastaleeq_License.html
> So I would expect our ftpmasters to seriously frown on this and reject it!).
> TTBOMK various people (including Mozilla) are in touch with upstream to get
> them to re-release under a community-approved license.

I did notice the custom license but didn't analyse it for DFSG issues.

-- 
bye,
pabs

http://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#724891: [debian-installer] debian-installer: Build firmware for the DNS-320/DNS-325

[Martin Michlmayr]

* Bastien ROUCARIES  [2014-06-09 23:26]:
> flash-kernel: deferring update (trigger activated)
> Processing triggers for flash-kernel (3.19) ...
> Installing kirkwood-dns320.dtb 3.14-1-kirkwood into /boot
> flash-kernel: installing version 3.14-1-kirkwood
> Not enough space in MTD ramdisk (need 8695959 but is actually 5242880).

Debian installer sets MODULES=dep, which makes the ramdisk much
smaller.  Try putting that in /etc/initramfs-tools/initramfs.conf
-- 
Martin Michlmayr
http://www.cyrius.com/


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751048: Sponsorship of newer Fizsh package

[Axel Beckert]

Hi Guido,

TL;DR: Most stuff is fine, but for an upload, I'd like to have at least
debian/copright to be streamlined. Fixes for the remaining remarks are
of course appreciated, too. Details see below.

(And if you don't mind that it there will be a slightly different
package in Debian than on SourceForge, I'd prefer that package to have
the version 1.0.6-1, too.)

On Sun, Jun 08, 2014 at 11:21:03AM +0200, Guido van Steen wrote:
> I have just uploaded a new version of Fizsh to Sourceforge. This is version
> 1.0.6. I have also uploaded the corresponding Debian source package to
> Debian Mentors. This package is availabe at
> http://mentors.debian.net/debian/pool/main/f/fizsh
> 
> Could you please review the package? I looking forward to reading your
> review.

So far I noticed the following things:


debian/copyright:

* The licenses "BSD-3-clause~zsh-history-substring-search-contributors",
  "BSD-3-clause~fizsh" and
  "BSD-3-clause~zsh-syntax-highlighting-contributors" seem to be
  identical word-wise. In that case the license only needs to be
  spelled out respectively defined once.

  Of course they differ in the copyright holders, but those are
  already listed in the "Files:" starting paragraphs and should only
  be listed there.

* The "License:" starting paragraphs only define the license text and
  do not need verbatim formatting. They should be word-wrapped if
  lines are longer than 80 columns. Comments signs from licenses
  copied from source code headers can and should be dropped.


debian/README: This file should be probably better named
debian/README.source.


debian/rules:

* lintian warning script-not-executable

  # the scripts in the "./scripts/" directory of the source package are
  # copied to both "./debian/usr/bin/" and "./debian/etc/fizsh/". they
  # are also copied to "./debian/fizsh/usr/share/fizsh/", but they are
  # not meant to be copied there. moreover they end up there without the
  # executable bit, which causes lintian to complain about
  # "script-not-executable". therefore they are explicitly removed after
  # dh_install.

  While it is good to not have the files in the package twice, this
  maybe a case where it may have been better to override the lintian
  warning as the files are meant to be sourced (if it works without
  them being executables). This not seldom with shell-related
  packages.

  So just decided if you want them user-modifiable or not and put them
  in either /etc/fizsh or /usr/share/fizsh and override the above
  mentioned lintian warning.

  Another way to get rid of that lintian warning would be to remove the
  shebang lines from those scripts. They're not needed anyway if the
  scripts are just sourced.

* A general remark on lines like the following:

  [ -d foo ] && rm -rf foo || true

  Just using "rm -rf foo" should suffice and is easier to read:

  * If the directory doesn't exist, it does nothing
  * It does exit with return code 0 even if the file does not exist.

* Warnings from configure:

  # without the following override the ./configure script would be called with 
two
  # unrecognized options: --disable-maintainer-mode, 
--disable-dependency-tracking
  override_dh_auto_configure:
./configure \
--prefix=/usr \
--includedir=\${prefix}/include \
--mandir=\${prefix}/share/man \
--infodir=\${prefix}/share/info \
--sysconfdir=/etc \
--localstatedir=/var

  I think those warnings can be safely ignored and hence the override
  could be dropped. I'm though fine if you are annoyed by the warnings
  and prefer to keep the override. (I'd be rather annoyed by such a
  long override. :-)

debian/changelog:

* While it is acceptable, I find the style with a blank line between
  each item hard to read.

* I'd also indent any line not starting wit "*" by two blanks.


debian/watch and .sig files:

* The .sig files mentioned in the context of pgpsigurlmangle are meant
  to be signature files, not public key files as on [1]. See the
  documentation for "gpg --sign" for details. The public key file goes
  into debian/upstream/signing-key.asc as done correctly with the
  package.

  [1] http://sourceforge.net/projects/fizsh/files/

  I'd be nice if you could fix that at "upstream".


Feel free to ask if my explanations weren't clear enough or too short.


To not only mention negative stuff I noticed, I was also positively
surprised that the package is indeed lintian clean, even with
--pedantic and --experimental!

Yay! :-)

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


signature.asc
Description: Digital signature

Bug#751067: python-pyramid: Bump upstream version

[Thomi Richards]

Package: python-pyramid
Severity: normal

Dear Maintainer,


Please release the new version of the python-pyramid upstream code, version 
1.5.1. See attached diff for the packaging changes I believe are necessary.


-- System Information:
Debian Release: jessie/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.13.0-29-generic (SMP w/8 CPU cores)
Locale: LANG=en_NZ.UTF-8, LC_CTYPE=en_NZ.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Index: debian/changelog
===
--- debian/changelog	(revision 29279)
+++ debian/changelog	(working copy)
@@ -1,3 +1,11 @@
+python-pyramid (1.5.1-1) unstable; urgency=low
+
+  * New upstream release
+  * Note: +dfsg was dropped from the version number since upstream version is now
+compatible with the DFSG.
+
+ -- Thomi Richards   Tue, 10 Jun 2014 10:12:32 +1200
+
 python-pyramid (1.4.5+dfsg-1) unstable; urgency=low
 
   * New upstream release
Index: debian/rules
===
--- debian/rules	(revision 29279)
+++ debian/rules	(working copy)
@@ -10,5 +10,4 @@
 		$(CURDIR)/debian/python-pyramid/usr/share/pyshared/pyramid/scaffolds/alchemy/+package+/models.py
 #		$(CURDIR)/debian/python-pyramid/usr/share/pyshared/pyramid/scaffolds/alchemy/+package+/__init__.py_tmpl \
 
-# zcat pyramid-1.3a1.tar.gz | tar --wildcards  --delete  '*/docs' | gzip > a.tgz
 

Bug#749989: [libraw1394] Bootstrap using Build-Depends-Indep

[Peter Pentchev]

On Mon, Jun 09, 2014 at 12:50:17AM +0300, Peter Pentchev wrote:
> Hi,
> 
> Here's another take on the build dependency loop issue involving
> libraw1394 and (through a long dependency list) docbook-utils.
> 
> What do you think of the attached very simple patch that only moves
> docbook-utils and docbook-xml from Build-Depends to Build-Depends-Indep
> instead?

And of course, it would all have been so much easier if I had actually
attached the patch...

G'luck,
Peter

-- 
Peter Pentchev  r...@ringlet.net r...@freebsd.org p.penc...@storpool.com
PGP key:http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13
From ee6a71a9857421c93a620ec43adf164934009ce2 Mon Sep 17 00:00:00 2001
From: Peter Pentchev 
Date: Mon, 9 Jun 2014 00:37:07 +0300
Subject: [PATCH] Move the docbook packages to Build-Depends-Indep.

Since the programs from docbook-utils are only needed when building
the arch:all libraw1394-doc package, this dependency (and the related
dependency on docbook-xml) may safely be moved to Build-Depends-Indep.

Among other benefits, this breaks a circular build dependency and makes
it possible to bootstrap the build of libraw1394 without having built
jadetex, libcupsfilters1, librsvg2-bin, libproxy1 and kdelibs5-dev
first.
---
 debian/control | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/debian/control b/debian/control
index f54f3ca..11d4ba1 100644
--- a/debian/control
+++ b/debian/control
@@ -1,7 +1,8 @@
 Source: libraw1394
 Priority: optional
 Maintainer: Guus Sliepen 
-Build-Depends: debhelper (>= 9), autotools-dev, docbook-utils, docbook-xml, 
dpkg-dev (>= 1.16.1~)
+Build-Depends: debhelper (>= 9), autotools-dev, dpkg-dev (>= 1.16.1~)
+Build-Depends-Indep: docbook-utils, docbook-xml
 Standards-Version: 3.9.3
 Section: libs
 Homepage: https://ieee1394.wiki.kernel.org/
-- 
2.0.0



signature.asc
Description: Digital signature

Bug#748561: GNU Health autoremove from testing

[Emilien Klein]

Hi team, read below for an important announcement regarding the GNU
Health package in  Debian.

2014-06-02 23:28 GMT+02:00 Emilien Klein :
> Piuparts identified this bug in March, and I haven't taken the time to
> fully address the issue that only happens in certain locales it seems
> (I've not encountered it in all my installations)
>
> The solution will be either to:
> - review the encoding of the database (`psql -l` to check it)

The encoding of the database is already Unicode, nothing to change
there (I already had the assumption that dbconfig-common does the
right thing)

> - only initialize a limited number of GNU Health Tryton modules, point 2 in 
> [0].

That doesn't work, since the "bug" in not in a GNU Health provided
file, but in the initializing of the "ir" module, which is provided by
Tryton upstream.

Since the Tryton Debian package isn't creating a database as part of
their packaging efforts, they never hit this issue (which, as I've
explained, I've never seen myself, but piuparts somehow does). Based
on the various discussions with the Tryton Debian maintainer, I don't
expect the Tryton package will start creating its own database anytime
soon, and as such they will not see/fix this bug. I will mention this
one more time for good measure.

In order to pass piuparts, the only solution is to not initialize the
database at all.
Tryton will not recognize an empty (as in, not Tryton-initialized)
Postgres database. Thus, there is no need anymore to create the
database using dbconfig-common for the gnuhealth-server package.
Creating, but more importantly upgrading and backing up the database
was the main driver for the existence of the gnuhealth-server package.

The gnuhealth-client package was created as a shell to allow for easy
and user-friendly (including creation of a Tryton profile which links
to the specific GNU Health Tryton server, a .desktop file with an icon
that end users [nurses, doctors, etc.] could just double-click). But
since there is no ready-to-use database anymore, the need for this
client package also dissapears.

Starting with version 2.4.1-3 of the GNU Health package in Debian,
there will thus only be one binary package (`gnuhealth`) produced,
which will contain the server-side components (Tryton modules) and
nothing else.

I am a bit sad to remove what I still consider to be a functional and
user-friendly packaging:
Just apt-get install gnuhealth, enter your chosen password and you're
ready to go with a database that will be upgraded and backed up
automatically for you, should you forget to do so (you obviously had
the option to respond "no" when prompted if the package should
maintain the database for you, and you are always free/encouraged to
run your own backups of your databases)

With the new GNU Health package, you will have to:
- set up your Tryton server manually (see the lengthy manual steps at
[0], which among other things includes having to modify your
PostgreSQL config files manually),
- create your database (granted, not too difficult since it can be
done in the Tryton client)
- more worryingly, make sure that each user has to apply the
upstream-provided scripts and back their database up (don't tell me
all the users will do that without ever missing a step...)

But on the other hand I'm not that sad, since:
- it was a very interesting learning project, allowing me to
understand dbconfig-common
- it's not like it's a super-used package: popcon had an all-time
record of 3 installs (and that's including 2 on my test and devel
boxes, I assume)
- it will still help the user a little bit by not having to download,
unpack and install new tarballs, and uninstalling a Debian package is
much easier than a PIP-installed sofware ;)

Should anyone in the future want to see how the user-friendly package
used to work, please look at the Debian-med subversion repository
prior to revision 17092 [1].

The new version 2.4.1-3 is pushed to Subversion. Could one of the
Debian-med DDs please upload it to unstable? (will close the Serious
bug #748561 which, if left open, would mean the complete removal of
gnuhealth in sid in less than 2 weeks).

The packages gnuhealth-server and gnuhealth-client will have to be
removed from sid (and from testing once the new package migrates to
testing). I'd appreciate a pointer to understand who I should ask that
to.

Thanks everybody for your input and help on this package!
   +Emilien

[0] 
http://anonscm.debian.org/gitweb/?p=tryton/tryton-server.git;a=blob_plain;f=debian/tryton-server.README.Debian;hb=HEAD
[1] http://anonscm.debian.org/viewvc/debian-med?view=revision&revision=17092


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750026: transition: qtbase-opensource-src

[Emilio Pozuelo Monfort]

On 10/06/14 00:24, Emilio Pozuelo Monfort wrote:
> On 10/06/14 00:10, Lisandro Damián Nicanor Pérez Meyer wrote:
>> fcitx-qt5 can be binNMUed on all archs now.
> 
> Scheduled.

BTW I just saw this. Is there anything we need to do here?

https://release.debian.org/transitions/html/auto-qtdeclarative-opensource-src.html

Emilio


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747609: give-backs on armhf for ruby-fftw3 and ruby-yajl

[Emilio Pozuelo Monfort]

On 10/06/14 00:05, Christian Hofstaedtler wrote:
>   gb ruby-yajl_1.2.0-2.dsc . armhf
>   gb ruby-fftw3_0.4-6.dsc . armhf

Scheduled.

Emilio


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750026: transition: qtbase-opensource-src

[Emilio Pozuelo Monfort]

On 10/06/14 00:10, Lisandro Damián Nicanor Pérez Meyer wrote:
> fcitx-qt5 can be binNMUed on all archs now.

Scheduled.

Emilio


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750846: wheezy-pu: package clamav/0.98.1+dfsg-1+deb7u3

[Scott Kitterman]

On Monday, June 09, 2014 23:05:21 Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Sat, 2014-06-07 at 10:05 -0400, Scott Kitterman wrote:
> > This is a small, low risk change cherry-picked from upstream that fixes a
> > significant issue reported by a Debian Wheezy user.  We had intended to
> > wait for the final 0.98.4 release and just fix this with the next package
> > update, but that release has been unaccountably delayed, so I think it
> > makes sense to go ahead and fix this issue while we wait for upstream to
> > get 0.98.4 out the door.
> 
> Please go ahead; thanks.

clamav/0.98.1+dfsg-1+deb7u4 uploaded.

Thanks,

Scott K


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#523413: It won't fix

[Lisandro Damián Nicanor Pérez Meyer]

tag 523413 wontfix
thanks

Hi! This particular bug will not be fixed in Qt4 because it is deprecated by 
upstream, only bug fixes can happen (this is considered as a feature request).

You can try building your app with Qt5.

Kinds regards, Lisandro.

-- 
If little green men land in your back yard, hide any little green women
you've got in the house.
  Mike Harding, "The Armchair Anarchist's Almanac"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#750026: transition: qtbase-opensource-src

[Lisandro Damián Nicanor Pérez Meyer]

On Wednesday 04 June 2014 18:51:51 Emilio Pozuelo Monfort wrote:
> Control: forwarded -1
> https://release.debian.org/transitions/html/qtbase-abi-5-3-0.html Control:
> tags -1 confirmed
> 
> On 31/05/14 22:20, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Package: release.debian.org
> > Severity: normal
> > User: release.debian@packages.debian.org
> > Usertags: transition
> > 
> > Hi Release Team! We are ready to go with the private stuff transition for
> > Qt 5.3.0.

qtcreator and pyqt5 got sourcefull uploads.

fcitx-qt5 can be binNMUed on all archs now.

For gammaray we need to wait a little longer.

Kinds regards, Lisandro.

-- 
Passwords are like underwear. You shouldn’t leave them out where people can
see them. You should change them regularly. And you shouldn’t loan them out
to strangers.
  Anonymous

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/


signature.asc
Description: This is a digitally signed message part.

Bug#750846: wheezy-pu: package clamav/0.98.1+dfsg-1+deb7u3

[Adam D. Barratt]

Control: tags -1 + confirmed

On Sat, 2014-06-07 at 10:05 -0400, Scott Kitterman wrote:
> This is a small, low risk change cherry-picked from upstream that fixes a
> significant issue reported by a Debian Wheezy user.  We had intended to wait
> for the final 0.98.4 release and just fix this with the next package update,
> but that release has been unaccountably delayed, so I think it makes sense to
> go ahead and fix this issue while we wait for upstream to get 0.98.4 out the
> door.

Please go ahead; thanks.

Regards,

Adam


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#747609: give-backs on armhf for ruby-fftw3 and ruby-yajl

[Christian Hofstaedtler]

Dear wanna-build team,

I've tried to reproduce the build failures on armhf of ruby-fftw3
and ruby-yajl, but couldn't see anything wrong on harris.d.o.

Please try a g-b for them:

  gb ruby-yajl_1.2.0-2.dsc . armhf
  gb ruby-fftw3_0.4-6.dsc . armhf

Thank you,
-- 
 ,''`.  Christian Hofstaedtler 
: :' :  Debian Developer
`. `'   7D1A CFFA D9E0 806C 9C4C  D392 5C13 D6DB 9305 2E03
  `-



signature.asc
Description: Digital signature

Bug#751066: flash-kernel: debconf database not purged on package purge

[Vagrant Cascadian]

Package: flash-kernel
Version: 3.20
Severity: normal
Tags: patch

I think the debconf database needs to be purged when flash-kernel is purged,
but it appears to leave the questions in tact after purge:

  # dpkg -l flash-kernel
  ...
  ii  flash-kernel   3.20 armhfutility to make certain embedded

  ~# debconf-show flash-kernel
  * flash-kernel/linux_cmdline: root=/dev/mmcblk0p1 console=ttymxc0,115200

  ~# apt-get --purge remove flash-kernel
  Reading package lists... Done
  ...
  Removing flash-kernel (3.20) ...
  Purging configuration files for flash-kernel (3.20) ...
  dpkg: warning: while removing flash-kernel, directory 
'/usr/share/flash-kernel/bootscript' not empty so not removed

  ~# debconf-show flash-kernel
  * flash-kernel/linux_cmdline: root=/dev/mmcblk0p1 console=ttymxc0,115200


The following patch fixes this:

diff --git a/debian/flash-kernel.postrm b/debian/flash-kernel.postrm
index 1eddd4d..48ae0d9 100644
--- a/debian/flash-kernel.postrm
+++ b/debian/flash-kernel.postrm
@@ -21,3 +21,5 @@ case "$1" in
exit 1
;;
 esac
+
+#DEBHELPER#


live well,
  vagrant


signature.asc
Description: Digital signature

Bug#751065: python-pyface: FTBFS - find: `/srv/jenkins-slave/workspace/sid-goto-cc-python-pyface/python-pyface-4.4.0/debian/python-pyface//usr/share/pyshared': No such file or directory

[Michael Tautschnig]

Package: python-pyface
Version: 4.4.0-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
dh_shlibdeps -ppython-pyface
find 
/srv/jenkins-slave/workspace/sid-goto-cc-python-pyface/python-pyface-4.4.0/debian/python-pyface//usr/share/pyshared
 -type f | xargs chmod 644
find: 
`/srv/jenkins-slave/workspace/sid-goto-cc-python-pyface/python-pyface-4.4.0/debian/python-pyface//usr/share/pyshared':
 No such file or directory
chmod: missing operand after '644'
Try 'chmod --help' for more information.
debian/rules:14: recipe for target 'binary-predeb/python-pyface' failed
make: *** [binary-predeb/python-pyface] Error 123


The full build log is attached - I'm wondering whether there might have been
changes to some python build tool as #751056 also has an issue with
usr/share/pyshared.

Best,
Michael



python-pyface-build-log.txt.gz
Description: application/gunzip


pgpHHrXodmKim.pgp
Description: PGP signature

Bug#751064: RM: haskell-http-client-multipart -- ROM; Merged into haskell-http-client

[Joachim Breitner]

Package: ftp.debian.org
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear FTP-Team,

haskell-http-client-multipart is obsolete and merged into
haskell-http-client, please remove it from the archive.

dak complains about a broken build-depends in haskell-http-conduit, but
that packages FTBFS for other reasons anyways and will be fixed with a
newer version, which will remove the dependency on 
haskell-http-client-multipart.

Thanks,
Joachim

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlOWKgMACgkQ9ijrk0dDIGxDQACgk/zzaeLIIPXYIsiUzVI4ht2D
svsAnjQzObUE6eemGflofjnvwV+tER4h
=TIVb
-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#751063: python-keystoneclient: FTBFS - MismatchError: !=

[Michael Tautschnig]

Package: python-keystoneclient
Version: 1:0.7.1-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/httpretty/core.py", line 1013, in 
wrapper
return test(*args, **kw)
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-python-keystoneclient/python-keystoneclient-0.7.1/keystoneclient/tests/test_session.py",
 line 238, in test_history_matches_requests
self.assertEqual(type(req_resp.history), type(ses_resp.history))
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 321, in 
assertEqual
self.assertThat(observed, matcher, message)
  File "/usr/lib/python2.7/dist-packages/testtools/testcase.py", line 406, in 
assertThat
raise mismatch_error
MismatchError:  != 


==
FAIL: process-returncode
process-returncode
--
_StringException: Binary content:
  traceback (test/plain; charset="utf8")


--
Ran 642 tests in 6.000s

FAILED (failures=2, skipped=6)
debian/rules:11: recipe for target 'override_dh_auto_test' failed
make[1]: *** [override_dh_auto_test] Error 1


The full build log is attached.

Best,
Michael



python-keystoneclient-build-log.txt.gz
Description: application/gunzip


pgpJnLjziY_dD.pgp
Description: PGP signature

Bug#715038: add mips64(el) mipsn32(el) support to eglibc

[Aurelien Jarno]

On Mon, Jun 09, 2014 at 11:21:30PM +0200, Aurelien Jarno wrote:
> On Tue, Jun 10, 2014 at 05:01:45AM +0800, Aron Xu wrote:
> > On Mon, Jun 9, 2014 at 10:11 PM, Aurelien Jarno  
> > wrote:
> > > On Thu, Jun 05, 2014 at 11:34:37PM +0800, Yunqiang Su wrote:
> > >> Hi, as I asked that guys, they insist on using /usr/lib but not 
> > >> /usr/libo32. :-(
> > >
> > > Who are the guys? What is the argument on using /usr/lib instead of
> > > /usr/libo32?
> > >
> > 
> > See https://lists.debian.org/debian-mips/2014/05/msg00050.html
> > 
> > I guess the standard he refers means the "MIPS N32 ABI Handbook".
> 
> Debian doesn't follow the standard already by putting the 64-bit
> libraries in /lib instead of /lib64, so I don't consider the argument
> that we should follow the standard for o32 libraries as valid.

Oh, and I forgot to add we are talking about a quite limited set of
packages which will have to use /libo32, and that list will probably
get even smaller with jessie. It's basically packages built from
either gcc-4.X, eglibc, ncurses, readline6 and zlib.

All other o32 packages installed through multiarch will go to
(/usr)/lib/mipsel-linux-gnu.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap

[Bastien ROUCARIES]

On Mon, Jun 9, 2014 at 11:15 PM, Ian Campbell
 wrote:
> On Mon, 2014-06-09 at 22:49 +0200, Bastien ROUCARIES wrote:
>> On Mon, Jun 9, 2014 at 8:19 PM, Ian Campbell
>>  wrote:
>> > On Mon, 2014-06-09 at 17:54 +0200, Bastien ROUCARIES wrote:
>> >> On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker  wrote:
>> >> > On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote:
>> >> >
>> >> >> Package: flash-kernel
>> >> >> Severity: important
>> >> >>
>> >> >> Flash-kernel should detect it run under debrootstrap and fail 
>> >> >> gracefully/
>> >> >>
>> >> >> Install message:
>> >> >>
>> >> >> Processing triggers for libc-bin (2.18-7) ...
>> >> >> Processing triggers for initramfs-tools (0.115) ...
>> >> >> update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood
>> >> >> /bin/df: Warning: cannot read table of mounted file systems: No such 
>> >> >> file or directory
>> >> >> warning: failed to read mtab
>> >> >> ^Cdpkg: error processing package initramfs-tools (--configure):
>> >> >>  subprocess installed post-installation script was interrupted
>> >> >> Errors were encountered while processing:
>> >> >>  initramfs-tools
>> >> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> >> >
>> >> > Hello,
>> >> >
>> >> > I am trying to understand which problem exactly you have
>> >> > encountered, but I am a bit confused: you have filed a bug
>> >> > against flash-kernel but in the log you have provided, it is not
>> >> > flash-kernel that shows an error message, but initramfs-tools.  I
>> >> > also cannot see in which context that has happened and how it
>> >> > relates to debootstrap - by default debootstrap does neither
>> >> > install a kernel image nor flash-kernel.  From your log, it looks
>> >> > like you have manually interrupted the update-initramfs process,
>> >> > resulting in the error message above:
>> >>
>> >> No I have not interupted.
>> >
>> > What is the ^C in the output from? Was it produced verbatim by the
>> > process?
>> No it is a left over
>
> From what?
>
>> >> I have installed te kirkwood kernel and flash-kernel on my chroot.
>> >
>> > Out of interest, why?
>>
>> Because I wand to add support for dns-320 and thus I am creating an image.
>
> If this is to do with
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724891 then you don't
> need to create an image for that AFAIK.

Yes it is for it. Itis a chicken and egg problem. I boot from usb key
and I have created a usb image

>> >> The problem is that flash-kernel is run by 
>> >> initramfs/post-update.d/flash-kernel
>> >>
>> >> I have added an exit 0 at the beginning of this file and everything is ok
>> >>
>> >> The best think is to exit 0 if we are under a debootstrap.
>> >
>> > If you want to install flash-kernel in a chroot/debootstrap etc then you
>> > should set FK_MACHINE=none in the environment or write none to
>> > $chroot/etc/flash-kernel/machine, either of which will cause
>> > flash-kernel to become a nop.
>>
>> Is it documented somewhere ?
>
> Apart from in the flash-kernel changelog, no.

Could be mentioned in the man page ?

Bastien

> Ian.
>


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751062: python-greenlet: FTBFS - FAIL: test_threaded_adv_leak (tests.test_leaks.ArgRefcountTests)

[Michael Tautschnig]

Package: python-greenlet
Version: 0.4.2-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
==
FAIL: test_threaded_adv_leak (tests.test_leaks.ArgRefcountTests)
--
Traceback (most recent call last):
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-python-greenlet/python-greenlet-0.4.2/tests/test_leaks.py",
 line 62, in test_threaded_adv_leak
self.assertTrue(g() is None)
AssertionError: False is not true

--
Ran 61 tests in 0.424s

FAILED (failures=1)
debian/rules:36: recipe for target 'test-2.7-stamp' failed
make[1]: *** [test-2.7-stamp] Error 1


The full build log is attached - please do let me know if the build failure
turns out to be unreproducible, in which case I shall try to provide further
information.

Best,
Michael



python-greenlet-build-log.txt.gz
Description: application/gunzip


pgpXsfkqHvhyM.pgp
Description: PGP signature

Bug#724891: [debian-installer] debian-installer: Build firmware for the DNS-320/DNS-325

[Bastien ROUCARIES]

On Mon, Mar 3, 2014 at 5:49 AM, Ian Campbell  wrote:
> On Mon, 2014-03-03 at 03:48 +0100, Cyril Brulebois wrote:
>> Control: reassign -1 flash-kernel
>>
>> Ben Hutchings  (2014-03-03):
>> > On Mon, 2014-03-03 at 02:25 +, Ben Hutchings wrote:
>> > > I found these pages:
>> > >
>> > > http://jamie.lentin.co.uk/devices/dlink-dns325/
>> >
>> > Oh, that's exactly what Bastien linked to.  Well anyway, I hope I
>> > extracted the most useful information below.
>>
>> Certainly, thanks!
>>
>> > > http://jamie.lentin.co.uk/devices/dlink-dns325/keeping-original-firmware/
>> > >
>> > > They say that these models use a Kirkwood SoC (so the kirkwood kernel
>> > > and installer flavours should be used) and that they are supported by
>> > > the standard kernel package in wheezy-backports but not wheezy.
>> > >
>> > > Given that the instructions include writing a custom kernel install
>> > > hook, I would assume that flash-kernel doesn't support these models and
>> > > therefore this bug should be reassigned to flash-kernel.  But there may
>> > > be other changes needed elsewhere.
>>
>> Punting that to flash-kernel for the time being. Ian will likely know
>> what to do with it. ;)
>
> Please can someone with access to the system provide a flash-kernel
> stanza for the system. After installing the flash-kernel
> package /usr/share/doc/flash-kernel/README.gz will contain documentation
> for (most of) the possible stanza entries
> and /usr/share/flash-kernel/db/all.db will have plenty of examples. For
> testing a stanza can be added to /etc/flash-kernel/db.
>
> From
> http://jamie.lentin.co.uk/devices/dlink-dns325/keeping-original-firmware/ it 
> looks like you can boot from both NAND and the regular disk/MMC, I'd be 
> inclined to go with installing to NAND by default, which would mean using the 
> Mtd-Kernel/Initrd style of entries.

ok the existing mtd partition are too small :S See bellow. How can I
do ? I have more space but I need to change partition table and likely
change uboot...

I have used the following config:
Machine: D-Link DNS-320 NAS (Rev A1)
Kernel-Flavors: kirkwood
DTB-Id: kirkwood-dns320.dtb
DTB-Append: Yes
Mtd-Kernel: uImage
Mtd-Initrd: ramdisk
U-Boot-Kernel-Address: 0xa0
U-Boot-Initrd-Address: 0xf0
Required-Packages: u-boot-tools
Bootloader-Sets-Incorrect-Root: yes

the mdtdinfo is:
Count of MTD devices:   6
Present MTD devices:mtd0, mtd1, mtd2, mtd3, mtd4, mtd5
Sysfs interface supported:  yes

mtd0
Name:   u-boot
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  8 (1048576 bytes, 1024.0 KiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Character device major/minor:   90:0
Bad blocks are allowed: true
Device is writable: false

mtd1
Name:   uImage
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  40 (5242880 bytes, 5.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Character device major/minor:   90:2
Bad blocks are allowed: true
Device is writable: true

mtd2
Name:   ramdisk
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  40 (5242880 bytes, 5.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Character device major/minor:   90:4
Bad blocks are allowed: true
Device is writable: true

mtd3
Name:   image
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  816 (106954752 bytes, 102.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Character device major/minor:   90:6
Bad blocks are allowed: true
Device is writable: true

mtd4
Name:   mini firmware
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  80 (10485760 bytes, 10.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Character device major/minor:   90:8
Bad blocks are allowed: true
Device is writable: true

mtd5
Name:   config
Type:   nand
Eraseblock size:131072 bytes, 128.0 KiB
Amount of eraseblocks:  40 (5242880 bytes, 5.0 MiB)
Minimum input/output unit size: 2048 bytes
Sub-page size:  512 bytes
OOB size:   64 bytes
Characte

Bug#724466: mrpt: FTBFS: "libdc1394 error: Failed to initialize libdc1394", followed by a SIGSEGV

[Jose Luis Blanco]

Hi Olly, and thanks for following up.

Actually the error from "libdc1394" is, I'm almost 100% sure, not
related to the crash: that error message comes from initialization
code in OpenCV (libopencv-dev), which MRPT links against, and during
some range of versions it was always shown at start-up and was
annoying, but not critical.

About the "urandom" error: I have no clue...

I'm trying to catch up with this package, so will try to reproduce the
error, and if I feel swamped would consider orphan it.

Best,
JL


On Mon, Jun 9, 2014 at 6:29 AM, Olly Betts  wrote:
> Jose - this RC bug has now been open for 8.5 months without any comment
> from the maintainer.  Are you still interested in maintaining mrpt in
> Debian?  If not, it would be better to orphan the package so that others
> who are interested in maintaining it can more easily take over.
>
> On Tue, Sep 24, 2013 at 07:46:12AM +0300, Damyan Ivanov wrote:
>> mrpt seems to fail to build in a clean current sid pbuilder chroot:
>>
>> [100%] Generating performance HTML pages
>> /tmp/buildd/mrpt-1.0.2/bin/mrpt-perfdata2html 
>> /tmp/buildd/mrpt-1.0.2/doc/perf-data/
>> libdc1394 error: Failed to initialize libdc1394
>> *FATAL*: Signal SIGSEGV caught!
>> make[4]: *** [doc/CMakeFiles/documentation_performance_html] Aborted
>
> Using sbuild, I also get a FTBFS, but with a different error - perhaps
> this helps:
>
> | [100%] Generating performance HTML pages
> | /«PKGBUILDDIR»/bin/mrpt-perfdata2html /«PKGBUILDDIR»/doc/perf-data/
> | Fatal: can't open /dev/urandom: Bad address
> | make[4]: *** [doc/CMakeFiles/documentation_performance_html] Aborted
>
> There's been a new upstream release of libdc1394-22 packaged since dam's
> report, so perhaps the different message is due to that rather than
> sbuild vs pbuilder:
>
> http://metadata.ftp-master.debian.org/changelogs//main/libd/libdc1394-22/libdc1394-22_2.2.2-1_changelog
>
> Cheers,
> Olly


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715038: add mips64(el) mipsn32(el) support to eglibc

[Aurelien Jarno]

On Tue, Jun 10, 2014 at 05:06:03AM +0800, Aron Xu wrote:
> On Mon, Jun 9, 2014 at 10:38 PM, Aurelien Jarno  wrote:
> > On Mon, Jun 09, 2014 at 09:02:04PM +0800, Sphinx Jiang wrote:
> >> I refreshed this patch with 2.19-1.
> >>
> >> Tested on mips64el device, build successfully.
> >>
> >>
> >> Sphinx
> >
> >
> > I have just merged the non-controversial parts, that is everything but
> > multlib. I am still opposed to having the o32 libraries in /lib and I am
> > waiting for arguments about why it can't be for example in /libo32.
> >
> > Anyway I do wonder if we want multilib support at all on a new port, we
> > now have multiarch to address this, so one can just install the
> > libc6:mips on a mipsn32 or mips64 system, or libc6:mipsel on a
> > mipsn32el or mips64el system to get o32 support.
> >
> 
> Multilib is still nice-to-have, so that we don't miss anything might
> be useful for users, and related code/configuration does not change
> from time to time so there should be maintainability burdens.

With my glibc maintainer hat, multilib is a huge pain to maintain and
doesn't play well with multiarch, so I would be more than happy to not
have it for a new architecture.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715038: add mips64(el) mipsn32(el) support to eglibc

[Aurelien Jarno]

On Tue, Jun 10, 2014 at 05:01:45AM +0800, Aron Xu wrote:
> On Mon, Jun 9, 2014 at 10:11 PM, Aurelien Jarno  wrote:
> > On Thu, Jun 05, 2014 at 11:34:37PM +0800, Yunqiang Su wrote:
> >> Hi, as I asked that guys, they insist on using /usr/lib but not 
> >> /usr/libo32. :-(
> >
> > Who are the guys? What is the argument on using /usr/lib instead of
> > /usr/libo32?
> >
> 
> See https://lists.debian.org/debian-mips/2014/05/msg00050.html
> 
> I guess the standard he refers means the "MIPS N32 ABI Handbook".

Debian doesn't follow the standard already by putting the 64-bit
libraries in /lib instead of /lib64, so I don't consider the argument
that we should follow the standard for o32 libraries as valid.

-- 
Aurelien Jarno  GPG: 4096R/1DDD8C9B
aurel...@aurel32.net http://www.aurel32.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap

[Ian Campbell]

On Mon, 2014-06-09 at 22:49 +0200, Bastien ROUCARIES wrote:
> On Mon, Jun 9, 2014 at 8:19 PM, Ian Campbell
>  wrote:
> > On Mon, 2014-06-09 at 17:54 +0200, Bastien ROUCARIES wrote:
> >> On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker  wrote:
> >> > On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote:
> >> >
> >> >> Package: flash-kernel
> >> >> Severity: important
> >> >>
> >> >> Flash-kernel should detect it run under debrootstrap and fail 
> >> >> gracefully/
> >> >>
> >> >> Install message:
> >> >>
> >> >> Processing triggers for libc-bin (2.18-7) ...
> >> >> Processing triggers for initramfs-tools (0.115) ...
> >> >> update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood
> >> >> /bin/df: Warning: cannot read table of mounted file systems: No such 
> >> >> file or directory
> >> >> warning: failed to read mtab
> >> >> ^Cdpkg: error processing package initramfs-tools (--configure):
> >> >>  subprocess installed post-installation script was interrupted
> >> >> Errors were encountered while processing:
> >> >>  initramfs-tools
> >> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
> >> >
> >> > Hello,
> >> >
> >> > I am trying to understand which problem exactly you have
> >> > encountered, but I am a bit confused: you have filed a bug
> >> > against flash-kernel but in the log you have provided, it is not
> >> > flash-kernel that shows an error message, but initramfs-tools.  I
> >> > also cannot see in which context that has happened and how it
> >> > relates to debootstrap - by default debootstrap does neither
> >> > install a kernel image nor flash-kernel.  From your log, it looks
> >> > like you have manually interrupted the update-initramfs process,
> >> > resulting in the error message above:
> >>
> >> No I have not interupted.
> >
> > What is the ^C in the output from? Was it produced verbatim by the
> > process?
> No it is a left over

>From what?

> >> I have installed te kirkwood kernel and flash-kernel on my chroot.
> >
> > Out of interest, why?
> 
> Because I wand to add support for dns-320 and thus I am creating an image.

If this is to do with
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=724891 then you don't
need to create an image for that AFAIK.

> >> The problem is that flash-kernel is run by 
> >> initramfs/post-update.d/flash-kernel
> >>
> >> I have added an exit 0 at the beginning of this file and everything is ok
> >>
> >> The best think is to exit 0 if we are under a debootstrap.
> >
> > If you want to install flash-kernel in a chroot/debootstrap etc then you
> > should set FK_MACHINE=none in the environment or write none to
> > $chroot/etc/flash-kernel/machine, either of which will cause
> > flash-kernel to become a nop.
> 
> Is it documented somewhere ?

Apart from in the flash-kernel changelog, no.

Ian.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751033: the jdk note

[Stephen Mahood]

Just to note, the reference is that bbb can use openjdk whereas
openmeeting require sun/oracle jdk. BBB does have some dependence on openjdk

~mv
-- 
cyberunions.org co-host/activist



signature.asc
Description: OpenPGP digital signature

Bug#751054: krb5-multidev: use #ifdef rather than #if in gssapi.h

[Michael Tautschnig]

Control: severity -1 wishlist

[...]
> I'm not sure if you can use #ifdef with #elif.  I've always avoided doing
> so, but have to admit having not looked it up in the C standard.
> 

Just for the record, here's what it says:

"Preprocessing directives of the forms

#ifdef identifier new-line groupopt
#ifndef identifier new-line groupopt

check whether the identifier is or is not currently defined as a macro name.
Their conditions are equivalent to #if defined identifier and #if !defined
identifier respectively."

So, yes, mixing #ifdef with #elif is fine. But using #if defined(...) will
definitively remove any doubts.

> I generally agree with you that it would be better to write -Wundef-clean
> code, but a lot of examples from, say, Autoconf are not -Wundef-clean, so
> I suspect there's a lot of this out there.  And since behavior of an
> undefined variable in preprocessor directives is well-defined by the
> standard, you'll probably get pushback against making it a rule.
> 

Yes, indeed, this case is explicitly covered. So maybe the rule should rather be
"use -Wundef with your own header files only."

I've adjusted the severity to wishlist, but feel free to tag it wontfix.

Best,
Michael



pgp_yG7O4qlFn.pgp
Description: PGP signature

Bug#747309: [xml/sgml-pkgs] Bug#747309: CVE-2014-0191

[Aron Xu]

Hi,

On Mon, Jun 9, 2014 at 11:22 PM, Salvatore Bonaccorso  wrote:
> Hi,
>
> Not looked in detail, but if applying this patch, it would also need a
> followup patch to fix a  regression.
>
> See: https://bugs.launchpad.net/ubuntu/+source/libxml2/+bug/1321869
> and http://www.ubuntu.com/usn/usn-2214-2/
>

I tried to update the package when the first USN comes out and noticed
there's action from Ubuntu Security team for regression, so the update
was held back. Now I'll try to deal with the update as soon as
possible.


Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715038: add mips64(el) mipsn32(el) support to eglibc

[Aron Xu]

On Mon, Jun 9, 2014 at 10:38 PM, Aurelien Jarno  wrote:
> On Mon, Jun 09, 2014 at 09:02:04PM +0800, Sphinx Jiang wrote:
>> I refreshed this patch with 2.19-1.
>>
>> Tested on mips64el device, build successfully.
>>
>>
>> Sphinx
>
>
> I have just merged the non-controversial parts, that is everything but
> multlib. I am still opposed to having the o32 libraries in /lib and I am
> waiting for arguments about why it can't be for example in /libo32.
>
> Anyway I do wonder if we want multilib support at all on a new port, we
> now have multiarch to address this, so one can just install the
> libc6:mips on a mipsn32 or mips64 system, or libc6:mipsel on a
> mipsn32el or mips64el system to get o32 support.
>

Multilib is still nice-to-have, so that we don't miss anything might
be useful for users, and related code/configuration does not change
from time to time so there should be maintainability burdens.

Aron


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750849: nouveau: gnome3 starts in legacy mode with nouveau and geforce gtx 650

[Julien Cristau]

Control: tag -1 moreinfo

On Sat, Jun  7, 2014 at 11:01:02 -0400, Gregory Derecho wrote:

> Package: libgl1-mesa-dri
> Version: 8.0.5-4+deb7u2
> Severity: important
> File: nouveau
> 
> Dear Maintainer,
> 
> I'm not sure if this is the right package to file this bug under, but I
> can't get the gnome-shell to start under the nouveau driver with a gtx
> 650.
> 
Please include X, kernel and gnome session logs.

Cheers,
Julien


signature.asc
Description: Digital signature

Bug#751054: krb5-multidev: use #ifdef rather than #if in gssapi.h

[Russ Allbery]

Michael Tautschnig  writes:

>> In this specific case, it would probably be fine for the MIT Kerberos code
>> base to change this line to instead be:
>> 
>> #if !defined(TARGET_OS_MAC)
>   ^ (Sure? I don't think negation is due here.)

Ack, you're correct.  I reversed the sense.

> So I do believe that

> ^\s*#\s*if\s+[a-zA-Z_][a-zA-Z0-9_]*\s*$

> is almost always wrong as those should really be #ifdef ... or #if
> defined(...), but there may be more complex expressions that are wrong
> as well. Fixing this appears to be a worthwhile (but indeed possibly
> non-trivial) goal.

There used to be a coding style that recommended #if over #ifdef for stuff
like this, but I forget why.

I'm not sure if you can use #ifdef with #elif.  I've always avoided doing
so, but have to admit having not looked it up in the C standard.

I generally agree with you that it would be better to write -Wundef-clean
code, but a lot of examples from, say, Autoconf are not -Wundef-clean, so
I suspect there's a lot of this out there.  And since behavior of an
undefined variable in preprocessor directives is well-defined by the
standard, you'll probably get pushback against making it a rule.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750160: [Aptitude-devel] Bug#750160: RFS: aptitude/0.6.11-1 [RC]

[Axel Beckert]

Control: tag -1 + pending

Hi Daniel,

Daniel Hartwig wrote:
> >>   * debian/control: New Build-Depends on libxapian-dev,
> >> replacing libept-dev.
> >
> > Thanks.
> 
> Uploaded (mentors.d.n).

Thanks. Will upload soon.

One remark though about something I didn't notice with the previous
version:

aptitude doesn't seem to cleanly build twice in a row. After a
non-chrooted build with "debuild" and "debclean" afterwards,
"pdebuild" for the chrooted build initially failed as follows:

$ pdebuild
dpkg-buildpackage: source version 0.6.11-1
dpkg-buildpackage: source distribution unstable
dpkg-buildpackage: source changed by Daniel Hartwig 
 dpkg-source --before-build aptitude-0.6.11
 fakeroot debian/rules clean
dh clean --parallel --builddirectory=build-arch --dbg-package=aptitude-dbg
   dh_testdir -O--parallel -O--builddirectory=build-arch 
-O--dbg-package=aptitude-dbg
   dh_auto_clean -O--parallel -O--builddirectory=build-arch 
-O--dbg-package=aptitude-dbg
   dh_clean -O--parallel -O--builddirectory=build-arch 
-O--dbg-package=aptitude-dbg
 dpkg-source -b aptitude-0.6.11
dpkg-source: info: using source format `3.0 (quilt)'
dpkg-source: info: building aptitude using existing 
./aptitude_0.6.11.orig.tar.xz
dpkg-source: info: local changes detected, the modified files are:
 aptitude-0.6.11/doc/de/aptitude.xml
 aptitude-0.6.11/doc/de/manpage.xml
 aptitude-0.6.11/doc/es/aptitude.xml
 aptitude-0.6.11/doc/es/manpage.xml
 aptitude-0.6.11/doc/fr/aptitude.xml
 aptitude-0.6.11/doc/fr/manpage.xml
 aptitude-0.6.11/doc/it/aptitude.xml
 aptitude-0.6.11/doc/it/manpage.xml
 aptitude-0.6.11/doc/ja/aptitude.xml
 aptitude-0.6.11/doc/ja/manpage.xml
 aptitude-0.6.11/doc/pl/aptitude.xml
 aptitude-0.6.11/doc/pl/manpage.xml
 aptitude-0.6.11/doc/ru/aptitude.xml
 aptitude-0.6.11/doc/ru/manpage.xml
dpkg-source: error: aborting due to unexpected upstream changes, see 
/tmp/aptitude_0.6.11-1.diff.7en63G
dpkg-source: info: you can integrate the local changes with dpkg-source --commit
dpkg-buildpackage: error: dpkg-source -b aptitude-0.6.11 gave error exit status 
2

The mentioned diff shows that these files are new files. So they
should be cleaned up in the clean target.

Maybe adding

doc/??/aptitude.xml
doc/??/manpage.xml

to debian/clean helps -- unless the source files are matched by this, too.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE
  `-|  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#715038: add mips64(el) mipsn32(el) support to eglibc

[Aron Xu]

On Mon, Jun 9, 2014 at 10:11 PM, Aurelien Jarno  wrote:
> On Thu, Jun 05, 2014 at 11:34:37PM +0800, Yunqiang Su wrote:
>> Hi, as I asked that guys, they insist on using /usr/lib but not /usr/libo32. 
>> :-(
>
> Who are the guys? What is the argument on using /usr/lib instead of
> /usr/libo32?
>

See https://lists.debian.org/debian-mips/2014/05/msg00050.html

I guess the standard he refers means the "MIPS N32 ABI Handbook".


Regards,
Aron Xu


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751061: puredata: Conflicting declarations of function canvas_properties

[Michael Tautschnig]

Package: puredata
Version: 0.45.4-2
Usertags: goto-cc

Thank you very much for the previous bugfix. Yet during another rebuild of all
Debian packages in a clean sid chroot (using cowbuilder and pbuilder) the build
failed with a further error. Please note that we use our research compiler
tool-chain (using tools from the cbmc package), which permits extended reporting
on type inconsistencies at link time.

[...]
libtool: link: gcc -DPD -DINSTALL_PREFIX=\"/usr\" -DUSEAPI_ALSA -DUSEAPI_JACK 
-DJACK_XRUN -DUSEAPI_OSS -DUSEAPI_PORTAUDIO -O3 -funroll-loops 
-fomit-frame-pointer -g -O2 -fstack-protector --param=ssp-buffer-size=4 
-Wformat -Werror=format-security -Wl,-z -Wl,relro -Wl,--as-needed -o pd 
pd-g_canvas.o pd-g_graph.o pd-g_text.o pd-g_rtext.o pd-g_array.o 
pd-g_template.o pd-g_io.o pd-g_scalar.o pd-g_traversal.o pd-g_guiconnect.o 
pd-g_readwrite.o pd-g_editor.o pd-g_all_guis.o pd-g_bang.o pd-g_hdial.o 
pd-g_hslider.o pd-g_mycanvas.o pd-g_numbox.o pd-g_toggle.o pd-g_vdial.o 
pd-g_vslider.o pd-g_vumeter.o pd-m_pd.o pd-m_class.o pd-m_obj.o pd-m_atom.o 
pd-m_memory.o pd-m_binbuf.o pd-m_conf.o pd-m_glob.o pd-m_sched.o pd-s_main.o 
pd-s_inter.o pd-s_file.o pd-s_print.o pd-s_loader.o pd-s_path.o pd-s_entry.o 
pd-s_audio.o pd-s_midi.o pd-s_utf8.o pd-d_ugen.o pd-d_ctl.o pd-d_arithmetic.o 
pd-d_osc.o pd-d_filter.o pd-d_dac.o pd-d_misc.o pd-d_math.o pd-d_fft.o 
pd-d_array.o pd-d_global.o pd-d_delay.o pd-d_resample.o pd-d_soundfile.o 
pd-x_arithmetic.o pd-x_connective.o pd-x_interface.o pd-x_midi.o pd-x_misc.o 
pd-x_time.o pd-x_acoustics.o pd-x_net.o pd-x_text.o pd-x_gui.o pd-x_list.o 
pd-x_array.o pd-x_scalar.o pd-s_audio_alsa.o pd-s_audio_alsamm.o 
pd-s_midi_alsa.o pd-d_fft_mayer.o pd-d_fftroutine.o pd-s_audio_jack.o 
pd-s_audio_oss.o pd-s_midi_oss.o pd-s_audio_pa.o pd-s_audio_paring.o 
-Wl,--export-dynamic  -lm -lasound -ljack -lportaudio -lpthread -ldl -lrt

error: conflicting function declarations "canvas_properties"
old definition in module g_canvas file g_canvas.c line 1532
void (struct _gobj *)
new definition in module g_editor file g_editor.c line 1045
void (struct _glist *x)

reason for conflict in types listed below (struct/struct):
composite type component counts differ (2/47)
struct _gobj {
  struct _class * g_pd;
  struct _gobj * g_next;
}
struct _glist {
  struct _text gl_obj;
  struct _gobj * gl_list;
  struct _gstub * gl_stub;
  signed int gl_valid;
  unsigned int $pad0;
  struct _glist * gl_owner;
  signed int gl_pixwidth;
  signed int gl_pixheight;
  float gl_x1;
  float gl_y1;
  float gl_x2;
  float gl_y2;
  signed int gl_screenx1;
  signed int gl_screeny1;
  signed int gl_screenx2;
  signed int gl_screeny2;
  signed int gl_xmargin;
  signed int gl_ymargin;
  struct _tick gl_xtick;
  signed int gl_nxlabels;
  struct _symbol ** gl_xlabel;
  float gl_xlabely;
  struct _tick gl_ytick;
  signed int gl_nylabels;
  unsigned int $pad1;
  struct _symbol ** gl_ylabel;
  float gl_ylabelx;
  unsigned int $pad2;
  struct _editor * gl_editor;
  struct _symbol * gl_name;
  signed int gl_font;
  unsigned int $pad3;
  struct _glist * gl_next;
  struct _canvasenvironment * gl_env;
  unsigned int gl_havewindow;
  unsigned int gl_mapped;
  unsigned int gl_dirty;
  unsigned int gl_loading;
  unsigned int gl_willvis;
  unsigned int gl_edit;
  unsigned int gl_isdeleting;
  unsigned int gl_goprect;
  unsigned int gl_isgraph;
  unsigned int gl_hidetext;
  unsigned int gl_private;
  unsigned __CPROVER_bitvector[5] $bit_field_pad0;
  unsigned __CPROVER_bitvector[48] $pad4;
}
Makefile:671: recipe for target 'pd' failed
make[3]: *** [pd] Error 64
make[3]: Leaving directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-puredata/puredata-0.45.4/src'
Makefile:903: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1

So canvas_properties is defined here:

http://sources.debian.net/src/puredata/0.45.4-2/src/g_editor.c?hl=1045#L1045

and as described above the declaration here

http://sources.debian.net/src/puredata/0.45.4-2/src/g_canvas.c?hl=1532#L1532

conflicts. What is possibly more worrying, however, is the use here:

http://sources.debian.net/src/puredata/0.45.4-2/src/g_canvas.c?hl=1607#L1607

as a t_propertiesfn really takes two arguments, one being a t_gobj and the other
being a struct _glist (so combine the conflicting declaration to get that!?):

http://sources.debian.net/src/puredata/0.45.4-2/src/m_pd.h?hl=479#L479

Consequently I'm not sure whether fixing the declaration only will do the trick
here.

Best,
Michael




pgpA3_Lx8fRkJ.pgp
Description: PGP signature

Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap

[Bastien ROUCARIES]

On Mon, Jun 9, 2014 at 8:08 PM, Karsten Merker  wrote:
> On Mon, Jun 09, 2014 at 05:54:35PM +0200, Bastien ROUCARIES wrote:
>> On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker  wrote:
>> > On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote:
>> >
>> >> Package: flash-kernel
>> >> Severity: important
>> >>
>> >> Flash-kernel should detect it run under debrootstrap and fail gracefully/
>> >>
>> >> Install message:
>> >>
>> >> Processing triggers for libc-bin (2.18-7) ...
>> >> Processing triggers for initramfs-tools (0.115) ...
>> >> update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood
>> >> /bin/df: Warning: cannot read table of mounted file systems: No such file 
>> >> or directory
>> >> warning: failed to read mtab
>> >> ^Cdpkg: error processing package initramfs-tools (--configure):
>> >>  subprocess installed post-installation script was interrupted
>> >> Errors were encountered while processing:
>> >>  initramfs-tools
>> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> >
>> > Hello,
>> >
>> > I am trying to understand which problem exactly you have
>> > encountered, but I am a bit confused: you have filed a bug
>> > against flash-kernel but in the log you have provided, it is not
>> > flash-kernel that shows an error message, but initramfs-tools.  I
>> > also cannot see in which context that has happened and how it
>> > relates to debootstrap - by default debootstrap does neither
>> > install a kernel image nor flash-kernel.  From your log, it looks
>> > like you have manually interrupted the update-initramfs process,
>> > resulting in the error message above:
>>
>> No I have not interupted.
>>
>> I have installed te kirkwood kernel and flash-kernel on my chroot.
>
> Hello,
>
> I unfortunately cannot yet reproduce your problem. Due to the
> kernel version (3.14-1) I assume that you are debootstrapping
> jessie or sid.  I have just debootstrapped a sid/armel chroot
> that included flash-kernel and linux-image-3.14-1-kirkwood on
> a sid/armhf system without problems:
>
> # debootstrap --arch=armel --include=flash-kernel,linux-image-kirkwood sid 
> armel-sid-chroot http://ftp.de.debian.org/debian
> I: Retrieving Release
> I: Retrieving Release.gpg
> I: Checking Release signature
> I: Valid Release signature (key id A1BD8E9D78F7FE5C3E65D8AF8B48AD6246925553)
> [...]
> I: Configuring linux-image-3.14-1-kirkwood...
> I: Configuring flash-kernel...
> I: Configuring libgnutls-openssl27:armel...
> I: Configuring wget...
> I: Configuring libcwidget3:armel...
> I: Configuring aptitude...
> I: Configuring linux-image-kirkwood...
> I: Configuring iputils-ping...
> I: Configuring tasksel...
> I: Configuring tasksel-data...
> I: Configuring perl-modules...
> I: Configuring perl...
> I: Configuring init-system-helpers...
> I: Configuring cron...
> I: Configuring rsyslog...
> I: Configuring logrotate...
> I: Configuring libc-bin...
> I: Configuring initramfs-tools...
> I: Base system installed successfully.
> #
>
> Just to be sure: On which kind of hardware (kirkwood or
> non-kirkwood system) and in which Debian release (wheezy, jessie
> or sid) are you running the debootstrap command and which release
> are you bootstrapping with debootstrap (jessie or sid)?

jessie.

> Have you created your chroot like I did above, i.e. with the
> "--include" parameter, or have you first run debootstrap without it
> and later on manually installed linux-image-3.14-1-kirkwood and
> flash-kernel in the already-created chroot?

I have first run deboostrap using command line here:
http://jamie.lentin.co.uk/devices/dlink-dns325/keeping-original-firmware/
then installed the kernel
then installed flash-kernel
then installed systemd. It fail during postconfigure of systemd

Bastien

> Please provide a full log of the whole process starting with the
> invocation of debootstrap up to the point where flash-kernel runs
> but should not.

>
> Regards,
> Karsten
> --
> Gem. Par. 28 Abs. 4 Bundesdatenschutzgesetz widerspreche ich der Nutzung
> sowie der Weitergabe meiner personenbezogenen Daten für Zwecke der
> Werbung sowie der Markt- oder Meinungsforschung.


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751054: krb5-multidev: use #ifdef rather than #if in gssapi.h

[Michael Tautschnig]

Control: clone 751054 -2
Control: reassign -2 pidgin-sipe 1.18.1-1
Control: severity -2 serious
Control: retitle -2 pidgin-sip: FTBFS - uses -Werror -Wundef with third-party 
headers

> Michael Tautschnig  writes:
> 
> > libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 
> > -Werror -Wall -Wextra -Waggregate-return -Wcast-align 
> > -Wdeclaration-after-statement -Wdeprecated-declarations -Winit-self 
> > -Wmaybe-uninitialized -Wmissing-declarations -Wmissing-prototypes 
> > -Wnested-externs -Wpointer-arith -Wundef -Wunused-but-set-variable 
> > -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> > -DLOCALEDIR=\"/usr/share/locale\" -I./../api -I/usr/include/mit-krb5 -g -O2 
> > -fstack-protector --param=ssp-buffer-size=4 -Wformat 
> > -Werror=format-security -c sip-sec-gssapi.c  -fPIC -DPIC -o 
> > .libs/libsipe_core_la-sip-sec-gssapi.o
> > In file included from sip-sec-gssapi.c:42:0:
> > /usr/include/mit-krb5/gssapi/gssapi.h:47:5: error: "TARGET_OS_MAC" is not 
> > defined [-Werror=undef]
> >  #if TARGET_OS_MAC
> >  ^
> 
> -Werror=undef is not really a sane compiler flag to try to build with if
> you use random third-party headers.  Most software does not have -Wundef
> cleanliness as an explicit goal, and the machinations that you have to go
> through to achieve this are often not trivial.
>

I tend to agree, hence cloned the bug to get pidgin-sipe to change (as well).

> In this specific case, it would probably be fine for the MIT Kerberos code
> base to change this line to instead be:
> 
> #if !defined(TARGET_OS_MAC)
  ^ (Sure? I don't think negation is due here.)

> 
> but it would surprise me if this is the last problem that you run into
> along these lines.  I would instead remove either -Werror or -Wundef from
> your compiler flags or otherwise make -Wundef warnings not a fatal error.
> 

So I do believe that

^\s*#\s*if\s+[a-zA-Z_][a-zA-Z0-9_]*\s*$

is almost always wrong as those should really be #ifdef ... or #if defined(...),
but there may be more complex expressions that are wrong as well. Fixing this
appears to be a worthwhile (but indeed possibly non-trivial) goal.

Best,
Michael



pgpgs6VDMPyIS.pgp
Description: PGP signature

Bug#751012: [flash-kernel] Flash-kernel should fail with exit 0 under debrootstrap

[Bastien ROUCARIES]

On Mon, Jun 9, 2014 at 8:19 PM, Ian Campbell
 wrote:
> On Mon, 2014-06-09 at 17:54 +0200, Bastien ROUCARIES wrote:
>> On Mon, Jun 9, 2014 at 5:21 PM, Karsten Merker  wrote:
>> > On Mon, Jun 09, 2014 at 03:48:11PM +, bastien ROUCARIES wrote:
>> >
>> >> Package: flash-kernel
>> >> Severity: important
>> >>
>> >> Flash-kernel should detect it run under debrootstrap and fail gracefully/
>> >>
>> >> Install message:
>> >>
>> >> Processing triggers for libc-bin (2.18-7) ...
>> >> Processing triggers for initramfs-tools (0.115) ...
>> >> update-initramfs: Generating /boot/initrd.img-3.14-1-kirkwood
>> >> /bin/df: Warning: cannot read table of mounted file systems: No such file 
>> >> or directory
>> >> warning: failed to read mtab
>> >> ^Cdpkg: error processing package initramfs-tools (--configure):
>> >>  subprocess installed post-installation script was interrupted
>> >> Errors were encountered while processing:
>> >>  initramfs-tools
>> >> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> >
>> > Hello,
>> >
>> > I am trying to understand which problem exactly you have
>> > encountered, but I am a bit confused: you have filed a bug
>> > against flash-kernel but in the log you have provided, it is not
>> > flash-kernel that shows an error message, but initramfs-tools.  I
>> > also cannot see in which context that has happened and how it
>> > relates to debootstrap - by default debootstrap does neither
>> > install a kernel image nor flash-kernel.  From your log, it looks
>> > like you have manually interrupted the update-initramfs process,
>> > resulting in the error message above:
>>
>> No I have not interupted.
>
> What is the ^C in the output from? Was it produced verbatim by the
> process?
No it is a left over

>> I have installed te kirkwood kernel and flash-kernel on my chroot.
>
> Out of interest, why?

Because I wand to add support for dns-320 and thus I am creating an image.

>> The problem is that flash-kernel is run by 
>> initramfs/post-update.d/flash-kernel
>>
>> I have added an exit 0 at the beginning of this file and everything is ok
>>
>> The best think is to exit 0 if we are under a debootstrap.
>
> If you want to install flash-kernel in a chroot/debootstrap etc then you
> should set FK_MACHINE=none in the environment or write none to
> $chroot/etc/flash-kernel/machine, either of which will cause
> flash-kernel to become a nop.

Is it documented somewhere ?

Bastien

> Alternatively if you want f-k to behave as if it was installing on a
> particular piece of h/w you can use the appropriate DB Machine name,
> although YMMV if that machine requires writing to specific partitions
> etc.
>
> Ian.
>
>


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751054: krb5-multidev: use #ifdef rather than #if in gssapi.h

[Russ Allbery]

Michael Tautschnig  writes:

> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 
> -Werror -Wall -Wextra -Waggregate-return -Wcast-align 
> -Wdeclaration-after-statement -Wdeprecated-declarations -Winit-self 
> -Wmaybe-uninitialized -Wmissing-declarations -Wmissing-prototypes 
> -Wnested-externs -Wpointer-arith -Wundef -Wunused-but-set-variable 
> -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include 
> -DLOCALEDIR=\"/usr/share/locale\" -I./../api -I/usr/include/mit-krb5 -g -O2 
> -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security 
> -c sip-sec-gssapi.c  -fPIC -DPIC -o .libs/libsipe_core_la-sip-sec-gssapi.o
> In file included from sip-sec-gssapi.c:42:0:
> /usr/include/mit-krb5/gssapi/gssapi.h:47:5: error: "TARGET_OS_MAC" is not 
> defined [-Werror=undef]
>  #if TARGET_OS_MAC
>  ^

-Werror=undef is not really a sane compiler flag to try to build with if
you use random third-party headers.  Most software does not have -Wundef
cleanliness as an explicit goal, and the machinations that you have to go
through to achieve this are often not trivial.

In this specific case, it would probably be fine for the MIT Kerberos code
base to change this line to instead be:

#if !defined(TARGET_OS_MAC)

but it would surprise me if this is the last problem that you run into
along these lines.  I would instead remove either -Werror or -Wundef from
your compiler flags or otherwise make -Wundef warnings not a fatal error.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751059: pycurl: FTBFS - conflicting (transitive) build dependencies

[Michael Tautschnig]

Package: pycurl
Version: 7.19.3.1-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
 -> Attempting to parse the build-deps 
 -> Considering build-dep debhelper (>= 7.0.50~)
   -> Trying debhelper
 -> Considering build-dep python-all-dev (>= 2.6.6-3~)
   -> Trying python-all-dev
 -> Considering build-dep python-all-dbg
   -> Trying python-all-dbg
 -> Considering build-dep python3-all-dev
   -> Trying python3-all-dev
 -> Considering build-dep python3-all-dbg
   -> Trying python3-all-dbg
 -> Considering build-dep dh-python
   -> Trying dh-python
 -> Considering build-dep libcurl4-gnutls-dev (>= 7.19.0)
   -> Trying libcurl4-gnutls-dev
 -> Considering build-dep librtmp-dev
   -> Trying librtmp-dev
 -> Considering build-dep libssh2-1-dev
   -> Trying libssh2-1-dev
   -> Cannot install libssh2-1-dev; apt errors follow:
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
 librtmp-dev : Depends: libgnutls-dev but it is not going to be installed
E: Unable to correct problems, you have held broken packages.
E: Could not satisfy build-dependency.


A further investigation suggests that the problem is

- librtmp-dev --depends--> libgnutls-dev --depends--> libgcrypt11-dev
- libssh2-1-dev --depends--> libgcrypt20-dev --conflicts--> libgcrypt11-dev

Hence you may wish to reassign this bug report in case there is a chance for
libgnutls-dev's build dependencies can be bumped to seemingly newer libgcrypt20.
As is, however, the pycurl package cannot be built.

Best,
Michael



pgphkLz5zBsP5.pgp
Description: PGP signature

Bug#751058: pychef: FTBFS - URLError:

[Michael Tautschnig]

Package: pychef
Version: 0.2.3-1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
==
ERROR: test_create_bag (chef.tests.test_data_bag.DataBagTestCase)
--
Traceback (most recent call last):
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-pychef/pychef-0.2.3/chef/tests/__init__.py",
 line 52, in tearDown
obj.delete()
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-pychef/pychef-0.2.3/chef/base.py", 
line 117, in delete
api.api_request('DELETE', self.url)
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-pychef/pychef-0.2.3/chef/api.py", 
line 225, in api_request
response = self.request(method, path, headers, data)
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-pychef/pychef-0.2.3/chef/api.py", 
line 208, in request
response = self._request(method, self.url+path, data, dict((k.capitalize(), 
v) for k, v in request_headers.iteritems()))
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-pychef/pychef-0.2.3/chef/api.py", 
line 195, in _request
return urllib2.urlopen(request).read()
  File "/usr/lib/python2.7/urllib2.py", line 127, in urlopen
return _opener.open(url, data, timeout)
  File "/usr/lib/python2.7/urllib2.py", line 404, in open
response = self._open(req, data)
  File "/usr/lib/python2.7/urllib2.py", line 422, in _open
'_open', req)
  File "/usr/lib/python2.7/urllib2.py", line 382, in _call_chain
result = func(*args)
  File "/usr/lib/python2.7/urllib2.py", line 1222, in https_open
return self.do_open(httplib.HTTPSConnection, req)
  File "/usr/lib/python2.7/urllib2.py", line 1184, in do_open
raise URLError(err)
URLError: 

--
Ran 71 tests in 59.780s

FAILED (errors=1, skipped=2)
{}
{1: 2}
debian/rules:10: recipe for target 'override_dh_auto_test' failed


I'm not sure whether this test expects any network connectivity!? The full build
log is attached, but please do let me know if the problem happens to be
unreproducible.

Best,
Michael



pychef-build-log.txt.gz
Description: application/gunzip


pgpIW3SvZ60F2.pgp
Description: PGP signature

Bug#751057: pyqwt3d: FTBFS - SIP failed to generate the C++ code.

[Michael Tautschnig]

Package: pyqwt3d
Version: 0.1.7~cvs20090625-12
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
sip invokation:
'/usr/bin/sip -I /usr/share/sip/PyQt4 -b tmp-Qwt3D_Qt4/qwt3d.sbf -c 
tmp-Qwt3D_Qt4   -x VendorID -t WS_X11 -x PyQt_NoPrintRangeBug -t Qt_4_8_6 -x 
Py_v3 -g -I ../sip -x HAS_QT3 -x HAS_NUMARRAY -x HAS_NUMERIC 
../sip/Qwt3D_Qt4_Module.sip'

SIP failed to generate the C++ code.


The full build log is attached - but the output here seems hardly useful. Please
do let me know if this happens to be unreproducible, in which case I shall try
to investigate further. But a somewhat more elaborate error reporting would
definitively be useful.

Best,
Michael



pyqwt3d-build-logs.txt.gz
Description: application/gunzip


pgpLeEx9uUXXZ.pgp
Description: PGP signature

Bug#751056: python-babel: FTBFS - rm: cannot remove 'debian/python-babel/usr/share/pyshared/babel/localedata/*.dat': No such file or directory

[Michael Tautschnig]

Package: python-babel
Version: 1.3+dfsg.1-3
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
make[1]: Entering directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-python-babel/python-babel-1.3+dfsg.1'
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
py3versions: no X-Python3-Version in control file, using supported versions
dh_python2 -O--buildsystem=python_distutils
set -e && for pyvers in 2.7; do \
  rm 
debian/python-babel/usr/lib/python$pyvers/dist-packages/babel/localedata/*.dat 
; \
  rmdir 
debian/python-babel/usr/lib/python$pyvers/dist-packages/babel/localedata ; \
  ln -s ../../../../share/python-babel-localedata/localedata 
debian/python-babel/usr/lib/python$pyvers/dist-packages/babel/localedata ; \
  rm debian/python-babel/usr/lib/python$pyvers/dist-packages/babel/global.dat ; 
\
  ln -s ../../../../share/python-babel-localedata/global.dat 
debian/python-babel/usr/lib/python$pyvers/dist-packages/babel/global.dat ; \
done
rm debian/python-babel/usr/share/pyshared/babel/localedata/*.dat
rm: cannot remove 
'debian/python-babel/usr/share/pyshared/babel/localedata/*.dat': No such file 
or directory
debian/rules:32: recipe for target 'override_dh_python2' failed
make[1]: *** [override_dh_python2] Error 1
make[1]: Leaving directory 
'/srv/jenkins-slave/workspace/sid-goto-cc-python-babel/python-babel-1.3+dfsg.1'
debian/rules:7: recipe for target 'binary' failed


The full build log is attached.

Best,
Michael



python-babel-build-log.txt.gz
Description: application/gunzip


pgpy6T0QULsYE.pgp
Description: PGP signature

Bug#751055: python-csa: FTBFS - ImportError: cannot import name _tkagg

[Michael Tautschnig]

Package: python-csa
Version: 0.1.0-1.1
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
dh_auto_clean
pyversions: missing X(S)-Python-Version in control file, fall back to 
debian/pyversions
pyversions: missing debian/pyversions file, fall back to supported versions
Traceback (most recent call last):
  File "setup.py", line 4, in 
from csa.version import __version__
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-python-csa/python-csa-0.1.0/csa/__init__.py",
 line 28, in 
from plot import *
  File 
"/srv/jenkins-slave/workspace/sid-goto-cc-python-csa/python-csa-0.1.0/csa/plot.py",
 line 21, in 
import matplotlib.pyplot as _plt
  File "/usr/lib/pymodules/python2.7/matplotlib/pyplot.py", line 98, in 
_backend_mod, new_figure_manager, draw_if_interactive, _show = pylab_setup()
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/__init__.py", line 28, 
in pylab_setup
globals(),locals(),[backend_name],0)
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/backend_tkagg.py", 
line 11, in 
import matplotlib.backends.tkagg as tkagg
  File "/usr/lib/pymodules/python2.7/matplotlib/backends/tkagg.py", line 2, in 

from matplotlib.backends import _tkagg
ImportError: cannot import name _tkagg
dh_auto_clean: python setup.py clean -a returned exit code 1
debian/rules:9: recipe for target 'override_dh_auto_clean' failed


The full build log is attached.

Best,
Michael



python-csa-build-log.txt.gz
Description: application/gunzip


pgpql9SYUgLJD.pgp
Description: PGP signature

Bug#751054: krb5-multidev: use #ifdef rather than #if in gssapi.h

[Michael Tautschnig]

Package: krb5-multidev
Version: 1.12.1+dfsg-2
Affects: pidgin-sipe

Trying to build pidgin-sipe failed with the following error:

[...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. -D_FORTIFY_SOURCE=2 -Werror 
-Wall -Wextra -Waggregate-return -Wcast-align -Wdeclaration-after-statement 
-Wdeprecated-declarations -Winit-self -Wmaybe-uninitialized 
-Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith 
-Wundef -Wunused-but-set-variable -I/usr/include/glib-2.0 
-I/usr/lib/x86_64-linux-gnu/glib-2.0/include -DLOCALEDIR=\"/usr/share/locale\" 
-I./../api -I/usr/include/mit-krb5 -g -O2 -fstack-protector 
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -c sip-sec-gssapi.c  
-fPIC -DPIC -o .libs/libsipe_core_la-sip-sec-gssapi.o
In file included from sip-sec-gssapi.c:42:0:
/usr/include/mit-krb5/gssapi/gssapi.h:47:5: error: "TARGET_OS_MAC" is not 
defined [-Werror=undef]
 #if TARGET_OS_MAC
 ^
In file included from sip-sec-gssapi.c:42:0:
/usr/include/mit-krb5/gssapi/gssapi.h:821:5: error: "TARGET_OS_MAC" is not 
defined [-Werror=undef]
 #if TARGET_OS_MAC
 ^
In file included from /usr/include/mit-krb5/krb5.h:8:0,
 from /usr/include/mit-krb5/gssapi/gssapi_krb5.h:32,
 from sip-sec-gssapi.c:46:
/usr/include/mit-krb5/krb5/krb5.h:111:5: error: "TARGET_OS_MAC" is not defined 
[-Werror=undef]
 #if TARGET_OS_MAC
 ^
/usr/include/mit-krb5/krb5/krb5.h:8185:5: error: "TARGET_OS_MAC" is not defined 
[-Werror=undef]
 #if TARGET_OS_MAC
 ^
cc1: all warnings being treated as errors


But really it seems weird that an unrelated package would have to define all
sorts of macros to a 0 value just in order to build. I believe that using #ifdef
rather than #if should solve this problem.

Best,
Michael

PS.: This might actually have higher severity as it breaks the build of an
unrelated package.



pgpojiCpJTOIW.pgp
Description: PGP signature

Bug#697121: vlc: sudden very loud sound to cause hearing demage

[Rémi Denis-Courmont]

Le lundi 9 juin 2014, 15:56:44 Felipe Sateler a écrit :
> But isn't an uncorked stream an "inactive stream"? I'm not sure of
> what you mean by that.

I never wrote anything about inactive streams. Inactive sessions is a WASAPI 
notion, that the -in that respect inferior- PulseAudio design lacks.

> >> 2. VLC could create the stream on startup and destroy it on exit. This
> >> is what Clementine seems to do.
> > 
> > That is not possible since VLC may play different formats at successive
> > times. Also...
> 
> OK. So that rules out permanent streams. BTW, out of curiosity, why is
> this the case? I thought VLC did their own decoding (and thus output a
> single stream format).

VLC decodes (and PulseAudio does not) but the sample rates and channels maps 
may vary, not to mention pass-through.

> Also, semi-permanent streams might be the option then: reuse streams
> as long as the format doesn't change. This may well be more work than
> this problem merits, though.
> 
> >> 3. VLC could, at startup, create a stream, get the volume and destroy
> >> the stream.
> > 
> > Because of flat volumes, doing that would potentially cause spurious
> > changes to the master volume and glitches in mixer UIs.
> 
> Is this really correct? If pa_stream_connect_playback is set with a
> NULL cvolume parameter, PA should set a reasonable volume for the
> stream.

Yes, and...?

> > Furthermore, all options 1 and 2 fail if another process creates a stream
> > with the same role (or whatever matching criteria) in the mean time, and
> > change the volume.
> 
> I don't think roles are used for this purpose. Streams have
> independent volumes, AFAICT.

Active streams have independent volumes. But the whole point is what to do 
without an active stream. By *default*, PulseAudio restores volumes by stream 
role.

-- 
Rémi Denis-Courmont
http://www.remlab.net/


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751053: [fdroidserver] fdroid init can't find config.sample.py

[Diane Trout]

Package: fdroidserver
Version: 0.1-2
Severity: normal

--- Please enter the report below this line. ---

Hello,

I tried running fdroid init and got an error:

Traceback (most recent call last):
  File "/usr/bin/fdroid", line 66, in 
main()
  File "/usr/bin/fdroid", line 62, in main
mod.main()
  File "/usr/lib/python2.7/dist-packages/fdroidserver/init.py", line 111, in 
main
shutil.copyfile(os.path.join(examplesdir, 'config.sample.py'), 
'config.py')
  File "/usr/lib/python2.7/shutil.py", line 82, in copyfile
with open(src, 'rb') as fsrc:
IOError: [Errno 2] No such file or directory: 
'/usr/share/doc/fdroidserver/examples/config.sample.py'

Looking in /usr/share/doc/fdroidserver/examples/ it looks like the config file 
got compressed. 

Do you think its reasonable to either not compress the sample config file, or 
to modify the init step to extract it?

Diane

--- System information. ---
Architecture: amd64
Kernel:   Linux 3.12-1-amd64

Debian Release: jessie/sid
  500 testing ftp.us.debian.org 
  500 stable-updates  ftp.us.debian.org 
  500 stable  security.debian.org 
  500 stable  ftp.us.debian.org 
  110 unstableftp.us.debian.org 
  110 unstablecdn.debian.net 
1 experimentalftp.us.debian.org 

--- Package information. ---
Depends (Version) | Installed
=-+-===
python   (>= 2.7) | 2.7.6-2
python   (<< 2.8) | 2.7.6-2
python-magic  | 1:5.18-1
python-imaging| 2.3.0-2


Recommends   (Version) | Installed
==-+-===
default-jre| 2:1.7-52
default-jdk| 2:1.7-52
rsync  | 3.1.0-3
wget   | 1.15-1


Suggests(Version) | Installed
=-+-===
bzr   | 2.6.0+bzr6595-1
git   | 1:2.0.0-1
gradle| 
maven | 3.0.5-1
mercurial | 3.0-1
php5  | 
ruby  | 1:2.1.0.1
subversion| 1.8.9-1
vagrant   | 1:1.6.2
virtualbox| 


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751051: pxsl-tools: FTBFS - build-dep on non-existent package libghc-containers-dev

[Joachim Breitner]

Control: reassign -1 ghc
Control: retitle -1 Provides got lost

This is a mistake in my last GHC update, thanks for spotting.

Am Montag, den 09.06.2014, 20:54 +0100 schrieb Michael Tautschnig:
> Package: pxsl-tools
> Version: 1.0-5.2
> Severity: serious
> Usertags: goto-cc
> 
> During a rebuild of all Debian packages in a clean sid chroot (using 
> cowbuilder
> and pbuilder) the build failed with the following error.
> 
> [...]
>  -> Attempting to parse the build-deps 
>  -> Considering build-dep cdbs
>-> Trying cdbs
>  -> Considering build-dep debhelper (>= 6)
>-> Trying debhelper
>  -> Considering build-dep ghc
>-> Trying ghc
>  -> Considering build-dep libghc-mtl-dev (>= 1.0)
>-> Trying libghc-mtl-dev
>  -> Considering build-dep libghc-parsec3-dev
>-> Trying libghc-parsec3-dev
>  -> Considering build-dep libghc-containers-dev
>-> Trying libghc-containers-dev
>-> Cannot install libghc-containers-dev; apt errors follow:
> Reading package lists...
> Building dependency tree...
> Reading state information...
> E: Unable to locate package libghc-containers-dev
> 
> 
> I'm not sure whether libghc-containers-dev existed until recently, but it
> certainly isn't in the archive right now. (Is it in NEW?)
> 
> I'm CC'ing Joachim as he uploaded the last two versions.
> 
> Best,
> Michael
> 

-- 
Joachim "nomeata" Breitner
Debian Developer
  nome...@debian.org | ICQ# 74513189 | GPG-Keyid: F0FBF51F
  JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata



signature.asc
Description: This is a digitally signed message part

Bug#697121: vlc: sudden very loud sound to cause hearing demage

[Felipe Sateler]

On Mon, Jun 9, 2014 at 3:20 PM, Rémi Denis-Courmont  wrote:
> Le lundi 9 juin 2014, 14:51:53 Felipe Sateler a écrit :
>> OK, thanks for explaining. I see that vlc creates the stream when it
>> starts playback and destroys it when stopped (although not pause).
>>
>> This leaves the following options:
>>
>> 1. Pulseaudio could add a function to get the volume an output/input
>> sink/source stream would get if it were created.
>
> PulseAudio does not really have a notion of inactive session, as Windows
> does... I don't really see how that would work with the current architecture
> (not that I'm that familiar with it though).

But isn't an uncorked stream an "inactive stream"? I'm not sure of
what you mean by that.

>
>> 2. VLC could create the stream on startup and destroy it on exit. This
>> is what Clementine seems to do.
>
> That is not possible since VLC may play different formats at successive times.
> Also...

OK. So that rules out permanent streams. BTW, out of curiosity, why is
this the case? I thought VLC did their own decoding (and thus output a
single stream format).

Also, semi-permanent streams might be the option then: reuse streams
as long as the format doesn't change. This may well be more work than
this problem merits, though.

>
>> 3. VLC could, at startup, create a stream, get the volume and destroy
>> the stream.
>
> Because of flat volumes, doing that would potentially cause spurious changes 
> to
> the master volume and glitches in mixer UIs.

Is this really correct? If pa_stream_connect_playback is set with a
NULL cvolume parameter, PA should set a reasonable volume for the
stream.

>
> Furthermore, all options 1 and 2 fail if another process creates a stream with
> the same role (or whatever matching criteria) in the mean time, and change the
> volume.

I don't think roles are used for this purpose. Streams have
independent volumes, AFAICT.

>> Are there problems with going with option 2? This option has the added
>> benefit the volume can potentially be controlled by another program
>> before starting playback.
>
> Ultimately, the problem is simple. On the one hand, PulseAudio developers
> consider that audio applications shall not show volume UI. Only the dedicated
> mixer application(s) and the session process grabbing the volume media keys
> shall be concerned with the volume. On the other hand, VLC GUI developers want
> to have a volume control.

Indeed, it seems PA devs have convinced many people. Several media
players now no longer come with volume UIs, or at least don't show
them until playback has started.

>
> The two perspectives are incompatible. That is not a technical problem; and
> thus it won't be solved by code.

It doesn't mean it is impossible to work around.

-- 

Saludos,
Felipe Sateler


--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751052: RM: iproute2 -- ROM; Deprecated by src:iproute2

[Hector Oron]

Package: ftp.debian.org
Severity: normal

Hello ftp-master,

  Apparently src:iproute is to be removed from experimental/unstable/testing 
suites, as it has been deprecated by src:iproute2.

  Andreas, maintainer of the package, concurs on this action.
  (see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=741797#27)

Best regards


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#750953: flash-kernel: Add support for SolidRun Cubox-i Dual/Quad.

[Vagrant Cascadian]

On Mon, Jun 09, 2014 at 07:27:30PM +0100, Ian Campbell wrote:
> I think it is OK as it was, I just wanted to check we weren't painting
> ourselves into a corner wrt future changes, I think I'm convinced we are
> not.

ok.


> Do you have push rights to this repo or would you like me to pickup the
> patch?

I don't, so plase go ahead and push them.


live well,
  vagrant


signature.asc
Description: Digital signature

Bug#750733: Processed: bumping severity

[Thomas Dickey]

- Original Message -
| From: "Sven Joachim" 
| To: "Thomas Dickey" 
| Cc: 750...@bugs.debian.org, "Klaus Ethgen" 
| Sent: Monday, June 9, 2014 3:43:20 PM
| Subject: Re: Bug#750733: Processed: bumping severity
| 
| On 2014-06-09 21:22 +0200, Thomas Dickey wrote:
| 
| > On Mon, Jun 09, 2014 at 07:12:11PM +, Debian Bug Tracking
| > System wrote:
| >> Processing commands for cont...@bugs.debian.org:
| >> 
| >> > # Not sure if the problem happens with more readable fonts than
| >> > 5x8,
| >> > # but better keep this xterm version out of testing
| >> > severity 750733 serious
| >> Bug #750733 [xterm] Newest version sets the foreground to the
| >> background color in some cases
| >> Severity set to 'serious' from 'normal'
| >> > thanks
| >> Stopping processing here.
| >
| > fwiw, there's a fix for this in
| >
| > ftp://invisible-island.net/temp/xterm-306a.patch.gz
| 
| Thanks, this fixes the problem with the bold text.  However, when
| running 16colors.sh I see that text which is supposed to be
| underlined
| is not, still a regression from xterm 304.
| 

thanks (I had not noticed that).  I will work on that next...

-- 
Thomas E. Dickey 
http://invisible-island.net
ftp://invisible-island.net


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#751051: pxsl-tools: FTBFS - build-dep on non-existent package libghc-containers-dev

[Michael Tautschnig]

Package: pxsl-tools
Version: 1.0-5.2
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
 -> Attempting to parse the build-deps 
 -> Considering build-dep cdbs
   -> Trying cdbs
 -> Considering build-dep debhelper (>= 6)
   -> Trying debhelper
 -> Considering build-dep ghc
   -> Trying ghc
 -> Considering build-dep libghc-mtl-dev (>= 1.0)
   -> Trying libghc-mtl-dev
 -> Considering build-dep libghc-parsec3-dev
   -> Trying libghc-parsec3-dev
 -> Considering build-dep libghc-containers-dev
   -> Trying libghc-containers-dev
   -> Cannot install libghc-containers-dev; apt errors follow:
Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libghc-containers-dev


I'm not sure whether libghc-containers-dev existed until recently, but it
certainly isn't in the archive right now. (Is it in NEW?)

I'm CC'ing Joachim as he uploaded the last two versions.

Best,
Michael



pgpG_PAQ06l6R.pgp
Description: PGP signature

Bug#751050: pycode-browser: FTBFS - pdflatex (file cm-super-t1.enc): cannot open encoding file for reading

[Michael Tautschnig]

Package: pycode-browser
Version: 20120614+git+b041dd2-6
Severity: serious
Usertags: goto-cc

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error.

[...]
pdflatex mapy.tex
This is pdfTeX, Version 3.14159265-2.6-1.40.15 (TeX Live 2014/Debian) 
(preloaded format=pdflatex)
 restricted \write18 enabled.
entering extended mode
[...]

LaTeX Warning: There were undefined references.


LaTeX Warning: Label(s) may have changed. Rerun to get cross-references right.

 )
(see the transcript file for additional information)
!pdfTeX error: pdflatex (file cm-super-t1.enc): cannot open encoding file for r
eading
 ==> Fatal error occurred, no output PDF file produced!
Makefile:17: recipe for target 'mapy.pdf' failed


This may be an issue of build dependencies. The full build log is attached.

Best,
Michael

PS.: A similar issue will be filed against the proofgeneral package.



pycode-browser-build-log.txt.gz
Description: application/gunzip


pgpCJ4SpsZ9IO.pgp
Description: PGP signature