Bug#728061: coreutils: mailcap for cat
Kevin Ryde wrote: Bob Proulx b...@proulx.com writes: What mail-user-agent are you using where this configuration is advantageous? It was to make run-mailcap --action=cat work on text/plain. A response that completely avoided answering my question. The run-mailcap command is in the mime-support package. Perhaps this issue would be better discussed within the mime-support package project rather than about coreutils? Perhaps, though it seemed to me reasonably clear the cat program could be sensibly given an entry of the kind described in fact already in the mailcap(5) man page. mime-support generates a few things of its own making, but mainly leaves entries to the package containing the program. The 'cat' program is for concatenating files. It isn't a text display program and should not be used as such. Especially not as a system default configuration. (Nor should cat be used to write device drivers in machine code even if one is inclined to do so.) Bob signature.asc Description: Digital signature
Bug#701112: Delay...
This one sure slipped under the cracks for me. So... check if it's root:root 755; if so, change to www-data:adm 750 Would that sufficiently deal with this? -- Michael Lustfield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728175: gdm3 : Accessibility / Usability : Login list unfocused when coming back from screen saver at initial login
Package: gdm3 Version: 3.8.4-3 Hi, The problem : Using keyboard only to login is impossible when the screen sever has been activated. The steps to reproduce : 1 - Startup gdm3 service 2 - Wait a long enough time to enable the screen saver activation 3 - Type 'enter' key to get rid off the screen saver 4 - The login list of users doesn't have the focus : using a mouse is mandatory to select the user you want to login with. This is a problem of usability and it is above all an accessibility problem for visually impaired people or with low hand movement capability. signature.asc Description: This is a digitally signed message part
Bug#722930: gdm3 blank screen: missing pam_systemd
Hi, I ran into one issue where gdm3 would start but the screen would stay blank. It seems that it was caused by some custom /etc/pam.d/ config on my system, which prevented libpam-systemd to update the config file properly. After running 'sudo pam-auth-update --force', the config files were updated, and gdm3 started normally. Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722177: 6.x dependencies
While you're updating things for nikola 6 - Debian only has python-doit 0.22.1, and nikola (6.2 at least, but probably went in earlier) needs at least doit 0.23 (and the failure mode is an obscure error, under earlier versions.) -- _Mark_ eic...@thok.org eic...@gmail.com
Bug#707069: Vote for no
Cyril, My vote is to not include this. The psol dependency alone should be enough to simply say no. It's a neat module, but my opinion for this is that if others want to use it, then they can build Nginx themselves. The number of external libraries is also going to bloat things a lot. I also don't see any point to it. If you write your website decent to begin with, then this module provides nothing. This is essentially a band-aid for people that can't write proper code to begin with. (no offense anyone...) -- Michael Lustfield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722328: Hm..
I've seen many good uses for the postgres module. I personally don't like postgres at all. I also happen to be comfortable with that developer. However, the two extra modules (devel kit is there) that would be required aren't exactly light modules. It would be nice to see a bit more interest or cause before tacking on three more modules (rds, form, postgres) to our list of modules to manage. -- Michael Lustfield -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#701508: What else?
The nginx-common package is required for nginx-{light,full,extras}.
nginx-common already suggests fcgiwrap
Nginx does not provide any cgi. It will only proxy to it via fastcgi_pass.
I do not feel comfortable claiming that these packages provide this, but by
request, it's been changed and committed.
--
Michael Lustfield
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#728174: ploop: FTBFS on non-Linux: asm/types.h: No such file or directory
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 u...@debian.org 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
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 u...@debian.org 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
Thanks. Will fix. On Tue, Oct 29, 2013 at 4:02 AM, Aaron M. Ucko u...@debian.org 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 sys/syscall.h 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
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
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
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
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 none 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 equivsnone 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 none 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-debiannone pn python3-magic none 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 none pn devscripts-elnone 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-perlnone 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
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
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 nome...@debian.org
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 james...@debian.org 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?
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
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.
On 28/10/13 at 18:21 -0700, Russ Allbery wrote: Wouter Verhelst wou...@master.debian.org 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
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,
Bug#727708: tech-ctte: Decide which init system to default to in Debian.
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)
Il Lunedì 28 Ottobre 2013 14:16, Robert Lemmen rober...@semistable.com 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
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 herla...@gmail.com 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 pratika...@gmail.com and Kamil Prusko kamilpru...@gmail.com * 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]
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
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 none 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 none pn devscripts-elnone 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-perlnone ii libtimedate-perl 1.2000-1 pn libyaml-syck-perlnone ii mutt 1.5.21-6.4 ii openssh-client [ssh-client] 1:6.2p2-6 pn svn-buildpackage none 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/user/project/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/project-$1.tar.gz/ \ + https://github.com/user/project/tags .*/v?(\d\S*)\.tar\.gz # For Google Code projects you should use the downloads page like this: http://code.google.com/p/project/downloads/list?can=1 \e
Bug#728183: plasma-desktop: Plasma desktop crashes on boot since update
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: In detail, tell us what you were doing when the application crashed. 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: In detail, tell us what you were doing when the application crashed. 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 Plasma::AppletScript::staticMetaObject, obj=obj@entry=0x2a73bb0) at kernel/qmetaobject.cpp:275 #7 0x7fd0f77371cf in qobject_castPlasma::WallpaperScript* (object=0x2a73bb0) at /usr/include/qt4/QtCore/qobject.h:380 #8 createPlasma::WallpaperScript (args=..., keyword=..., parent=optimized out, parentWidget=optimized out, this=optimized out) at .../../kdecore/util/kpluginfactory.h:533 #9 createInstancePlasma::WallpaperScript (error=optimized out, args=..., parent=optimized out, parentWidget=optimized out, this=optimized out) at .../../kdecore/services/kservice.h:559 #10 createInstancePlasma::WallpaperScript (error=optimized out, args=..., parent=optimized out, this=optimized out) 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=optimized out, name=..., appletId=optimized out, appletId@entry=172, args=...) at .../../plasma/pluginloader.cpp:134 #16 0x7fd0f76832a5 in Plasma::Applet::load (appletName=..., appletId=appletId@entry=172, args=...) at
Bug#727670: Please add calendar and carddav plugins
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
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 r...@debian.org
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)
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.
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...@lists.debian.org with a subject of unsubscribe. Trouble? Contact
Bug#728181: RFS: tofrodos/1.7.13+ds-1 [ITA]
Hello, On 29 October 2013 09:57, Markus Koschany a...@gambaru.de 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
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:anynone 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
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]
On 29.10.2013 10:23, Andrew Shadura wrote: Hello, On 29 October 2013 09:57, Markus Koschany a...@gambaru.de 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]
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 raf...@laboissiere.net -
Date: Tue, 29 Oct 2013 09:36:39 +0100
From: Rafael Laboissiere raf...@laboissiere.net
To: Andreas Tille ti...@debian.org
Subject: Re: Patch for devscripts
* Andreas Tille ti...@debian.org [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
Bug#728186: clamav-milter: silently fails to start
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 Optional features supported: MEMPOOL IPv6 FRESHCLAM_DNS_FIX AUTOIT_EA06 BZIP2 JIT Database information Database directory: /var/lib/clamav bytecode.cld:
Bug#728187: clamav-milter: clamd socket not accessible
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/clamav/clamav-milter.socket MilterSocketGroup disabled MilterSocketMode = 660 LocalNet = local OnClean = Accept OnInfected = Reject OnFail = Defer RejectMsg
Bug#727818: mongodb-server: please, integrate changes from github
-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
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: version 18032, sigs: 443721, built on Tue Oct 29 05:37:43 2013 Total number of signatures: 2867989 Platform information uname: Linux 3.2.0-4-amd64 #1 SMP Debian
Bug#727691: (no subject)
Il Martedì 29 Ottobre 2013 10:23, Robert Lemmen rober...@semistable.com 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
On Mon, Oct 28, 2013 at 03:50:33PM -0300, Felipe Sateler wrote: On Mon, Oct 28, 2013 at 2:22 PM, Vincent Bernat ber...@debian.org wrote: ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler fsate...@debian.org : 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.
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 z...@zachlatta.com * Package name: gitignorer Version : 1.0.0 Upstream Author : Zach Latta z...@zachlatta.com * 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
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
On 2013-10-28, David Kalnischkies kalnischkies+deb...@gmail.com 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)
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
* Ximin Luo infini...@gmx.com, 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=curlpparch=i386ver=0.7.3-3stamp=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
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 martin.p...@ubuntu.com 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
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
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
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
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
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
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)
-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
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
* Russ Allbery (r...@debian.org) [131029 03:15]: Michael Stapelberg stapelb...@debian.org 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
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
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 @@ link rel=up href=ch01.html title=Core link rel=prev href=MbimMessage.html title=MbimMessage link rel=next href=libmbim-glib-Enumerations-and-Flags.html title=Enumerations and Flags -meta name=generator content=GTK-Doc V1.19 (XML mode) +meta name=generator content=GTK-Doc V1.18 (XML mode) link rel=stylesheet href=style.css type=text/css /head body bgcolor=white text=black link=#FF vlink=#840084 alink=#FF @@ -710,6 +710,6 @@ /div div class=footer hr - Generated by GTK-Doc V1.19/div + Generated by GTK-Doc V1.18/div /body /html \ 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 @@ link rel=up href=ch01.html title=Core link rel=prev href=libmbim-glib-Command-IDs.html title=Command IDs link rel=next href=MbimDevice.html title=MbimDevice -meta name=generator content=GTK-Doc V1.19 (XML mode) +meta name=generator content=GTK-Doc V1.18 (XML mode) link rel=stylesheet href=style.css type=text/css /head body bgcolor=white text=black link=#FF vlink=#840084 alink=#FF @@ -1388,6 +1388,6 @@ /div div class=footer hr - Generated by GTK-Doc V1.19/div + Generated by GTK-Doc V1.18/div /body /html \ 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 @@ link rel=home href=index.html title=libmbim-glib Reference Manual link rel=up href=index.html title=libmbim-glib Reference Manual link rel=prev href=deprecated-api-index.html title=Index of deprecated API -meta name=generator content=GTK-Doc V1.19 (XML mode) +meta name=generator content=GTK-Doc V1.18 (XML mode) link rel=stylesheet href=style.css type=text/css /head body bgcolor=white text=black link=#FF vlink=#840084 alink=#FF @@ -20,25 +20,25 @@ td /td /tr trtd colspan=5 class=shortcuts -a class=shortcut href=#glsTT/a +a class=shortcut href=#glsOO/a | - a class=shortcut href=#glsOO/a + a class=shortcut href=#glsTT/a /td/tr /table div class=glossary div class=titlepagedivdivh1 class=title
Bug#652003: Fwd: Ticket #961
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
On 29/10/13 10:24, Jakub Wilk wrote: * Ximin Luo infini...@gmx.com, 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=curlpparch=i386ver=0.7.3-3stamp=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
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
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
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 james...@debian.org signature.asc Description: Digital signature
Bug#494945: fixed in gnat-4.8
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
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 ber...@debian.org wrote: ❦ 15 juillet 2013 23:27 CEST, Felipe Sateler fsate...@debian.org : [...] 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 tab 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
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
* Ximin Luo infini...@gmx.com, 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
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
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 paul...@debian.org : :' : 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
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
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
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 none 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 none pn devscripts-elnone 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-perlnone 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 none 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
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
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
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
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
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
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
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 none -- 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
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
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
Hi, the same error occurs on mips/mipsel. Full build log: https://buildd.debian.org/status/fetch.php?pkg=python-scryptarch=mipsver=0.6.1-5stamp=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
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
* 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
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 grp.h
#include time.h
#include ctype.h
+#include netdb.h
#ifdef STRCASECMP_IN_STRINGS_H
#include strings.h
@@ -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
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
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
Package: wnpp Severity: wishlist Owner: Mathieu Parent math.par...@gmail.com 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
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. ballo...@debian.org 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
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
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
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
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
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
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
Bug#728203: dh-buildinfo: Please mark Multi-Arch: foreign
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)
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 * mirabilos 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
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
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
