Bug#728174: ploop: FTBFS on non-Linux: asm/types.h: No such file or directory

[Ola Lundqvist]

Hi

Thanks. I'll adjust the architecture from any to linux-any.

// Ola


On Tue, Oct 29, 2013 at 4:05 AM, Aaron M. Ucko  wrote:

> Source: ploop
> Version: 1.9-2
> Severity: important
>
> Builds of ploop on kFreeBSD and the Hurd have been failing:
>
>   ../include/linux/types.h:4:23: fatal error: asm/types.h: No such file or
> directory
>
> It looks like Ploop is Linux-specific, which is fair; all the same,
> please formally adjust its architecture from any to linux-any to
> reflect that restriction.
>
> Thanks!
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#728172: ploop: FTBFS: libxml/parser.h: No such file or directory

[Ola Lundqvist]

Thanks for the report. I'll do so. I thought I had checked it on a minimal
install but it turned out to be more than a minimal one.

// Ola


On Tue, Oct 29, 2013 at 3:59 AM, Aaron M. Ucko  wrote:

> Source: ploop
> Version: 1.9-2
> Severity: serious
> Justification: fails to build from source
>
> Builds of ploop in minimal environments have been failing even when not
> affected by architecture-specific issues (which I'll report separately):
>
> xml.c:23:27: fatal error: libxml/parser.h: No such file or directory
>
> Please declare a build dependency on libxml2-dev and confirm with pbuilder
> or the like that no others are missing.
>
> Thanks!
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#728173: ploop: FTBFS on non-x86: misses fallocate, syncfs syscall numbers

[Ola Lundqvist]

Thanks. Will fix.


On Tue, Oct 29, 2013 at 4:02 AM, Aaron M. Ucko  wrote:

> Source: ploop
> Version: 1.9-2
> Severity: serious
> Justification: fails to build from source
>
> Builds of ploop on Linux architectures other than amd64 and i386 have
> been failing:
>
>   ploop.h:21:2: error: #error "No fallocate syscall known for this arch"
>   ploop.h:31:2: error: #error "No syncfs syscall known for this arch"
>
> Please try having ploop.h #include  to pick up system
> definitions rather than relying on its fallbacks, defined only for x86.
>
> Thanks!
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comAnnebergsslingan 37\
|  o...@debian.org   654 65 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Bug#728065: [Pkg-xfce-devel] Bug#728065: thunar: USB and eSATA devices not seen by Thunar

[Yves-Alexis Perez]

On Mon, 2013-10-28 at 16:57 -0700, David Christensen wrote:

> 
> I did some more testing with a Canon PowerShot A570IS camera (USB 
> interface) just now:

Actually, that's not a good test. Thunar only supports/shows USB Mass
Storage devices, which Canon cameras are not (they use some proprietary
canon protocol on USB mode, or PTP on PTP mode). You need to interface
with it using gphoto2, which is what Shotwell is actually doing.

> 
> 1.  (Xfce XMouse?) -> Settings -> Removable Drives and Media -> Storage 
> -> Removable Storage -> all boxes unchecked.
> 
> 2.  Open Thunar and Shotwell.
> 
> 2.  Plug in Canon PowerShot A570IS camera via USB.  Camera does not 
> change to USB connected state.  No desktop icon.  Nothing in Thunar. 
> However, an entry appears for the camera in the left pane of Shotwell.
> 
> 3.  Select camera in Shotwell.  Camera goes to USB connected state. 
> Shotwell accesses camera and displays thumbnails in right pane.  Nothing 
> on desktop.  Nothing in Thunar.
> 
> 
> Therefore, something is broken for the Xfce desktop and Thunar -- I 
> expected a camera icon on the desktop and a camera entry in the left 
> pane of Thunar at steps #2 and #3.  Shotwell seems okay.
> 
> 
> I also did some testing with two different USB flash drives and obtained 
> the same results:
> 
> 1.  (Xfce Mouse?) -> Settings -> Removable Drives and Media -> Storage 
> -> Removable Storage -> all boxes unchecked.
> 
> 2.  Open Thunar.
> 
> 3.  Plug in USB flash drive.  Drive icon appears on desktop.  Drive 
> entry appears in left pane of Thunar.
> 
> 4.  Desktop icon context menu has option to mount drive; don't invoke it.
> 
> 5.  Select drive in left pane of Thunar.  Drive contents displayed in 
> right pane.
> 
> 6.  Desktop icon context menu on desktop now has option to eject drive.
> 
> 
> Therefore, everything seems to be working correctly with Xfce and Thunar 
> for USB flash drives.

Indeed.
> 
> 
> I also did some testing on another Wheezy/Xfce machine with a Seagate 
> FreeAgent Xtreme external hard disk drive via USB and eSATA -- nothing 
> on desktop or in Thunar.
> 
> 
> Therefore, it seems that whatever Xfce/ Debian/ Linux subsystem 
> underlies Thunar works for USB flash drives, but not for the camera or 
> for the external hard disk drive.

This one is weird.
> 
> 
> Another clue -- hot-plug for the external hard drive stoppled working 
> around Sept. 3, when I did a BIOS update.  I seem to recall a kernel 
> update around the same time.

Can you check:

- if the USB drive is correctly seen by the kernel (shows in dmesg, can
be mounted manually)
- if the USB drive is correctly seen by udisks (I think it's someting
like udisks --dump, and udisks --monitor can help too).

Regards,
-- 
Yves-Alexis


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

Bug#726600: otrs2: Internal server error when replying to email ticket

[Patrick Matthäi]

Am 28.10.2013 20:05, schrieb Salvatore Bonaccorso:

Hi Niko and Dominic

otrs2 seems to have an anoying (not easy to reproduce bug), which was
reported against otrs2 (and which seems to appear after the perl
5.14.2 -> 5.18.1 update):

  http://bugs.debian.org/724972
  http://bugs.debian.org/726600

Does this sound somewhere familiar to you, or does this ring a bell?

Regards,
Salvatore



Hatte Niko schon am WE ne Mail geschrieben :-)

--
/*
Mit freundlichem Gruß / With kind regards,
 Patrick Matthäi
 GNU/Linux Debian Developer

  Blog: http://www.linux-dev.org/
E-Mail: pmatth...@debian.org
patr...@linux-dev.org
*/


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

Bug#728127: "end game" ends the whole session

[Stefano Zacchiroli]

Hey Russ,

On Mon, Oct 28, 2013 at 08:08:41PM -0700, Russ Allbery wrote:
> I think I may be missing something here, but what semantics do you believe
> ending the current game in the middle of a match should have?  Off-hand,
> that doesn't seem like a sensible action to me, since wouldn't it then
> leave the match status in an undefined state?
> 
> Or, put another way, why would you use end game rather than resign?

The semantics is indeed a bit confused, at least in my mind; I don't
exclude that a proper solution for this bug would be improved
documentation of what "end game" is supposed to do --- I didn't find any
in the doc.

So, first of all, whereas resigning implies that you lose, "end game"
does not. Using "end game" it's the AI that will play in your stead
until the end of the current game. So you can also win.

I believe the intended use case is that you use to quickly terminate a
game, if you are at present not interested in playing, say, the bear off
phase. But if you're ahead in that specific game, you do expect
(statistically) to win that game.  If that happens in, say, the first
game of a match to be played at 11-points, you do expect to be able to
play yourself the subsequent games. It is this that seems to be
impossible, and it smells like a software bug (something like:
triggering the boolean "match ended" instead of the boolean "game ended"
once done).

Hope this clarifies,
Cheers.
-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader  . . @zack on identi.ca . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Bug#728177: debcommit -r with darcs fails if the repo is clean

[Joachim Breitner]

Package: devscripts
Version: 2.13.4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

like with git, debcommit -r should only call “darcs record” if the repo
is not clean, otherwise it fails. Will append patch as soon as I know
the bug number.

I noticed that debscripts is now in collab-maint. Please let me know if
I should commit my patch myself.

Thanks,
Joachim


- -- Package-specific info:

- --- /etc/devscripts.conf ---

- --- ~/.devscripts ---
DEBCHANGE_PRESERVE=yes
DEBCHANGE_RELEASE_HEURISTIC=changelog
DEBCHANGE_AUTO_NMU=no
DEBRELEASE_UPLOADER=dput

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.17.1
ii  libc62.17-93
ii  perl 5.18.1-4
ii  python3  3.3.2-17
pn  python3:any  

Versions of packages devscripts recommends:
ii  at3.1.14-1
ii  curl  7.33.0-1
ii  dctrl-tools   2.23
ii  debian-keyring2013.07.31
ii  dput  0.9.6.4
pn  equivs
ii  fakeroot  1.20-1
ii  gnupg 1.4.15-1.1
ii  libcrypt-ssleay-perl  0.58-1+b1
ii  libdistro-info-perl   0.11
ii  libencode-locale-perl 1.03-1
ii  libjson-perl  2.61-1
pn  libparse-debcontrol-perl  
ii  libsoap-lite-perl 0.716-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.05-1
ii  lintian   2.5.19
ii  man-db2.6.5-2
ii  patch 2.7.1-3
ii  patchutils0.3.2-2
pn  python3-debian
pn  python3-magic 
ii  sensible-utils0.0.9
ii  strace4.5.20-2.3
ii  unzip 6.0-10
ii  wdiff 1.2.1-1
ii  wget  1.14-4
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii  build-essential  11.6
pn  cvs-buildpackage 
pn  devscripts-el
ii  gnuplot  4.6.4-1
ii  gpgv 1.4.15-1.1
ii  libauthen-sasl-perl  2.1500-1
ii  libfile-desktopentry-perl0.07-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 1.2000-1
ii  libyaml-syck-perl1.27-2+b1
ii  mutt 1.5.21-6.4
ii  openssh-client [ssh-client]  1:6.2p2-6
ii  svn-buildpackage 0.8.5
ii  w3m  0.5.3-12

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iEYEARECAAYFAlJva7AACgkQ9ijrk0dDIGyYCwCgkPXquakqanAIeF+98OxbDZcJ
GjgAn1KQI0hmbi6misFqL6OZwWnDP+Ay
=WTdl
-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#728178: transition: gdcm 2.4.0

[Mathieu Malaterre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

I'd like to request a transition slot for GDCM 2.4.0. Once #727154 is
fixed GDCM can be moved to sid. I'll prepare a list of impacted
packages.


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

Bug#728177: debcommit -r with darcs fails if the repo is clean

[Joachim Breitner]

Control: tag -1 patch


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


From 690c34c9051ea2f882d7bef035b4620f15ff9a65 Mon Sep 17 00:00:00 2001
From: Joachim Breitner 
Date: Tue, 29 Oct 2013 09:06:34 +0100
Subject: [PATCH] debcommit: Fix --release with darcs when the repository is
 clean. (Closes: #728177)

---
 debian/changelog | 4 
 scripts/debcommit.pl | 8 
 2 files changed, 12 insertions(+)

diff --git a/debian/changelog b/debian/changelog
index 43288f9..3bbf0c2 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -8,6 +8,10 @@ devscripts (2.13.5) UNRELEASED; urgency=low
   * debcheckout: allow setting the user for auth mode in the config.  (Closes:
 #722171)
 
+  [ Joachim Breitner ]
+  * debcommit: Fix --release with darcs when the repository is clean. (Closes:
+#728177)
+
  -- James McCoy   Mon, 07 Oct 2013 22:21:31 -0400
 
 devscripts (2.13.4) unstable; urgency=low
diff --git a/scripts/debcommit.pl b/scripts/debcommit.pl
index 00656d5..d11628e 100755
--- a/scripts/debcommit.pl
+++ b/scripts/debcommit.pl
@@ -586,6 +586,14 @@ sub commit {
 	}
 }
 elsif ($prog eq 'darcs') {
+	if (! @files_to_commit && ($all || $release)) {
+	# check to see if the WC is clean. darcs record would exit
+	# nonzero, so don't run it in --all or --release mode.
+	$action_rc = action($prog, "status");
+	if (!$action_rc) {
+		return;
+	}
+	}
 	if ($diffmode) {
 	$action_rc = action($prog, "diff", @files_to_commit);
 	} else {
-- 
1.8.4.rc3



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

Bug#612966: Merge uboot-envtools into u-boot?

[Vagrant Cascadian]

Control: retitle 612966 Merge uboot-envtools into u-boot

Seems like there are only a few remaining features not yet merged:

On Wed, Feb 23, 2011 at 12:18:07AM +0100, Loïc Minier wrote:
>* uboot-envedit script; this does indeed make sense within u-boot,
>  but I don't want to track multiple upstreams; maybe this should be
>  sent upstream?

There is another bug report open for this, #540039.


>* debconf / automatic configuration: I'm not too happy with more
>  and more packages maintaining a list of board Hardware: names  :-/
>  I have some ideas to fix this on the long term, but it will take
>  time; also, I'm not too hot on debconf myself: I'd rather see d-i
>  install the correct config, perhaps in flash-kernel or some udeb
>  with board-specific knowledge

Should this issue become a separate bug?


Are there other outstanding issues/features not yet merged from
uboot-envtools?


live well,
  vagrant


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

Bug#728179: transition: libgsoap4, libgridsite2, canl-c

[Mattias Ellert]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: transition

Hi!

There are currently three packages that are somewhat tangled.

1) canl-c 2.1.2-1

This package is in the NEW queue - it is a new dependency for gridsite
2.0.4 below.

2) gridsite 2.0.4-2

Updated version of the gridsite package. Accepted in testing, but not
buildable due to the missing canl-c. This update means a transition from
libgridsite1.7 to libgridsite2.

3) gsoap 1.8.16-1

Updated gsoap package. This is in the NEW queue and means a transition
for libgsoap3 to libgsoap4. The gridsite package above depends on gsoap.


Packages needing rebuild:

  canl-c (in NEW queue)
  gsoap (in NEW queue)
  gridsite (depends canl-c, gsoap)
  voms (depends gsoap)
  cgsi-gsoap (depends gsoap, voms)
  lcgdm (depends gsoap, cgsi-gsoap, voms)
  srm-ifce (depends cgsi-gsoap)
  gfal2 (depends gsoap, gridsite, lcgdm, srm-ifce)
  nordugrid-arc (depends gridsite)
  condor (depends gsoap)
  virtualbox [contrib] (depends gsoap)

Mattias


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

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Lucas Nussbaum]

On 28/10/13 at 18:21 -0700, Russ Allbery wrote:
> Wouter Verhelst  writes:
> 
> > Also, since all alternative init implementations under consideration do
> > support sysv-style init scripts, I think that whatever init system we
> > (well, you, the TC) end up choosing, the requirement in policy should be
> > that a package should ship either some init configuration for the
> > default init system, or a sysv-style init script. In fact, I think we
> > should continue to encourage the latter, in cases where it does make
> > sense (e.g., when a given daemon doesn't have any init system specific
> > features that could be enabled), since that will help our non-Linux
> > ports without significantly impacting performance of the new init
> > system.
> 
> Well, I've said this before, but I think it's worth reiterating.  Either
> upstart or systemd configurations are *radically better* than init scripts
> on basically every axis.  They're more robust, more maintainable, easier
> for the local administrator to fix and revise, better on package upgrades,
> support new capabilities, etc.
> 
> I believe that much of the benefit for adopting a new init system is
> dropping init scripts and using a much better configuration language.  If
> we're not going to take advantage of that benefit, it calls into question
> whether we should change init systems at all.

Note that there are two options that could be explored, to remove the
need to maintain init scripts:
- generating sysvinit scripts from systemd service files or upstart job
  files at build time (this was explored, for systemd service files,
  during a GSoC project in 2012, without much success)
- having a .service/job files runtime interpreter (that sounds quite
  promising)

Even if it cannot be used for all services, using such as interpreter
could maybe provide an easy support path for sysvinit on non-linux
platforms for a large number of "simple" services.

There's a subthread about that starting at
https://lists.debian.org/debian-devel/2013/05/msg01309.html
Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Lucas


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

Bug#728180: gdm3: service gdm3 stop leaves lots of processes running, preventing restart or start of other dm

[Johannes Rohr]

Package: gdm3
Version: 3.8.4-3
Severity: normal

After running service gdm3 stop I still see a host of related processes running:


root 28772  0.0  0.1 294920  4316 ?Sl   09:13   0:00 
/usr/lib/gdm3/gdm-simple-slave --display-id 
/org/gnome/DisplayManager/Displays/_0
root 28777  0.4  0.3 153236 14748 tty7 Ssl+ 09:13   0:00 /usr/bin/Xorg 
:0 -background none -verbose -auth 
/var/run/gdm3/auth-for-Debian-gdm-h5EX9C/database -nolisten tcp vt7
root 28790  0.0  0.1 256400  6436 ?Sl   09:13   0:00 
gdm-session-worker [pam/gdm-launch-environment]
Debian-+ 28801  0.0  0.3 587212 12128 ?Ssl  09:13   0:00 
/usr/bin/gnome-session --autostart /usr/share/gdm/greeter/autostart
Debian-+ 28804  0.0  0.0  24464   608 ?S09:13   0:00 
/usr/bin/dbus-launch --exit-with-session /usr/bin/gnome-session --autostart 
/usr/share/gdm/greeter/autostart
Debian-+ 28835  0.9  2.5 1389068 103396 ?  Sl   09:13   0:01 gnome-shell 
--mode=gdm


What I did what running

service gdm3 stop
dpkg-reconfigure kdm , selected kdm as default dm
service kdm start

The screen remains blank. Only after  manually killing those processes, kdm can 
be launched.

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

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

Versions of packages gdm3 depends on:
ii  accountsservice0.6.34-2
ii  adduser3.113+nmu3
ii  dconf-cli  0.18.0-1
ii  dconf-gsettings-backend0.18.0-1
ii  debconf [debconf-2.0]  1.5.51
ii  eterm [x-terminal-emulator]0.9.6-1
ii  gir1.2-gdm33.8.4-3
ii  gnome-session [x-session-manager]  3.8.4-3
ii  gnome-session-bin  3.8.4-3
ii  gnome-settings-daemon  3.8.5-2
ii  gnome-shell3.8.4-4
ii  gnome-terminal [x-terminal-emulator]   3.8.4-1
ii  gsettings-desktop-schemas  3.8.2-2
ii  icewm [x-window-manager]   1.3.7-5
ii  kde-window-manager [x-window-manager]  4:4.10.5-3
ii  konsole [x-terminal-emulator]  4:4.10.5-2
ii  libaccountsservice00.6.34-2
ii  libatk1.0-02.10.0-2
ii  libaudit1  1:2.3.2-2
ii  libc6  2.17-93
ii  libcairo-gobject2  1.12.16-2
ii  libcairo2  1.12.16-2
ii  libcanberra-gtk3-0 0.30-2
ii  libcanberra0   0.30-2
ii  libgdk-pixbuf2.0-0 2.28.2-1
ii  libgdm13.8.4-3
ii  libglib2.0-0   2.36.4-1
ii  libglib2.0-bin 2.36.4-1
ii  libgtk-3-0 3.8.6-1
ii  libpam-modules 1.1.3-9
ii  libpam-runtime 1.1.3-9
ii  libpam0g   1.1.3-9
ii  libpango-1.0-0 1.32.5-5+b1
ii  libpangocairo-1.0-01.32.5-5+b1
ii  librsvg2-common2.36.4-2
ii  libselinux12.1.13-3
ii  libwrap0   7.6.q-24
ii  libx11-6   2:1.6.2-1
ii  libxau61:1.0.8-1
ii  libxdmcp6  1:1.1.1-1
ii  libxrandr2 2:1.4.1-1
ii  lsb-base   4.1+Debian12
ii  metacity [x-window-manager]1:2.34.13-1
ii  twm [x-window-manager] 1:1.0.6-1
ii  upower 0.9.23-2
ii  x11-common 1:7.7+4
ii  x11-xserver-utils  7.7+1
ii  xterm [x-terminal-emulator]297-1

Versions of packages gdm3 recommends:
ii  at-spi2-core   2.10.0-1+b1
ii  desktop-base   7.0.3
ii  gnome-icon-theme   3.8.3-1
ii  gnome-icon-theme-symbolic  3.8.2.2-2
ii  x11-xkb-utils  7.7~1
ii  xserver-xephyr 2:1.14.3-4
ii  xserver-xorg   1:7.7+4
ii  zenity 3.8.0-1

Versions of packages gdm3 suggests:
ii  gnome-orca3.4.2-2
ii  libpam-gnome-keyring  3.8.2-2

-- Configuration Files:
/etc/gdm3/greeter.gsettings changed:
[org.gnome.desktop.background]
picture-uri='file:///usr/share/themes/Adwaita/backgrounds/morning.jpg'
 picture-options='zoom'
[org.gnome.login-screen]
logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png'
fallback-logo='/usr/share/icons/gnome/48x48/places/debian-swirl.png'


-- debconf information:
  gdm3/daemon_name: /usr/sbin/gdm3
* shared/default-x-display-manager: kdm


-- 
To UNSUBSCRIBE, emai

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Steve Langasek]

On Mon, Oct 28, 2013 at 05:22:14PM +, Wouter Verhelst wrote:
> On Sat, Oct 26, 2013 at 11:20:21AM -0700, Steve Langasek wrote:
> > Right.  Whichever init system we pick, I do expect the next step to be to
> > drop the requirement to maintain sysvinit backwards-compatibility;

> While I'm not sure from your mail whether you meant to suggest otherwise,
> I do think that whatever we decide for jessie, we should continue the
> requirement of sysvinit compatibility for at least one release after we
> ship with some more modern init system.

The point was not about whether the init system would maintain
backwards-compatibility with sysvinit, which is straightforward to conserve
for some time, but whether individual packages providing services need to
maintain compatibility with sysvinit or if they can adopt the native service
definition format.  If we adopt a different init system as the default in
jessie, then certainly by jessie+1 at the latest, maintainers should feel
free to use the native format exclusively and not feel required to maintain
compatibility with sysvinit.

> Also, since all alternative init implementations under consideration do
> support sysv-style init scripts, I think that whatever init system we
> (well, you, the TC) end up choosing, the requirement in policy should be
> that a package should ship either some init configuration for the
> default init system, or a sysv-style init script. In fact, I think we
> should continue to encourage the latter, in cases where it does make
> sense (e.g., when a given daemon doesn't have any init system specific
> features that could be enabled), since that will help our non-Linux
> ports without significantly impacting performance of the new init
> system.

I see no reason that, if upstart were chosen as the default, porters could
not use it for our non-Linux ports as well.  This is a much better outcome
across our distribution as a whole than to require developers to continue
maintaining init scripts just for our non-Linux ports.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#727691: (no subject)

[Gianfranco Costamagna]

Il Lunedì 28 Ottobre 2013 14:16, Robert Lemmen  ha 
scritto:

hi gianfranco,
>
>there is indeed some reasoning behind this: the ABI (and even API) of
>libcheck isn't particularily stable, arguably it wouldn't even be
>desirable for a library like this to have a stable interface: the cost
>of making it harder to change outweghts the benefits. 
>
>because of this, libcheck is shipped as a *static only* library, which
>means you can still link against it and don't have to include libcheck
>*code* in your project. the static library is called liobcheck.a, and a
>typical linker invocation involves "-static" to tell the linker about
>the fact that you want to link statically.

Thanks, I tried, but I'm still having linking problems.
(I don't know why travis-ci succeedes, while I have problems on my computer
>
>please also note that it is not the target usecase to ever *ship*
>anything linked against libcheck, which is the usual reason for wanting
>to link against a .so.

Sorry I didn't undestand this part, the pourpose of check is to include tests 
on a particular software right?

what we do is:
- build ettercap,
- build tests (linked against check)
- run tests.

so check is not linked against ettercap, but only against test code, and it 
isn't shipped with any installer, is just for running testsuites.

Do you have any better way for running tests on ettercap project?



thanks for your answers!

G.

>
>regards  robert
>
>
>On Fri, Oct 25, 2013 at 02:10:06PM +0100, Gianfranco Costamagna wrote:
>> Hi developers, maybe do you have a rationale for this, but in ettercap we 
>> have recently enabled tests, and we link our tests with libcheck.so file.
>> 
>> In debian seems to be this file is deleted upon build, as shown in rules file
>>     rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so.*
>>     rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.so
>>     rm -f debian/check/usr/lib/$(DEB_HOST_MULTIARCH)/libcheck.la
>> 
>> How can we link it if you delete it when building?
>> 
>> At this moment we are using an embedded libcheck copy, but this solution 
>> isn't the best one.
>
>-- 
>Robert Lemmen                              http://www.semistable.com
>
>


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

Bug#728059: RFS: gnome-shell-pomodoro/0.6.20131027-1

[Joseph Herlant]

Hi,

It seems the version I packaged is ONLY compatible gnome-shell 3.4, so
it won't work in unstable (see discussion on debian-mentors list).
I tested the package in Debain testing and it worked fine, but I'll
will redo the package for the unstable version (gnome-shell 3.8).
In the mean time, please don't upload it, you'd loose your time.

Best regards,
Joseph


On Sun, Oct 27, 2013 at 11:59 PM, Joseph Herlant  wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "gnome-shell-pomodoro"
>
> * Package name: gnome-shell-pomodoro
>   Version : 0.6.20131027-1
>   Upstream Author :  Arun Mahapatra  and Kamil
> Prusko 
> * URL : https://github.com/codito/gnome-shell-pomodoro
> * License : gpl-v3
>   Section : gnome
>
> It builds those binary packages:
>
> gnome-shell-pomodoro - This GNOME Shell extension helps managing time
> according to Pomodoro technique
>
> To access further information about this package, please visit the
> following URL:
>
> http://mentors.debian.net/package/gnome-shell-pomodoro
>
>
> Alternatively, one can download the package with dget using this command:
>
> dget -x 
> http://mentors.debian.net/debian/pool/main/g/gnome-shell-pomodoro/gnome-shell-pomodoro_0.6.20131027-1.dsc
>
> More information about hello can be obtained from
> https://github.com/codito/gnome-shell-pomodoro.
>
> Regards,
> Joseph HERLANT
>
>
> --
> To UNSUBSCRIBE, email to package-sponsorship-requests-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> Archive: 
> http://lists.debian.org/capqicoygq_xutqxcydg6xlmd26e5depdimls_1vn8tapa-r...@mail.gmail.com
>


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

Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]

[Markus Koschany]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "tofrodos" which I intend to
adopt.

Package name: tofrodos
Version : 1.7.13+ds-1
Upstream Author : Christopher Heng
URL : http://www.thefreecountry.com/tofrodos/index.shtml
License : GPL-2
Section : utils

It builds those binary packages:

tofrodos   - Converts DOS <-> Unix text files, alias tofromdos

To access further information about this package, please visit the
following URL:

http://mentors.debian.net/package/tofrodos

Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/t/tofrodos/tofrodos_1.7.13+ds-1.dsc

Changes since the last upload:

 [ Alexander Reichle-Schmehl ]
  * Fix last changelog entry, remove the "NOT RELEASED YET" entry.
(Closes: #645830) Thanks to Josh Triplett for noticing!

  [ Markus Koschany ]
  * New Maintainer. (Closes: #726553)
  * New upstream release. (Closes: #692421)
- Drop FTBFS_non-linux.patch. Merged upstream.
  * Switch to source format 3.0.
  * Bump compat level to 9 and require debhelper >= 9.
  * Bump Standards-Version to 3.9.5, no changes.
  * Improve watch file. Thanks to Bart Martens.
  * Drop README.source and build dependency on quilt. Source format 3.0
uses quilt by default.
  * Drop NEWS file because it is obsolete.
  * Register tofrodos.html with doc-base.
  * Switch to dh sequencer.
  * Add a get-orig-source target to debian/rules.
  * Enable all hardening build flags.
  * debian/control:
- Maintain tofrodos in a Git repository. Change VCS-fields
  accordingly.
- Drop Conflicts field in debian/control. It is obsolete.
   * Update debian/copyright to copyright format 1.0.

Regards,

Markus Koschany



signature.asc
Description: OpenPGP digital signature

Bug#728182: devscripts: [ uscan ] out of date github example in manpage

[YABUKI Yukiharu]

Package: devscripts
Version: 2.13.4
Severity: minor
Tags: patch

Dear Maintainer,

Please check my patch for uscan.1

Yesterday, I checked uscan manpage. I was looking for example which
is how to write github watch file. I found it. and it did not work
well. Then, I searched example in wiki.debian.org. I got it.

Best
Yukiharu.

P.S.

I believed that I don't create any works of writing. if you take
care of license, I'd like to apply upstream's license.
thanks.


-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

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

Versions of packages devscripts depends on:
ii  dpkg-dev 1.17.1
ii  libc62.17-93
ii  perl 5.18.1-4
ii  python3  3.3.2-17
pn  python3:any  

Versions of packages devscripts recommends:
ii  at3.1.14-1
ii  curl  7.33.0-1
ii  dctrl-tools   2.23
ii  debian-keyring2013.07.31
ii  dput  0.9.6.4
ii  equivs2.0.9
ii  fakeroot  1.20-1
ii  gnupg 1.4.15-1.1
ii  libcrypt-ssleay-perl  0.58-1+b1
ii  libdistro-info-perl   0.11
ii  libencode-locale-perl 1.03-1
ii  libjson-perl  2.61-1
ii  libparse-debcontrol-perl  2.005-4
ii  libsoap-lite-perl 0.716-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.05-1
ii  lintian   2.5.19
ii  man-db2.6.5-2
ii  patch 2.7.1-3
ii  patchutils0.3.2-2
ii  python3-debian0.1.21+nmu2
ii  python3-magic 1:5.14-2
ii  sensible-utils0.0.9
ii  strace4.5.20-2.3
ii  unzip 6.0-10
ii  wdiff 1.2.1-1
ii  wget  1.14-4
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii  build-essential  11.6
pn  cvs-buildpackage 
pn  devscripts-el
ii  gnuplot  4.6.4-1
ii  gpgv 1.4.15-1.1
ii  libauthen-sasl-perl  2.1500-1
ii  libfile-desktopentry-perl0.07-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 1.2000-1
pn  libyaml-syck-perl
ii  mutt 1.5.21-6.4
ii  openssh-client [ssh-client]  1:6.2p2-6
pn  svn-buildpackage 
ii  w3m  0.5.3-12

-- no debconf information
diff --git scripts/uscan.1 scripts/uscan.1
index af4e57f..899cccd 100644
--- scripts/uscan.1
+++ scripts/uscan.1
@@ -77,7 +77,10 @@ http://example.com/example-(\ed[\ed\.]*)\e.(?:zip|tgz|tbz2|txz|tar\e.(?:gz|bz2|x
 http://sf.net/audacity/audacity-src-(.+)\e.tar\e.gz
 
 # For GitHub projects you can use the tags page:
-https://github.com///tags .*/(\ed[\ed\e.]*)\e.tar\e.gz
+#  or if you would like to use releases page, please replace
+#  tags with releases.
+opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/-$1.tar.gz/ \
+  https://github.com///tags .*/v?(\d\S*)\.tar\.gz
 
 # For Google Code projects you should use the downloads page like this:
 http://code.google.com/p//downloads/list?can=1 \e

Bug#728183: plasma-desktop: Plasma desktop crashes on boot since update

[debian-bug-reports]

Package: plasma-desktop
Version: 4:4.10.5-3
Severity: grave
Justification: renders package unusable

Since an update to the packages on Debian testing last night, the KDE desktop
crashes on boot, giving a message that prompts to create a backtrace. Here is
that backtrace.

As you can see, running Debian Jessie, versions of KDE packages are 4.10.5-1 or
4.10.5-2. kernel 3.10-3-amd64. I have a wallpaper slideshow which appears to be
one of the things crashing. What is the source of this problem? This is the
first time my desktop has failed in 3 years of KDE atop debian. Will be happy
for a solution as have had to fall back to another desktop.


Reproducible: Always


Steps to Reproduce: 1. Boot with user configuration into KDE desktop. (guest
account with default configuration boots normally.)
2. Error message appears indicating that the plasma desktop has crashed. Ctrl-
Alt-Del will still bring up a restart/shutdown/logout menu with the correct
appearance settings.
3.
Actual Results:
KDE desktop does not appear at boot.


Expected Results:
KDE desktop renders computer available for use when started up.

Application: plasma-desktop (4.10.5)
KDE Platform Version: 4.10.5
Qt Version: 4.8.6
Operating System: Linux 3.10-3-amd64 x86_64
Distribution: Debian GNU/Linux testing (jessie)


-- Information about the crash:
 The
crash can be reproduced every time.

-- Backtrace:

Application: plasma-desktop (4.10.5)
KDE Platform Version: 4.10.5
Qt Version: 4.8.6
Operating System: Linux 3.10-3-amd64 x86_64
Distribution: Debian GNU/Linux testing (jessie)

-- Information about the crash:


The crash can be reproduced every time.

-- Backtrace:
Application: Plasma Desktop Shell (plasma-desktop), signal: Segmentation fault
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Current thread is 1 (Thread 0x7fd0f8287780 (LWP 7946))]

Thread 3 (Thread 0x7fd0d9719700 (LWP 7957)):
#0  0x7fd0ebff8e35 in __GI___pthread_mutex_lock (mutex=0x239eb10) at
pthread_mutex_lock.c:95
#1  0x7fd0eb724291 in g_mutex_lock () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#2  0x7fd0eb6e4a2b in g_main_context_query () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#3  0x7fd0eb6e5102 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#4  0x7fd0eb6e55fa in g_main_loop_run () from /lib/x86_64-linux-
gnu/libglib-2.0.so.0
#5  0x7fd0e05abd26 in ?? () from /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
#6  0x7fd0eb7091d5 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0
#7  0x7fd0ebff6e0e in start_thread (arg=0x7fd0d9719700) at
pthread_create.c:311
#8  0x7fd0f7b889ed in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 2 (Thread 0x7fd0ce491700 (LWP 7959)):
#0  pthread_cond_wait@@GLIBC_2.3.2 () at
.../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185
#1  0x7fd0f174ba4b in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#2  0x7fd0f174ba89 in ?? () from /usr/lib/x86_64-linux-gnu/libQtScript.so.4
#3  0x7fd0ebff6e0e in start_thread (arg=0x7fd0ce491700) at
pthread_create.c:311
#4  0x7fd0f7b889ed in clone () at
.../sysdeps/unix/sysv/linux/x86_64/clone.S:113

Thread 1 (Thread 0x7fd0f8287780 (LWP 7946)):
[KCrash Handler]
#6  0x7fd0f46d7b80 in QMetaObject::cast (this=this@entry=0x7fd0f7a8e560
, obj=obj@entry=0x2a73bb0) at
kernel/qmetaobject.cpp:275
#7  0x7fd0f77371cf in qobject_cast
(object=0x2a73bb0) at /usr/include/qt4/QtCore/qobject.h:380
#8  create (args=..., keyword=..., parent=, parentWidget=, this=) at
.../../kdecore/util/kpluginfactory.h:533
#9  createInstance (error=, args=...,
parent=, parentWidget=, this=) at
.../../kdecore/services/kservice.h:559
#10 createInstance (error=, args=...,
parent=, this=) at
.../../kdecore/services/kservice.h:536
#11 Plasma::loadEngine (language=..., type=type@entry=Plasma::AppletComponent,
parent=parent@entry=0x2a74140) at ../../plasma/scripting/scriptengine.cpp:185
#12 0x7fd0f7737796 in Plasma::loadScriptEngine (language=...,
applet=0x2a74140) at ../../plasma/scripting/scriptengine.cpp:209
#13 0x7fd0f768b9ad in Plasma::AppletPrivate::init (this=0x290aa70,
packagePath=...) at ../../plasma/applet.cpp:2799
#14 0x7fd0f7690a53 in Plasma::Applet::Applet (this=0x2a74140,
parentObject=0x0, args=...) at ../../plasma/applet.cpp:193
#15 0x7fd0f76cdf62 in Plasma::PluginLoader::loadApplet (this=, name=..., appletId=, appletId@entry=172, args=...) at
.../../plasma/pluginloader.cpp:134
#16 0x7fd0f76832a5 in Plasma::Applet::load (appletName=...,
appletId=appletId@entry=172, args=...) at ../../plasma/applet.cpp:2451
#17 0x7fd0f76a04e4 in Plasma::ContainmentPrivate::addApplet
(this=0x291caf0, name=..., args=..., appletGeometry=..., id=id@entry=172,
delayInit=delayInit@entry=true) at ../../plasma/containment.cpp:2221
#18 0x7fd0f76a4be5 in Plasma::Containment::restoreContents (this=0x28f0990,
group=...) at ../../plasma/containment.cpp:497
#19 0x7fd0f76a1734 in Plasma::Containment::restore (this=0x28f0990,

Bug#727670: Please add calendar and carddav plugins

[Jérémy Bobbio]

Control: tags -1 wontfix

Matteo Calorio:
> >> https://github.com/graviox/Roundcube-CardDAV
> 
> > This one has not been touched for a while. Can you confirm 
> that it works
> > well with Roundcube 0.9?
> 
> I worked for me with previous version of Roundcube, I don't know 
> with version 0.9. I tried right now, it seems it imports contacts 
> from ownCloud, but it doesn't show them.

That confirm my thoughts, thanks.

Sorry but until there's a working plugin, there's nothing to package.
Don't hesitate to send a new email if the situation changes.

-- 
Lunar.''`. 
lu...@debian.org: :Ⓐ  :  # apt-get install anarchism
`. `'` 
  `-   


signature.asc
Description: Digital signature

Bug#728184: python-suds: Suds doesn't merge multiple namespaces correctly

[Russell Stuart]

Package: python-suds
Version: 0.4.1-9.0
Severity: wishlist
Tags: patch upstream

If multiple wsdl:schema's are used with different namespaces suds
doesn't resolve type names properly.  Turns out my problem is caused by
the same issue as this existing suds bug report (although it is
reporting different symptoms):

  http://fedorahosted.org/suds/ticket/346

The reporter has provided a patch, which I have verified works (thus the
odd debian verison number).  The quilt patch is attached.


-- System Information:
Debian Release: 7.2
  APT prefers stable
  APT policy: (990, 'stable'), (500, 'stable-updates'), (50, 'testing'), (40, 
'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages python-suds depends on:
ii  python2.7.3-4+deb7u1
ii  python-pkg-resources  0.6.24-1

python-suds recommends no packages.

python-suds suggests no packages.

-- no debconf information
Author: Russell Stuart 
Description: Suds doesn't merge multiple namespaces correctly
Bug: https://fedorahosted.org/suds/ticket/346

--- a/suds/xsd/schema.py
+++ b/suds/xsd/schema.py
@@ -265,6 +265,7 @@
 @returns: self
 @rtype: L{Schema} 
 """
+initial_count = len(self.all)
 for item in schema.attributes.items():
 if item[0] in self.attributes:
 continue
@@ -290,6 +291,9 @@
 continue
 self.all.append(item[1])
 self.agrps[item[0]] = item[1]
+for top_level_item in self.all[initial_count:]:
+for descendant in top_level_item.content():
+descendant.schema = self
 schema.merged = True
 return self
 

Bug#727691: (no subject)

[Robert Lemmen]

On Tue, Oct 29, 2013 at 08:50:05AM +, Gianfranco Costamagna wrote:
> >because of this, libcheck is shipped as a *static only* library, which
> >means you can still link against it and don't have to include libcheck
> >*code* in your project. the static library is called liobcheck.a, and a
> >typical linker invocation involves "-static" to tell the linker about
> >the fact that you want to link statically.
> 
> Thanks, I tried, but I'm still having linking problems.
> (I don't know why travis-ci succeedes, while I have problems on my computer

hmm, can you tell me in detail what you are doing (i.e. linker
invocation) and what error message you are getting?

> Sorry I didn't undestand this part, the pourpose of check is to include tests 
> on a particular software right?
> 
> what we do is:
> - build ettercap,
> - build tests (linked against check)
> - run tests.
> 
> so check is not linked against ettercap, but only against test code, and it 
> isn't shipped with any installer, is just for running testsuites.
> 
> Do you have any better way for running tests on ettercap project?

no better suggestions, what you do sounds absolutely right. I just said
that because a typical reason for people wanting a .so instead of a
static lib si that they want to ship the test binary and are concerned
about the size of it. and that's just not what unit tests are for...

regards  robert

-- 
Robert Lemmen   http://www.semistable.com 


signature.asc
Description: Digital signature

Bug#727708: tech-ctte: Decide which init system to default to in Debian.

[Helmut Grohne]

TL;DR: Thoughts on using systemd .service files on non-Linux ports.

On Tue, Oct 29, 2013 at 09:20:10AM +0100, Lucas Nussbaum wrote:
> Note that there are two options that could be explored, to remove the
> need to maintain init scripts:
> - generating sysvinit scripts from systemd service files or upstart job
>   files at build time (this was explored, for systemd service files,
>   during a GSoC project in 2012, without much success)
> - having a .service/job files runtime interpreter (that sounds quite
>   promising)
> 
> Even if it cannot be used for all services, using such as interpreter
> could maybe provide an easy support path for sysvinit on non-linux
> platforms for a large number of "simple" services.
> 
> There's a subthread about that starting at
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> Helmut Grohne (Cced) did most of the work on analyzing those possibilities.

Thanks for inviting me to speak up here. Lucas asked me to summarize my
analysis of systemd/sysv integration earlier and I'll be giving this
summary (written for Lucas at that time) below.

For better separation of facts and opinion, let me point out my
motivation for working on this aspect. I believe that the declarative
service configuration of systemd and upstart is superior to init shell
scripts. Consequently, dropping the need for init shell scripts is the
only way to improve the situation (imo). Lacking time, I mostly
neglected upstart.

On 23/08/13 at 22:32 +0200, Helmut Grohne wrote:
> The existing converter (GSOC) can be found at
> https://github.com/akhilvij/systemd-to-sysvinit-converter.
> 
> My analysis of this project:
> https://lists.debian.org/debian-devel/2013/05/msg01309.html
> This includes a drafted idea on how to do runtime conversion.
> 
> Implementation details on runtime conversion: (last pragraph)
> https://lists.debian.org/debian-devel/2013/05/msg01337.html
> 
> Random details about service file conversion issues:
> https://lists.debian.org/debian-devel/2013/05/msg01334.html
> Important point over here: In .service files important dependency
> information has been elided by socket activation. Socket activation is
> official part of the dependency tree and any conversion utility that
> does not do socket activation will not produce correct boot ordering.
> 
> Statistical analysis of existing .service files in Debian.
> https://lists.debian.org/debian-devel/2013/07/msg00436.html
> 
> .service file parser written in C, could be used as a starting point.
> https://lists.debian.org/debian-devel/2013/07/msg00429.html
> 
> I presume that you are preparing arguments for a discussion with the
> CTTE about how to move forward with /sbin/init. The question of whether
> or how to support systemd .service files on non-Linux platforms will be
> asked over there.
> 
> The biggest issue I see here is the socket activation. It is mandatory
> for syslog, so no service will declare a dependency on syslog and just
> assume it to be present. On a technical level implementing socket
> activation on non-Linux platforms is possible. It would require a super
> server (similar to inetd) to be started early on and it would start
> .service files on request by other interpreted .service files when
> executed as init scripts. This amounts to reimplementing a fair part of
> systemd. The only alternative would be to annotate .service files with
> the missing dependency information, but which would likely be wrong most
> of the time.
> 
> I guess that an implementation that allows socket activation would be
> able to support around 50% of the currently existing .service files.
> 
> Bear in mind that systemd is a rapidly moving target. When I talked to
> Lennart about the idea of a portable .service file interpreter, he
> summarized future extensions to systemd that would raise the bar. The
> next issue will likely be the tight integration with dbus and later
> kdbus (the kernel implementation of dbus). By the time we would have an
> implementation featuring socket activation, we will likely need it to do
> dbus activation as well.

Having read the parts of the ctte bug, it feels odd to preclude the
option of supporting multiple init systems from discussion or
consideration. If Debian is to support only one init system and that one
init system is systemd, then given my above analysis it will be very
hard for non-Linux ports to catch up. I argue that in this case we
should consider dropping support for non-Linux ports. So if we really
are considering such an outcome, why not consider the outcome of
supporting multiple init systems (but maybe only one per architecture)?
This would become radically easier if gnome were to become Architecture:
linux-any.

In any case, feel free to ask me for answers or help with respect to
possible integration of systemd .service files in a non-Linux
environment.

I hope that this mail moves the discussion/decision forward.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lis

Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]

[Andrew Shadura]

Hello,

On 29 October 2013 09:57, Markus Koschany  wrote:
> I am looking for a sponsor for my package "tofrodos" which I intend to
> adopt.

I've built, signed and uploaded your package. Thanks for your work.

Feel free to contact me if you need to sponsor your upload again.

-- 
WBR, Andrew


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

Bug#728185: alacarte: icons paths are pasted without extension

[Rene Brandt]

Package: alacarte
Version: 3.10.0-1
Severity: normal

Dear Maintainer,

Well, I had this issue for some time now, but up until recently my system was
not very stable. To eliminate user errors, I just installed a fresh Debian
testing install, and still have the problem that I can't set any custom icons
using the GUI. See a more detailed description below:
   * What led up to the situation? / What exactly did you do (or not do) that
was effective (or ineffective)?
When you edit a menu entry, you can click the icon in the submenu and enter a
file picking dialogue to set another icon. When I do so, I return to the
submenu. Here, I can see my newly set icon.

   * What was the outcome of this action?
When I click OK to accept the new icon, the icon becomes "empty" for both my
application menu and within alacarte. Checking the ~/.local/share/applications
directory for the .desktop file, I found out that the extension of the image
file is not pasted at all. So for example when I set ~/foo.bar as icon, the
icon path becomes
Icon=/home/rene/foo

   * What outcome did you expect instead?
That the extension is pasted. So in the above example, the line should become
Icon=/home/rene/foo.bar



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

Kernel: Linux 3.10-3-amd64 (SMP w/8 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 alacarte depends on:
ii  gir1.2-gdkpixbuf-2.0  2.28.2-1
ii  gir1.2-glib-2.0   1.36.0-2+b1
ii  gir1.2-gmenu-3.0  3.8.0-2
ii  gir1.2-gtk-3.03.8.4-1
ii  gnome-menus   3.8.0-2
ii  python-gi 3.8.2-1
pn  python:any

alacarte recommends no packages.

alacarte 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#685787: Praat has serious bug #713597

[Andreas Tille]

Hi James,

On Mon, Oct 28, 2013 at 07:06:37PM -0400, James McCoy wrote:
> Thanks Rafael for the feedback and Andreas for continued patience.
> 
> On Mon, Oct 28, 2013 at 10:10:00PM +0100, Andreas Tille wrote:
> > On Mon, Oct 28, 2013 at 07:44:57PM +0100, Rafael Laboissiere wrote:
> > > It would be preferable that you had created a side branch in the Git
> > > repository for your changes, such that the merge would be trivial to
> > > do.
> 
> This really wouldn't have made much of a difference.  It's trivial to
> add Andrea's repo as a remote and then the functionality is the same as
> if the branch were in devscripts' repo.  At the time that Andreas
> started work on this, devscripts wasn't in collab-maint so it made sense
> to just push his changes to a user repo on Alioth so people could access
> and review the changes.

OK.

> > > It will also be necessary to prepare a qpatched versions for uscan.1
> > > and debian/control.
> > 
> > I'd happily provide this if I could be sure that this effort is not
> > wasted in a way that uscan in devscripts simply moves on and I need
> > to redo the patch later again.  Some signal of devscripts maintainer
> > regarding this would be helpful.
> 
> As stated before, we were originally waiting for the (longish) Wheezy
> freeze to finish and release.  Since that has happened, there has been a
> lack of time available from existing maintainers.
> 
> Your work is not wasted, though, since we can integrate your changes
> regardless of whether they've been rebased on a recent version of uscan.
> It's "just" a matter of time to review and merge.
> 
> I will work on this within the next month.

Cool.  Just let me know if I could be of any help.

Kind regards and thanks for maintaining devscripts

  Andreas.

-- 
http://fam-tille.de


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

Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]

[Markus Koschany]

On 29.10.2013 10:23, Andrew Shadura wrote:
> Hello,
> 
> On 29 October 2013 09:57, Markus Koschany  wrote:
>> I am looking for a sponsor for my package "tofrodos" which I intend to
>> adopt.
> 
> I've built, signed and uploaded your package. Thanks for your work.
> 
> Feel free to contact me if you need to sponsor your upload again.

Andrew, thank you very much!

Markus



signature.asc
Description: OpenPGP digital signature

Bug#685787: [raf...@laboissiere.net: Re: Patch for devscripts]

[Andreas Tille]

Hi again,

just to make sure that Rafael's work is propagated in case it might
help.  I understood James' mail and that he could work with the existing
Git repository but since Rafael did some style changes this patch might
be more clean.

Kind regards

  Andreas.

- Forwarded message from Rafael Laboissiere  -

Date: Tue, 29 Oct 2013 09:36:39 +0100
From: Rafael Laboissiere 
To: Andreas Tille 
Subject: Re: Patch for devscripts

* Andreas Tille  [2013-10-28 22:56]:
> 
> On Mon, Oct 28, 2013 at 10:37:13PM +0100, Rafael Laboissiere wrote:
>> 
>> If you agree, I can give it a try.  Remember that users of Git
>> appreciate when you play the Git rules.
> 
> For sure I agree!  On one hand this gives another pair of eyeballs
> looking at my crappy code.  On the other hand I can spent my time
> for other burning things in Debian Med.  So feel free to move on
> and ping me if you need any help.

Ok, I succeeded to isolate the changes related to Files-Excluded and
put them all into a single patch, which you will find attached below.
This patch applies cleanly to the current qdevscript repository's
master:

git clone git://anonscm.debian.org/collab-maint/devscripts.git
cd devscripts
patch -p1 < /path/to/files-excluded.patch

The resulting uscan.pl script works fine for me (at least, for the
praat package).  Of course, it does not have the repack-compression
feature.

You will note that I did a couple of stylistic changes.  I also
removed those comments related to Parse::DebControl.  The goal is to
provide a slim patch, such that its chances to be accepted are higher.
I did not revise your Perl code in detail, though (since it ain't
broken, I won't fix it!).

In order to produce a proper Git patch you must give me a decent
commit message.  It does not need to be short.  On the contrary, it
must be quite clear on what has been changed.  I think that an
explanation as you gave in the report of Bug#685787 would be fine.

> Perhaps it makes sense to update the Wiki page about what's going on.

Probably, yes.

Best,

Rafael






diff --git a/debian/control b/debian/control
index d48f7f2..b9dc690 100644
--- a/debian/control
+++ b/debian/control
@@ -16,6 +16,7 @@ Build-Depends: debhelper (>= 9),
libparse-debcontrol-perl,
libterm-size-perl,
libtimedate-perl,
+   libtry-tiny-perl,
liburi-perl,
libwww-perl,
lsb-release,
@@ -50,6 +51,7 @@ Recommends: at,
 libencode-locale-perl,
 libjson-perl,
 libparse-debcontrol-perl,
+libtry-tiny-perl,
 liburi-perl,
 libwww-perl,
 lintian,
diff --git a/scripts/uscan.1 b/scripts/uscan.1
index af4e57f..fb53f3e 100644
--- a/scripts/uscan.1
+++ b/scripts/uscan.1
@@ -444,6 +444,10 @@ Give verbose output.
 .B \-\-no\-verbose
 Don't give verbose output.  (This is the default behaviour.)
 .TP
+.B \-\-no\-exclusion
+Do not automatically exclude files mentioned in
+\fIdebian/copyright\fR field \fBFiles-Excluded\fR
+.TP
 .B \-\-debug
 Dump the downloaded web pages to stdout for debugging your watch file.
 .TP
@@ -517,6 +521,10 @@ equivalent to the \fB\-\-destdir\fR option.
 If this is set to \fIyes\fR, then after having downloaded a bzip tar,
 lzma tar, xz tar, or zip archive, \fBuscan\fR will repack it to a gzip tar.
 This is equivalent to the \fB\-\-repack\fR option.
+.B USCAN_NO_EXCLUSION
+If this is set to \fIyes\fR, files mentioned in the field \fBFiles-Excluded\fR
+of \fIdebian/copyright\fR will be ignored and no exclusion of files will be
+tried.  This is equivalent to the \fB\-\-no-exclusion\fR option.
 .SH "EXIT STATUS"
 The exit status gives some indication of whether a newer version was
 found or not; one is advised to read the output to determine exactly
diff --git a/scripts/uscan.pl b/scripts/uscan.pl
index 976b368..5dc8a6e 100755
--- a/scripts/uscan.pl
+++ b/scripts/uscan.pl
@@ -27,6 +27,8 @@ use strict;
 use Cwd;
 use Cwd 'abs_path';
 use Dpkg::IPC;
+use Dpkg::Control::Hash;
+use Try::Tiny;
 use File::Basename;
 use File::Copy;
 use File::Temp qw/tempfile tempdir/;
@@ -46,6 +48,7 @@ BEGIN {
}
 }
 }
+
 my $CURRENT_WATCHFILE_VERSION = 3;
 
 my $progname = basename($0);
@@ -72,6 +75,7 @@ sub uscan_die (@);
 sub dehs_output ();
 sub quoted_regex_replace ($);
 sub safe_replace ($$);
+sub get_main_source_dir ($);
 
 sub usage {
 print <<"EOF";
@@ -138,6 +142,8 @@ Options:
 --no-conf, --noconf
Don\'t read devscripts config files;
must be the first option given
+--no-exclusion no automatic exclusion of files mentioned in
+   debian/copyright field Files-Excluded
 --help Show this message
 --version  Show version information
 
@@ -180,6 +186,7 @@ my $dehs_start_output = 0;
 my $pkg_report_header = '';
 my $timeout = 20;
 my $user_agent_string = 'Debian uscan ###VERSION###';
+my $no_ex

Bug#728186: clamav-milter: silently fails to start

[Olaf Zaplinski]

Package: clamav-milter
Version: 0.97.8+dfsg-1
Severity: grave
Justification: renders package unusable

Dear Maintainer,

clamav-milter fails to start without any notice:

root@binky:/etc/clamav# /etc/init.d/clamav-milter stop
[ ok ] Stopping Sendmail milter plugin for ClamAV: clamav-milter.

root@binky:/etc/clamav# /etc/init.d/clamav-milter start
[warn] Starting Sendmail milter plugin for ClamAV: clamav-milter[] Tried to 
change socket group, but socket did not appear. ... (warning).
. ok

root@binky:/etc/clamav# /etc/init.d/clamav-milter status
[FAIL] clamav-milter is not running ... failed!



-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamav/clamd.pid"
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
VirusEvent disabled
ExitOnOOM disabled
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = "yes"
ScanPE = "yes"
ScanELF = "yes"
DetectBrokenExecutables disabled
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
OLE2BlockMacros disabled
ScanPDF = "yes"
ScanArchive = "yes"
ArchiveBlockEncrypted disabled
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
ClamAuth disabled
ClamukoScanOnAccess disabled
ClamukoScannerCount = "3"
ClamukoScanOnOpen disabled
ClamukoScanOnClose disabled
ClamukoScanOnExec disabled
ClamukoIncludePath disabled
ClamukoExcludePath disabled
ClamukoExcludeUID disabled
ClamukoMaxFileSize = "5242880"
DevACOnly disabled
DevACDepth disabled
DevLiblog disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
PidFile = "/var/run/clamav/freshclam.pid"
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = "30"
ReceiveTimeout = "30"
SubmitDetectionStats disabled
DetectionStatsCountry disabled
DetectionStatsHostID disabled
SafeBrowsing disabled
Bytecode = "yes"

Config file: clamav-milter.conf
---
LogFile = "/var/log/clamav/clamav-milter.log"
LogFileUnlock disabled
LogFileMaxSize = "10485760"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_MAIL"
LogVerbose disabled
PidFile = "/var/run/clamav/clamav-milter.pid"
TemporaryDirectory = "/var/tmp"
FixStaleSocket = "yes"
MaxThreads = "10"
ReadTimeout = "120"
Foreground disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
MaxFileSize = "26214400"
ClamdSocket = "/var/run/clamav/clamd.ctl"
MilterSocket = "inet6:7357@::1"
MilterSocketGroup = "clamav"
MilterSocketMode = "660"
LocalNet = "local"
OnClean = "Accept"
OnInfected = "Reject"
OnFail = "Defer"
RejectMsg disabled
AddHeader = "Replace"
ReportHostname disabled
VirusAction disabled
Chroot disabled
Whitelist disabled
SkipAuthenticated disabled
LogInfected = "Full"
LogClean = "Basic"

Software settings
-
Version: 0.97.8
O

Bug#728187: clamav-milter: clamd socket not accessible

[Olaf Zaplinski]

Package: clamav-milter
Version: 0.97.8+dfsg-1
Severity: normal

Dear Maintainer,

clamav-milter cannot access the clamd socket:

Oct 29 10:41:02 binky clamav-milter[28085]: +++ Started at Tue Oct 29 10:41:02 
2013
Oct 29 10:41:02 binky clamav-milter[28086]: Failed to parse ClamdSocket 
directive '/var/run/clamav/clamd.ctl'
Oct 29 10:41:02 binky clamav-milter[28086]: Failed to init the socket pool

... and silently dies:

root@binky:/etc/clamav# /etc/init.d/clamav-milter start
[ ok ] Starting Sendmail milter plugin for ClamAV: clamav-milter.

root@binky:/etc/clamav# /etc/init.d/clamav-milter status
[FAIL] clamav-milter is not running ... failed!

The socket file does exist:

root@binky:/etc/clamav# l /var/run/clamav
total 4
drwxr-xr-x  2 clamav root100 Oct 29 10:43 ./
drwxr-xr-x 20 root   root660 Oct 29 09:30 ../
srw-rw  1 clamav postfix   0 Oct 29 10:43 clamav-milter.socket=
srw-rw-rw-  1 clamav clamav0 Oct 29 10:21 clamd.ctl=
-rw-rw-r--  1 clamav clamav5 Oct 29 10:21 clamd.pid




-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamav/clamd.pid"
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
VirusEvent disabled
ExitOnOOM disabled
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = "yes"
ScanPE = "yes"
ScanELF = "yes"
DetectBrokenExecutables disabled
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
OLE2BlockMacros disabled
ScanPDF = "yes"
ScanArchive = "yes"
ArchiveBlockEncrypted disabled
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
ClamAuth disabled
ClamukoScanOnAccess disabled
ClamukoScannerCount = "3"
ClamukoScanOnOpen disabled
ClamukoScanOnClose disabled
ClamukoScanOnExec disabled
ClamukoIncludePath disabled
ClamukoExcludePath disabled
ClamukoExcludeUID disabled
ClamukoMaxFileSize = "5242880"
DevACOnly disabled
DevACDepth disabled
DevLiblog disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
PidFile = "/var/run/clamav/freshclam.pid"
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = "30"
ReceiveTimeout = "30"
SubmitDetectionStats disabled
DetectionStatsCountry disabled
DetectionStatsHostID disabled
SafeBrowsing disabled
Bytecode = "yes"

Config file: clamav-milter.conf
---
LogFile disabled
LogFileUnlock disabled
LogFileMaxSize = "1048576"
LogTime disabled
LogSyslog = "yes"
LogFacility = "LOG_MAIL"
LogVerbose = "yes"
PidFile = "/var/run/clamav/clamav-milter.pid"
TemporaryDirectory = "/var/tmp"
FixStaleSocket = "yes"
MaxThreads = "10"
ReadTimeout = "120"
Foreground disabled
User disabled
AllowSupplementaryGroups disabled
MaxFileSize = "26214400"
ClamdSocket = "/var/run/clamav/clamd.ctl"
MilterSocket = "/var/run/cl

Bug#727818: mongodb-server: please, integrate changes from github

[James Page]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 28/10/13 12:53, László Böszörményi (GCS) wrote:
> Then I plan to include systemd support and correct the copyright
> file with the AGPL+OpenSSL license exception. Then MongoDB should
> be built on all architectures[2] that V8 supports. I think these
> are the most important changes needed to the packaging. James, what
> do you think?

All sounds good to me. I have a couple of other things I would like to
work in so that we can remove all of the Ubuntu delta:

1) upstart configuration - this should co-exist with systemd and init
scripts OK

2) SSL enablement - this should be OK now with the license exception
and is something we have in Ubuntu

3) -base package split for server; I have a specific requirement in
another package for just the mongod/mongos binaries without the
associated init scripts.

If you would like another co-maintainer I'd be happy to work directly
in the git repository todo this work.

Getting Rogerio's changes in for reducing the client package size
would also be fantastic.


- -- 
James Page
Ubuntu and Debian Developer
james.p...@ubuntu.com
jamesp...@debian.org
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSb4MRAAoJEL/srsug59jDjOIP/Rsdz8cPLI7XoO+f8/FMyx2Y
PpgdDDyc7yDXcwzlgPEPipI7XOpM/50rOmaLyK6XUZAENs5PPly5vIP5eE5LEsV8
IkPWNgmcjB7Qvvp1/ZiDyyelHwyQstxdzSEjUOJj+3QchWR8w8hqNLdhI7hnZrBL
hjq38ptbEet/1pCW79iE818MNsarh2FpNbs1RQJ1Q1JwuqyZPcRQx2Vi24o05Wjw
zj1grUrgl18s1ii13zFXFqOsD6dhZXr9J84WsafJcCWORXgNw3MShTBQ49DfSkMy
UgeTFq5OcA1fesE9sBOWKqajoP6S9H3y0I0qbOCaxIerCJF3XlNMCyHa1iE2bkh7
8W/RtaQ1sWLNSHI3n0VRwcqRh1uwKPHMzhXtc5Hxr9BvqEC/maknq8SZ0hXvCI58
rJdF2uKuciSMtZfjt+LZ8lALoUb6OWvRe0GXeivClwYcAQd9ypRI16p/ghfXwNDi
o/fSPmV7a8BEh/8VQXAKSaQ9C+nWXiEc61SVKPtzvtllydY7eRAdJS/rtbxPZ9zs
PFtwP1vUJbBMAl6Mj3xrUeyQNm4UudARVhDIVuU7FPNMRs1NTiD9zb+a4W6w3XPS
Kk60JmpOOdNnJ78ELcn2/a6WHp7YRsFEYdr4yhTfQZdRZEnA7BmfxQDVl7VYK64z
tL1thxXa+IN+E05rgngo
=ABCl
-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#728188: clamav-milter: errata in /usr/share/doc/clamav-milter/README.Debian.gz

[Olaf Zaplinski]

Package: clamav-milter
Version: 0.97.8+dfsg-1
Severity: wishlist

Dear Maintainer,

please see /usr/share/doc/clamav-milter/README.Debian.gz at line 139:
"See /usr/share/doc/clamav-milter/INSTALL.gz for some details"

This file does not exist, please provide it or change README.Debian.gz.


-- Package-specific info:
--- configuration ---
Checking configuration files in /etc/clamav

Config file: clamd.conf
---
LogFile = "/var/log/clamav/clamav.log"
LogFileUnlock disabled
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogClean disabled
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
ExtendedDetectionInfo = "yes"
PidFile = "/var/run/clamav/clamd.pid"
TemporaryDirectory disabled
DatabaseDirectory = "/var/lib/clamav"
OfficialDatabaseOnly disabled
LocalSocket = "/var/run/clamav/clamd.ctl"
LocalSocketGroup = "clamav"
LocalSocketMode = "666"
FixStaleSocket = "yes"
TCPSocket disabled
TCPAddr disabled
MaxConnectionQueueLength = "15"
StreamMaxLength = "26214400"
StreamMinPort = "1024"
StreamMaxPort = "2048"
MaxThreads = "12"
ReadTimeout = "180"
CommandReadTimeout = "5"
SendBufTimeout = "200"
MaxQueue = "100"
IdleTimeout = "30"
ExcludePath disabled
MaxDirectoryRecursion = "15"
FollowDirectorySymlinks disabled
FollowFileSymlinks disabled
CrossFilesystems = "yes"
SelfCheck = "3600"
VirusEvent disabled
ExitOnOOM disabled
Foreground disabled
Debug disabled
LeaveTemporaryFiles disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
Bytecode = "yes"
BytecodeSecurity = "TrustSigned"
BytecodeTimeout = "6"
BytecodeUnsigned disabled
BytecodeMode = "Auto"
DetectPUA disabled
ExcludePUA disabled
IncludePUA disabled
AlgorithmicDetection = "yes"
ScanPE = "yes"
ScanELF = "yes"
DetectBrokenExecutables disabled
ScanMail = "yes"
ScanPartialMessages disabled
PhishingSignatures = "yes"
PhishingScanURLs = "yes"
PhishingAlwaysBlockCloak disabled
PhishingAlwaysBlockSSLMismatch disabled
HeuristicScanPrecedence disabled
StructuredDataDetection disabled
StructuredMinCreditCardCount = "3"
StructuredMinSSNCount = "3"
StructuredSSNFormatNormal = "yes"
StructuredSSNFormatStripped disabled
ScanHTML = "yes"
ScanOLE2 = "yes"
OLE2BlockMacros disabled
ScanPDF = "yes"
ScanArchive = "yes"
ArchiveBlockEncrypted disabled
MaxScanSize = "104857600"
MaxFileSize = "26214400"
MaxRecursion = "16"
MaxFiles = "1"
ClamAuth disabled
ClamukoScanOnAccess disabled
ClamukoScannerCount = "3"
ClamukoScanOnOpen disabled
ClamukoScanOnClose disabled
ClamukoScanOnExec disabled
ClamukoIncludePath disabled
ClamukoExcludePath disabled
ClamukoExcludeUID disabled
ClamukoMaxFileSize = "5242880"
DevACOnly disabled
DevACDepth disabled
DevLiblog disabled

Config file: freshclam.conf
---
LogFileMaxSize = "4294967295"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_LOCAL6"
LogVerbose disabled
PidFile = "/var/run/clamav/freshclam.pid"
DatabaseDirectory = "/var/lib/clamav"
Foreground disabled
Debug disabled
AllowSupplementaryGroups disabled
UpdateLogFile = "/var/log/clamav/freshclam.log"
DatabaseOwner = "clamav"
Checks = "24"
DNSDatabaseInfo = "current.cvd.clamav.net"
DatabaseMirror = "db.local.clamav.net", "database.clamav.net"
MaxAttempts = "5"
ScriptedUpdates = "yes"
TestDatabases = "yes"
CompressLocalDatabase disabled
ExtraDatabase disabled
DatabaseCustomURL disabled
HTTPProxyServer disabled
HTTPProxyPort disabled
HTTPProxyUsername disabled
HTTPProxyPassword disabled
HTTPUserAgent disabled
NotifyClamd = "/etc/clamav/clamd.conf"
OnUpdateExecute disabled
OnErrorExecute disabled
OnOutdatedExecute disabled
LocalIPAddress disabled
ConnectTimeout = "30"
ReceiveTimeout = "30"
SubmitDetectionStats disabled
DetectionStatsCountry disabled
DetectionStatsHostID disabled
SafeBrowsing disabled
Bytecode = "yes"

Config file: clamav-milter.conf
---
LogFile = "/var/log/clamav/clamav-milter.log"
LogFileUnlock disabled
LogFileMaxSize = "10485760"
LogTime = "yes"
LogSyslog disabled
LogFacility = "LOG_MAIL"
LogVerbose disabled
PidFile = "/var/run/clamav/clamav-milter.pid"
TemporaryDirectory = "/var/tmp"
FixStaleSocket = "yes"
MaxThreads = "10"
ReadTimeout = "120"
Foreground disabled
User = "clamav"
AllowSupplementaryGroups = "yes"
MaxFileSize = "26214400"
ClamdSocket = "/var/run/clamav/clamd.ctl"
MilterSocket = "inet6:7357@::1"
MilterSocketGroup = "clamav"
MilterSocketMode = "660"
LocalNet = "local"
OnClean = "Accept"
OnInfected = "Reject"
OnFail = "Defer"
RejectMsg disabled
AddHeader = "Replace"
ReportHostname disabled
VirusAction disabled
Chroot disabled
Whitelist disabled
SkipAuthenticated disabled
LogInfected = "Full"
LogClean = "Basic"

Software settings
-
Version: 0.97.8
Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 
JIT

Database information

Database directory: /var/lib/clamav
bytecode.cld: version 228, sigs: 43, built on Fri Oct  4 22:37:48 2013
main.cld: version 55, sigs: 2424225, built on Tue Sep 17 16:57:28 2013
daily.cld: v

Bug#727691: (no subject)

[Gianfranco Costamagna]

> Il Martedì 29 Ottobre 2013 10:23, Robert Lemmen  ha 
> scritto:

> > On Tue, Oct 29, 2013 at 08:50:05AM +, Gianfranco Costamagna wrote:
>>  >because of this, libcheck is shipped as a *static only* library, which
>>  >means you can still link against it and don't have to include 
> libcheck
>>  >*code* in your project. the static library is called liobcheck.a, and a
>>  >typical linker invocation involves "-static" to tell the 
> linker about
>>  >the fact that you want to link statically.
>> 
>>  Thanks, I tried, but I'm still having linking problems.
>>  (I don't know why travis-ci succeedes, while I have problems on my 
> computer
> 
> hmm, can you tell me in detail what you are doing (i.e. linker
> invocation) and what error message you are getting?
> 

Ok I found and fixed the problem.

The problem was that (seems to be a fault in debian/check build), check wasn't 
linked against pthread, math and time.
this commit fixed the problem
https://github.com/LocutusOfBorg/ettercap/commit/a8d67aa64ecea865971105fff1256de7ecf749cc

I had some of this kind of problem with the switch from eglibc 2.15 to eglibc 
2.17, I had to add manually some pthread or math somewhere in the makefiles on 
various debian programs, because the libraries weren't automatically linked (I 
never looked deeply at this kind of issues).

can this be fixed on check side?

>>  Sorry I didn't undestand this part, the pourpose of check is to include 
> tests on a particular software right?
>> 
>>  what we do is:
>>  - build ettercap,
>>  - build tests (linked against check)
>>  - run tests.
>> 
>>  so check is not linked against ettercap, but only against test code, and it 
> isn't shipped with any installer, is just for running testsuites.
>> 
>>  Do you have any better way for running tests on ettercap project?
> 
> no better suggestions, what you do sounds absolutely right. I just said
> that because a typical reason for people wanting a .so instead of a
> static lib si that they want to ship the test binary and are concerned
> about the size of it. and that's just not what unit tests are for...
> 
> 

Well, thanks for the explanation!

> regards  robert
> 
> -- 
> Robert Lemmen                              http://www.semistable.com 
>


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

Bug#717002: zsh: Update for git-buildpackage completion

[Guido Günther]

On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote:
> On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat  wrote:
> >  ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler  :
> >
> >> Git buildpackage has changed the preferred interface. I have taken a
> >> stab at updating the current completion into the new interface. I also
> >> took the time to add completion for the other gbp commands.
> >>
> >> Unfortunately my completion foo is quite limited, so they are not as
> >> good as they could be (multiple pq commands are allowed;
> >> cannot detect when to require a dsc or a package name in import-dsc and
> >> others).
> >>
> >> I still think the result is somewhat useful.
> >
> > It is working fine for me. Maybe this could be shipped with gbp instead?
> 
> GBP maintainers, would you mind adding this file to the gbp package?
> It's a start for a zsh completion, but it is already useful.

If somebody submits a patch I'd be happy to. I do wonder why you
hardcode the options though instead of parsing it from the command's
--help output?
Cheers,
 -- Guido


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

Bug#727676: ITP: gitignorer -- A simple utility that aids in the creation of .gitignore files.

[Guido Günther]

Hi,
On Mon, Oct 28, 2013 at 01:17:48PM -0700, Zach Latta wrote:
> You're absolutely right, it could.
> 
> Gitignorer fetches user-specified .gitignore templates from
> github.com/gitignore, concatenates them together, then writes them to a
> .gitignore file.

Is the above lacking a /github/ as github.com/github/gitignore ? 
>
> For example, if `gitignorer create java maven` is called,
> gitignorer will fetch the Java and Maven templates from
> github.com/github/gitignore, concatenate them together, and then write
> them to a .gitignore file.

I now understand what the tool does. Maybe the short description should
then be:

A utility to create .gitignore files based on github's gitignore

Or can it work with other tools?
Cheers,
 -- Guido


> 
> On Mon, Oct 28, 2013 at 11:37:54AM +0100, Guido Günther wrote:
> > Hi,
> > On Fri, Oct 25, 2013 at 02:28:42AM -0700, Zach Latta wrote:
> > > Package: wnpp
> > > Severity: wishlist
> > > Owner: Zach Latta 
> > > 
> > > * Package name: gitignorer
> > >   Version : 1.0.0
> > >   Upstream Author : Zach Latta 
> > > * URL : https://github.com/zachlatta/gitignorer
> > > * License : MIT
> > >   Programming Lang: Go
> > >   Description : A simple utility that aids in the creation of 
> > > .gitignore files.
> > > 
> > > Gitignore is a simple command-line utility that aids in the creation of
> > > .gitignore files.
> > 
> > Could the package description be imporved and explain _how_ it helps to
> > create the files? vim helps to create .gitignore files too, as does
> > echo.
> > Cheers,
> >  -- Guido
> > 
> > > 
> > > 
> > > -- 
> > > To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
> > > with a subject of "unsubscribe". Trouble? Contact 
> > > listmas...@lists.debian.org
> > > Archive: 
> > > http://lists.debian.org/20131025092842.13920.39658.report...@plato.zachlatta.com
> > > 
> 


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

Bug#714040: transition: glew

[Matteo F. Vescovi]

Control: retitle -1 transition: glew 1.10

Hi again!

On Tue, Jun 25, 2013 at 03:18:31PM +0200, Matteo F. Vescovi wrote:
> Update: after a quick rebuild against pure unstable, it seems like
> that even arb failure has to be considered as glew-related.

On July 22nd, 2013 a new upstream version (1.10.0) was released.
On October 27th, 2013 it has been uploaded to experimental suite.

Former FTBFS packages (arb and bino) in unstable now build fine against
this new version, as you can see at [1] and [2] respectively.

Following, the new ben file updated to track the transition for this new
stable release.

Thanks for your time and patience.


Ben file:

title = "glew";
is_affected = .depends ~ "libglew1.7" | .depends ~ "libglewmx1.7" | .depends ~ 
"libglew1.10" | .depends ~ "libglewmx1.10";
is_good = .depends ~ "libglew1.10" | .depends ~ "libglewmx1.10";
is_bad = .depends ~ "libglew1.7" | .depends ~ "libglewmx1.7";


[1] http://debomatic-i386.debian.net/experimental/pool/arb_5.5-4/
[2] http://debomatic-i386.debian.net/experimental/pool/bino_1.4.2-1/

-- 
Matteo F. Vescovi
Debian Maintainer
GnuPG KeyID: 0x83B2CF7A


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

Bug#728153: apt-cdrom should succeed if any drive succeeds

[John Ogness]

On 2013-10-28, David Kalnischkies  wrote:
>> If there are multiple CDROM drives, `apt-cdrom add` will abort with
>> an error if any of the drives do not contain a Debian CD. This is
>> particularly a problem if apt-cdrom happens to check a drive with no
>> CD first. Then it will abort without even searching the other drives.
>
> I am not sure if ignoring errors is really a good idea. Maybe the
> drive is empty or the CD has a million scratches, is upside down in
> the slot or other "valid" error cases a user should be notified about.

My main concerns are:

1. That apt-cdrom doesn't check all the drives before giving up.

2. That apt-cdrom returns error code even if it was successful with one
   of the drives.

The current behavior makes calling apt-cdrom very confusing if I have
multiple drives and have my CD in the "wrong" drive. Or debian-installer
(apt-setup) aborts with errors because apt-cdrom returns an error on one
of the drives, even if it succeeded on other.

> In any case, the patch doesn't apply as the code changed around 0.9.9.
> Is this version still not trying all drives before erroring out
> completely?

I will try this and post results.

> What we could do to collect the error messages without giving the
> Add() calls a hint that previous invocations failed is:
> _error->PushToStack() and the reverse _error->MergeWithStack().

I considered that as well. In the all-errors case this is definately a
good approach. But in the case where at least 1 drive succeeds, I
believe we should return success.

The manpage for apt-cdrom states:

"apt-cdrom is used to add *a* new CDROM to APTs list"

So as long as *a* CDROM was added, I think it should return success.

> If we are patching, there is similar code in DoIdent,
> so this probably needs to be patched, too.

Agreed. If 0.9.9 still has this problem I will address both in a new
patch.

John Ogness


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

Bug#718626: Acknowledgement (chromium: Cannot print to a file in the home directory)

[Martin Ziegler]

The trick also works here. Thanks!

Martin


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

Bug#728097: libcurlpp-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

* Ximin Luo , 2013-10-28, 14:11:
libcurlpp-dev is marked as "Multi-Arch: same", but the following file is 
architecture-dependent:


/usr/include/curlpp/Types.hpp

An example diff between i386 and amd64 is attached.


Are you sure you built this correctly?


I didn't build the package, buildds did.


Can you attach a build log?


The build log is in the usual place:
https://buildd.debian.org/status/fetch.php?pkg=curlpp&arch=i386&ver=0.7.3-3&stamp=1382628769

debian/patches/dont-install-config-h.patch would be the cause of this, but 
this file is unconditionally applied in all architectures, so I'm not sure 
how you ended up not applying it on i386.


Your clean target unapplies all the patches.

--
Jakub Wilk


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

Bug#728190: autopkgtest fails due to stderr output

[Martin Pitt]

Package: mafft
Version: 7.123-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hello,

Thanks for adding an autopkgtest to mafft! However, it currently fails
as it routinely writes stderr output which autopkgtest considers as
failure (unless you use the "allow-stderr" restriction):

| /tmp/mafft-7.123 $ adt-run --no-built-binaries ./ --- adt-virt-schroot sid
| [...]
| adt-run: & tree0t-with-example-data:  - - - - - - - - - - results - - - - - - 
- - - -
| tree0t-with-example-data FAIL status: 0, stderr: 
| adt-run: & tree0t-with-example-data:  - - - - - - - - - - stderr - - - - - - 
- - - -
| 
| nseq =  36
| distance =  local
| [...]

The attached patch is one proposal to route the progress output to a
temporary file and only write it to stderr if the test fails (to give
some details why it fails).

Thanks for considering,

Martin

-- 
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)
diff -Nru mafft-7.123/debian/changelog mafft-7.123/debian/changelog
--- mafft-7.123/debian/changelog2013-10-16 01:22:22.0 +0200
+++ mafft-7.123/debian/changelog2013-10-29 11:29:49.0 +0100
@@ -1,3 +1,9 @@
+mafft (7.123-1ubuntu1) trusty; urgency=low
+
+  * debian/tests/with-example-data: Don't write progress to stderr on success.
+
+ -- Martin Pitt   Tue, 29 Oct 2013 11:29:22 +0100
+
 mafft (7.123-1) unstable; urgency=low
 
   * New upstream version.
diff -Nru mafft-7.123/debian/tests/with-example-data 
mafft-7.123/debian/tests/with-example-data
--- mafft-7.123/debian/tests/with-example-data  2013-10-14 03:29:28.0 
+0200
+++ mafft-7.123/debian/tests/with-example-data  2013-10-29 11:29:15.0 
+0100
@@ -3,9 +3,11 @@
 MAFFT="mafft --thread 0"
 TESTDATADIR=/usr/share/doc/mafft/test/
 
-$MAFFT   $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.fftns2 -
-$MAFFT --maxiterate 100  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.fftnsi -
-$MAFFT --globalpair  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.gins1 -
-$MAFFT --globalpair --maxiterate 100 $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.ginsi -
-$MAFFT --localpair   $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.lins1 -
-$MAFFT --localpair --maxiterate 100  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.linsi -
+PF=$ADTTMP/progress
+
+$MAFFT --progress $PF   $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.fftns2 - || cat $PF >&2
+$MAFFT --progress $PF --maxiterate 100  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.fftnsi - || cat $PF >&2
+$MAFFT --progress $PF --globalpair  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.gins1 - || cat $PF >&2
+$MAFFT --progress $PF --globalpair --maxiterate 100 $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.ginsi - || cat $PF >&2
+$MAFFT --progress $PF --localpair   $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.lins1 - || cat $PF >&2
+$MAFFT --progress $PF --localpair --maxiterate 100  $TESTDATADIR/sample | diff 
$TESTDATADIR/sample.linsi - || cat $PF >&2

Bug#728191: RFA: assaultcube-data -- data files and documentation for AssaultCube

[Markus Koschany]

Package: wnpp
Severity: normal

We, the Debian Games Team, request an adopter for assaultcube because
nobody is actively working on this package. We would prefer that the
adopter maintained the packages as part of the Games Team but this is not a
requirement.

AssaultCube, formerly ActionCube, is a first-person-shooter based on
the game Cube. Set in a realistic looking environment, as far as
that's possible with this engine, while gameplay stays fast and
arcade. This game is all about team oriented multiplayer fun.


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

Bug#728194: RFA: enemylines7 -- first person 3d-shooter game

[Markus Koschany]

Package: wnpp
Severity: normal

We, the Debian Games Team, request an adopter for enemylines7 because
nobody is actively working on this package. We would prefer that the
adopter maintained the package as part of the Games Team but this is
not a requirement.


The package description is:
 Enemy Lines 7 is a single-player game. You have to shoot down enemy
 bombers threatening your city in a three-dimensional environment.


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

Bug#728192: geany-plugins: Plugins are not available via plugin-manager

[Oz Nahum Tiram]

Package: geany-plugins
Version: 1.23+dfsg-3
Severity: important

Dear Maintainer,

I installed geany-plugins and I did not see geany-pluginvc in the
plugin manger.
Hence I download the upstream package and installed it.

I noticed that upstream installed the plugins to:

  /usr/local/lib/geany/geanyvc.so

Whereas the debian package installed the file to

  /usr/lib/i386-linux-gnu/geany/geanyvc.so

I remove the upstream package and created a link :

sudo ln -vs  /usr/lib/i386-linux-gnu/geany/geanyvc.so
/usr/local/lib/geany/geanyvc.so

This made the vs plugin available.

So this issue can be relatively easily solved by:

  * Change the installed file path to the one expected by geany.
Probably violates Debian's policy.
  * Reconfigure geany to search for the plugin in Debian's path.
  * Create a link as part of the installation of the package,
remove the link if the package is removed.

Best Regards,

Oz


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

Kernel: Linux 3.10-3-686-pae (SMP w/1 CPU core)
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 geany-plugins depends on:
ii  geany-plugin-addons 1.23+dfsg-3
ii  geany-plugin-codenav1.23+dfsg-3
ii  geany-plugin-debugger   1.23+dfsg-3
ii  geany-plugin-devhelp1.23+dfsg-3
ii  geany-plugin-doc1.23+dfsg-3
ii  geany-plugin-extrasel   1.23+dfsg-3
ii  geany-plugin-gendoc 1.23+dfsg-3
ii  geany-plugin-geniuspaste1.23+dfsg-3
ii  geany-plugin-gproject   1.23+dfsg-3
ii  geany-plugin-insertnum  1.23+dfsg-3
ii  geany-plugin-latex  1.23+dfsg-3
ii  geany-plugin-lipsum 1.23+dfsg-3
ii  geany-plugin-lua1.23+dfsg-3
ii  geany-plugin-macro  1.23+dfsg-3
ii  geany-plugin-miniscript 1.23+dfsg-3
ii  geany-plugin-multiterm  1.23+dfsg-3
ii  geany-plugin-numberedbookmarks  1.23+dfsg-3
ii  geany-plugin-pg 1.23+dfsg-3
ii  geany-plugin-prettyprinter  1.23+dfsg-3
ii  geany-plugin-prj1.23+dfsg-3
ii  geany-plugin-latex  1.23+dfsg-3
ii  geany-plugin-lipsum 1.23+dfsg-3
ii  geany-plugin-lua1.23+dfsg-3
ii  geany-plugin-macro  1.23+dfsg-3
ii  geany-plugin-miniscript 1.23+dfsg-3
ii  geany-plugin-multiterm  1.23+dfsg-3
ii  geany-plugin-numberedbookmarks  1.23+dfsg-3
ii  geany-plugin-pg 1.23+dfsg-3
ii  geany-plugin-prettyprinter  1.23+dfsg-3
ii  geany-plugin-prj1.23+dfsg-3
ii  geany-plugin-sendmail   1.23+dfsg-3
ii  geany-plugin-shiftcolumn1.23+dfsg-3
ii  geany-plugin-spellcheck 1.23+dfsg-3
ii  geany-plugin-tableconvert   1.23+dfsg-3
ii  geany-plugin-treebrowser1.23+dfsg-3
ii  geany-plugin-updatechecker  1.23+dfsg-3
ii  geany-plugin-vc 1.23+dfsg-3
ii  geany-plugin-webhelper  1.23+dfsg-3
ii  geany-plugin-xmlsnippets1.23+dfsg-3

geany-plugins recommends no packages.

geany-plugins suggests no packages.

-- no debconf information

Bug#728193: RFA: assaultcube -- realistic first-person-shooter

[Markus Koschany]

Package: wnpp
Severity: normal

We, the Debian Games Team, request an adopter for assaultcube because
nobody is actively working on this package. We would prefer that the
adopter maintained the package as part of the Games Team but this is
not a requirement.

AssaultCube, formerly ActionCube, is a first-person-shooter based on
the game Cube. Set in a realistic looking environment, as far as
that's possible with this engine, while gameplay stays fast and
arcade. This game is all about team oriented multiplayer fun.

If you are interested in this package, please see also

http://bugs.debian.org/728191

for the assaultcube-data package.


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

Bug#246187: reassign to gnat-4.8

[Nicolas Boulenguez]

Followup-For: Bug #246187
Control: reassign -1 gnat-4.8 4.8.2-1
Control: retitle -1 Bug box, Storage_Error at system.ads:139:5 on legal program

4.8.2 (x86_64-linux-gnu) Storage_Error stack overflow or erroneous memory access
Error detected at system.ads:152:5


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

Bug#727818: mongodb-server: please, integrate changes from github

[Rogério Brito]

Hi there.

On Oct 29 2013, James Page wrote:
> On 28/10/13 12:53, László Böszörményi (GCS) wrote:
> > Then I plan to include systemd support and correct the copyright
> > file with the AGPL+OpenSSL license exception. Then MongoDB should
> > be built on all architectures[2] that V8 supports. I think these
> > are the most important changes needed to the packaging. James, what
> > do you think?
> 
> All sounds good to me. I have a couple of other things I would like to
> work in so that we can remove all of the Ubuntu delta:
> 
> 1) upstart configuration - this should co-exist with systemd and init
> scripts OK

That is great.

> 2) SSL enablement - this should be OK now with the license exception
> and is something we have in Ubuntu

Just curious, since I may have missed this (well, I said that I lost
motivation for a while): is there a license exception? That would be
superb. Otherwise, we could be 

> 3) -base package split for server; I have a specific requirement in
> another package for just the mongod/mongos binaries without the
> associated init scripts.

Since you brought these reorderings in question, I always felt that the way
that things were done did not have the "correct" taste. In particular:

* the point you bring about splitting the init scripts from the binaries
  would be super nice, especially given that when people want a sharded
  and/or replicated environment, our scripts get in the way.

* I am not so sure that I would like to have the mongodb-server
  hard-depending on the mongo-clients, unless mongod/mongos *depend* on the
  client programs. A recommends would be better, if they don't really depend
  (and I think that they don't).

* Also, having the package mongo pull in the development headers seems like
  a strange choice, given the rest of our repository. It might pull in
  mongodb-server and mongodb-clients, but I am not so sure about the -dev
  one.

  I just inspected (without following all the recursion) that mongodb-dev
  pulls in libboost-dev which pulls in (currently) libboost1.54-dev which
  pulls in a bunch of other headers.

  If the person that wants to compile a dependency stuff (say, via
  nodejs/npm), they would have to grab more things (like build-essential and
  so on) which, from a quick cursory look are pulled in.

> If you would like another co-maintainer I'd be happy to work directly
> in the git repository todo this work.

I would also like to contribute from time to time.

> Getting Rogerio's changes in for reducing the client package size
> would also be fantastic.

Thanks for the feedback.

I now feel that I deserve some public apologies to the Ubuntu maintainers of
mongodb: they were doing the right thing, but we had in Debian people that
were slowing down the progress of things.


Thanks again,

-- 
Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFC
http://cynic.cc/blog/ : github.com/rbrito : profiles.google.com/rbrito
DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br


signature.asc
Description: Digital signature

Bug#727234: (no subject)

[Ross Gammon]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

retitle 727234 gramps: New Upstream Version 3.4.6
thanks

Okay, the next Gramps in the 3.4.x series (3.4.6) was released
yesterday, so we should switch to that instead of 3.4.5.

Regards,

Ross
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJSb5aZAAoJEFP+e72miRD8QukQAJJutvrcYlybS7PXzmRb4S+g
v7Nrp03cW0RsKUqsJrvsSZtz9G6AprSyPpzta3IRiuMpFz4vPOmW765PzPQTMsw8
CDi7FwAK698OOUhs8uNQNpgz5vhBFaL2rkfw+GlHx6o9hWsiZwWGqzXg62iqKaj5
s4adbL9cfOZlFLvyFKp8JGwDuBHpuQCkXKQGRZLvUShpAbbD7WY4Z96tw9NQkGcF
hF41gTou94TR7111hlXHIlOBCTVPk788QXn4WnrJ77p9XqzJ6SlxFB/Poy1ty2Ha
hed0RZ/KsOT+mohQAFbgT87o1HQrx45emnti0MPd5oP4Jo0vfBRyFpppDToVFCDf
/S4kgZaTSNf1LOGUn/2vMAw755YBHnYfzEdbSgQE/bxnWFfc0uxk+Xvx6I9xe+l3
EHc76/rUHl65+FODMqjZA1KEbF7MsvsjXvludR2rxcK0FGOZW/Ab9MGAv0J+Glit
We3p1ZKD+QSDa2b5O/v6F7GlljIBqZY49WO0VYPcHNh5X3lR6JdMsx91QNpIgwVB
5QP998bLJTEsGV6dMvcujWrWU7J30cfEi9d7+NX4/pxiNfA60yBV1E6SSqMCku/D
svkBLsQimbroKbsIeNKAXd1PwTZALI4yWaINtxQ/SeoZ2j50yOiaOBKvkb/z9PeQ
xDpkNiR0z6sOxoWPKPYs
=tiU0
-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#247564: reassign to gnat-4.8

[Nicolas Boulenguez]

Control: reassign -1 gnat-4.8 4.8.2-1
Control: retitle -1 Bug box on legal program in gnat_to_gnu_entity, at 
ada/gcc-interface/decl.c

4.8.2 (x86_64-linux-gnu) GCC error:
in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:582
Error detected at test_70.adb:18:9


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

Bug#727708: FYI: upstream’s take

[Andreas Barth]

* Russ Allbery (r...@debian.org) [131029 03:15]:
> Michael Stapelberg  writes:
> 
> > my apologies for not replying to any messages within the thread, but I
> > think my mail is orthogonal to the other messages.
> 
> > Lennart Poettering wrote about the systemd upstream point of view on the
> > discussion we are currently having:
> > https://plus.google.com/115547683951727699051/posts/8RmiAQsW9qf
> 
> This is a valuable post.  Thank you for the pointer!  I would be
> interested in seeing the two core technical arguments there (cgroup
> handling and how D-Bus services are handled) addressed by the upstart
> position paper, particularly if there are plans that Lennart isn't aware
> of for how that functionality will be provided.

I'm wondering how much libcgroup matches (or not) the role of cgroup
handling - I use that in a different environment quite successfully,
but that might be just me and not the full answer for everybody.



Andi


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

Bug#251265: reassign to gnat-4.8

[Nicolas Boulenguez]

Control: reassign -1 gnat-4.8 4.8.2-1
Control: retitle -1 Bug box in Case_Statement_to_gnu, at 
ada/gcc-interface/trans.c:2198, on legal Ada 83 program

4.8.2 (x86_64-linux-gnu) GCC error
in Case_Statement_to_gnu, at ada/gcc-interface/trans.c:2198
Error detected at test_106.adb:4:9


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

Bug#728195: libmbim-glib-dev: arch-dependent files in "Multi-Arch: same" package

[Jakub Wilk]

Package: libmbim-glib-dev
Version: 1.4.0-1
Severity: important
User: multiarch-de...@lists.alioth.debian.org
Usertags: multiarch

libmbim-glib-dev is marked as "Multi-Arch: same", but the following files are 
architecture-dependent:


/usr/share/gtk-doc/html/libmbim-glib/MbimDevice.html
/usr/share/gtk-doc/html/libmbim-glib/MbimMessage.html
/usr/share/gtk-doc/html/libmbim-glib/annotation-glossary.html
/usr/share/gtk-doc/html/libmbim-glib/api-index-full.html
/usr/share/gtk-doc/html/libmbim-glib/ch01.html
/usr/share/gtk-doc/html/libmbim-glib/ch02.html
/usr/share/gtk-doc/html/libmbim-glib/deprecated-api-index.html
/usr/share/gtk-doc/html/libmbim-glib/index.html
/usr/share/gtk-doc/html/libmbim-glib/index.sgml
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Auth.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Basic-Connect.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Command-IDs.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Common-utilities.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-DSS.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Enumerations-and-Flags.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Errors.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Phonebook.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-SMS.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-STK.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-USSD.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-UUIDs.html
/usr/share/gtk-doc/html/libmbim-glib/libmbim-glib-Version-checks.html
/usr/share/gtk-doc/html/libmbim-glib/object-tree.html

An example diff between i386 and amd64 is attached.

--
Jakub Wilk
diff -ur 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/MbimDevice.html
 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/MbimDevice.html
--- 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/MbimDevice.html
   2013-10-28 18:13:44.0 +0100
+++ 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/MbimDevice.html
  2013-07-17 11:42:13.0 +0200
@@ -8,7 +8,7 @@
 
 
 
-
+
 
 
 
@@ -710,6 +710,6 @@
 
 
 
-  Generated by GTK-Doc V1.19
+  Generated by GTK-Doc V1.18
 
 
\ No newline at end of file
diff -ur 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/MbimMessage.html
 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/MbimMessage.html
--- 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/MbimMessage.html
  2013-10-28 18:13:44.0 +0100
+++ 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/MbimMessage.html
 2013-07-17 11:42:13.0 +0200
@@ -8,7 +8,7 @@
 
 
 
-
+
 
 
 
@@ -1388,6 +1388,6 @@
 
 
 
-  Generated by GTK-Doc V1.19
+  Generated by GTK-Doc V1.18
 
 
\ No newline at end of file
diff -ur 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/annotation-glossary.html
 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/annotation-glossary.html
--- 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/annotation-glossary.html
  2013-10-28 18:13:44.0 +0100
+++ 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/annotation-glossary.html
 2013-07-17 11:42:13.0 +0200
@@ -7,7 +7,7 @@
 
 
 
-
+
 
 
 
@@ -20,25 +20,25 @@
  
 
 
-T
+O
   | 
-   O
+   T
 
 
 
 
 Annotation Glossary
-T
-transfer none
-Don't free data after the code is done.
-transfer full
-Free data after the code is done.
 O
 out
 Parameter for returning results. Default is transfer 
full.
+T
+transfer full
+Free data after the code is done.
+transfer none
+Don't free data after the code is done.
 
 
 
-  Generated by GTK-Doc V1.19
+  Generated by GTK-Doc V1.18
 
 
\ No newline at end of file
diff -ur 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/api-index-full.html
 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/api-index-full.html
--- 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/api-index-full.html
   2013-10-28 18:13:44.0 +0100
+++ 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/api-index-full.html
  2013-07-17 11:42:13.0 +0200
@@ -8,7 +8,7 @@
 
 
 
-
+
 
 
 
@@ -1440,6 +1440,6 @@
 
 
 
-  Generated by GTK-Doc V1.19
+  Generated by GTK-Doc V1.18
 
 
\ No newline at end of file
diff -ur 
libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/ch01.html 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/ch01.html
--- libmbim-glib-dev_1.4.0-1_i386/usr/share/gtk-doc/html/libmbim-glib/ch01.html 
2013-10-28 18:13:44.0 +0100
+++ 
libmbim-glib-dev_1.4.0-1_amd64/usr/share/gtk-doc/html/libmbim-glib/ch01.html
2013-07-17 11:42:13.0 +0200
@@ -8,7 +8,7 @@
 
 
 
-
+
 
 
 
@@ -21,7 +21,7 @@
 
 
 
-Core
+Core
 
 

Bug#652003: Fwd: Ticket #961

[bertagaz]

Hi,

On Mon, Oct 28, 2013 at 03:53:25AM +, Zooko O'Whielacronx wrote:
> Dear bertagaz:
> 
> • Re: line 50 ² this reminds me of Tahoe-LAFS ticket #725 (“We should
> whine if we're running as root.”) ³. I don't suggest any change to the
> tahoe-lafs.init script, but it makes me wonder if #725 should be
> hardened to "exit with an error if we're running as root".
> 
> ² 
> http://anonscm.debian.org/gitweb/?p=tahoe/tahoe.git;a=blob;f=debian/tahoe-lafs.init;h=352ee7581a9a1f52ada75e791f542fda4f68ea59#l50
> ³ https://tahoe-lafs.org/trac/tahoe-lafs/ticket/725# We should whine
> if we're running as root.

That's interesting, I'll reply on the trac ticket. :)

> This also means that if tahoe-lafs.init attempts to stop
> multiple nodes, and one or more of those nodes was already
> not-running, then the exit code from tahoe-lafs.init will be non-zero,
> since attempting to stop a not-running node results in a non-zero exit
> code. All of this sounds fine to me! The only change I would suggest
> is to put a comment at the top of the file stating this. ☺ Also, would
> it be appropriate to have the usage printout include a statement of
> this behavior?

I can add a comment in the initscript before mailing micah for him to
upload the new package. The usage printout should remain short IMO so I
believe it might not be the best place to put it.

> • Other than that suggestion to add documentation (in the form of a
> comment and/or usage printout), I see no problem in this script. It is
> much shorter than earlier versions, thanks to the refactoring of
> start, restart, and stop into the same code and the delegation of more
> functionality to the underlying "tahoe" script, so it was much faster
> to read through it, which hopefully means it will get better
> review/auditing/debugging in the future.

Yeah, this script has matured a lot, collective development rocks! :)

Thanks for all your feedbacks anyway, I'm very pleased all of you
participate.

bert.


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

Bug#728097: libcurlpp-dev: arch-dependent file in "Multi-Arch: same" package

[Ximin Luo]

On 29/10/13 10:24, Jakub Wilk wrote:
> * Ximin Luo , 2013-10-28, 14:11:
>>> libcurlpp-dev is marked as "Multi-Arch: same", but the following file is
>>> architecture-dependent:
>>>
>>> /usr/include/curlpp/Types.hpp
>>>
>>> An example diff between i386 and amd64 is attached.
>>
>> Are you sure you built this correctly?
> 
> I didn't build the package, buildds did.
> 
>> Can you attach a build log?
> 
> The build log is in the usual place:
> https://buildd.debian.org/status/fetch.php?pkg=curlpp&arch=i386&ver=0.7.3-3&stamp=1382628769
> 

Thanks, I'll take a look.

>> debian/patches/dont-install-config-h.patch would be the cause of this, but
>> this file is unconditionally applied in all architectures, so I'm not sure
>> how you ended up not applying it on i386.
> 
> Your clean target unapplies all the patches.
> 

That is still done independently of architecture, so I don't see why that would
cause this bug.

I don't believe it's incorrect to un-apply the patches during a clean, since
the build process is supposed to restore them. The normal developer tools work
this way:

man dpkg-buildpackage:

   3. If a specific target has been selected with the -T or --target
option, it calls that target and stops here. Otherwise it calls fakeroot
debian/rules clean to clean the build-tree (unless -nc is specified).

   4. It calls dpkg-source -b to generate the source package (unless a
binary-only build has been requested with -b, -B or -A).

man dpkg-source:

   Note: dpkg-source --before-build (and -b) will ensure that all patches
listed in the series file are applied so that a package build always has all
patches applied. It does this by finding unapplied patches (they are listed in
the series file but not in
   .pc/applied-patches), and if the first patch in that set can be applied
without errors, it will apply them all. The option --no-preparation can be used
to disable this behavior.

If buildd's behaviour differs from this, I consider it a bug of buildd and not
this package - I can't be expected to have a copy of the entire Debian build
infrastructure in order to maintain packages.

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#339356: fixed in gnat-4.8

[Nicolas Boulenguez]

Control: retitle -1 [Fixed in 4.8] Assert_Failure atree.adb:794 on invalid code 
(mixture of protected object and accept of entry family)

4.8.2-1 correctly detects the error:
gnat_bug.adb:13:10: enclosing body of accept must be a task


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

Bug#726988: findbugs: fails to build from source

[Ronny Standtke]

Hi Tony

> It appears that you're trying to build the package before the debian
> patches are applied.  debian/patches/0001-fix-ant-docs.patch patches
> build.xml such that you shouldn't see that path during the build.
>
> I'm not able to reproduce the build failure here.

You can reproduce the issue by trying to build the package with "debuild
-nc".
When calling "./debian/rules clean" in advance, the build failure is gone.

Regards

Ronny


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

Bug#728177: debcommit -r with darcs fails if the repo is clean

[James McCoy]

On Tue, Oct 29, 2013 at 09:02:56AM +0100, Joachim Breitner wrote:
> like with git, debcommit -r should only call “darcs record” if the repo
> is not clean, otherwise it fails.

Thanks for noticing and fixing.

> I noticed that debscripts is now in collab-maint. Please let me know if
> I should commit my patch myself.

Sure, go ahead and commit.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Bug#494945: fixed in gnat-4.8

[Nicolas Boulenguez]

Control: retitle -1 [Fixed in 4.8] Assert_Failure at atree.adb:886 caused by 
legal prefixed notation

Both triggers produce the expected behaviour with 4.8.2-1:
gcc-4.8 -c trigger1.adb
gcc-4.8 -c p.ads
cannot generate code for file p.ads (package spec)
gnatmake: "p.ads" compilation error


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

Bug#717002: zsh: Update for git-buildpackage completion

[Frank Terbeck]

Hey,

with my pkg-zsh hat on, here are some thoughts:

Guido Günther wrote:
> On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote:
>> On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat  wrote:
>> >  ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler  :
[...]
>> >> Unfortunately my completion foo is quite limited, so they are not as
>> >> good as they could be (multiple pq commands are allowed;
>> >> cannot detect when to require a dsc or a package name in import-dsc and
>> >> others).
>> >>
>> >> I still think the result is somewhat useful.
>> >
>> > It is working fine for me. Maybe this could be shipped with gbp instead?

The three options are: a) Shipping the completion separately (which is
the worst possible solution; b) have it shipped with gbp; and c) have it
shipped with zsh.

Upstream zsh welcomes additions to the pool of available completion
functions. Debian already has its own sub-directory within that pool, so
adding ‘_gbp’ to that pool would be a natural thing to do. The advantage
of that would be, that knowledgeable eyes at least scan the code you
submit. On the flip-side, you'd have to regularly sync your version of
the completion with zsh's repository, because nobody gains anything from
massively outdated completion functions.


>> GBP maintainers, would you mind adding this file to the gbp package?
>> It's a start for a zsh completion, but it is already useful.

If you choose to ship ‘_gbp’ with gbp itself, the advantage would be
that you'd ship a completion that always exactly matches the command
line interface of the software - if you keep the completion up to date.

Debian's zsh package provides an $fpath entry for other packages to drop
completion function files into. That entry was introduced to
specifically support completions that are shipped with the target
software rather than with upstream zsh. That directory would be:

  /usr/share/zsh/function/vendor-completions

For completeness, if you want to ship non-completion functions, the
directory to use would be:

  /usr/share/zsh/function/vendor-functions


> If somebody submits a patch I'd be happy to. I do wonder why you
> hardcode the options though instead of parsing it from the command's
> --help output?

The idea is usually to provide context-specific completion depending on
the option-set. That's why you often need to name the options anyway
since the following code-paths depend on them. By context-sensitive, I
mean for example, with git's completion, "git add " only shows
files that are not .gitignored and either not tracked yet or contain
changes. To identify that context, the completion needs to know about
‘add’.

Those are my 2¢.

Regards, Frank


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

Bug#725828: ITP: netmate -- netdude clone that shows pcap dump lines in network header style

[Eriberto]

Package done. Waiting for adjustmensts from upstream.

Thanks


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

Bug#728097: libcurlpp-dev: arch-dependent file in "Multi-Arch: same" package

[Jakub Wilk]

* Ximin Luo , 2013-10-29, 11:45:
debian/patches/dont-install-config-h.patch would be the cause of this, but 
this file is unconditionally applied in all architectures, so I'm not sure 
how you ended up not applying it on i386.


Your clean target unapplies all the patches.


That is still done independently of architecture, so I don't see why that 
would cause this bug.


I don't believe it's incorrect to un-apply the patches during a clean, since 
the build process is supposed to restore them. The normal developer tools work 
this way:


man dpkg-buildpackage:

3. If a specific target has been selected with the -T or --target option, it 
calls that target and stops here. Otherwise it calls fakeroot debian/rules 
clean to clean the build-tree (unless -nc is specified).


4. It calls dpkg-source -b to generate the source package (unless a 
binary-only build has been requested with -b, -B or -A).


buildds do request binary-only build (using the -B option), so dpkg-source 
is not called, therefore patches are not applied.


--
Jakub Wilk


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

Bug#728097: libcurlpp-dev: arch-dependent file in "Multi-Arch: same" package

[Ximin Luo]

On 29/10/13 11:45, Ximin Luo wrote:
> On 29/10/13 10:24, Jakub Wilk wrote:
>> Your clean target unapplies all the patches.
>>
> 
> That is still done independently of architecture, so I don't see why that 
> would
> cause this bug.
> 
> I don't believe it's incorrect to un-apply the patches during a clean, since
> the build process is supposed to restore them. The normal developer tools work
> this way:
> 
> man dpkg-buildpackage:
> 
>3. If a specific target has been selected with the -T or --target
> option, it calls that target and stops here. Otherwise it calls fakeroot
> debian/rules clean to clean the build-tree (unless -nc is specified).
> 
>4. It calls dpkg-source -b to generate the source package (unless a
> binary-only build has been requested with -b, -B or -A).
> 

I had a look and the bug symptom is due to buildd doing a binary-only build
which bypasses `dpkg-source -b` re-applying the patches.

Reading the documentation, it seems that the applied patches are strictly "part
of the source package". So you are right that I ought not to be calling
`dh_quilt_apply` and `dh_quilt_unapply`. However, the reason why I did this in
the first place, is because `debuild clean` does not detect an unpatched source
tree (which strictly is *not* the correct source package).

man debuild:

   An alternative way of using debuild is to use one or more of the
parameters binary, binary-arch, binary-indep and clean, in which case debuild
will attempt to gain root privileges and then run debian/rules with the given
parameters.

Therefore I will file a bug for `debuild` in addition to fixing my clean
target. There might be other tools that fail to properly check when the patches
are applied, please let me know about them. (`dpkg-buildpackage` does do this,
since it calls `dpkg-source --before-build` unconditionally.)

> man dpkg-source:
> 
>Note: dpkg-source --before-build (and -b) will ensure that all patches
> listed in the series file are applied so that a package build always has all
> patches applied. It does this by finding unapplied patches (they are listed in
> the series file but not in
>.pc/applied-patches), and if the first patch in that set can be applied
> without errors, it will apply them all. The option --no-preparation can be 
> used
> to disable this behavior.
> 
> If buildd's behaviour differs from this, I consider it a bug of buildd and not
> this package - I can't be expected to have a copy of the entire Debian build
> infrastructure in order to maintain packages.
> 

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728196: php-gearman is licensed under the PHP license, and is not php

[Paul Tagliamonte]

Package: php-gearman
Severity: serious
User: paul...@debian.org
Usertags: ftp
X-Debbugs-CC: ftpmas...@ftp-master.debian.org
thanks

From the REJECT faq:

/
| You have a PHP add-on package (any php script/"app"/thing, not PHP
| itself) and it's licensed only under the standard PHP license. That
| license, up to the 3.x which is actually out, is not really usable for
| anything else than PHP itself. I've mailed our -legal list about that
| and got only one response, which basically supported my view on this.
| Basically this license talks only about PHP, the PHP Group, and includes
| Zend Engine, so its not applicable to anything else. And even worse,
| older versions include the nice ad-clause.
| 
| One good solution here is to suggest a license change to your upstream,
| as they clearly wanted a free one. LGPL or BSD seems to be what they
| want.
\

Sorry this made it through NEW,


Hope you're well, and thanks for your work,
  Paul

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / 8F04 9AD8 2C92 066C 7352  D28A 7B58 5B30 807C 2A87
 `- http://people.debian.org/~paultag


signature.asc
Description: Digital signature

Bug#579920: fixed in gnat-4.8

[Nicolas Boulenguez]

Control: retitle -1 [Fixed in 4.8] Assert_Failure sinfo.adb:2738

4.8.2-1 produces the expected result:
a.ads:10:10: unmatched actual "Foo"
a.ads:10:10: in instantiation of "B" declared at line 5


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

Bug#728197: Low entropy for encrypted swap partition

[Milan Kral]

Package: cryptsetup
Version: 2:1.6.1-1
Severity: important


Dear Maintainer,
I have added encrypted swap partition to /etc/crypttab exactly as
recommended in /usr/share/doc/cryptsetup/README.Debian.gz

cswap1 /dev/hdc1  /dev/urandom   
swap,cipher=aes-cbc-essiv:sha256,size=256,hash=sha256

The problem is that in /etc/rcS.d  the scripts S07cryptdisks-early,
S09cryptdisks are run before S13urandom. We are trying to read from
/dev/urandom before the Linux random number generator is properly
seeded. This can lead to predictable encryption key for the swap partition.

One solution would be to move S13urandom to S06urandom, but then the
random seed file /var/lib/urandom/random-seed  muss be present before
mounting crypto partitions.

Please see also the comment "*2.2 How do I set up encrypted swap?"*

https://code.google.com/p/cryptsetup/wiki/FrequentlyAskedQuestions#2._Setup

Again, the problem is that S13urandom is run only after S09cryptdisks




signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Ximin Luo]

Package: devscripts
Version: 2.13.4
Severity: important

It does not make sense to build or clean an unpatched source tree, since the
applied patches are considered strictly *part of the source package*. However,
`debuild build/clean`, and probably many other tools, still allows this to
happen without any warning.

This is partly a fault of policy which is very loose on what is a correct state
to initiate build actions from; I will file a separate bug for that too.

http://www.debian.org/doc/debian-policy/ch-source.html

-- Package-specific info:

--- /etc/devscripts.conf ---

--- ~/.devscripts ---
Not present

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

Kernel: Linux 3.10-3-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 devscripts depends on:
ii  dpkg-dev 1.16.12
ii  libc62.17-93
ii  perl 5.18.1-4
ii  python3  3.3.2-17
pn  python3:any  

Versions of packages devscripts recommends:
ii  at3.1.14-1
ii  curl  7.32.0-1
ii  dctrl-tools   2.23
ii  debian-keyring2013.07.31
ii  dput  0.9.6.4
ii  equivs2.0.9
ii  fakeroot  1.18.4-2
ii  gnupg 1.4.15-1.1
ii  libcrypt-ssleay-perl  0.58-1+b1
ii  libdistro-info-perl   0.11
ii  libencode-locale-perl 1.03-1
ii  libjson-perl  2.59-1
ii  libparse-debcontrol-perl  2.005-4
ii  libsoap-lite-perl 0.716-1
ii  liburi-perl   1.60-1
ii  libwww-perl   6.05-1
ii  lintian   2.5.19
ii  man-db2.6.5-2
ii  patch 2.7.1-3
ii  patchutils0.3.2-2
ii  python3-debian0.1.21+nmu2
ii  python3-magic 1:5.14-2
ii  sensible-utils0.0.9
ii  strace4.5.20-2.3
ii  unzip 6.0-9
ii  wdiff 1.1.2-1
ii  wget  1.14-4
ii  xz-utils  5.1.1alpha+20120614-2

Versions of packages devscripts suggests:
ii  bsd-mailx [mailx]8.1.2-0.20131005cvs-1
ii  build-essential  11.6
pn  cvs-buildpackage 
pn  devscripts-el
ii  gnuplot  4.6.3-2
ii  gpgv 1.4.15-1.1
ii  heirloom-mailx [mailx]   12.5-2
ii  libauthen-sasl-perl  2.1500-1
ii  libfile-desktopentry-perl0.07-1
ii  libnet-smtp-ssl-perl 1.01-3
pn  libterm-size-perl
ii  libtimedate-perl 1.2000-1
ii  libyaml-syck-perl1.27-2+b1
ii  mutt 1.5.21-6.4
ii  openssh-client [ssh-client]  1:6.2p2-6
pn  svn-buildpackage 
ii  w3m  0.5.3-11

-- 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#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Ximin Luo]

On 29/10/13 12:14, Ximin Luo wrote:
> Package: devscripts
> Version: 2.13.4
> Severity: important
> 
> It does not make sense to build or clean an unpatched source tree, since the
> applied patches are considered strictly *part of the source package*. However,
> `debuild build/clean`, and probably many other tools, still allows this to
> happen without any warning.
> 
> This is partly a fault of policy which is very loose on what is a correct 
> state
> to initiate build actions from; I will file a separate bug for that too.
> 
> http://www.debian.org/doc/debian-policy/ch-source.html
> 

To clarify, I'm talking about the source format 3.0 (quilt), where the
application of patches is considered to be the responsibility of dpkg-source
rather than the build process itself.

If this basic check isn't done, bugs like this [1] happen to developers that
don't know about all the precise details of how build infrastructure works.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728097

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#728180: gdm3: service gdm3 stop leaves lots of processes running, preventing restart or start of other dm

[Simon McVittie]

On 29/10/13 08:23, Johannes Rohr wrote:
> Package: gdm3
> Version: 3.8.4-3
> Severity: normal
> 
> After running service gdm3 stop I still see a host of related processes 
> running

Is your process 1 systemd, or sysvinit, or something else?

If you're using a non-systemd init, gdm 3.8 might be relying on
systemd's "kill the entire cgroup" behaviour to have these processes
killed correctly - which would still be a bug, but it's probably
relevant/useful information for fixing it.

S


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

Bug#427108: reassign to gnat-4.8

[Nicolas Boulenguez]

Control: reassign -1 gnat-4.8 4.8.2-1
Control: retitle -1 Bug box Program_Error exp_disp.adb:8445 explicit raise

The same source now causes a compiler crash instead of an incorrect
executable.

gcc-4.8 -c test1.adb
+===GNAT BUG DETECTED==+
| 4.8.2 (x86_64-linux-gnu) Program_Error exp_disp.adb:8445 explicit raise  |
| Error detected at test1.adb:21:4 |


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

Bug#655558: fixed in gnat-4.8

[Nicolas Boulenguez]

Control: reassign -1 gnat-4.4
Control: retitle -1 [Fixed in 4.6, 4.8] Complains about missing "with", even 
when it is there

4.8.2-1 produces the expected empty output.


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

Bug#727782: [Pkg-samba-maint] Bug#727782: samba: FTBFS due to several file list mismatches

[Jelmer Vernooij]

On Mon, Oct 28, 2013 at 08:40:19PM +, Thorsten Glaser wrote:
> Jelmer Vernooij dixit:
> 
> >Can you provide the config.log from the Samba4 build? Configure tries
> >to run this exact command, and for some reason it failed there.
> 
> Not from that exact build (any more), sorry. But I???m re-running it
> and will get back to you on this.

Thanks!

Note that it succesfully built on all other archs except for hurd-i386 (where
not all dependencies are available). 

https://buildd.debian.org/status/package.php?p=samba

Cheers,

Jelmer


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

Bug#728200: debian-policy: force build tools to ensure source trees are build-ready

[Ximin Luo]

Package: debian-policy
Severity: important

I was recently hit by this bug [1] which stems from inconsistent assumptions
that various build tools have about the state of the build tree. I filed [2]
to devscripts to suggest a fix.

However, policy wording could be better in this area, and it is especially not
helpful for Section 4.14 [3] to effectively give free reign to the maintainer
to make arbitrary instructions on how to take the source tree from an unpacked
state to a build-ready state. (How does this even work with buildd??? Did you
guys solve NLP???)

I would suggest policy make explicit definitions for the terms "unpacked" state
vs "build-ready" state, and force build tools to detect and reject performing
`debian/rules` actions on source trees that are not "build-ready". It just
doesn't make sense for this to happen, no good result can come out of it.

Or probably better, the build-tool can simply make the source tree build-ready
by running `dpkg-source --before-build` or `debian/rules patch` before running
other debian/rules actions. (This also requires "patch" to be idempotent.)

To keep consistency with how "clean" interacts with 3.0 (quilt) patches and
`dpkg-source --before-build`, we would also need to specify that "clean" does
not undo "patch".

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728097
[2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=728198
[3] http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource

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

Kernel: Linux 3.10-3-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#728199: fails to upgrade: ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': File exists

[Thijs Kinkhorst]

Package: dokuwiki
Version: 0.0.20130510a-2
Severity: serious

Hi,

dokuwiki fails to upgrade, and exits the upgrade with an error.
Turning set -x on in postinst, this is what happens:

+ [ -e /etc/apache2/conf.d/dokuwiki.conf ]
+ [ -d /etc/apache2/conf-available -a ! -e 
/etc/apache2/conf-available/dokuwiki.conf ]
+ ln -s /etc/dokuwiki/apache.conf /etc/apache2/conf-available/dokuwiki.conf
ln: failed to create symbolic link '/etc/apache2/conf-available/dokuwiki.conf': 
File exists
dpkg: error processing dokuwiki (--configure):
 subprocess installed post-installation script returned error exit status 1

The code fails because /etc/apache2/conf.d/dokuwiki.conf, the link target,
does not exist (it is removed in the same script) and therefore the -e
on the link itself fails.


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

Kernel: Linux 3.11-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages dokuwiki depends on:
ii  debconf [debconf-2.0]  1.5.51
ii  javascript-common  11
ii  libjs-jquery   1.7.2+dfsg-3
ii  libjs-jquery-cookie8-2
ii  libjs-jquery-ui1.10.1+dfsg-1
ii  libphp-simplepie   1.2.1-3
ii  php-geshi  1.0.8.11-2
ii  php5   5.5.5+dfsg-1
ii  ucf3.0027+nmu1

Versions of packages dokuwiki recommends:
ii  php5-cli5.5.5+dfsg-1
ii  php5-gd 5.5.5+dfsg-1
ii  php5-ldap   5.5.5+dfsg-1
ii  php5-mysql  5.5.5+dfsg-1

Versions of packages dokuwiki suggests:
pn  libapache2-mod-xsendfile  

-- Configuration Files:
/etc/dokuwiki/dokuwiki.php changed [not included]

-- debconf information excluded


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

Bug#587916: Already available in currently packaged asciidoc

[Joseph Herlant]

Control: tags 587916 + moreinfo fixed

Hello,

The option you asked for (I know, it's a few years ago) is available
in the currently packaged version.
You must add the ":linkcss:" at the begining of the document to do so.

It is explained in the official documentation at:
http://www.methods.co.nz/asciidoc/chunked/ch07.html

Quote:
 - If the AsciiDoc linkcss attribute is defined then CSS and
JavaScript files are linked to the output document, otherwise they are
embedded (the default behavior).
 - The default locations for CSS and JavaScript files can be changed
by setting the AsciiDoc stylesdir and scriptsdir attributes
respectively.


I put the bug in moreinfo and fixed. Please let me know if this
solution fits your needs so I could close the bug.

Best regards,
Joseph


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

Bug#728180: gdm3: service gdm3 stop leaves lots of processes running, preventing restart or start of other dm

[Johannes Rohr]

Am Dienstag, 29. Oktober 2013, 12:21:28 schrieb Simon McVittie:
> On 29/10/13 08:23, Johannes Rohr wrote:
> > Package: gdm3
> > Version: 3.8.4-3
> > Severity: normal
> > 
> > After running service gdm3 stop I still see a host of related processes
> > running
> Is your process 1 systemd, or sysvinit, or something else?

/sbin/init is a symlink to /lib/systemd/systemd
 But I think that it was no different, when I had sysvinit runnig.

Thanks,

Johannes


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

Bug#724158: python-scrypt: FTBFS: scrypt-1.1.6/lib/crypto/crypto_aesctr.c:34:25: fatal error: openssl/aes.h: No such file or directory

[Dejan Latinovic]

Hi,
the same error occurs on mips/mipsel.

Full build log:
https://buildd.debian.org/status/fetch.php?pkg=python-scrypt&arch=mips&ver=0.6.1-5&stamp=1377211402

Header openssl/aes.h is part of libssl-dev package.
After I installed it, package was built successfully.

Is it a correct solution to add libssl-dev as a Build-Depends for
python-scrypt package?


Regards,
Dejan Latinović


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

Bug#687834: Some progress with uscan and https_proxy

[Dominique Dumont]

Hello

I've managed to get uscan working with https behind a corporate firewall.

First, LWP::UserAgent needs to be patched [1]. And uscan must be modified to 
require 'Net::SSL' instead of 'Crypt::SSLeay'.

Then uscan works as expected using the proxy specified in https_proxy env 
variable. Note that some site will redirect https requests to http request so 
http_proxy (without the 's') must also be specified.

All the best

[1] https://github.com/libwww-perl/libwww-perl/pull/51

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.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#727708: Init systems: arguments for the CTTE

[Andreas Barth]

* Josselin Mouette (j...@debian.org) [131028 10:39]:
> As a side note, I think upstart’s CLA dismisses it as software
> of choice for our core system. 
> I know it’s not the only important piece of software in Debian
> with a CLA. I still stand on this point. I have experienced a
> real world CUPS nightmare because of Apple’s CLA, and I would be
> all for ditching CUPS as default too if we had a decent
> alternative.

It is important for us that we can identify and fix bugs in our
packages, and that we could forward bug reports to upstream and have a
good working relationship with them (and allow them to pull our
patches).

However, lots of packages in Debian require copyright assignments to
bring patches upstream. This includes as central packages as gcc. One
could argue that the assignment policies between Ubuntu and FSF are
different enough that it matters. On the other hand, I don't see why
this is a blocker for us.

The upstart maintainers in Debian will work on bug reports and
proposed patches even without copyright assignment (as do the gcc
maintainers), and that is what is required for us. Of course I would
prefer if the copyright assignment policy would be changed, but that's
something else.

So, IMHO this topic is not a blocker for upstart (which doesn't on the
other hand automatically imply upstart is the right answer - this
depends on other questions and answers within this discussion).


Andi


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

Bug#214741: Patch for 214741

[Jonathan Hall]

We are also experiencing this with postfix 2.7.1 and 2.9.6.  The 
included patch solves the problem for 2.7.1, and should be trivial to 
adapt for newer versions.



Index: src/global/mail_params.c
===
--- src/global/mail_params.c(revision 8399)
+++ src/global/mail_params.c(revision 8400)
@@ -148,6 +148,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef STRCASECMP_IN_STRINGS_H
 #include 
@@ -294,7 +295,6 @@
 static const char *check_myhostname(void)
 {
 static const char *name;
-const char *dot;
 const char *domain;
 
 /*
@@ -308,10 +308,17 @@
  * contents of $mydomain. Use a default domain as a final workaround.
  */
 name = get_hostname();
-if ((dot = strchr(name, '.')) == 0) {
-   if ((domain = mail_conf_lookup_eval(VAR_MYDOMAIN)) == 0)
-   domain = DEF_MYDOMAIN;
-   name = concatenate(name, ".", domain, (char *) 0);
+if (strchr(name, '.') == 0) {
+   /* This may or may not be the most intelligent possible method,
+  but it is what Debian 'hostname --fqdn' does. */
+   struct hostent *ent = gethostbyname(name);
+   if (ent)
+   name = strdup(ent->h_name);
+   if (strchr(name, '.') == 0) {
+   if ((domain = mail_conf_lookup_eval(VAR_MYDOMAIN)) == 0)
+   domain = DEF_MYDOMAIN;
+   name = concatenate(name, ".", domain, (char *) 0);
+   }
 }
 return (name);
 }

Bug#728151: libimobiledevice4: fails upgrade

[Michael Biebl]

Please just disable hal support and drop
/usr/share/hal/fdi/information/20thirdparty/31-apple-mobile-device.fdi

hal is completely broken nowadays and it doesn't make sense pretending
this file is useful.
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#723676: pgadmin3-data: es_ES language is not available, it has been removed

[eduardo]

Package: pgadmin3-data
Version: 1.18.1-1
Followup-For: Bug #723676

Dear Maintainer,
*** Please consider answering these questions, where appropriate ***

   * What led up to the situation?
Upgrade to unstable revision
   * What exactly did you do (or not do) that was effective (or
 ineffective)?
Update pgadmin3 and pgadmin3-data, uninstall, install from stable to 
testing and next from testing to sid.
Into testing and sid revisions es_ES is not available.
   * What was the outcome of this action?
pgadmin3 has all language but never shows es_ES language, something has 
destroyed this language
   * What outcome did you expect instead?
pgadmin3 should show all languages, including es_ES, and it should be 
available/selectable.

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


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

Kernel: Linux 3.10-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=es_ES.UTF-8, LC_CTYPE=es_ES.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-- 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#728201: ITP: php-horde-socket-client -- Horde Socket Client

[Mathieu Parent]

Package: wnpp
Severity: wishlist
Owner: Mathieu Parent 
X-Debbugs-Cc: pkg-horde-hack...@lists.alioth.debian.org

 Package name: Horde_Socket_Client
 Version : 1.0.1
 Upstream Author : Michael Slusarz
 URL : http://horde.org/
 License : LGPL-2.1
 Programming Lang: PHP
 Description : Horde Socket Client
Provides abstract class for use in creating PHP network socket clients.

I'm packaging this as part of Horde5 packaging.

Mathieu Parent


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

Bug#728200: debian-policy: force build tools to ensure source trees are build-ready

[Bill Allombert]

On Tue, Oct 29, 2013 at 12:41:45PM +, Ximin Luo wrote:
> Package: debian-policy
> Severity: important
> 
> I was recently hit by this bug [1] which stems from inconsistent assumptions
> that various build tools have about the state of the build tree. I filed [2]
> to devscripts to suggest a fix.

I agree that debclean should be fixed, but your use of question marks suggests
that you are seriously confused about the policy.
The reason of bugs in devscripts is due to the introduction of the new source
format rather than misunderstanding the policy.

> However, policy wording could be better in this area, and it is especially not
> helpful for Section 4.14 [3] to effectively give free reign to the maintainer
> to make arbitrary instructions on how to take the source tree from an unpacked
> state to a build-ready state. (How does this even work with buildd??? Did you
> guys solve NLP???)

You are misreading 4.14 [3]. README.source documents how to edit the source
package and how to use new upstream tarball.

> I would suggest policy make explicit definitions for the terms "unpacked" 
> state
> vs "build-ready" state, and force build tools to detect and reject performing
> `debian/rules` actions on source trees that are not "build-ready". It just
> doesn't make sense for this to happen, no good result can come out of it.

As far as policy is concerned, freshly unpacked source package are build ready.

> Or probably better, the build-tool can simply make the source tree build-ready
> by running `dpkg-source --before-build` or `debian/rules patch` before running
> other debian/rules actions. (This also requires "patch" to be idempotent.)

'debian/rules patch' is deprecated by the new source format "3.0 (quilt)"

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


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

Bug#727551: compton: with -c, opaque window movement is slow

[Scott Leggett]

On 24/10/13 19:19, Vincent Lefevre wrote:
> Package: compton
> Version: 0.1~beta1-1
> Severity: normal
> 
> With "compton -c" or "compton -c --backend=xrender", opaque window
> movement is slow (tested with fvwm). There is no such problem
> without -c or without a compositor or with "xcompmgr -c".

Hi Vincent,

Which graphics drivers are you using?

Also, do you have any settings saved under the various default config
file locations? (see the man page)


-- 
Regards,
Scott Leggett.



signature.asc
Description: OpenPGP digital signature

Bug#728202: cmus: m4a playback is broken

[Dominik George]

Package: cmus
Version: 2.5.0-4
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I cannot play any .m4a files, although cmus adds them to the library
when scanning directories. When playing those files, only noise comes
out of the speakers, as though the file were being tried to be decoded
as mp3 or something.

- -- 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.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages cmus depends on:
ii  libao4  1.1.0-2
ii  libasound2  1.0.27.2-3
ii  libc6   2.17-93
ii  libcddb21.3.2-3
ii  libcdio-cdda1   0.83-4
ii  libcdio13   0.83-4
ii  libfaad22.7-8
ii  libflac81.3.0-2
ii  libmad0 0.15.1b-8
ii  libmodplug1 1:0.8.8.4-4
ii  libmpcdec6  2:0.1~r459-4
ii  libncursesw55.9+20130608-1
ii  libtinfo5   5.9+20130608-1
ii  libvorbisfile3  1.3.2-1.3
ii  libwavpack1 4.60.1-3

Versions of packages cmus recommends:
ii  cmus-plugin-ffmpeg  2.5.0-4
ii  libpulse0   4.0-6+b1

cmus suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQJOBAEBCAA4BQJSb71iMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8pZrLhAAty0XBloOwVkCCDhz74Uv
jgrgqCk88JA6eFlnt12h+T53JgXjoh3mju8d1vBaqDQifOIcThvTGGj1lFY2e4Wm
vZVyJ/DbOywBF1jWY0TlHFN1BDyx3qzPfTeCvFXI6W763yJ1tKDQMAuYrPRdu9Dn
d8kJOt7VY2mm0Orp5mUmAr3a6pZ4CyOdH1U0CokY+U677w5HyiQ6ewhqhcew1swD
IullyKZCLF9xTHmT8OhEeiNgged9+52A3Rl6kMeMx4huz+SqYZxloXtkTn4i0AUb
N4WRTHDv0MLY48RpYma4hboHVohMdpTTF8JG/4f0uJykLXG+qllkxWDO9tXNDsNp
pEvmK6vNT7Oge26fK0QH3bYrLyk0Y9xpUNAo/IxpM7ldc9BjvK9mbpK8wn3xLhch
YQK/JY+qE877ebkoCay1kzuoRopcRFf3p3yKeS0eRcazv4hW0grplNqIdKfeSWBP
QDJakkBp+CDGbrC68ktS1xqg+snlyo7PFOj2ZKOsMCODVQn8wc1BrmmRsI34C2vf
xPuAyODaMB83TJ/RXVA+pnB4KzZPtyuD5xZfipVcHWccOySzStWPubpAeKlGfG9O
DhGvCVJHth5q5hnIw3MztTDh/INjlPFDaDe9k6t29Pb3ixbhPzy3kRvi2WKaFI5Q
YsXaniib3I/3XYLojStUNOw=
=mlL0
-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#717295: ADF not working on HP scanjet 8350

[motorecycler]

Hi there. I cam across a bug log with someone that could not get the ADF 
working with a HP OfficeJet 4620 using gscan2pdf.  I have the same 
problem with a HP scanjet 8350. Im using v1.1.3.

Any updates that might fix this in the future?
thanks!
Dave


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

Bug#728200: debian-policy: force build tools to ensure source trees are build-ready

[Ximin Luo]

On 29/10/13 13:15, Bill Allombert wrote:
> On Tue, Oct 29, 2013 at 12:41:45PM +, Ximin Luo wrote:
>> Package: debian-policy
>> Severity: important
>>
>> I was recently hit by this bug [1] which stems from inconsistent assumptions
>> that various build tools have about the state of the build tree. I filed [2]
>> to devscripts to suggest a fix.
> 
> I agree that debclean should be fixed, but your use of question marks suggests
> that you are seriously confused about the policy.
> The reason of bugs in devscripts is due to the introduction of the new source
> format rather than misunderstanding the policy.
> 
>> However, policy wording could be better in this area, and it is especially 
>> not
>> helpful for Section 4.14 [3] to effectively give free reign to the maintainer
>> to make arbitrary instructions on how to take the source tree from an 
>> unpacked
>> state to a build-ready state. (How does this even work with buildd??? Did you
>> guys solve NLP???)
> 
> You are misreading 4.14 [3]. README.source documents how to edit the source
> package and how to use new upstream tarball.
> 
>> I would suggest policy make explicit definitions for the terms "unpacked" 
>> state
>> vs "build-ready" state, and force build tools to detect and reject performing
>> `debian/rules` actions on source trees that are not "build-ready". It just
>> doesn't make sense for this to happen, no good result can come out of it.
> 
> As far as policy is concerned, freshly unpacked source package are build 
> ready.
> 

The wording of 4.14 is not consistent with that interpretation:

"If running dpkg-source -x on a source package doesn't [..] allow one to [..] 
run dpkg-buildpackage to produce a modified package [..], creating a 
debian/README.source documentation file is recommended."

implying that it's valid to for "dpkg-source -x" to produce a package that is 
not build-ready.

Anyway, this is a separate issue from fixing those tools, but I thought making 
policy more strict and explicit would help prevent such bugs in any future 
tools.

>> Or probably better, the build-tool can simply make the source tree 
>> build-ready
>> by running `dpkg-source --before-build` or `debian/rules patch` before 
>> running
>> other debian/rules actions. (This also requires "patch" to be idempotent.)
> 
> 'debian/rules patch' is deprecated by the new source format "3.0 (quilt)"
> 

Not having to support "patch" greatly simplifies things, but "deprecation" is 
not mentioned anywhere in Section 4... Do you know how many existing packages 
still use "patch"?

X

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature

Bug#697940: Closing

[Thijs Kinkhorst]

reopen 697940
forwarded 697940 http://trac.nginx.org/nginx/ticket/13
tags 697940 = security upstream
thanks

Hi,

This issue is not yet fixed in the package so it seems premature to close
it. You're probably right that upstream needs to do this and there's no
need for Debian to do it locally. But that is expressed with the
'upstream' and 'forwarded' tags; no need to close it for that reason. It
can be closed when a new upstream is uploaded to Debian that fixes the
issue.


Cheers,
Thijs


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

Bug#728204: mplayer2: playback of .m4a files produces funny time information display

[Dominik George]

Package: mplayer2
Version: 2.0-701-gd4c5b7f-2
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

When playing back .m4a files (downloaded from iTunes some time ago), I
see a funny effect with playback/total time information.

mplayer opens an X window displaying the album artwork and, as per my
configuration, an OSD showing playback time and total duration of the
stream.

This OSD correctly displays the song as being 00:03:43 long, however,
the playback time remains at 0:00:00.

On the other hand, on the console, the stream length is displayd as ??
seconds, but the playback time is incremented and displayed correctly -
although this only happens in seconds, whereas for other file formats,
both decimal seconds and h:mm:ss is shown on the console.

This raises several questions:

 - Why does the OSD know the duration, while the conolse says it
   doesn't?
 - Why does the console show playback time, while the OSD has no idea?
 - Why isn't mplayer able to determine the h:mm:ss format while it knows
   the playback time in decimal seconds quite well, *and* can do so in
   the OSD for the track duration?

Cheers,
Nik

- -- 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.11-1-amd64 (SMP w/2 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/mksh

Versions of packages mplayer2 depends on:
ii  liba52-0.7.4  0.7.4-16
ii  libasound21.0.27.2-3
ii  libass4   0.10.1-3
ii  libavcodec54  6:9.10-1
ii  libavformat54 6:9.10-1
ii  libavresample16:9.10-1
ii  libavutil52   6:9.10-1
ii  libbluray11:0.4.0-1
ii  libbs2b0  3.1.0+dfsg-2
ii  libc6 2.17-93
ii  libcaca0  0.99.beta18-1
ii  libcdio-cdda1 0.83-4
ii  libcdio-paranoia1 0.83-4
ii  libcdio13 0.83-4
ii  libdca0   0.0.5-6
ii  libdirectfb-1.2-9 1.2.10.0-5
ii  libdv41.0.0-6
ii  libdvdnav44.2.0+20130225-3
ii  libdvdread4   4.2.0+20130219-2
ii  libenca0  1.15-1
ii  libfaad2  2.7-8
ii  libgif4   4.1.6-10
ii  libgl1-mesa-glx [libgl1]  9.2.2-1
ii  libjack-jackd2-0 [libjack-0.116]  1.9.9.5+20130622git7de15e7a-1
ii  libjpeg8  8d-1
ii  liblcms2-22.2+git20110628-2.3
ii  liblircclient00.9.0~pre1-1
ii  libmad0   0.15.1b-8
ii  libmng1   1.0.10-3
ii  libmpg123-0   1.16.0-1
ii  libncurses5   5.9+20130608-1
ii  libogg0   1.3.1-1
ii  libpng12-01.2.49-5
ii  libpostproc52 6:0.git20120821-4
ii  libpulse0 4.0-6+b1
ii  libquvi7  0.4.1-2
ii  libsdl1.2debian   1.2.15-8
ii  libsmbclient  2:4.0.10+dfsg-3
ii  libspeex1 1.2~rc1.1-1
ii  libswscale2   6:9.10-1
ii  libtheora01.1.1+dfsg.1-3.1
ii  libtinfo5 5.9+20130608-1
ii  libvdpau1 0.7-1
ii  libvorbis0a   1.3.2-1.3
ii  libx11-6  2:1.6.2-1
ii  libxext6  2:1.3.2-1
ii  libxinerama1  2:1.1.3-1
ii  libxss1   1:1.2.2-1
ii  libxv12:1.0.9-1
ii  libxvidcore4  2:1.3.2-9
ii  libxxf86vm1   1:1.1.3-1
ii  zlib1g1:1.2.8.dfsg-1

mplayer2 recommends no packages.

mplayer2 suggests no packages.

- -- no debconf information

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.15 (GNU/Linux)

iQJOBAEBCAA4BQJSb77KMRpodHRwczovL3d3dy5kb21pbmlrLWdlb3JnZS5kZS9n
cGctcG9saWN5LnR4dC5hc2MACgkQt5o8FqDE8paN+RAApgFolOrqVXtxZQL06Lkt
ghSpBfys8HrMDqg6INnqx4XKLKssPPqNFAtygs83AX7pz4G1bODj3ueAVrfNwWRG
IGM4RCEqTh8Lvc5LSkaRhnAGdU0z/dbMZl1Gny/G22uzzhibrHglxQaoELTqKAgo
T8BOVxCTHemscxsLYv+rPtJ/l41DJDt+1GwjHNLZK+GTm4cZ16CBrcvGwkrvbtDq
IP92P222hjDcw/xXMbdA8a3fDU6kiWiyJ+EULRGWvcM9qnl3c4zIe+ij+UW6j3EB
ZEZORVoJ/MqlVPiHo3NsnNHuNonW7JsGHJTXsE37vTfRjGnx2z7LrakRjAmIU+J6
nVhS8ADCiPRJEIztL5/YYvSJqVNdWrys4ELJhzFIuIRN/5ORWQ0To/UbZMFqrp+O
NjardGhAl0aE89989S80LHo2W3tDXpDm/gmFhujTLlq7Z1rAgNVCpYff/cBbTo6v
p5SRB3Oeeax5dEIFjapw+mhAztOM/ed88aknIlp/648on7qKTsdYAhIb/RgzILEG
KesaceKX3JHATzJzLIS7ZyUW4QM7B/mmRuuI7U77OjtMN9W0RX/HzzSq8OpWK2fV
b2dy/UbFqXeisE93T2RXCufXFxeZ+DmsAk+EcPJ71YZShLlHNY5kIb08KfF6RM

Bug#728203: dh-buildinfo: Please mark Multi-Arch: foreign

[Colin Watson]

Package: dh-buildinfo
Version: 0.10
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu ubuntu-patch trusty

Hi,

Enough source packages (605 in unstable) Build-Depend on dh-buildinfo
that it would be very helpful to have it marked as "Multi-Arch:
foreign".  This would make it easier to cross-build those packages.  If
you're wondering why this is necessary for an Architecture: all package,
please see:

  
https://wiki.ubuntu.com/MultiarchSpec#Dependencies_involving_Architecture:_all_packages

  * Make dh-buildinfo Multi-Arch: foreign, so that it can satisfy
cross-build-dependencies.

diff -Nru dh-buildinfo-0.10/debian/control 
dh-buildinfo-0.10ubuntu1/debian/control
--- dh-buildinfo-0.10/debian/control2013-09-22 09:43:09.0 -0700
+++ dh-buildinfo-0.10ubuntu1/debian/control 2013-10-29 06:34:54.0 
-0700
@@ -8,6 +8,7 @@
 
 Package: dh-buildinfo
 Architecture: all
+Multi-Arch: foreign
 Depends: debhelper, ${perl:Depends}, ${misc:Depends}, build-essential (>= 7)
 Description: Debhelper addon to track package versions used to build a package
  This script is designed to be run at build-time, and registers in a

Thanks,

-- 
Colin Watson   [cjwat...@ubuntu.com]


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

Bug#728204: Acknowledgement (mplayer2: playback of .m4a files produces funny time information display)

[Dominik George]

I suspect that this has something to do with the embedded album artwork,
as the MJPEG stream used for it obviously has no timing information.

Yet this doesn't explain the mix-up between OSD and console.


Here is information about the clip in question:

[lavf] stream 0: audio (aac), -aid 0, -alang und
[lavf] stream 1: video (mjpeg), -vid 0
Clip info:
 major_brand: M4A
 minor_version: 0
 compatible_brands: M4A mp42isom
 creation_time: 2007-05-03 16:59:47
 title: Just Can't Get Enough
 artist: Depeche Mode
 album_artist: Depeche Mode
 album: The Best of Depeche Mode, Vol. 1
 genre: Pop
 track: 2/18
 disc: 1/1
 gapless_playback: 0
 date: 2006-11-13T08:00:00Z
 copyright: ℗  2006 The copyright in this compilation is owned by Venusnote 
Limited under exclusive licence to Mute Records Limited
 season_number: 0
 episode_sort: 0
 media_type: 1

-- 
* concerning Mozilla code leaking assertion failures to tty without D-BUS *
 That means, D-BUS is a tool that makes software look better
than it actually is.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Bug#699736: fixed in 4.8

[Nicolas Boulenguez]

Control: fixed -1 4.6.4-2
Control: retitle -1 [Fixed in 4.8] Bug box in gnat_to_gnu, at 
ada/gcc-interface/trans.c:4526

4.8.2-1 answers like 4.6.4-2.


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

Bug#728205: xmobar: does not look for configuration file in XDG config dir

[Gian Piero Carrubba]

Package: xmobar
Version: 0.19-1
Severity: minor

Despite what stated in NEWS.Debian and in the man page, xmobar does not 
search for the configuration file in $XDG_CONFIG_HOME/xmobar/xmobarrc.


~ $ ls -l .xmobarrc .config/xmobar/xmobarrc
ls: cannot access .xmobarrc: No such file or directory
-rw-r--r-- 1 gpiero gpiero 2602 May 31 08:42 .config/xmobar/xmobarrc
~ 2! echo ${XDG_CONFIG_HOME:-empty}
empty
~ $ xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]

~ 1! XDG_CONFIG_HOME=~/.config xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]

~ 1! export XDG_CONFIG_HOME=~/.config ; xmobar
xmobar: /home/gpiero/.xmobarrc: file not found!
Usage: xmobar [OPTION...] [FILE]
[...]

Ciao,
Gian Piero.

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

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

Versions of packages xmobar depends on:
ii  libc6 2.17-93
ii  libffi6   3.0.13-4
ii  libgmp10  2:5.1.2+dfsg-3
ii  libiw30   30~pre9-8
ii  libx11-6  2:1.6.2-1
ii  libxext6  2:1.3.2-1
ii  libxft2   2.3.1-1
ii  libxinerama1  2:1.1.3-1
ii  libxml2   2.9.1+dfsg1-3
ii  libxrandr22:1.4.1-1

Versions of packages xmobar recommends:
ii  curl  7.33.0-1

Versions of packages xmobar suggests:
ii  xmonad  0.11-6

-- no debconf information


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

Bug#727551: compton: with -c, opaque window movement is slow

[Vincent Lefevre]

Hi Scott,

On 2013-10-30 00:30:39 +1100, Scott Leggett wrote:
> Which graphics drivers are you using?

The nouveau driver. It was slow on my laptop with the following
card: NVIDIA Corporation G98M [Quadro NVS 160M] (rev a1)

But no problems on another machine, still with the nouveau driver,
but with: NVIDIA Corporation G98 [Quadro NVS 295] (rev a1)

> Also, do you have any settings saved under the various default config
> file locations? (see the man page)

Apparently no config files on either machine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


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

Bug#728202: Acknowledgement (cmus: m4a playback is broken)

[Dominik George]

The file has embedded album artwork as MJPEG stream - I can imagine this
is at least part of the issue. It could be related to #728204 as well.

-- 
 Auf welchem Server liegt das denn jetzt…?
 Wenn es nicht übers Netz kommt bei Hetzner, wenn es nicht
gelesen wird bei STRATO, wenn es klappt bei manitu.

PGP-Fingerprint: 3C9D 54A4 7575 C026 FB17  FD26 B79A 3C16 A0C4 F296


signature.asc
Description: Digital signature

Bug#697940: Closing

[Michael Lustfield]

I wasn't aware of forwarded or tags. Shows my experience level... Sorry for
prematurely closing this and thanks for giving me new stuff to learn.


On Tue, Oct 29, 2013 at 8:57 AM, Thijs Kinkhorst  wrote:

> reopen 697940
> forwarded 697940 http://trac.nginx.org/nginx/ticket/13
> tags 697940 = security upstream
> thanks
>
> Hi,
>
> This issue is not yet fixed in the package so it seems premature to close
> it. You're probably right that upstream needs to do this and there's no
> need for Debian to do it locally. But that is expressed with the
> 'upstream' and 'forwarded' tags; no need to close it for that reason. It
> can be closed when a new upstream is uploaded to Debian that fixes the
> issue.
>
>
> Cheers,
> Thijs
>
>

Bug#725752: Workaround

[Raghu Rao]

Please see here:

http://productforums.google.com/forum/#!topic/chat/WZzFG6or9Tw

I tried both solutions separately -- removing libudev0 and downgrading
libcairo2 to the version from wheezy -- and they both work for me.

In my case, removing libudev0 is the better solution as I have no
packages depending on it.  Downgrading libcairo2 required me to
downgrade / remove / install a few other packages.

---
$ uname -smrv
Linux 3.10-3-amd64 #1 SMP Debian 3.10.11-1 (2013-09-10) x86_64

$ lsb_release -cis
Debian
jessie

~$ aptitude versions '^google-talkplugin$' '^libcairo2$' '^iceweasel$'
'^google-chrome-stable$' | tr -s ' '
Package google-chrome-stable:
i 30.0.1599.114-1 stable 500

Package google-talkplugin:
i 4.8.3.0-1 stable 500

Package iceweasel:
i 17.0.9esr-1~deb7u1 stable,testing 500

Package libcairo2:
p A 1.12.2-3 stable 500
i A 1.12.16-2 testing 500


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

Bug#728206: RFP: librtr -- Library implementing the client-side of the RPKI-RTR Protocol.

[Fabian Holler]

Package: wnpp
Severity: wishlist

* Package name: librtr
  Version : 0.2.3
  Upstream Author : Fabian Holler 
* URL : http://rpki.realmv6.org/
* License : LGPL
  Programming Lang: C
  Description : Library implementing the client-side of the RPKI-RTR 
Protocol.

The RTRlib is an open-source C implementation of the  RPKI/Router Protocol 
client. The library allows to fetch and
store validated prefix origin data from a RTR-cache and performs origin 
verification of prefixes. It supports different
types of transport sessions (e.g., SSH, unprotected TCP) and is easily 
extendable.

The RTRlib is useful for developers of routing software but also for network 
operators. Developers can integrate the
RTRlib into the BGP daemon to extend their implementation towards RPKI. Network 
operators may use the RTRlib to develop
monitoring tools (e.g., to check the proper operation of caches or to evaluate 
their performance).

Debian Packaging files are available at: 
https://github.com/rtrlib/rtrlib/tree/master/debian


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

Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Bill Allombert]

On Tue, Oct 29, 2013 at 12:14:16PM +, Ximin Luo wrote:
> Package: devscripts
> Version: 2.13.4
> Severity: important
> 
> It does not make sense to build or clean an unpatched source tree, since the
> applied patches are considered strictly *part of the source package*. However,
> `debuild build/clean`, and probably many other tools, still allows this to
> happen without any warning.

I think I understand Ximin issue:

debclean can fail in a source tree when using the source format "3.0 quilt",
if 'debian/rules clean' requires the patches to be applied to work, for example
an upstream Makefile is fixed,
because debclean does not make sure the patches are applied.

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 


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

Bug#727549: window resize information is not displayed with fvwm

[Scott Leggett]

This bug is due to the method fvwm uses to display the geometry
feedback, and is largely outside the control of compton.

Please see the discussion in this upstream bug report[0], as well as a
workaround (using fvwm event scripts and compton's dbus interface to
disable redirection while resizing is taking place).

Please try this workaround and let us know how effective it is.

If it works, I can't see an easy way to add it to the package, but it
might be worth a mention in the manpage.

[0] https://github.com/chjj/compton/issues/41

-- 
Regards,
Scott Leggett.



signature.asc
Description: OpenPGP digital signature

Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees

[Ximin Luo]

On 29/10/13 14:23, Bill Allombert wrote:
> On Tue, Oct 29, 2013 at 12:14:16PM +, Ximin Luo wrote:
>> Package: devscripts
>> Version: 2.13.4
>> Severity: important
>>
>> It does not make sense to build or clean an unpatched source tree, since the
>> applied patches are considered strictly *part of the source package*. 
>> However,
>> `debuild build/clean`, and probably many other tools, still allows this to
>> happen without any warning.
> 
> I think I understand Ximin issue:
> 
> debclean can fail in a source tree when using the source format "3.0 quilt",
> if 'debian/rules clean' requires the patches to be applied to work, for 
> example
> an upstream Makefile is fixed,
> because debclean does not make sure the patches are applied.
> 
> Cheers,
> 

Thanks, Bill! Yes that's what I meant.

One possible way to fix this, is to change `debuild $TARGET` so that it runs:

$ dpkg-source --before-build
$ debian/rules $TARGET
$ dpkg-source --after-build

instead of just `debian/rules $TARGET`.

This works for my use case, but I'm less certain if it is "completely correct".

-- 
GPG: 4096R/1318EFAC5FBBDBCE
git://github.com/infinity0/pubkeys.git



signature.asc
Description: OpenPGP digital signature