Bug#721929: gnome-open: not found
Control: tags -1 help I have been starring at the source code but I cannot find where in the code 'gnome-open' is being called. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733718: RM: browser-plugin-spice [armel armhf hurd-i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc] -- ROM; unusable on archs without spice-client
Package: ftp.debian.org Severity: normal The new package spice-xpi generate the binary package browser-plugin-spice, which before version 2.8-4 was build on all architectures, but failed to install on most of them because its requirement spice-client was missing on everything except amd64 and i386. I changed the build rules to depend on spice-client to make sure the XPI module only show up on platforms with spice-client, and need to have the non-installable binary packages removed from the archive to allow spice-xpi to propagate into testing. Please remove browser-plugin-spice for armel, armhf, hurd-i386, ia64, kfreebsd-amd64, kfreebsd-i386, mips, mipsel, powerpc, s390x and sparc in unstable. -- Happy hacking Petter Reinholdtsen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733719: warning: 'anonymous.VECTOR3float::x' is used uninitialized in this function [-Wuninitialized]
Package: imagevis3d
Need to fix:
g++ -c -fopenmp -DPACKAGE_MANAGER -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -std=c++0x
-fno-strict-aliasing -g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security
-D_FORTIFY_SOURCE=2 -fPIC -D_REENTRANT -Wall -W -D_FILE_OFFSET_BITS=64
-D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG
-DQT_OPENGL_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
-I/usr/share/qt4/mkspecs/hurd-g++ -I. -I/usr/include/qt4/QtCore
-I/usr/include/qt4/QtGui -I/usr/include/qt4/QtOpenGL
-I/usr/include/qt4 -I. -I3rdParty/GLEW -IIO/3rdParty/boost
-IIO/3rdParty/zlib -IBasics -IIO/exception -I/usr/include/lua5.2
-I/usr/X11R6/include -I. -o Build/objects/AbstrRenderer.o
Renderer/AbstrRenderer.cpp
In file included from Renderer/../Renderer/CullingLOD.h:43:0,
from Renderer/AbstrRenderer.h:47,
from Renderer/AbstrRenderer.cpp:41:
Renderer/../Renderer/../Basics/Vectors.h: In member function
'FLOATVECTOR3 tuvok::AbstrRenderer::GetViewDir() const':
Renderer/../Renderer/../Basics/Vectors.h:295:58: warning:
'anonymous.VECTOR3float::x' is used uninitialized in this function
[-Wuninitialized]
T length() const FUNC_CONST {return sqrt(T(x*x+y*y+z*z));}
^
Renderer/AbstrRenderer.cpp:1598:17: note: 'anonymous' was declared here
return (m_vAt-m_vEye).normalized();
^
In file included from Renderer/../Renderer/CullingLOD.h:43:0,
from Renderer/AbstrRenderer.h:47,
from Renderer/AbstrRenderer.cpp:41:
Renderer/../Renderer/../Basics/Vectors.h:295:58: warning:
'anonymous.VECTOR3float::y' is used uninitialized in this function
[-Wuninitialized]
T length() const FUNC_CONST {return sqrt(T(x*x+y*y+z*z));}
^
Renderer/AbstrRenderer.cpp:1598:17: note: 'anonymous' was declared here
return (m_vAt-m_vEye).normalized();
^
In file included from Renderer/../Renderer/CullingLOD.h:43:0,
from Renderer/AbstrRenderer.h:47,
from Renderer/AbstrRenderer.cpp:41:
Renderer/../Renderer/../Basics/Vectors.h:295:58: warning:
'anonymous.VECTOR3float::z' is used uninitialized in this function
[-Wuninitialized]
T length() const FUNC_CONST {return sqrt(T(x*x+y*y+z*z));}
^
Renderer/AbstrRenderer.cpp:1598:17: note: 'anonymous' was declared here
return (m_vAt-m_vEye).normalized();
^
ref:
https://buildd.debian.org/status/fetch.php?pkg=imagevis3darch=hurd-i386ver=3.0.0-2%2Bb1stamp=1384473975
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733720: ITP: r-bioc-gviz -- Plotting data and annotation information along genomic coordinates
Package: wnpp Severity: wishlist Owner: Andreas Tille ti...@debian.org * Package name: r-bioc-gviz Version : 1.6.0 Upstream Author : Florian Hahne, Steffen Durinck, e.a. * URL : http://bioconductor.org/packages/release/bioc/html/Gviz.html * License : Artistic-2.0 Programming Lang: R Description : Plotting data and annotation information along genomic coordinates Genomic data analyses requires integrated visualization of known genomic information and new experimental data. Gviz uses the biomaRt and the rtracklayer packages to perform live annotation queries to Ensembl and UCSC and translates this to e.g. gene/transcript structures in viewports of the grid graphics package. This results in genomic information plotted together with your data. This package is the last missing precondition to upgrade r-bioc-cummerbund and maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-gviz/trunk/ -- 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 system thoughts
]] Steve Langasek In any case, systemd does indeed support this case; simply make your service depend on network-online.target, which will block for a reasonable amount of time to see if a network interface comes online, and eventually time out if that doesn't occur. This will actually work even if your primary network is a wireless network managed by NetworkManager, and even if that network doesn't actually work until the user has logged in, assuming your service is not actually in the dependency path of the user logging in. And what makes this work in the case where you *aren't* using NetworkManager? I see no integration with ifupdown in the systemd package. There is none, and it would not be ifupdown-specific. We could easily enough add a «wait for a default ipv4 and ipv6 default route to appear» unit if somebody desired that, which would be pulled in by network-online.target. It's a pretty trivial piece of code. Alternatively, just put systemctl start network-online.target into a fragment in if-up.d if you consider ifup considering a network interface up to be enough. (I don't, but as pointed out on the systemd wiki page referenced, people have different ideas about what «network online» means.) -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726763: Bug#727708: systemd-shim uploaded to NEW
On Mon, Dec 30, 2013 at 09:52:37PM +0100, Tollef Fog Heen wrote: ]] Ian Jackson Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW): So I repeat here my request that the systemd maintainers make a suitable split of the systemd binary package, so that systemd-shim will be coinstallable with the systemd-provided implementations of the other dbus services. Is there a summary of the systemd maintainers' response to this request ? I glanced #726763 and #729576 but they were very long and if the answer is in there I probably wouldn't have found it. I see no point in doing that, in particular not in the middle of when the ctte is choosing a new default init system. If anything, I think it's pretty rude of Steve to upload systemd-shim and asking the systemd maintainers to solve the problem for him. Conversely, I think it's rude of everyone involved in having created this bug to be pointing fingers at each other and disclaiming all responsibility for fixing it, while in the meantime users of unstable are being left with silently broken desktops on upgrades. Even if Debian ultimately decides for systemd, that doesn't do the least bit of good for users who suddenly find suspend not working on their systems right now. The only alternative I see is for systemd-shim to declare a Replaces: against systemd without a Conflicts, This would be quite wrong; Replaces is not supposed to be used like that (but you apparently know that). How do the systemd maintainers think this problem should be solved ? Initially, by waiting for the ctte to come to a conclusion. If that is that systemd should be the default init system I think we should solve the problem by not solving it. If the decision is that another init system should be solved, I'm probably going to solve it by removing the init functionality from the systemd package at which point the bug solves itself, AIUI. If the systemd-shim maintainers want to solve it in the meantime, going with Raphael's suggestion seems reasonable enough. So given that dpkg-divert can't be used for the conffile, is this still your position? This means that divert+Replaces is the only other option, which will result in the conffile being removed if systemd-shim is installed and then purged. -- 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#697841: ufvconvert requires libQtOpenGL.so.4
Control: found -1 3.0.0-2 Bug #697841 is hard to fix. Indeed: $ readelf -d /usr/bin/uvfconvert [...] 0x0001 (NEEDED) Shared library: [libGLU.so.1] 0x0001 (NEEDED) Shared library: [libQtOpenGL.so.4] 0x0001 (NEEDED) Shared library: [libQtGui.so.4] But at the same time: $ ldd -u -r /usr/bin/uvfconvert - none ! Need to talk with upstream why a command line tool needs so much stuff from Qt -- 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 system thoughts
On Mon, Dec 30, 2013 at 6:55 PM, Colin Watson cjwat...@debian.org wrote: The criticisms of Upstart's event model in the systemd position statement simply do not make sense to me. Events model how things actually happen in reality; dependencies are artificial constructions on top of them, and making them work requires the plethora of different directives in systemd (e.g. Wants, which is sort of a non-depending dependency) to avoid blocking the boot process on a single failing service. Yes, there are some bugs possible in the Upstart design, but I don't agree that those are world-ending fundamental issues and I think they're generally incrementally fixable. The systemd design appears to me to expose far more complexity to the user writing unit files, and I think it's important that their mental model be as straightforward as possible. (Now, I've been working with Upstart's model for years, and it's now a pretty fundamental way of how I think of system operation; so if people who are new to *both* models rather than partisans of one side or the other consistently tell me that the systemd model is easier to grasp, then I'll listen.) I would like to give my view of the event vs. dependency model. I will declare my conclusion up front: Upstart's event model is, in my opinion, more flexible, and much more compatible with socket activation than systemd's dependency model (which is ironic, since Upstart does not stress socket activation, and systemd does). I will start with an example including syslog, dbus, and NetworkManager. One way a distribution developer would write these job files is by saying start on syslog-started and stop on syslog-stopped for dbus. Although this may seem like the obvious way to write the job, it is not the most efficient. This is what I will call an always on job. Whenever it is possible for this job to be on (its dependencies have started, and the job is enabled) it will be on. This can cause slow boot, because a ton of jobs are being started that do not need to be. This is the fault of //the distribution developer//, not Upstart itself. Now, lets imagine this developer stopped for a second to think before denouncing Upstart as inefficient crap. He knows that his dbus job was probably not efficient, and he wants to try to make a more efficient NetworkManager job. So, the developer crafts a start on dbus-started and /* dbus signal received */ stop on dbus-stopped or /* dbus signal not received */ So this is cool. NetworkManager is started not simply when it is able to start, but also when it needs to start. It stops when dbus stops (its dependencies are unavailable) or when it is not needed by anyone. What is great about Upstart's model is its flexibility. Example: start on dbus-started and /* dbus address accessed */ stop on dbus-stopped This starts NetworkManager when its services are required, but then keeps it running even after they are not, until it can no longer provide its services. This may be desirable in some situations (maybe starting and stopping nm a lot is unwanted), and shows how this event model puts more control in the job, rather than a config file. Now lets say that developer realizes how powerful the event model is, and goes back to reimplement his dbus job. He/she wants dbus to be running only when its services are needed. start on syslog-started and /* socket event aimed at dbus */ stop on syslog-started or /* no socket events toward dbus */ Now, this changes things around, and the NetworkManager job needs to modified to not wait for dbus to start, but just access the socket and let Upstart automatically start dbus following that event. start on dbus SIGNAL= stop on dbus-stopped I think this usage of Upstart's event model is incredibly superb, and much more understandable and usable than systemd's socket and bus activation model. Although systemd's declarative syntax is simple, I think it offers too little flexibility and does not reflect the realities of the system to the unit, which makes the declarative syntax an abstraction that needs to be understood by the admin, or it will be misused. Furthermore, with a little work put into Upstart's socket event bridge and socket handling (which should not be a problem since the infrastructure is already there), the boot time speed ups and socket based activation model of systemd can be achieved with only a little effort, and considerably more flexibility. Good night, Cameron Norman
Bug#721929: gnome-open ?
It may be related to: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685304 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#719208: file conflicts in mediawiki / mediawiki-extensions
Hi *, I’ve had a look at this again. Helmut had suggested that I split the installed trees between core and extensions into two separate directories (instead of combining them into one directory with entries being sometimes symlinks, sometimes directories, under /var/lib/mediawiki/extensions), but this would be futile: hundreds of files (in core, core-extensions and extra-extensions) hardcode the path. I shall be trying something else. bye, //mirabilos -- tarent solutions GmbH Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/ Tel: +49 228 54881-393 • Fax: +49 228 54881-314 HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941 Geschäftsführer: Boris Esser, Sebastian Mancke -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733685: at-spi2-atk: Please use dh-autoreconf at build time, to support new ports
Cyril Brulebois, le Tue 31 Dec 2013 02:35:16 +0100, a écrit : Looks fine to me. I was about to merge and upload, but packaging for 2.10.2-1 seems to be missing from the git repository. Samuel, can you please push your branch tag? Oops, sorry, there they are. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733721: lrzsz: packages source missing homepage and Vcs-* fields
Package: lrzsz Version: 0.12.21-7 Severity: minor Hi! The package is missing both the Homepage and Vcs-* fields in debian/control. The homepage is still available [1] even though it does not carry the latest version which is available in Debian. As for the Vcs-*, those are always very handy to have when backporting or forking the package or writing patches. It might also be a good idea to update the copyright file to the new format 1.0 when doing these updates. Thanks for the recent updates to lrzsz. Adrian [1] https://ohse.de/uwe/software/lrzsz.html -- 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.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lrzsz depends on: ii libc6 2.17-97 lrzsz recommends no packages. Versions of packages lrzsz suggests: ii minicom 2.6.2-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726763: Bug#727708: systemd-shim uploaded to NEW
Steve Langasek wrote: Looking more closely, I find that one of the conflicting files is a conffile (/etc/dbus-1/system.d/org.freedesktop.systemd1.conf). diversions and conffiles still don't mix, AFAIK (and according to current policy). So that seems to still leave us without a proper solution that doesn't involve splitting the systemd binary package. Files in /etc/dbus-1/system.d/ need not have names that match the interface they control; see, for instance, gdm.conf or nm-dhcp-client.conf. Why not simply install a systemd-shim.conf with the contents you need? To the best of my knowledge, I see nothing in org.freedesktop.systemd1.conf that should interfere with you. (That said, personally I'd prefer to see systemd-shim continue to conflict with systemd, and work with a hypothetical forked-systemd-logind package instead, which would also conflict with systemd. That would then, for instance, unblock systemd's ability to upgrade past version 204.) - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#670624: git-buildpackage: should not run clean command in the non-exported directory when using --git-export-dir
Hi, On Fri, 09 Nov 2012, Raphael Hertzog wrote: On Thu, 08 Nov 2012, Guido Günther wrote: So you're suggesting to not run clean by default? Or only when using --export-dir? I'm suggesting that when --export-dir is present, then git-buildpackage should not call debian/rules clean in the git repository. When --export-dir is not present, it's ok since dpkg-buildpackage would call it anyway a bit later. And it allows you to distinguish between an unclean tree due to changes/bugs from an unclean tree due to a former build, so it's certainly ok to keep it. Ping, could we have the bug fixed ? It annoys the hell out of me every time that I stumble on a upstream package whose make clean is broken and where I add the required patch but since the git repository doesn't have the patch applied, the build fails and I have to work around this annoying behaviour of git-buildpackage. I have now started using debian/gbp.conf with cleaner = /bin/true as work-around but it's a poor work-around IMO and I'd rather see the bug fixed. Cheers, -- Raphaël Hertzog ◈ Debian Developer Discover the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733320: ITA: empire - the war game of the century
Hi! I have pushed a new version to http://anonscm.debian.org/gitweb/?p=pkg-games/empire.git I'm quite happy with it but some changes/patches need more testing. So we shouldn't rush things here. I think the first or second week of January is a realistic date for a release. And now Happy New Year und Guten Rutsch! Markus signature.asc Description: OpenPGP digital signature
Bug#733723: ruby-rmagick: FTBFS on i386: stroke_linecap.rb:42:in `draw': pixels are not authentic
Package: ruby-rmagick Version: 2.13.2-1 Severity: serious Justification: fails to build from source (but built successfully in the past) Dear Maintainer, ruby-rmagick failed to build from source on i386. Excerpt from https://buildd.debian.org/status/fetch.php?pkg=ruby-rmagickarch=i386ver=2.13.2-1stamp=1380584926 /usr/bin/ruby1.9.1 -I /«PKGBUILDDIR»/./lib -I /«PKGBUILDDIR»/./ext/RMagick stroke_dasharray.rb (example 154 of 188) /«PKGBUILDDIR»/lib/RMagick.rb:1836: warning: assigned but unused variable - current /usr/bin/ruby1.9.1 -I /«PKGBUILDDIR»/./lib -I /«PKGBUILDDIR»/./ext/RMagick stroke_fill.rb (example 155 of 188) /«PKGBUILDDIR»/lib/RMagick.rb:1836: warning: assigned but unused variable - current /usr/bin/ruby1.9.1 -I /«PKGBUILDDIR»/./lib -I /«PKGBUILDDIR»/./ext/RMagick stroke_linecap.rb (example 156 of 188) /«PKGBUILDDIR»/lib/RMagick.rb:1836: warning: assigned but unused variable - current stroke_linecap.rb:42:in `draw': pixels are not authentic `' @ error/cache.c/QueueAuthenticPixelCacheNexus/4387 (Magick::ImageMagickError) from stroke_linecap.rb:42:in `main' setup.rb: Too many examples failed. Search for Help! at http://rmagick.rubyforge.org/install-faq.html. post-setup.rb: stroke_linecap.rb example returned error code pid 19738 exit 1 This build failure has delayed migration to testing for 91 days. Christian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727085: Now we don't depend on the weird libevent patch
On Tue, Dec 31, 2013 at 3:45 AM, Faidon Liambotis parav...@debian.org wrote: On Mon, Dec 30, 2013 at 12:56:48AM +0100, László Böszörményi (GCS) wrote: Two weeks is probably too often for Debian but time-based releases in general (rather than important bugfix) are fairly common. I think the original idea of accumulating multiple sprints into one community release is a great path forward. The proposal for 8-week releases sounds just fine to me. I meant there's no force on FB to do community releases. Two weeks releases is a bit fast, right. On the other hand as I see the releases get QA care. Upload bigger changes (8 weeks time) may be worse as they may contain more backward incompatible changes. Also the maintainer can decide how s/he uploads those releases. Maybe those will go to experimental and say, every month after one more week test time the package would be uploaded to Sid. Then users can get the fast moving package in experimental with the more tested, monthly updates in Sid. Maybe just follow upstream changelog and upload new releases when s/he thinks so (new feature, bugfix needed for Debian - but maybe just backport that fix), etc. Some upstreams tend to release some LTS releases for such uses, potentially labeling one of their incremental releases as LTS. This isn't a prerequisite, but it's good to actually have some longer stable/security management in mind when planning your release schedule. +1 on LTS releases; like Ubuntu does with its distribution. Well, noone really forced you to ITP this :) You definitely seem to have your hands full, there's no need for you to take on more than you're able to handle. If you're too busy, I can just takeover this ITP, just say so. I realize my lines sound worse than I wanted to. Yes, it's a bit hard now, but my second work is project based and I expect to finish it in a month or two. Some of my packages are team or co-maintained. I work 48 hours + a normal day because we had too many free days left for December. It's me who let others go on holiday and take off their free days. We are a group of eight persons, but due to the reason mentioned, today only two of us are working. Tomorrow only me, but from the 2nd of January everyone will be back on track. Even today I've time to make a tea and drink it passionate or answer my mails. Last but not least I've a half-baken package already. Now my previous package section for HHVM, which I've named hiphop-php (to match the PHP policy of Debian, but will re-check that): Which section of the policy mandates that? I'd be very suprised if the existing PHP policy covers alternative interpeters. To match _generic_ package names. It doesn't have any part about interpeter. Also as Paul noted, the package should be named HHVM now. The php-hhvm package name comes to my mind or just hhvm. The last two lines are incorrect considering the new FastCGI mode of operation, which AIUI will be the only one actually offered by the package, as the embedded standalone webserver requires patches to libevent. Sure, I've mentioned it was the _previous_ package description. I think packaging for Debian is a good step. Then Ubuntu maintainers will pick it up and as I know, Mint based on Ubuntu, they will have it as well. Ubuntu automatically syncs from Debian, there's no need for Ubuntu maintainers to do anything. As I heard, it's semi-automatic. They have their transitions when they don't sync everything and changes over Debian packaging that needs manual adjustments. Also my package delaboratory is not in Ubuntu for an unknown reason to me. It doesn't have any RC bug, not a big or unsupportable one, built on all archs, etc. Laszlo/GCS -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733724: ohcount: Build-Depends on ruby1.8
Package: ohcount Version: 3.0.0-7 Severity: normal Dear Maintainer, Your package Build-Depends on upstream-unmaintained ruby1.8. The Debian Ruby team wants to remove ruby1.8 from sid and jessie soon [1], which will cause your package to fail to build. Please migrate to ruby 1.9 / 2.0. Thank you, Christian [1] https://wiki.debian.org/Teams/Ruby/Jessie -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733320: ITA: empire - the war game of the century
Hi! On 12/31/2013 10:53 AM, Markus Koschany wrote: I'm quite happy with it but some changes/patches need more testing. So we shouldn't rush things here. I think the first or second week of January is a realistic date for a release. And now Cool! I'll look into it next year :). Happy New Year und Guten Rutsch! The same to you, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 signature.asc Description: OpenPGP digital signature
Bug#733725: error: unable to find a register to spill in class 'FP_REGS'
Package: vips
Version: 7.36.5-1
Severity: normal
User: debian-sp...@lists.debian.org
Usertags: sparc64
vips cannot currently be compiled on sparc64, it fails with:
/bin/bash ../../libtool --tag=CXX --mode=compile g++
-DHAVE_CONFIG_H -I. -I../.. -I../../libvips/include
-DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -pthread -fopenmp
-I/usr/lib/sparc64-linux-gnu/glib-2.0/include
-I/usr/include/sparc64-linux-gnu -I/usr/include/pango-1.0
-I/usr/include/orc-0.4 -I/usr/include/openslide -I/usr/include/libxml2
-I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/harfbuzz
-I/usr/include/glib-2.0 -I/usr/include/freetype2
-I/usr/include/OpenEXR -I/usr/include/ImageMagick
-D_FORTIFY_SOURCE=2 -g -O2 -fPIE -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -c -o
lbb.lo lbb.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../..
-I../../libvips/include -DG_DISABLE_ASSERT -DG_DISABLE_CHECKS -pthread
-fopenmp -I/usr/lib/sparc64-linux-gnu/glib-2.0/include
-I/usr/include/sparc64-linux-gnu -I/usr/include/pango-1.0
-I/usr/include/orc-0.4 -I/usr/include/openslide -I/usr/include/libxml2
-I/usr/include/libpng12 -I/usr/include/libexif -I/usr/include/harfbuzz
-I/usr/include/glib-2.0 -I/usr/include/freetype2
-I/usr/include/OpenEXR -I/usr/include/ImageMagick -D_FORTIFY_SOURCE=2
-g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -c lbb.cpp -fPIC -DPIC -o .libs/lbb.o
lbb.cpp: In function 'void
vips_interpolate_lbb_interpolate(VipsInterpolate*, void*, VipsRegion*,
double, double)':
lbb.cpp:849:1: error: unable to find a register to spill in class 'FP_REGS'
}
^
lbb.cpp:849:1: error: this is the insn:
(insn 1682 1731 1683 5 (set (reg:DF 64 %f32 [orig:2739 D.23872 ] [2739])
(float:DF (reg:SI 2740 [ MEM[base: p_112, index: _3441,
offset: 0B]+-3 ]))) lbb.cpp:746 155 {floatsidf2}
(expr_list:REG_DEAD (reg:SI 2740 [ MEM[base: p_112, index: _3441,
offset: 0B]+-3 ])
(expr_list:REG_EQUIV (mem:DF (plus:DI (reg/f:DI 14 %sp)
(const_int 2359 [0x937])) [0 S8 A64])
(nil
lbb.cpp:849: confused by earlier errors, bailing out
ref:
http://buildd.debian-ports.org/status/fetch.php?pkg=vipsarch=sparc64ver=7.36.5-1stamp=1387688423
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733726: wordpress: New upstream version (3.8)
Package: wordpress Severity: wishlist There's a new upstream version of Wordpress available. It needs to be packaged for Debian unstable. I have put in copy all the persons who got in touch with me to volunteer for the task. Some are experienced (Ean Schussler, Craig Small) and some are just starting with Debian packaging (Pablo Vasquez, Nicolas). Are the experienced people willing to review the work of the less experienced one? Who is up for the task? Pablo is the only person who contributed since the time when he volunteered but needed a bit of handholding to get his first task done. Pablo, do you know how to work with git-buildpackage to package a new upstream version? Beware wordpress is special as we need to repack the upstream tarball. This can be done with debian/rules get-orig-source VERSION=3.8 and you then need to work from this generated tarball. Cheers, -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=fr_FR.utf8, LC_CTYPE=fr_FR.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#329192: I echo Peter Green's comment
Peter Green wrote: If a message that is too large for the smarthost to accept gets into the queue this can waste MASSIVE ammounts of bandwidth This happened to me, except in my case it was on the public internet. I cannot recommend using nullmailer with a bug like this in it, it's catastrophic. -dan -- d...@telent.net http://ww.telent.net
Bug#733648: patch updated
I have updated the patch to make it compatible with kfreebsd_amd64, if wine is built for that architecture too. I've also tidied it up. Regards diff -ur wine-1.6.1-8/debian/scripts/wine wine-1.6.1/debian/scripts/wine --- wine-1.6.1-8/debian/scripts/wine 2013-12-30 04:29:20.0 +0100 +++ wine-1.6.1/debian/scripts/wine 2013-12-31 11:10:02.937957214 +0100 @@ -2,14 +2,65 @@ set -e -wine=/usr/lib/i386-linux-gnu/wine/bin/wine32 -if [ $(file -b -L $1 | cut -d\ -f1) = PE32+ ]; then -wine=/usr/lib/x86_64-linux-gnu/wine/bin/wine64 +WINE32= +WINE64= + +#detect which wine binaries are present +if test -x /usr/lib/i386-linux-gnu/wine/bin/wine32 + then WINE32=/usr/lib/i386-linux-gnu/wine/bin/wine32 +elif test -x /usr/lib/powerpc-linux-gnu/wine/bin/wine32 + then WINE32=/usr/lib/powerpc-linux-gnu/wine/bin/wine32 +elif test -x /usr/lib/i386-kfreebsd-gnu/wine/bin/wine32 + then WINE32=/usr/lib/i386-kfreebsd-gnu/wine/bin/wine32 +fi +if test -x /usr/lib/x86_64-linux-gnu/wine/bin/wine64 + then WINE64=/usr/lib/x86_64-linux-gnu/wine/bin/wine64 +elif test -x /usr/lib/x86_64-kfreebsd-gnu/wine/bin/wine64 + then WINE64=/usr/lib/x86_64-kfreebsd-gnu/wine/bin/wine64 fi -if [ -f $wine ]; then -$wine $@ +#at least one of the two architectures should be present +if test -z $WINE32 -a -z $WINE64 + then echo Your installation of wine appears to be broken. Please assure you have met all dependencies.2 + exit 127 +#if only 32 or 64 bit exist, use that +elif test -n $WINE32 -a -z $WINE64 + then wine=$WINE32 +elif test -z $WINE32 -a -n $WINE64 + then wine=$WINE64 +#from here on, both WINE32 and WINE64 are valid +#if WINEARCH is set, that overrides anything else +elif test -n $WINEARCH + then if test $WINEARCH = win32 + then wine=$WINE32 + elif test $WINEARCH = win64 + then wine=$WINE64 + else echo Variable WINEARCH is set to an invalid value.2 + exit 126 + fi +#if wine is executed on a file, determine whether it's 32 or 64 bit +elif test -f $1 + then if [ $(file -b -L $1 | cut -d\ -f1) = PE32+ ] + then wine=$WINE64 + else wine=$WINE32 + fi +#otherwise, try to guess from the profile else -echo unable to find wine executable: the $(basename $wine) package probably needs to be installed. -exit 1 + #if no WINEPREFIX is given, use default + if test -z $WINEPREFIX + then WINEPREFIX=$HOME/.wine + fi + #if WINEPREFIX already exists, use corresponding arch + if test -f $WINEPREFIX/system.reg + then WINEARCH=$(cat $WINEPREFIX/system.reg|grep #arch|sed -e s/'#arch='/''/) + if test $WINEARCH = win64 +then wine=$WINE64 +else wine=$WINE32 + fi + #if PROFILE does not exist yet, use default profile for maximum compatibility + else wine=$WINE64 + fi fi + +#actually run the program +$wine $@
Bug#721929: gnome-open: not found
Mathieu Malaterre writes: Control: tags -1 help I have been starring at the source code but I cannot find where in the code 'gnome-open' is being called. IV3D does not use it directly. It is probably coming from QDesktopServices::openUrl in ImageVis3D_Help.cpp (despite the name, the API also opens local files). See the OpenManual method for more details. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733727: wine32: /usr/lib/i386-linux-gnu/wine/bin/wine32: could not open
Package: wine32
Version: 1.6.1-10
Severity: grave
Running any program results in the message
/usr/lib/i386-linux-gnu/wine/bin/wine32: could not open
and an unsuccessful exit. AFAICT, this message comes from
wine-preloader; here is the tail from strace -f wine32 notepad:
,
| 16196 readlink(/proc/self/exe, /usr/lib/i386-linux-gnu/wine/bin/wine,
256) = 37
| 16196 stat64(/usr/lib/i386-linux-gnu/wine/bin/wineserver,
{st_mode=S_IFREG|0755, st_size=424352, ...}) = 0
| 16196 execve(/usr/lib/i386-linux-gnu/wine/bin/wine-preloader,
[/usr/lib/i386-linux-gnu/wine/bin..., /usr/lib/i386-linux-gnu/wine/bin...,
notepad], [/* 42 vars */]) = 0
| 16196 set_thread_area({entry_number:-1 - 12, base_addr:0x7c402080,
limit:1048575, seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1,
seg_not_present:0, useable:1}) = 0
| 16196 old_mmap(NULL, 65536, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0xffd6226008fa1028) = -1
EPERM (Operation not permitted)
| 16196 old_mmap(0x1, 1048576, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0xffd6226008fa1028) =
0x1
| 16196 old_mmap(0x11, 1743716352, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0xffd6226008fa1028) =
0x11
| 16196 old_mmap(0x7f00, 50331648, PROT_NONE,
MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS|MAP_NORESERVE, -1, 0xffd6226008fa1028) =
0x7f00
| 16196 mprotect(0x7000, 4096, PROT_READ|PROT_EXEC) = 0
| 16196 open(/usr/lib/i386-linux-gnu/wine/bin/wine32, O_RDONLY) = -1 ENOENT
(No such file or directory)
| 16196 write(2, /usr/lib/i386-linux-gnu/wine/bin..., 56) = 56
| 16196 _exit(1) = ?
`
Symlinking /usr/bin/wine32 to /usr/lib/i386-linux-gnu/wine/bin/ fixes
the problem.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (101, 'experimental')
Architecture: i386 (x86_64)
Kernel: Linux 3.13.0-rc6-nouveau (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 wine32 depends on:
ii libc6 2.17-97
ii libwine1.6.1-10
ii libwine-gecko-1.4 1.4+dfsg1-3
ii x11-utils 7.7+1
wine32 recommends no packages.
wine32 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#733706: installation-report: installation on a Lenovo Thinkpad E431
Hi anarcat, On 31.12.2013 05:00, anarcat wrote: Comments/Problems: Install went generally well and fast. There was a problem installing the boot loader during the install, and although I didn't investigate during the install, when I rebooted, grub was not installed in the MBR and I was brought back into windows. It turns out this thing boots using UEFI, and I had to turn that off in the BIOS for the boot loader to work at all. I also had to manually go back using the live USB stick to install grub2, which wasn't installed, although grub1 maay have been installed without me noticing. Installing on UEFI firmware is supported, but is a little bit tricky, see for example [1]. Particularly you need a GPT partitioned hard disk with two additional partitions, one EFI partition marked with the 'boot' flag in gparted and a partition for grub marked as 'bios_grub' in gparted. Then the installer has to support installing on UEFI, which the default installer does, but I don't know about the one you created. Last but not least, you have to select the UEFI:USB in the firmware and not BIOS:USB, which every firmware has a different marking scheme for, but disabling legacy-bios (or equivalent option) in the UEFI BIOS, should always disable the BIOS:USB option. (It can be enabled again after installation.) The next missing thing was wifi. I tried installing firmware-linux- nonfree, but that wasn't enough - firmware-iwlwifi was the one that was required. The installer should install the correct firmware, if you have (on some partition accessible during installation) a /firmware folder that contains the unpacked firmware bundle, which can be downloaded from [2]. But this is currently broken, see [3]. I also had to go in the gnome control center to make sure the touch pad works as expected. What exactly did you have to do in the gnome control center? What do you mean by 'works as expected'? Wanting this thing to be pretty, I also had to manually install plymouth to get a nicer boot up sequence, *and* I had to edit /etc/default/grub to make that work (add the splash parameter), something I wouldn't expect a novice to be able to do at all on a first install. While I also prefer having plymouth installed, I think there are many users that prefer not to have it, so one cannot make everyone happy with the default installation. That being said, I think it really might be a good idea to install plymouth by default, as 'novices' generally prefer it, and anyone who wants to see the boot messages should have sufficient knowledge to remove it. Best regards and a happy new year, Andreas 1: http://www.rodsbooks.com/linux-uefi/ 2: http://cdimage.debian.org/cdimage/unofficial/non-free/firmware/ 3: http://bugs.debian.org/725714 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733642: pu: package nut/2.6.4-2.3
On 2013-12-31 00:03, Cyril Brulebois wrote: Jonathan Wiltshire jmw+deb...@tiger-computing.co.uk (2013-12-30): Please accept this trivial fix for USB timeouts in nut. It's fixed upstream and in sid, and I've reproduced it in Wheezy on some of our client sites. The patch fixed the problem there with no other ill effects. Debdiff attached. Looks good to me, please go ahead. Uploaded. Thanks, -- Jonathan Wiltshire j...@debian.org Debian Developer http://people.debian.org/~jmw 4096R: 0xD3524C51 / 0A55 B7C5 1223 3942 86EC 74C3 5394 479D D352 4C51 directhex i have six years of solaris sysadmin experience, from 8-10. i am well qualified to say it is made from bonghits layered on top of bonghits -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#697841: ufvconvert requires libQtOpenGL.so.4
Mathieu Malaterre writes: Control: found -1 3.0.0-2 Bug #697841 is hard to fix. Indeed: $ readelf -d /usr/bin/uvfconvert [...] 0x0001 (NEEDED) Shared library: [libGLU.so.1] 0x0001 (NEEDED) Shared library: [libQtOpenGL.so.4] 0x0001 (NEEDED) Shared library: [libQtGui.so.4] But at the same time: $ ldd -u -r /usr/bin/uvfconvert - none ! Need to talk with upstream why a command line tool needs so much stuff from Qt Yeah, we'd *love* if the Qt dependency could be removed, too. Unfortunately we use Qt for loading images, and thus need it to do batch conversion of image sets, a fairly popular use case. We could use something like FreeImage, but don't want to add another dependency just for this. The other option is coding specifically for libpng and libtiff directly (I think we already have code specific to jpeg, due to IJG's jpeg not sufficing). libpng and libtiff are already deps due to Qt, so it doesn't add anything to our set of dependencies. Patches welcome... -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733721: lrzsz: packages source missing homepage and Vcs-* fields
On 12/31/2013 11:45 AM, Martin Godisch wrote: Homepage field is already present. Oops, sorry, I completely missed that. Was probably thinking of minicom. As for the Vcs fields all information I can find point to tirka.ohse.de, which resolves to 192.168.2.3. Those fields are supposed to point to the repository where you as the maintainer keep the packaging sources, see here [1]. See also one of my packages, fs-uae [2], for example. Adrian [1] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-VCS-fields [2] http://packages.qa.debian.org/f/fs-uae.html -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#722959: quilt: patches wrong file
Hello, It's quite some time and I trashed both the package and the particular version of quilt. quilt .60 has quite a few other oddities - like it fails quite colorfully when patch names contain some characters special for whatever interpreter it uses. Hopefully quilt .61 no longer has this issue either. Thanks Michal -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
Hi Julian, On 12/31/2013 01:29 AM, Julian Andres Klode wrote: On Sun, Dec 29, 2013 at 12:06:18PM +0100, Michael Schaller wrote: Package: python-apt Version: 0.9.2 Severity: wishlist Tags: patch This patch does far too many things that are not even remotely connected. Fine by me. It's always hard for me to judge the right patch size if I contribute the first time to a project. I'm already happy that the overall idea of the patch seems to be acceptable. ;-) From 0d295006a98769cd6151c78b3a078ad92d8047ee Mon Sep 17 00:00:00 2001 From: Michael Wisheu mich...@5challer.de Did you change your surname after writing the patch? Good catch! I've got married two months ago and took my wife's last name. I'm still hunting down all the occurrences of my old last name and it looks like I've still had the old name in my git config. I wonder how I've managed to change my mail address but not my name... *sigh* Anyhow... If you think this name change is fishy please let me know and I'll proof to you my identity and that the name change happened. Date: Sun, 29 Dec 2013 11:57:19 +0100 Subject: [PATCH] * apt/cache.py: - Fixed PEP8 linter and pyflakes issues - Added 'InstalledFilter' to get a filtered cache that only contains the currently installed packages. * apt/packages.py: - Fixed PEP8 linter issues The PEP8 stuff should be separate. The InstalledFilter should be separate - Removed special handling of 'collections' import as all supported distributions have Python 2.6 or newer by now. This should be separate - Replaced faulty 'BaseDependency.__dstr' with easier to read compat code. This should be separate - Added new properties to 'Dependency' and 'BaseDependency' to get the target package versions that could satisfy a dependency. Only this should be the patch. Before I start sending smaller patches could you please tell me if I should open new bugs or if we can handle all this in this one bug? Best, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726073: Processed: Re: libcurl3-nss: tries to use libnsspem, which is not provided by libnss3
On Mon, Dec 30, 2013 at 11:04:48AM -0800, Jonathan Nieder wrote:
block 726073 by 726116
quit
(culling cc list)
Hi,
Alessandro Ghedini wrote:
On ven, dic 27, 2013 at 11:24:11 +, Debian Bug Tracking System wrote:
Processing commands for cont...@bugs.debian.org:
affects 726073 + git src:git
Bug #726073 [libcurl3-nss] libcurl3-nss: tries to use libnsspem, which is
not provided by libnss3
Added indication that 726073 affects git and src:git
Care to explain how this affects git, considering that it uses
libcurl3-gnutls?
Time permitting, I'd like to switch git to using libcurl3-gnutls (for a
few different reasons --- sidestepping the libgmp licensing issue is
one, and the possibility of better interoperability with some broken
servers is another). Using affects makes it easier for me to track
this bug when working on the git package.
TBQH if ever libnss turned out to be a viable option, I'd seriously consider
switching curl to be libnss-only (like e.g. Red Hat does).
Also, there's not much I can do about this (except maybe dropping
libcurl3-nss
altogether), and since we have #726116 tracking this now, I'm inclined to
close
this report.
Could we keep it open? It's the only report that tracks the symptom
instead of that specific proposed fix --- e.g., if libcurl could use the
shared nssdb instead of PEM certificates when using the NSS backend,
that would be a fine way to solve this.
Ok, makes sense.
--
perl -E '$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'
signature.asc
Description: Digital signature
Bug#637652: Re: dotconf: New upstream version 1.3 available
Hi Luke, I am looking into the changes that you and Jason provided, but I have a serious issue with your proposed debian/copyright file (that IIUC is already in Ubuntu, right?). There is no need to provide a new debdiff, but I like your response, before I decide what I will do. Biggest issue: you claimed sole copyright on all files in debian/ which is completely not true. Second issue: you put the GPL license on all files in debian/ without proof that you even consulted the current maintainer or Jason. Furthermore, it is not common to choose a different license than upstream for the packaging. E.g. patches would be impossible to ship upstream in this case. Therefore I think it should be the same as upstream, as Shane and Jason didn't make a statement about that. Of course you are free to put your work under GPL, but that just means I will not use it, as I find it too unpractical in *this* case. Third issue: you forgot that the current upstream maintainer also has copyright on the source of dotconf. Much lesser addition issue: I don't agree with the way you implemented the get-orig-source target. Debian prefers to have the exact same tar ball as released by upstream. This is obtainable at the following URL: https://github.com/williamh/dotconf/releases. So I propose the attached watch file instead of your target (and maybe call uscan in the get-orig-source, but that is not much gain then). Furthermore: 1) Running autoreconf doesn't help, as you want to do this during build time. It increases the tar ball drastically and because it is running an unversioned version of autoreconf might even result in a different orig.tar, which is exactly not what you want to achieve. 2) If you use a throw-away directory, use mktmp to create a proper temporary directory. @all: apparently upstream changed the soname, so this updates needs a transition as well. This means that I need to do some more checking (all reverse build dependencies) and that we need permission from the release managers. Also the new package needs to go through NEW so it might take some time there. Paul version=3 opts=filenamemangle=s/.+\/v?(\d\S*)\.tar\.gz/dotconf-$1\.tar\.gz/ \ https://github.com/williamh/dotconf/tags .*/v?(\d\S*)\.tar\.gz signature.asc Description: OpenPGP digital signature
Bug#733470: git-buildpackage: Please provide a command to dump (single values from) merged gbp.conf configuration files
On Mon, Dec 30, 2013 at 04:29:31PM +0100, Axel Beckert wrote: [..snip..] There's obviously some need, otherwise the Debian Perl Group wouldn't have implemented it and I wouldn't have modified it to be also usable with the Debian Zsh Team's git repositories where the debian-branch is debian instead of master and the upstream tags have a different syntax. Push the branch configured as debian-branch, the branch configured as upstream-branch, the pristine-tar branch, and all tags matching upstream-tag and debian-tag, to the remote origin. Maybe /usr/share/doc/git-buildpackage/examples/gbp-posttag-push is what you're (partially) after? (I'm reading this offline so I can't check your references yet). This posthook is intended to push up to the newly created tag (including the upstream branch). That's there reason why there's no gbp push (yet). 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#732666: about libvirt commit 96f9aae6a
On Mon, Dec 30, 2013 at 11:35:48PM +0100, phep wrote: Le 30/12/2013 16:34, Guido Günther a écrit : Current git will not mount the memory cgroup anymore by default - only with the cgroup_enable=memory cmdline. OK, thank you Guido, I think I got the whole thing clearer now; I misinterpreted your answer to Mike in message #20 in believing modifying the kernel cmdline should not be necessary with you patch. Thanks for checking! On the other hand, this new behaviour might deserve some notice in NEWS.Debian or changelog.Debian at least, yet. Isn't the notice about cgroups enough already? What else would you expect. 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#727708: upstart and upgrading from sysvinit scripts
On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote: The second supported option is DAEMON_OPTS, which sets additional flags to add to the process. For as long as we need to support multiple init systems, this option needs to stay in /etc/default/lbcd and be read from there by all supported init systems so that configuration is preserved as the user moves between init systems. I'd like to suggest that this should only be done for daemons where there is anything that a sysadmin can sensibly configure in this way. The patch proposed for #712167 (native Upstart init support in dbus) did this, but after checking the available command-line options in dbus-daemon, I couldn't actually find any command-line options that can be changed by a sysadmin without breaking system integration; so I think it's OK that the systemd unit doesn't read /etc/default/dbus, and I don't think the (potential future) Upstart job should either. If dbus-daemon had command-line options that made sense as local configuration, then reading /etc/default/dbus would be fine, but I've tried to avoid that in favour of having anything locally-configurable only be available in the (XML) configuration files, and not on the command-line: see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712167#20 for more on command-line options vs. configuration. (Perhaps this means /etc/init.d/dbus should stop reading /etc/default/dbus...) S -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732676: flashplugin-nonfree: Please leave the nosse2 option
Hello I updated my testing box, and now I don't have the flash plugin installed. I'm an happy user of the flashplugin-nonfree package, that have a Pentium III without sse2. I was so happy with the (now gone) --nosse2 option !! My last manual procedure for install the flash plugin that works in this box is: - Go to http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html - Find the newest 10.3 version and download the zip package. - Unzip it and get the XXX_linux.tar.gz package - Install the libflashplayer.so file. Today I make these steps and flash is working now !!. For make a help and solve this bug report, I look into the flashplugin-nonfree 3.3 source code at http://snapshot.debian.org/package/flashplugin-nonfree/1%3A3.3/ I see that the procedure in the file get-upstream-version.pl seems similar to my procedure (I know nothing about perl, but I can see the same url for the download)... Maybe, the confusion in the script is because now there are two versions 10.3 in http://helpx.adobe.com/flash-player/kb/archived-flash-player-versions.html, the first is Mac only (Released 7/9/2013), and the second is for all architectures (Released 6/11/2013). The last one is the version that works in my system !! :-D I don't know if this explanation is usefull. Many thanks for your hard work. Greetings. Martintxo. Sustrai Erakuntza: respuesta jurídico-técnica a proyectos insostenibles. proiektu jasangaitzei erantzun juridiko-teknikoa. http://www.fundacionsustrai.org http://www.sustraierakuntza.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On Tue, Dec 31, 2013 at 01:29:53AM +0100, Julian Andres Klode wrote: On Sun, Dec 29, 2013 at 12:06:18PM +0100, Michael Schaller wrote: [..] - Fixed PEP8 linter issues The PEP8 stuff should be separate. [..] Thanks for bringing up better pep8 compliance. I think something like the attached patch would nice to ensure that the code stays in the pep8 style. If there is consensus on this, I'm happy to make the test pass (i.e. make the rest of the code pep8 compatible). Cheers, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726763: Bug#727708: systemd-shim uploaded to NEW
* Raphael Hertzog hert...@debian.org, 2013-12-30, 19:42: dpkg-divert is the usual answer when you need/want to replace something without the consent of the other side. FWIW, Policy §3.9 reads: “You should not use ‘dpkg-divert’ on a file belonging to another package without consulting the maintainer of that package first.” -- 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#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
Hi Michael, From my experience PEP8 and pyflakes are great tools with nearly no false positives - especially compared to pylint - and by now they are available for Python 2 and 3. I personally like to add a lint command to setup.py to my projects. Maybe this would be beneficial for python-apt too. Please let me know if you would like to see a patch for that. Best, Michael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
On Tue, Dec 31, 2013 at 12:23:54PM +0100, Michael Schaller wrote: Hi Julian, On 12/31/2013 01:29 AM, Julian Andres Klode wrote: On Sun, Dec 29, 2013 at 12:06:18PM +0100, Michael Schaller wrote: Package: python-apt Version: 0.9.2 Severity: wishlist Tags: patch This patch does far too many things that are not even remotely connected. Fine by me. It's always hard for me to judge the right patch size if I contribute the first time to a project. I'm already happy that the overall idea of the patch seems to be acceptable. ;-) The overall idea seems right, I'm not so sure about the implementation details, though. But I first need smaller patches to be able to read the functional changes without the other changes getting in the way. From 0d295006a98769cd6151c78b3a078ad92d8047ee Mon Sep 17 00:00:00 2001 From: Michael Wisheu mich...@5challer.de Did you change your surname after writing the patch? Good catch! I've got married two months ago and took my wife's last name. I'm still hunting down all the occurrences of my old last name and it looks like I've still had the old name in my git config. I wonder how I've managed to change my mail address but not my name... *sigh* Anyhow... If you think this name change is fishy please let me know and I'll proof to you my identity and that the name change happened. That's not a problem. [...] Before I start sending smaller patches could you please tell me if I should open new bugs or if we can handle all this in this one bug? You can just git-send-email them to the mailing list or even push a git branch somewhere. -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. Please do not top-post if possible. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733728: rinse: Too short timeout in /usr/sbin/rinse (sub downloadURL)
Package: rinse Version: 2.0.1-1 Severity: important Dear Maintainer, The problem is that in line 1069 of /usr/sbin/rinse timeout of 10 is hardcoded, which is causing the problem when contacted server DNS and ARP are not cached by server, where rins is run. I've changed this timeout to 50, this have no significant impact on situations when timeout should really happend (50ms?) and solves the problem for real situations. -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/32 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 rinse depends on: ii libterm-size-perl 0.207-1 ii libwww-perl6.04-1 ii perl-modules 5.14.2-21 ii rpm4.10.0-5+deb7u1 ii wget 1.13.4-3 rinse recommends no packages. rinse suggests no packages. -- Configuration Files: /etc/rinse/rinse.conf changed: [rhel-5] mirror = http://your.mirror.to.rhel5.repository.here/rhel/5/i386/Server/ mirror.amd64 = http://your.mirror.to.rhel5.repository.here/rhel/5/x86_64/Server/ [centos-4] mirror = http://mirror.bytemark.co.uk/centos/4/os/i386/CentOS/RPMS/ mirror.amd64 = http://mirror.bytemark.co.uk/centos/4/os/x86_64/CentOS/RPMS/ [centos-5] mirror = http://mirror.bytemark.co.uk/centos/5/os/i386/CentOS/ mirror.amd64 = http://mirror.bytemark.co.uk/centos/5/os/x86_64/CentOS/ [centos-6] mirror = http://mirror.bytemark.co.uk/centos/6/os/i386/Packages/ mirror.amd64 = http://mirror.bytemark.co.uk/centos/6/os/x86_64/Packages/ [slc-5] mirror = http://linuxsoft.cern.ch/cern/slc5X/i386/SL/ mirror.amd64 = http://linuxsoft.cern.ch/cern/slc5X/x86_64/SL/ [slc-6] mirror = http://linuxsoft.cern.ch/cern/slc6X/i386/SLC/Packages/ mirror.amd64 = http://linuxsoft.cern.ch/cern/slc6X/x86_64/SLC/Packages/ [sl-6] mirror = http://ftp.icm.edu.pl/pub/Linux/dist/scientificlinux/6/i386/os/Packages/ mirror = http://ftp.icm.edu.pl/pub/Linux/dist/scientificlinux/6/x86_64/os/Packages/ [fedora-core-4] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/4/i386/os/Fedora/RPMS/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/4/x86_64/os/Fedora/RPMS/ [fedora-core-5] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/5/i386/os/Fedora/RPMS/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/5/x86_64/os/Fedora/RPMS/ [fedora-core-6] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/6/i386/os/Fedora/RPMS/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/core/6/x86_64/os/Fedora/RPMS/ [fedora-core-7] mirror = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/7/Fedora/i386/os/Fedora/ mirror.amd64 = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/7/Fedora/x86_64/os/Fedora/ [fedora-core-8] mirror = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/8/Fedora/i386/os/Packages/ mirror.amd64 = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/8/Fedora/x86_64/os/Packages/ [fedora-core-9] mirror = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/9/Fedora/i386/os/Packages/ mirror.amd64 = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/9/Fedora/x86_64/os/Packages/ [fedora-core-10] mirror = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/10/Fedora/i386/os/Packages/ mirror.amd64 = http://ftp.heanet.ie/pub/fedora-archive/fedora/linux/releases/10/Fedora/x86_64/os/Packages/ [fedora-11] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/11/Fedora/i386/os/Packages/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/11/Fedora/x86_64/os/Packages/ [fedora-12] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/i386/os/Packages/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/12/Fedora/x86_64/os/Packages/ [fedora-13] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/13/Fedora/i386/os/Packages/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/13/Fedora/x86_64/os/Packages/ [fedora-14] mirror = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/14/Fedora/i386/os/Packages/ mirror.amd64 = http://dl.fedoraproject.org/pub/archive/fedora/linux/releases/14/Fedora/x86_64/os/Packages/ [opensuse-10.1] mirror = http://ftp.hosteurope.de/mirror/ftp.opensuse.org/discontinued/SL-10.1/inst-source/suse/i586/ mirror.amd64 = http://ftp.hosteurope.de/mirror/ftp.opensuse.org/discontinued/SL-10.1/inst-source/suse/x86_64/ [opensuse-10.2] mirror = http://ftp.hosteurope.de/mirror/ftp.opensuse.org/discontinued/10.2/repo/oss/suse/i586/ mirror.amd64 =
Bug#733729: python-bootstrapform and python-django-taggit: error when trying to install together
Package: python-bootstrapform,python-django-taggit Severity: serious python-bootstrapform and python-django-taggit are not co-installable: # apt-get install -qq python-bootstrapform python-django-taggit [...] Selecting previously unselected package python-bootstrapform. Preparing to unpack .../python-bootstrapform_3.1.0-2_all.deb ... Unpacking python-bootstrapform (3.1.0-2) ... Selecting previously unselected package python-django-taggit. Preparing to unpack .../python-django-taggit_0.11.1-1_all.deb ... Unpacking python-django-taggit (0.11.1-1) ... dpkg: error processing archive /var/cache/apt/archives/python-django-taggit_0.11.1-1_all.deb (--unpack): trying to overwrite '/usr/share/pyshared/tests/__init__.py', which is also in package python-bootstrapform 3.1.0-2 Errors were encountered while processing: /var/cache/apt/archives/python-django-taggit_0.11.1-1_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) -- 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#733730: localepurge: [INTL:es] Translation of debconf messages to Spanish
Package: localepurge Severity: wishlist Tags: l10n patch Dear Maintainer, Find attached an compressed file containing updated translations of localepurge's debconf messages to Spanish. Happy new year, Toote. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash localepurge.tar.gz Description: application/gzip
Bug#733731: strongswan: [INTL:es] updated debconf Spanish translation
Package: strongswan Severity: wishlist Tags: l10n patch Dear Maintainer, Find attached a compressed updated translation of strongSwan's debconf messages to Spanish. Happy new year, Toote -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash strongswan.tar.gz Description: application/gzip
Bug#733732: dokuwiki: [INTL:es] Updated Spanish translation of debconf messages
Package: dokuwiki Severity: wishlist Tags: l10n patch Dear Maintainer, Find attached a compressed updated translation of dokuwiki's debconf messages to Spanish. Happy new year! Toote -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing') Architecture: i386 (x86_64) Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash dokuwiki.tar.gz Description: application/gzip
Bug#733597: detect dev packages that don't depend on other dev packages
Control: retitle -1 [external] detect dev packages that don't depend on other dev packages Control: tags -1 + wontfix Thanks for the bug report. * Daniel Pocock dan...@pocock.com.au, 2013-12-30, 09:27: It would be useful for lintian to scan the headers in a dev package and see if they try to include any other headers that are not provided (transitively) by Depends I'm afraid we can't do that without violating Lintian design constraints: “* deterministic replay-ability: Checks should not rely on the state of system caches or even the system time. These things makes it harder for others to reproduce (the absence of) tags. * same source analysis: Lintian checks packages in small isolated groups based on the source package. Requiring the presence of all the dependencies to provide the full results make it harder to run lintian (not to mention, it makes deterministic replay-ability a lot harder as well).” (Lintian User's Manual §1.3) -- 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#733489: python-apt: Improve 'Dependency' and 'BaseDependency' to get target package versions that satisfy dependencies
You can just git-send-email them to the mailing list or even push a git branch somewhere. Alrighty. Then let's stick to the bug for the time being as it contains already the context for the patches. See attached the patch with the PEP8 linter and pyflakes fixes. PEP8 only showed typical minor issues (indentation, line continuation, ...) and pyflakes only found an unused import and an unused variable. From 865b39a4f2ed566e7dd7fc13ff83ea26edbab000 Mon Sep 17 00:00:00 2001 From: Michael Schaller mich...@5challer.de Date: Tue, 31 Dec 2013 13:55:09 +0100 Subject: [PATCH] apt/cache.py, apt/package.py: Fixed PEP8 and pyflakes issues --- apt/cache.py | 53 + apt/package.py | 40 +++- debian/changelog | 3 +++ 3 files changed, 47 insertions(+), 49 deletions(-) diff --git a/apt/cache.py b/apt/cache.py index 43fb55d..6b1e2bd 100644 --- a/apt/cache.py +++ b/apt/cache.py @@ -40,6 +40,7 @@ class FetchFailedException(IOError): class LockFailedException(IOError): Exception that is thrown when locking fails. + class CacheClosedException(Exception): Exception that is thrown when the cache is used after close(). @@ -53,7 +54,7 @@ class Cache(object): list of available packages. The cache can be used like a mapping from package names to Package -objects (although only getting items is supported). +objects (although only getting items is supported). Keyword arguments: progress -- a OpProgress object @@ -74,7 +75,7 @@ class Cache(object): self._fullnameset = set() self._changes_count = -1 self._sorted_set = None - + self.connect(cache_post_open, self._inc_changes_count) self.connect(cache_post_change, self._inc_changes_count) if memonly: @@ -86,17 +87,17 @@ class Cache(object): apt_pkg.config.clear(APT) apt_pkg.config.set(Dir, rootdir) apt_pkg.init_config() -if os.path.exists(rootdir+/etc/apt/apt.conf): +if os.path.exists(rootdir + /etc/apt/apt.conf): apt_pkg.read_config_file(apt_pkg.config, - rootdir + /etc/apt/apt.conf) -if os.path.isdir(rootdir+/etc/apt/apt.conf.d): + rootdir + /etc/apt/apt.conf) +if os.path.isdir(rootdir + /etc/apt/apt.conf.d): apt_pkg.read_config_dir(apt_pkg.config, - rootdir + /etc/apt/apt.conf.d) +rootdir + /etc/apt/apt.conf.d) apt_pkg.config.set(Dir::State::status, rootdir + /var/lib/dpkg/status) # also set dpkg to the rootdir path so that its called for the # --print-foreign-architectures call -apt_pkg.config.set(Dir::bin::dpkg, +apt_pkg.config.set(Dir::bin::dpkg, os.path.join(rootdir, usr, bin, dpkg)) # create required dirs/files when run with special rootdir # automatically @@ -105,7 +106,6 @@ class Cache(object): # recognized (LP: #320665) apt_pkg.init_system() self.open(progress) - def _inc_changes_count(self): Increase the number of changes @@ -118,12 +118,12 @@ class Cache(object): files = [/var/lib/dpkg/status, /etc/apt/sources.list, -] + ] dirs = [/var/lib/dpkg, /etc/apt/, /var/cache/apt/archives/partial, /var/lib/apt/lists/partial, - ] +] for d in dirs: if not os.path.exists(rootdir + d): #print creating: , rootdir + d @@ -165,8 +165,8 @@ class Cache(object): i = last = 0 size = len(self._cache.packages) for pkg in self._cache.packages: -if progress is not None and last+100 i: -progress.update(i/float(size)*100) +if progress is not None and last + 100 i: +progress.update(i / float(size) * 100) last = i # drop stuff with no versions (cruft) if pkg.has_versions: @@ -259,7 +259,8 @@ class Cache(object): def required_download(self): Get the size of the packages that are required to download. if self._records is None: -raise CacheClosedException(Cache object used after close() called) +raise CacheClosedException( +Cache object used after close() called) pm = apt_pkg.PackageManager(self._depcache) fetcher = apt_pkg.Acquire() pm.get_archives(fetcher, self._list, self._records) @@ -289,16 +290,14 @@ class Cache(object): # now check the result (this is the code from apt-get.cc)
Bug#652459: Move awk implementations from /usr/bin to /bin
On 31 December 2013 08:11, Vincent Bernat ber...@debian.org wrote: ❦ 31 décembre 2013 01:30 CET, m...@linux.it (Marco d'Itri) : Any thoughts? The correct solution is completing #652459, which mounts /usr in the initramfs. It is quite unclear why this bug is stalled. I believe there were reservations about /etc portions of the patch series, which were asked to be unbundled and to be considered separately. I don't know if this was done, if not I guess I should come up with such patch on top of the proposed patch series, as one of the interested parties to get this resolved. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733733: wrong complaint about missing python b-d when python*:any is given.
Package: lintian Version: 2.5.20 Severity: important not sure if the analysis is correct ... for python3-stdlib-extensions (3.3.3-2), lintian complains about: E: missing-python-build-dependency however the package has python:any as a build dependency. The architecture specific bits are satisfied by the libpython3-all-dev b-d. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733411: Recommend compiling in a clean chroot?
This problem would be noticed before upload if the maintainer used a clean chroot to (try to) build the package, and I get the impression that this is recommended, but the Developers' Reference and New Maintainers' Guide don't actually say so. (http://www.debian.org/doc/manuals/maint-guide/build.en.html#pbuilder is the closest they come.) Should they be changed as well? -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733184: libmicrohttpd: FTBFS on kfreebsd-* (symbol errors)
Hi, Thank you for reporting this FTBS. It seems that EXPORT.sym was ignored due to a misconfiguration upstream. This was easily fixed after contacting the main upstream coder. I prepared a new package fixing the list of exported symbols and therefore the build failure on kfreebsd-* and uploaded it on mentors [1]. My sponsor is not responsive these days, would you consider sponsoring my upload ? Regards, Bertrand [1] http://mentors.debian.net/debian/pool/main/libm/libmicrohttpd/libmicrohttpd_0.9.33-1.dsc signature.asc Description: OpenPGP digital signature
Bug#733734: apt-listchanges: sometimes gives too many changes
Package: apt-listchanges Version: 2.85.12 Severity: normal apt-listchanges sometimes gives too many changes, with changelogs for versions = the one being installed. For instance: xvii% apt-show-versions libaudit1 libaudit1:amd64/unstable 1:2.3.2-2 upgradeable to 1:2.3.2-3 xvii% apt-show-versions libaudit-common libaudit-common:all/unstable 1:2.3.2-2 upgradeable to 1:2.3.2-3 # apt-get install libaudit1 Reading package lists... Done Building dependency tree Reading state information... Done The following extra packages will be installed: libaudit-common The following packages will be upgraded: libaudit-common libaudit1 2 upgraded, 0 newly installed, 0 to remove and 96 not upgraded. Need to get 0 B/53.4 kB of archives. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] Retrieving bug reports... Done Parsing Found/Fixed information... Done Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done apt-listchanges: Do you want to continue? [Y/n] This gives the changelogs corresponding to: audit (1:2.3.2-3) unstable; urgency=medium audit (1:2.3.2-2) unstable; urgency=low audit (1:2.3.2-1) experimental; urgency=low audit (1:2.3.1-1) experimental; urgency=low audit (1:2.3-1) experimental; urgency=low audit (1:2.2.3-1) experimental; urgency=low audit (1:2.2.2-1) experimental; urgency=low audit (1:2.2.1-2) experimental; urgency=low audit (1:2.2.1-1) experimental; urgency=low except just the last one. When I execute apt-listchanges manually: apt-listchanges /var/cache/apt/archives/libaudit1_1%3a2.3.2-3_amd64.deb apt-listchanges /var/cache/apt/archives/libaudit-common_1%3a2.3.2-3_all.deb I don't have this problem, i.e. only the 1:2.3.2-3 changes are listed. But if I add --profile=apt, the problem occurs again; but I need to be root, otherwise I get the following error message: database /var/lib/apt/listchanges.db failed to load. even though /var/lib/apt/listchanges.db is readable by everyone (perhaps locking is involved?). If I add the --debug option to /etc/apt/apt.conf.d/20listchanges, I get: APT pipeline messages: VERSION 2 APT::Architecture=amd64 APT::Build-Essential::=build-essential APT::Install-Recommends=1 APT::Install-Suggests=0 APT::Authentication::TrustCDROM=true APT::NeverAutoRemove::=^firmware-linux.* APT::NeverAutoRemove::=^linux-firmware$ APT::NeverAutoRemove::=^kfreebsd-image.* APT::NeverAutoRemove::=^gnumach$ APT::NeverAutoRemove::=^gnumach-image.* APT::NeverAutoRemove::=^linux-image-3.11-2-amd64$ APT::NeverAutoRemove::=^linux-image-extra-3.11-2-amd64$ APT::NeverAutoRemove::=^linux-signed-image-3.11-2-amd64$ APT::NeverAutoRemove::=^linux-backports-modules-.*-3.11-2-amd64$ APT::NeverAutoRemove::=^linux-headers-3.11-2-amd64$ APT::NeverAutoRemove::=^linux-image-3.12-1-amd64$ APT::NeverAutoRemove::=^linux-image-extra-3.12-1-amd64$ APT::NeverAutoRemove::=^linux-signed-image-3.12-1-amd64$ APT::NeverAutoRemove::=^linux-backports-modules-.*-3.12-1-amd64$ APT::NeverAutoRemove::=^linux-headers-3.12-1-amd64$ APT::Never-MarkAuto-Sections::=metapackages APT::Never-MarkAuto-Sections::=restricted/metapackages APT::Never-MarkAuto-Sections::=universe/metapackages APT::Never-MarkAuto-Sections::=multiverse/metapackages APT::Never-MarkAuto-Sections::=oldlibs APT::Never-MarkAuto-Sections::=restricted/oldlibs APT::Never-MarkAuto-Sections::=universe/oldlibs APT::Never-MarkAuto-Sections::=multiverse/oldlibs APT::Cache-Limit=67108864 APT::Update::Post-Invoke-Success::=test%20-x%20/usr/bin/apt-show-versions%20||%20exit%200%20;%20apt-show-versions%20-i APT::Update::Post-Invoke-Success::=/usr/bin/test%20-e%20/usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service%20%20/usr/bin/test%20-S%20/var/run/dbus/system_bus_socket%20%20/usr/bin/gdbus%20call%20--system%20--dest%20org.freedesktop.PackageKit%20--object-path%20/org/freedesktop/PackageKit%20--timeout%201%20--method%20org.freedesktop.PackageKit.StateHasChanged%20cache-update%20%20/dev/null;%20/bin/echo%20%20/dev/null APT::Color::Highlight=%1b[32m APT::Color::Neutral=%1b[0m APT::Color::Red=%1b[31m APT::Color::Green=%1b[32m APT::Color::Yellow=%1b[33m APT::Color::Blue=%1b[34m APT::Color::Magenta=%1b[35m APT::Color::Cyan=%1b[36m APT::Color::White=%1b[37m APT::Compressor::lzma::Binary=xz APT::Compressor::lzma::CompressArg::=--format=lzma APT::Compressor::lzma::CompressArg::=-9 APT::Compressor::lzma::UncompressArg::=--format=lzma APT::Compressor::lzma::UncompressArg::=-d Dir=/ Dir::State=var/lib/apt/ Dir::State::lists=lists/ Dir::State::cdroms=cdroms.list
Bug#729203: Yes, switch Debian/Ubuntu to FFmpeg
I agree that we should go back to FFmpeg from Libav. I build FFmpeg from source frequently, but this isn't enough. Packages such as Totem, VLC Media Player, or Audacity either natively depend on the libav* libraries or have plugins for libav* support. Building FFmpeg from source works for the command line, but I can't use players such as VLC Media Player to play certain video files I have because Libav's libavcodec doesn't support them. (For example, FFmpeg supports the Windows Media Player MSS2 codec but Libav does not.) In addition, FFmpeg continues to be ABI- and API-compatible with Libav so a switch will not harm any existing programs. However, Libav does not try to be compatible with FFmpeg. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733736: moreutils: FTBFS on illumos-amd64
Package: moreutils
Version: 0.51
Severity: normal
Tags: patch
Attached patch fixes FTBFS on illumos-amd64.
Please consider applying it.
Proposed changes at http://cgit.osdyson.org/moreutils.git/log/ as well.
Thanks.
-- System Information:
Debian Release: bok
Architecture: illumos-amd64 (i86pc)
Kernel: SunOS 5.11
Locale: LANG=C, LC_CTYPE=C (charmap=646)
Shell: /bin/sh linked to /usr/bin/dash
Versions of packages moreutils depends on:
ii libc12.10+11
ii libipc-run-perl 0.90-1
ii perl 5.14.2-21+dyson1
moreutils recommends no packages.
Versions of packages moreutils suggests:
pn libtime-duration-perl none
ii libtimedate-perl 1.2000-1
-- no debconf information
diff --git a/ifdata.c b/ifdata.c
index 6d7ed6f..adf9f87 100644
--- a/ifdata.c
+++ b/ifdata.c
@@ -23,6 +23,12 @@
#include net/if.h
#endif
+#if defined(__sun)
+ #define s6_addr16 _S6_un._S6_u8
+ #include net/if.h
+ #include sys/sockio.h
+#endif
+
#include netinet/in.h
#include errno.h
#include fcntl.h
diff --git a/ifne.c b/ifne.c
index d8ecea9..e8bc100 100644
--- a/ifne.c
+++ b/ifne.c
@@ -23,6 +23,10 @@
#include sys/wait.h
#include sys/types.h
#include string.h
+#ifdef __sun
+#include signal.h /* raise() */
+#endif
+
#define streq(a, b) (!strcmp((a), (b)))
static void stdin_to_stream(char *buf, ssize_t r, FILE *outf) {
diff --git a/parallel.c b/parallel.c
index 1bd796b..b9d7ab2 100644
--- a/parallel.c
+++ b/parallel.c
@@ -32,6 +32,10 @@
#include sys/wait.h
#include unistd.h
+#ifdef __sun
+# include sys/loadavg.h /* getloadavg() */
+#endif
+
#if !defined(WEXITED)
#define WEXITED 0
#endif
Bug#733735: ITP: distlib -- (python) distribution utilities
Package: wnpp Severity: wishlist Owner: Matthias Klose d...@debian.org * Package name: distlib Version : 0.1.6 Upstream Author : Vinay Sajip * URL : https://pypi.python.org/pypi/distlib/ * License : BSD Programming Lang: Python Description : Distribution utilities Low-level components of distutils2/packaging, augmented with higher-level APIs for making packaging easier. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733737: Add python3-cclib package
Source: cclib Version: 1.1-1 Severity: wishlist -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gausssum 3 is only for Python 3. Therefor we need a python3-cclib package. Regards, Daniel - -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (850, 'unstable'), (700, 'testing'), (560, 'stable'), (500, 'oldstable'), (110, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/2 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (GNU/Linux) iEYEARECAAYFAlLCzE4ACgkQm0bx+wiPa4y2xwCePKrirqzd13xFs/Bi/lHc5SC4 UCgAoJkdnJBhOH78xTF3TNECijszUHue =Z6u8 -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#733738: backintime-common: Didn't show all translated words in UI
Package: backintime-common Version: 1.0.10-1 Severity: normal Tags: l10n In the UI many strings are untranslated. I already checked the de.po file. I couldn't find the untranslated strings. Anything else must be wrong. Upstream has version 1.0.34 now. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (700, 'testing'), (600, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages backintime-common depends on: ii cron3.0pl1-124 ii python 2.7.5-5 ii rsync 3.1.0-2 backintime-common recommends no packages. backintime-common 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#733739: upstart should support cgroups
Package: upstart Severity: normal cgroups are a useful way to group processes by service. They can be used to limit resources per service (instead of per process with ulimit). Using cgroups also allows to reliably terminate a service, even when it spawns helper processes. It would be nice if upstart could optionally contain services in cgroups. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733740: transition: dotconf
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 With permission of the current maintainer of dotconf, I like to update the dotconf package as it is a requirement for the new version of the speech-dispatcher, which is an important accessibility package. Upstream dotconf has changed the soname versioning scheme, and as such the update to the latest version is also a transition. I request a slot for it. Ubuntu already has the updated version. The following packages have a (build) dependency on dotconf: paul@wollumbin ~a11y $ reverse-depends -b libdotconf-dev Reverse-Build-Depends = * cpm * mysqmail * sbox-dtc * speech-dispatcher * speechd-up cpm/sbox-dtc/speech-dispatcher can be bin-NMUed AFAICT mysqmail/speechd-up need sourceful uploads as they have a hardcoded dependency on libdotconf1.0 Ben file: title = dotconf; is_affected = .build-depends ~ libdotconf-dev | .depends ~ libdotconf1.0 | .depends ~ libdotconf0; is_good = .depends ~ libdotconf0; is_bad = .depends ~ libdotconf1.0; - -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable'), (99, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.0-4-amd64 (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 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJSwtCEAAoJEJxcmesFvXUKEbMH/0fK8GbbXZdSIflI0E2it9/2 Epk/zyQHOBsbsAKOfDJWx2xs8Zuro/4CY5+ff3cBdZNVkS93v60jtZRRmMZBp9GQ Vbf1qkXfBXyWisoHcrLQgKJ/kBS6SY/WmzMTbZdzFQAX2LgH54PpZ7gTNk5W4iRH ja8vClujXe+Ytt6keloQI5n6pAn7offKiUwE7MnVZFOiKTJZ+sMghs+jfLWMwXIn Pt9t7G7yUnE0WIZkyp/GQNwD91b7R0ah/n+z4VNk7Q3US7bwt56HsWL1StuqhXto 7HL6u4Had+G7DT4xMqEhrc0kdu7VhzwVXs67x2pzltZtCoiDT1WLInL8Y9TZkGY= =1yUg -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#580916: This bug also exists upstream
Dear maintainer, I also reported this bug upstream in https://github.com/kfish/xsel/issues/3. Would be nice if somebody resolves this issue. Oz
Bug#727708: init system other points, and conclusion
Hello. I'm writing to you to request to do not use no systemd, nor upstart. I can guess that you have very important reasons to discuss this possibilities, but… IMHO, systemd doesn't even fit to UNIX philosophy [1]. [1] http://en.wikipedia.org/wiki/Unix_philosophy Sorry if I'm wrong. upstart is more satisfactorily. I have a lot of problems with it in LXC and other tasks*. So, I can work with upstart, but would prefer not to do that. I didn't try systemd in LXC, but I can guess that I'll catch much more problems with it. * I don't rule out the likelihood of that my hands were too curves. Also, I can also guess, that my opinion doesn't worth anything here. But at the moment the best Linux (meta-)distributions for me (and under my tasks) is Debian and Gentoo. With moving to systemd you will force me to choose another distribution as replacement for Debian. Please, don't do that. P.S.: It would be great to see OpenRC as default init-system for Debian :) -- Best regards, Dmitry, head of UNIX-tech department NRNU MEPhI, tel. 8 (495) 788-56-99, add. 8255 signature.asc Description: OpenPGP digital signature
Bug#733741: upstart: implement additional security features
Package: upstart Upstart should provide additional security features, such as isolating processes from the network using network namespaces, restricting file system access, preventing the processes to regain privileges, system call filters, private /tmp and limiting device access. See also this part of Russ' mail on -ctte: Russ Allbery r...@debian.org writes: * Security defense in depth. Both upstart and systemd support the basics (setting the user and group, process limits, and so forth). However, systemd adds a multitude of additional defense in depth features, ranging from capability limits to private namespaces or the ability to deny a job access to the network. This is just a simple matter of programming on the upstart side, but it still contributes to the general feature deficit; the capabilities in systemd exist today. I'm sure I'm not the only systems administrator who is expecting security features and this sort of defense in depth to become increasingly important over the next few years. Here again, I think we have an opportunity for Debian to be more innovative and forward-looking in what we attempt to accomplish in the archive by adopting frameworks that let us incorporate the principles of least privilege and defense in depth into our standard daemon configurations. Ansgar -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733742: rpcbind: cannot get uid of '': Transport endpoint is not connected
Package: rpcbind Version: 0.2.1-1 Severity: grave Justification: renders package unusable rpcbind doesn't start anymore and blocќs nis, nfs etc. Falling back to 0.2.0-8 make my sytems running again. Elimar -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (990, 'unstable'), (500, 'stable'), (100, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13.0-rc6-galadriel-lxtec-amd64 (SMP w/2 CPU cores; PREEMPT) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages rpcbind depends on: ii initscripts 2.88dsf-45 ii insserv 1.14.0-5 ii libc62.17-97 ii libtirpc10.2.2-5 ii libwrap0 7.6.q-24 ii lsb-base 4.1+Debian12 rpcbind recommends no packages. rpcbind 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#733743: ITP: libnih.la -- portable libnih implementation
Package: wnpp Owner: Dimitri John Ledkov x...@debian.org Severity: wishlist * Package name: libnih.la Version : 1.0.4 (git snapshot) Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD) * URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd http://libnih.la/ * License : GPL v2 Architecture: kfreebsd-any (hurd-any - maybe later) Description : portable libnih implementation I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports only. At the moment I have a port to kFreeBSD/eglibc. This is separate source package as the supported set of APIs is not yet fully same as of the Linux port of libnih. For example kqueue/kevent technology is not yet used to provide, e.g. file level notification as done with inotify in the linux port. Some of my patches have already been accepted upstream (https://github.com/keybuk/libnih), others are under review and some are not ready for submission yet. All libnih test-suite passes on kFreeBSD for those components that have been ported. Together with this effort, I am staging patches for Upstart itself for kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It compiles, but at the moment is still incomplete. The test-suite does not pass yet and there are no kFreeBSD specific bridges yet (e.g. devd events, instead of udev, etc.). I'm hoping to have a bootable kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on 5th of November 2014. The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present in Debian experimental. Alternatively, if lower eglibc versions are required I could easily use wait6 syscall directely, without eglibc wrapper. In that case only requirements would be patched kFreeBSD kernels for the kern/184002 http://www.freebsd.org/cgi/query-pr.cgi?pr=184002cat= bug which I discovered in FreeBSD. It's fixed in current/11, and is on track to be fixed in 9.2, 10 stable updates. I believe patch for that issue is already in debian packaging of FreeBSD kernels. I haven't started HURD port just yet, as I'm more familiar with FreeBSD. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: Hi anarcat, Hi Andreas! Installing on UEFI firmware is supported, but is a little bit tricky, see for example [1]. Particularly you need a GPT partitioned hard disk with two additional partitions, one EFI partition marked with the 'boot' flag in gparted and a partition for grub marked as 'bios_grub' in gparted. Yeah... I struggled with that before, and I *was* able to make it work, but since it wasn't obvious this was necessary *during* the installer, I did a normal MBR-based partitionning. When the boot loader failed to install, I didn't want to go back and redo everything, especially since this is a dual-boot system and I was happy to have been able to resize the NTFS partition at all... ;) (That resize, btw, was quite scary - I am not sure I did it right. First off it was very fast, so I suspect only the boundaries of the filesystem were changed, without telling NTFS. Then when we rebooted into Windows 7, it did a disk check which thankfully worked fine and it seems the Windows install is okay. But I can't think of doing this on an older system - it would have probably destroyed data, which is not clearly stated in partman. Then the installer has to support installing on UEFI, which the default installer does, but I don't know about the one you created. I was able to dig out more information about the image since then: $ less .disk/info Debian GNU/Linux 7.0.0 Wheezy - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-18:46 $ less .disk/udeb_include netcfg ethdetect pcmciautils-udeb live-installer From what I understand, debian-installer supports installing on UEFI/GPT, but partman doesn't support *creating* GPT partitions, do I get this right? Shouldn't we create GPT partitions all the time now anyways? Last but not least, you have to select the UEFI:USB in the firmware and not BIOS:USB, which every firmware has a different marking scheme for, but disabling legacy-bios (or equivalent option) in the UEFI BIOS, should always disable the BIOS:USB option. (It can be enabled again after installation.) Right, I guess this is the tricky bit. It seems that in any case, the user needs to go fiddle in the BIOS, which is annoying. In my case, I was able to install by *disabling* UEFI in the BIOS, but the reverse might be the case for others. Tricky. The next missing thing was wifi. I tried installing firmware-linux- nonfree, but that wasn't enough - firmware-iwlwifi was the one that was required. The installer should install the correct firmware, if you have (on some partition accessible during installation) a /firmware folder that contains the unpacked firmware bundle, which can be downloaded from [2]. But this is currently broken, see [3]. Understood. The weird thing is that the live image did find the wifi card without a problem, but it wasn't found after the install was done. Oh, and I forgot to mention that I had to remove this block for Network-Manager to properly pickup the wired interface: auto eth0 iface eth0 inet dhcp Otherwise it would say wired: not managed, which is strange to me... I also had to go in the gnome control center to make sure the touch pad works as expected. What exactly did you have to do in the gnome control center? I went into Mouse and Touchpad, clicked on the Touchpad tab, and enabled touch to click and two fingers scrolling. (I type this from memory, from my desktop where I don't have a touch pad. ;) What do you mean by 'works as expected'? My user was expecting the touch to click to work out of the box, and we were worried this wasn't supported, and in fact it wasn't until gnome was installed (XFCE failed to configure it properly). This is especially annoying on this laptop because the buttons are completely part of the touchpad construction, so it's actually difficult to click without moving the mouse slightly. Wanting this thing to be pretty, I also had to manually install plymouth to get a nicer boot up sequence, *and* I had to edit /etc/default/grub to make that work (add the splash parameter), something I wouldn't expect a novice to be able to do at all on a first install. While I also prefer having plymouth installed, I think there are many users that prefer not to have it, so one cannot make everyone happy with the default installation. Clearly bike shed material. ;) That being said, I think it really might be a good idea to install plymouth by default, as 'novices' generally prefer it, and anyone who wants to see the boot messages should have sufficient knowledge to remove it. I totally agree with that. One thing I noticed with plymouth is that even when you install it, it doesn't properly configure grub, you still have to go around the grub config and (*gasp*) edit a weird configuration file! ;) I would have expected the plymouth postinst to configure grub automagically. :) But then that's more an issue with plymouth
Bug#731156: libupsclient3: Library is containing undefined references
Hello Matthias, Thanks for the patch! It also includes backport-fix-lp753661.patch was that actually expected? Cheers, Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733744: transition: libdvbpsi
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hi, libdvbpsi bumped its SONAME once again (8 - 9). vlc is the only reverse dependency and builds fine against the new version of libdvbpsi which is currently in experimental. Please let me know when it's okay to upload libdvbpsi to unstable. Regards Ben file: title = libdvbpsi; is_affected = .build-depends ~ libdvbpsi-dev; is_good = .depends ~ libdvbpsi9; is_bad = .depends ~ libdvbpsi8; -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#733105: quantlib-swig: Please migrate to Ruby 2.0 / 1.9
Hi Dirk and Christian, the module does compile and install. I'm not sure if it's in any shape to be released, though: 3 scripts out of the four in Ruby/examples dump core on my machine (truth be told, it might have also happened with 1.8. I should go and check that, too). It looks like something going awry in a destructor. Do they run on yours? Supporting both 1.8 and 1.9 might be doable in the wrappers if I can get the Ruby version (I see a macro for it in ruby/version.h, but the comments are discouraging me from using it); it should be just a matter of defining some macro QL_RARRAY_LEN(x) to expand to RARRAY(x)-len for 1.8 and RARRAY_LEN(x) for 1.9. My Ruby-fu is very rusty, though, so I'm not sure how to require 'ftools' or 'fileutils' depending on the version, or how to alias a common name to the correct one. Christian, do you have any suggestions? (Also on the version thing above?) Later, Luigi (oh, and a happy new year in case I don't hear from you today) On Tue, Dec 31, 2013 at 5:34 AM, Dirk Eddelbuettel e...@debian.org wrote: Ok, one last one: I just updated the pull request https://github.com/lballabio/quantlib/pull/65 and the second patch contains further fixes to setup.rb to do the install step under Ruby 1.9. (The third patch just corrects the version back to '1.4' for the dev tree.) Supporting 1.8 and 1.9 upstream may be a bit of a pain though. I also uploaded a repaired new Debian package -- thanks again to Christian. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733743: ITP: libnih.la -- portable libnih implementation
Dmitri, Why do you not use libinotify-kqueue? I know you mentioned not wanting to have a lot of external dependencies, but I think using that library will allow other linux applications to more easily port to kFreeBSD. Great work, Cameron Norman On Tue, Dec 31, 2013 at 6:46 AM, Dimitri John Ledkov x...@debian.org wrote: Package: wnpp Owner: Dimitri John Ledkov x...@debian.org Severity: wishlist * Package name: libnih.la Version : 1.0.4 (git snapshot) Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD) * URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd http://libnih.la/ * License : GPL v2 Architecture: kfreebsd-any (hurd-any - maybe later) Description : portable libnih implementation I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports only. At the moment I have a port to kFreeBSD/eglibc. This is separate source package as the supported set of APIs is not yet fully same as of the Linux port of libnih. For example kqueue/kevent technology is not yet used to provide, e.g. file level notification as done with inotify in the linux port. Some of my patches have already been accepted upstream (https://github.com/keybuk/libnih), others are under review and some are not ready for submission yet. All libnih test-suite passes on kFreeBSD for those components that have been ported. Together with this effort, I am staging patches for Upstart itself for kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It compiles, but at the moment is still incomplete. The test-suite does not pass yet and there are no kFreeBSD specific bridges yet (e.g. devd events, instead of udev, etc.). I'm hoping to have a bootable kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on 5th of November 2014. The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present in Debian experimental. Alternatively, if lower eglibc versions are required I could easily use wait6 syscall directely, without eglibc wrapper. In that case only requirements would be patched kFreeBSD kernels for the kern/184002 http://www.freebsd.org/cgi/query-pr.cgi?pr=184002cat= bug which I discovered in FreeBSD. It's fixed in current/11, and is on track to be fixed in 9.2, 10 stable updates. I believe patch for that issue is already in debian packaging of FreeBSD kernels. I haven't started HURD port just yet, as I'm more familiar with FreeBSD. Regards, Dimitri. -- 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/87wqil13jl@ubuntu.com
Bug#733494: OptParse exception during [dist-]upgrade
Hello, On Sun, Dec 29, 2013 at 11:37:19AM +, Wolodja Wentland wrote: Package: apt-cudf Version: 3.1.3-7 Severity: normal Dear maintainer, I have used apt-cudf happily for a while now, but recently it started to show the following behaviour: $ sudo apt-get --solver aspcud dist-upgrade Reading package lists... Done Building dependency tree Reading state information... Done Fatal error: exception OptParse.Opt.No_value Execute external solver... Done Done Fatal error: exception OptParse.Opt.No_value Execute external solver... Done This might be a problem with aspcud, coming from the fact that a new version of gringo (one of aspcud's dependencies) was uploaded to sid before aspcud was ready for the migration. What are your current versions of aspcud and gringo ? If you have gringo 4.2.1-3 installed then could you please try with gringo 3.0.5-1+b1 from testing? Cheers -Ralf. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733745: RM: handbrake-dbg [armel armhf mips mipsel s390x sparc ia64] -- ANAIS; empty package, built by mistake
Package: ftp.debian.org Severity: normal handbrake-dbg was built on armel, armhf, mips, mipsel, s390x, sparc and ia64 by mistake. handbrake-dbg is empty there. The Architecture field was changed in the lastest upload to match handbrake's Architecture field. Please remove the package on these architectures. Regards -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
Hi there! On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote: On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: Installing on UEFI firmware is supported, but is a little bit tricky, see for example [1]. Particularly you need a GPT partitioned hard disk with two additional partitions, one EFI partition marked with the 'boot' flag in gparted and a partition for grub marked as 'bios_grub' in gparted. Wrong, with UEFI you do not need any 'bios_grub' partition at all: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=691046#36 Yeah... I struggled with that before, and I *was* able to make it work, but since it wasn't obvious this was necessary *during* the installer, I did a normal MBR-based partitionning. When the boot loader failed to install, I didn't want to go back and redo everything, especially since this is a dual-boot system and I was happy to have been able to resize the NTFS partition at all... ;) Sorry, but there is something strange here. In the first email you reported that when I rebooted, grub was not installed in the MBR and I was brought back into windows, which means that partman used the partition table already present. This can be checked with a simple `fdisk -l /dev/sda`: if there is no GPT mention, then the partition table is plain old MBR. BTW, Windows 7 does not mandate GPT nor UEFI, but can use both. Then the installer has to support installing on UEFI, which the default installer does, but I don't know about the one you created. I was able to dig out more information about the image since then: $ less .disk/info Debian GNU/Linux 7.0.0 Wheezy - Official Snapshot amd64 LIVE/INSTALL Binary 20130505-18:46 $ less .disk/udeb_include netcfg ethdetect pcmciautils-udeb live-installer From what I understand, debian-installer supports installing on UEFI/GPT, but partman doesn't support *creating* GPT partitions, do I get this right? Wrong, partman creates GPT partitions with no problem, but by default only for disk bigger than 2TB. Shouldn't we create GPT partitions all the time now anyways? Why? IMHO if there is no need for it (because BIOS is used) plain old MBR is easier. Last but not least, you have to select the UEFI:USB in the firmware and not BIOS:USB, which every firmware has a different marking scheme for, but disabling legacy-bios (or equivalent option) in the UEFI BIOS, should always disable the BIOS:USB option. (It can be enabled again after installation.) Right, I guess this is the tricky bit. It seems that in any case, the user needs to go fiddle in the BIOS, which is annoying. In my case, I was able to install by *disabling* UEFI in the BIOS, but the reverse might be the case for others. No need to fiddle in the BIOS if you simply use UEFI (d-i supports it). Thx, bye, Gismo / Luca signature.asc Description: PGP signature
Bug#733746: dpkg-dev: dpkg-source - can't build with source format '3.0 (quilt)' when version number is 1.0.0
Package: dpkg-dev Version: 1.17.5 Severity: normal Dear Maintainer, I am developing a software package using semantic versioning, and am trying to build a package of version 1.0.0. Versions before have built correctly, e.g. 0.15.0. In semantic versioning (http://semver.org/), you are required to make package names meaningful, so this will affect other packages as well. Here are the latest entries in my debian/changelog: pd-purest-json (1.0.0) UNRELEASED; urgency=low * Info for users while loading object * Bug fixes in [json-encode]: - array handling - number handling * Refactoring -- Thomas Mayer tho...@residuum.org Thu, 03 Jan 2013 15:00:00 +0100 pd-purest-json (0.15.0) UNRELEASED; urgency=low * Cancellation is now faster * Switch to json-c 0.11 * Refactoring of code * Breaking changes: - [oauth] and [rest]: -- [write( method is now called [file( -- [url( method is now called [init( -- init errors only output to console -- changes to status outlet: --- on success output bang --- on HTTP error output numerical HTTP status --- on cURL error output list: error code and message - [rest-json] has been removed - [json-decode]: -- string values will not be checked for numbers or boolean -- Thomas Mayer tho...@residuum.org Mon, 18 Nov 2013 23:00:00 +0100 The sequence of commands: mv purest_json-1.0.0 pd-`echo purest_json|tr '_' '-'`_1.0.0 tar --exclude-vcs -czpf ../pd-`echo purest_json|tr '_' '-'`_1.0.0.orig.tar.gz pd-`echo purest_json|tr '_' '-'`_1.0.0 rm -f -- purest_json-1.0.0.tar.gz rm -rf -- purest_json-1.0.0 pd-`echo purest_json|tr '_' '-'`_1.0.0 cd .. dpkg-source -b purest_json dpkg-source: info: using options from purest_json/debian/source/local-options: --unapply-patches --abort-on-upstream-changes dpkg-source: error: can't build with source format '3.0 (quilt)': version does not contain a revision This is possible related to bug #719348 http://bugs.debian.org/cgi- bin/bugreport.cgi?bug=719348 -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (800, 'stable'), (600, 'unstable'), (500, 'stable-updates') Architecture: i386 (x86_64) Kernel: Linux 3.11-2-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 dpkg-dev depends on: ii base-files7.2 ii binutils 2.24-2 ii bzip2 1.0.6-5 ii libdpkg-perl 1.17.5 ii make 3.81-8.3 ii patch 2.7.1-4 ii xz-utils 5.1.1alpha+20120614-2 Versions of packages dpkg-dev recommends: ii build-essential 11.6 ii fakeroot 1.18.4-2 ii gcc [c-compiler] 4:4.8.2-1 ii gcc-4.6 [c-compiler] 4.6.4-5 ii gcc-4.7 [c-compiler] 4.7.3-9 ii gcc-4.8 [c-compiler] 4.8.2-10 ii gnupg1.4.15-3 ii gnupg2 2.0.22-2 ii gpgv 1.4.15-3 pn libalgorithm-merge-perl none Versions of packages dpkg-dev suggests: ii debian-keyring 2013.12.13 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733706: installation-report: installation on a Lenovo Thinkpad E431
On 2013-12-31 10:23:18, Luca Capello wrote: Hi there! On Tue, 31 Dec 2013 15:50:39 +0100, Antoine Beaupré wrote: On 2013-12-31 05:45:01, Andreas Cadhalpun wrote: Yeah... I struggled with that before, and I *was* able to make it work, but since it wasn't obvious this was necessary *during* the installer, I did a normal MBR-based partitionning. When the boot loader failed to install, I didn't want to go back and redo everything, especially since this is a dual-boot system and I was happy to have been able to resize the NTFS partition at all... ;) Sorry, but there is something strange here. In the first email you reported that when I rebooted, grub was not installed in the MBR and I was brought back into windows, which means that partman used the partition table already present. This can be checked with a simple `fdisk -l /dev/sda`: if there is no GPT mention, then the partition table is plain old MBR. BTW, Windows 7 does not mandate GPT nor UEFI, but can use both. Oh right - I used the original partitionning I guess. I assumed it was MBR. Shouldn't we create GPT partitions all the time now anyways? Why? IMHO if there is no need for it (because BIOS is used) plain old MBR is easier. The reason is that it will fail on newer BIOS, from what I can tell. Last but not least, you have to select the UEFI:USB in the firmware and not BIOS:USB, which every firmware has a different marking scheme for, but disabling legacy-bios (or equivalent option) in the UEFI BIOS, should always disable the BIOS:USB option. (It can be enabled again after installation.) Right, I guess this is the tricky bit. It seems that in any case, the user needs to go fiddle in the BIOS, which is annoying. In my case, I was able to install by *disabling* UEFI in the BIOS, but the reverse might be the case for others. No need to fiddle in the BIOS if you simply use UEFI (d-i supports it). That would imply reformatting the whole drive and destroying all the data, from what I understand. Unless d-i can convert a MBR partition to GPT? A. -- Voter, c'est abdiquer - Élisée Reclus pgpYRHOG2JOFO.pgp Description: PGP signature
Bug#733105: quantlib-swig: Please migrate to Ruby 2.0 / 1.9
Update: it seems that the problem is already taken care of; ruby.h in version 1.8 contains #define RARRAY_PTR(s) (RARRAY(s)-ptr) #define RARRAY_LEN(s) (RARRAY(s)-len) and RbConfig and FileUtils already exist in the 1.8 library, so the changes for 1.9 are backward compatible. I guess now I'll try and check if the thing dumps in 1.8 too... Luigi On Tue, Dec 31, 2013 at 4:17 PM, Luigi Ballabio luigi.balla...@gmail.com wrote: Hi Dirk and Christian, the module does compile and install. I'm not sure if it's in any shape to be released, though: 3 scripts out of the four in Ruby/examples dump core on my machine (truth be told, it might have also happened with 1.8. I should go and check that, too). It looks like something going awry in a destructor. Do they run on yours? Supporting both 1.8 and 1.9 might be doable in the wrappers if I can get the Ruby version (I see a macro for it in ruby/version.h, but the comments are discouraging me from using it); it should be just a matter of defining some macro QL_RARRAY_LEN(x) to expand to RARRAY(x)-len for 1.8 and RARRAY_LEN(x) for 1.9. My Ruby-fu is very rusty, though, so I'm not sure how to require 'ftools' or 'fileutils' depending on the version, or how to alias a common name to the correct one. Christian, do you have any suggestions? (Also on the version thing above?) Later, Luigi (oh, and a happy new year in case I don't hear from you today) On Tue, Dec 31, 2013 at 5:34 AM, Dirk Eddelbuettel e...@debian.org wrote: Ok, one last one: I just updated the pull request https://github.com/lballabio/quantlib/pull/65 and the second patch contains further fixes to setup.rb to do the install step under Ruby 1.9. (The third patch just corrects the version back to '1.4' for the dev tree.) Supporting 1.8 and 1.9 upstream may be a bit of a pain though. I also uploaded a repaired new Debian package -- thanks again to Christian. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733105: quantlib-swig: Please migrate to Ruby 2.0 / 1.9
Luigi, * Luigi Ballabio luigi.balla...@gmail.com [131231 16:24]: the module does compile and install. I'm not sure if it's in any shape to be released, though: 3 scripts out of the four in Ruby/examples dump core on my machine (truth be told, it might have also happened with 1.8. I should go and check that, too). It looks like something going awry in a destructor. Do they run on yours? Supporting both 1.8 and 1.9 might be doable in the wrappers if I can get the Ruby version (I see a macro for it in ruby/version.h, but the comments are discouraging me from using it); [..] I don't know your userbase, but I somehow doubt that supporting 1.8 is still worth it. 1.8.7 has been released over 5 years ago, and 1.9.3 has been released over 2 years ago. In Debian, we might actually remove 1.9 in this cycle as well, and ship with 2.0. I hear Ruby upstream has released 2.1 recently. My Ruby-fu is very rusty, though, so I'm not sure how to require 'ftools' or 'fileutils' depending on the version, or how to alias a common name to the correct one. Christian, do you have any suggestions? (Also on the version thing above?) Try something like this: $ irb irb(main):001:0 RUBY_VERSION = 2.0.0 irb(main):009:0 if RUBY_VERSION = 1.9 irb(main):010:1 puts :yep irb(main):011:1 else irb(main):012:1* puts :no irb(main):013:1 end yep = nil Happy new year, Christian -- ,''`. Christian Hofstaedtler z...@debian.org : :' : Debian Developer `. `' 7D1A CFFA D9E0 806C 9C4C D392 5C13 D6DB 9305 2E03 `- signature.asc Description: Digital signature
Bug#733747: Please apply patch from https://github.com/the-tcpdump-group/libpcap/commit/1a52c9a05758d162e331dc93d60c51ebeb7b0f55
Package: libpcap0.8 Version: 1.5.2-1 Severity: normal Tags: upstream patch Hi, libpcap 1.5 introduced a regression that causes 100% cpu usage in arpwatch; see https://github.com/the-tcpdump-group/libpcap/issues/333. There is a trivial fix: https://github.com/the-tcpdump-group/libpcap/commit/1a52c9a05758d162e331dc93d60c51ebeb7b0f55 Please package a patched version. Thanks (and a happy new year!) Andras -- YOU're the computer, YOU tell ME where the file is! -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733105: quantlib-swig: Please migrate to Ruby 2.0 / 1.9
On 31 December 2013 at 16:17, Luigi Ballabio wrote: | Hi Dirk and Christian, | the module does compile and install. I'm not sure if it's in any | shape to be released, though: 3 scripts out of the four in | Ruby/examples dump core on my machine (truth be told, it might have | also happened with 1.8. I should go and check that, too). It looks | like something going awry in a destructor. Do they run on yours? I didn't try. I just built the Debian package in a dedicated chroot. | Supporting both 1.8 and 1.9 might be doable in the wrappers if I can | get the Ruby version (I see a macro for it in ruby/version.h, but the | comments are discouraging me from using it); it should be just a | matter of defining some macro QL_RARRAY_LEN(x) to expand to | RARRAY(x)-len for 1.8 and RARRAY_LEN(x) for 1.9. Good point. | My Ruby-fu is very rusty, though, so I'm not sure how to require | 'ftools' or 'fileutils' depending on the version, or how to alias a | common name to the correct one. Christian, do you have any | suggestions? (Also on the version thing above?) | | Later, | Luigi | | (oh, and a happy new year in case I don't hear from you today) Happy New Year from me too! Dirk | On Tue, Dec 31, 2013 at 5:34 AM, Dirk Eddelbuettel e...@debian.org wrote: | | Ok, one last one: I just updated the pull request | | https://github.com/lballabio/quantlib/pull/65 | | and the second patch contains further fixes to setup.rb to do the install | step under Ruby 1.9. (The third patch just corrects the version back to '1.4' | for the dev tree.) | | Supporting 1.8 and 1.9 upstream may be a bit of a pain though. | | I also uploaded a repaired new Debian package -- thanks again to Christian. | | Dirk | | -- | Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com | | | | -- | https://implementingquantlib.blogspot.com | https://twitter.com/lballabio -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733470: git-buildpackage: Please provide a command to dump (single values from) merged gbp.conf configuration files
Hi Guido, (Replying also to the according clone http://bugs.debian.org/733639 in addition to the original report at http://bugs.debian.org/733470 -- I suggest to continue this thread in #733639.) Guido Günther wrote: Push the branch configured as debian-branch, the branch configured as upstream-branch, the pristine-tar branch, and all tags matching upstream-tag and debian-tag, to the remote origin. Maybe /usr/share/doc/git-buildpackage/examples/gbp-posttag-push is what you're (partially) after? (I'm reading this offline so I can't check your references yet). This posthook is intended to push up to the newly created tag (including the upstream branch). Partially the code maybe, but I don't need such functionality in a hook. Using a hook would rather hinder my workflow. Not sure about the rest of the Debian Perl Group (who mostly knows about and uses dpt push), but my workflow usually looks like this: * Maybe import (and hence tag) a new upstream release using git-import-orig. * Push at least upstream and pristine-tar branches and tags, using dpt push * modify the package until I think I'm finished, but stay at UNRELEASED. Run debuild and debdiff ../….deb after each change which may have some bigger impact. * Maybe merge fixups via git rebase -i * Push all changes so far (usually doesn't matter if I do git push or dpt push) * Replace the UNRELEASED, bump the changelog entry's date stamp. * Run pdebuild * Run lintian on the changes file * Review the changes file manually * Install the resulted packages and test them * Run git-buildpackage --git-tag-only to set the tags * Run dput on the changes file * If the upload succeeds, then run dpt push, i.e. push all relevant branches and tags. I'm mostly picky about when to do stuff which can't be reverted, especially uploads and pushing, so I do them last after I've verified that everything else is fine. Hence a hook wouldn't work for me. (And yes, both, the push and the dput could fail, but due to commit notifications on IRC I can be quite sure that nobody else pushed stuff in the meantime.) But it would be nice to do the pushing of branches and tags in one short DWIM command instead of two short commands or one long command (git push + git push --tags or listing all refs manually), like dpt push does. So I extended dpt push to parse gbp.conf files, so that I can use it outside the Debian Perl Group, too, e.g. for the Debian Zsh Maintainers. So dpt push already does what I want. I just think that such generic functionality probably better belongs to gbp itself than into a team-specific package. And I suspect that gbp already contains all the relevant functionality as proven code, just not gathered in a push command, while dpt push is (at least since my gbp.conf parser in shell code :-) a rather hackish script which likely does not cover all corner cases properly. I hope the reason for this feature request is now more clear. Regards, Axel -- ,''`. | Axel Beckert a...@debian.org, http://people.debian.org/~abe/ : :' : | Debian Developer, ftp.ch.debian.org Admin `. `' | 1024D: F067 EA27 26B9 C3FC 1486 202E C09E 1D89 9593 0EDE `-| 4096R: 2517 B724 C5F6 CA99 5329 6E61 2FF9 CD59 6126 16B5 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733748: mirror listing update for ftp.debian.sk
Package: mirrors Severity: minor Submission-Type: update Site: ftp.debian.sk Aliases: debian.sk Aliases: mirrors.gts.sk Type: leaf Archive-architecture: ALL amd64 armel armhf hurd-i386 i386 ia64 kfreebsd-amd64 kfreebsd-i386 mips mipsel powerpc s390x sparc Archive-ftp: /debian/ Archive-http: /debian/ Archive-rsync: debian/ Backports-ftp: /debian-backports/ Backports-http: /debian-backports/ Backports-rsync: debian-backports/ IPv6: no Archive-upstream: syncproxy3.eu.debian.org Backports-upstream: syncproxy3.eu.debian.org Updates: push Maintainer: Matus UHLAR - fantomas ftpmas...@debian.sk Country: SK Slovakia Location: Bratislava, Slovakia Sponsor: GTS Slovakia http://www.gts.sk/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733749: dependency libqt4-sql-sqlite
Package:owncloud-client version: 1.5.0+dfsg-2 amd64 severity: important I upgraded my Owncloud client. It was working without any trouble. GUI throws error unable to initialize a sync journal Log shows error Database Driver QSQLITE could not be loaded! I installed some SQL related packages, this didn't help. In the end the issue was resolved by installing libqt4-sql-sqlite , as hinted on http://comments.gmane.org/gmane.comp.kde.devel.owncloud/11132 System: Linux 3.12-1-amd64 #1 SMP Debian 3.12.6-2 (2013-12-29) x86_64 GNU/Linux PS: this is my first bug report. I did my best to follow rules. This bug report is rather brief, since the cause and resolve are rather simple.
Bug#733105: quantlib-swig: Please migrate to Ruby 2.0 / 1.9
...which it does. The examples segfault with 1.8, too. Oh well. On Tue, Dec 31, 2013 at 4:35 PM, Luigi Ballabio luigi.balla...@gmail.com wrote: Update: it seems that the problem is already taken care of; ruby.h in version 1.8 contains #define RARRAY_PTR(s) (RARRAY(s)-ptr) #define RARRAY_LEN(s) (RARRAY(s)-len) and RbConfig and FileUtils already exist in the 1.8 library, so the changes for 1.9 are backward compatible. I guess now I'll try and check if the thing dumps in 1.8 too... Luigi On Tue, Dec 31, 2013 at 4:17 PM, Luigi Ballabio luigi.balla...@gmail.com wrote: Hi Dirk and Christian, the module does compile and install. I'm not sure if it's in any shape to be released, though: 3 scripts out of the four in Ruby/examples dump core on my machine (truth be told, it might have also happened with 1.8. I should go and check that, too). It looks like something going awry in a destructor. Do they run on yours? Supporting both 1.8 and 1.9 might be doable in the wrappers if I can get the Ruby version (I see a macro for it in ruby/version.h, but the comments are discouraging me from using it); it should be just a matter of defining some macro QL_RARRAY_LEN(x) to expand to RARRAY(x)-len for 1.8 and RARRAY_LEN(x) for 1.9. My Ruby-fu is very rusty, though, so I'm not sure how to require 'ftools' or 'fileutils' depending on the version, or how to alias a common name to the correct one. Christian, do you have any suggestions? (Also on the version thing above?) Later, Luigi (oh, and a happy new year in case I don't hear from you today) On Tue, Dec 31, 2013 at 5:34 AM, Dirk Eddelbuettel e...@debian.org wrote: Ok, one last one: I just updated the pull request https://github.com/lballabio/quantlib/pull/65 and the second patch contains further fixes to setup.rb to do the install step under Ruby 1.9. (The third patch just corrects the version back to '1.4' for the dev tree.) Supporting 1.8 and 1.9 upstream may be a bit of a pain though. I also uploaded a repaired new Debian package -- thanks again to Christian. Dirk -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- https://implementingquantlib.blogspot.com https://twitter.com/lballabio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733743: ITP: libnih.la -- portable libnih implementation
On 31 December 2013 15:25, cameron camerontnor...@gmail.com wrote: Dmitri, Why do you not use libinotify-kqueue? I know you mentioned not wanting to have a lot of external dependencies, but I think using that library will allow other linux applications to more easily port to kFreeBSD. I have packaged it and attempted to use it. [1] Unfortunately it doesn't provide sufficient compatibility and I see a lot of unit-test failures. Instead of enabling something partially broken, i'd rather not provide the facility full stop and instead implement a native kqueue/kevent. Granted I could spend time improving libinotify-kqueue. At the moment I'm focusing on booting a kFreeBSD/eglibc system with upstart, since file notifications are optional in upstart (well to be precise, they may fail / raise errors at runtime and upstart handles that gracefully) [1] http://packages.qa.debian.org/libi/libinotify-kqueue.html Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733003: ncl: FTBFS: ./Configure: not found (needs csh)
Hi, besides trying to close the wrong bug via the changelog (733033 instead of 733003), ncl 6.1.2-2 still FTBFS in current unstable as you can find at https://buildd.debian.org/status/package.php?p=nclsuite=sid : ... make[5]: Leaving directory `/«PKGBUILDDIR»/ni/src/examples' make[4]: Leaving directory `/«PKGBUILDDIR»/ni/src' make[3]: Leaving directory `/«PKGBUILDDIR»/ni' make[2]: Leaving directory `/«PKGBUILDDIR»' mkdir -p debian/libncarg-dev//usr/lib/x86_64-linux-gnu cp debian/tmp/lib/*.a debian/libncarg-dev//usr/lib/x86_64-linux-gnu mkdir -p debian/libncarg0//usr/lib/x86_64-linux-gnu cp shared/*.so.1 debian/libncarg0//usr/lib/x86_64-linux-gnu cp: cannot stat 'shared/*.so.1': No such file or directory make[1]: *** [override_dh_auto_install] Error 1 make[1]: Leaving directory `/«PKGBUILDDIR»' make: *** [binary-arch] Error 2 ... Roland -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733459: game-data-packager: md5 checksum error packing hexen II data
clone 733459 -1 -2 retitle -1 better advice for old versions of games (e.g. hexen2) severity -1 minor retitle -2 portal of praevus (hexen2 MP) support please severity -2 wishlist thanks Hi, On Sat, Dec 28, 2013 at 08:29:08PM -0500, Andres Cimmarusti wrote: As expected, g-d-p currently does not support pak3 and pak4, but they are fully supported by uhexen2 There are three bugs here. Simon is correct that there are shell quoting problems that you have hit since your folder is Hexen II. I'm surprised I didn't hit them myself. Additionally, I don't think we necessarily offer the clearest advice if you have an older, unpatched version of H2: we should at least point at how to upgrade your version (or obtain a patched version) if not walk through the patching itself within gdp. Finally, praevus is not yet supported, that should be pretty easy to add, I was not aware of hexenworld's pak4 and indeed we should manage that too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#731699: vlc: Segmentation fault by clicking on 'MyVideos' or 'My Music' or 'My Pictures'
reassign 731699 libdvdnav4 thanks -- Rémi Denis-Courmont http://www.remlab.net/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733752: modemmanager: installed dbus .service buggy
Package: modemmanager
Version: 1.0.0-1
Severity: normal
#secure method=pgpmime mode=sign
Dear Maintainer,
the file
/usr/share/dbus-1/system-services/org.freedesktop.ModemManager1.service
installed with modemmanager 1.0.0-1 from experimental
contain probably invalid ${exec_prefix}/sbin/ModemManager.
Probably this is an upstream bug.
I fixed this problem addin attached patch to quilt series.
--- a/configure.ac
+++ b/configure.ac
@@ -265,7 +265,6 @@ data/Makefile
data/ModemManager.pc
data/mm-glib.pc
data/org.freedesktop.ModemManager1.policy.in
-data/org.freedesktop.ModemManager1.service
include/Makefile
include/ModemManager-version.h
build-aux/Makefile
--- a/data/Makefile.am
+++ b/data/Makefile.am
@@ -35,6 +35,8 @@ endif
dbusactivationdir = $(datadir)/dbus-1/system-services
dbusactivation_DATA = org.freedesktop.ModemManager1.service
dbusactivation_in_files = org.freedesktop.ModemManager1.service.in
+org.freedesktop.ModemManager1.service: org.freedesktop.ModemManager1.service.in
+ $(edit) $ $@
# Icon
icondir=${datadir}/icons/hicolor/22x22/apps
Another problem during apt-get source modemmanager/1.0.0-1 debuild
cycle was realted to polkit. I have installed libpolkit-gobject-1-dev
resulting in a modemmanager build fail (dh_install --fail-missing).
Solved by adding usr/share/polkit-1 to modemmanager.install or adding
--with-polkit=none in overrride_dh_auto_configure rule.
Best regards,
Marco
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (800, 'unstable'), (500, 'testing'), (500, 'stable'), (500,
'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.11-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages modemmanager depends on:
ii libc6 2.17-97
ii libglib2.0-02.39.0~ae6dbb35-1
ii libgudev-1.0-0 204-5
ii libmbim-glib0 1.6.0-2
ii libmm-glib0 1.0.0-1
ii libqmi-glib01.4.0-1
Versions of packages modemmanager recommends:
ii usb-modeswitch 2.0.1+repack0-2
--
GPG key: 4096R/0xF7FE4DAA 2013-08-02 Marco Bardelli bardelli.ma...@gmail.com
Bug#731156: libupsclient3: Library is containing undefined references
Le Tue, 31 Dec 2013 15:59:58 +0100, Laurent Bigonville bi...@debian.org a écrit : Hello Matthias, Thanks for the patch! It also includes backport-fix-lp753661.patch was that actually expected? Looks like this has been fixed an other way, http://trac.networkupstools.org/projects/nut/changeset/2973 Also, the patch makes libupsclient export new symbols (from libcommon), that's probably not wanted. Cheers Laurent Bigonville -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733754: plymouth errors out during start-up
Package: plymouth Version: 0.8.5.1-5 Severity: important Dear Maintainer, Plymouth in Wheezy errors out. I'm having difficulty capturing output of the error and might have to resort to some camerawork if I can't find something logged. I observe two errors. First, something Plymouth is doing either directly or indirectly results in a denied lookup for information associated with UID 0. Second, the plymouth init script returns failure consistently. (This is with a fresh install of Wheezy.) I'll add more to the ticket as I'm able to capture it. But for now, this largely destroys Plymouth's appeal, as rather than covering boot messages, it generates errors that wouldn't be there otherwise, both foreshortening its screen coverage and adding worrisome error messages to the boot process. Makes Debian look shabby having things broken in Stable, and as such if this is something known and fixed in Jessie or Sid, it ought to be applied to Wheezy. I don't know that this is the case with this package, but I'd like us to avoid any unfortunate situation in which the flagship product of Debian is neglected for any reason. Thanks! -- System Information: Debian Release: 7.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-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 plymouth depends on: ii initramfs-tools0.109.1 ii libc6 2.13-38 ii multiarch-support 2.13-38 plymouth recommends no packages. Versions of packages plymouth suggests: ii desktop-base 7.0.3 ii plymouth-drm 0.8.5.1-5 -- Configuration Files: /etc/plymouth/plymouthd.conf changed: [Daemon] Theme=fade-in -- 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#733753: cfitsio3: add arm64 support
Package: cfitsio3 Version: 3.340-2 Severity: normal Tags: patch User: ubuntu-de...@lists.ubuntu.com Usertags: origin-ubuntu ubuntu-patch trusty This patch adds support for the arm64 architecture. It would be nice if this package would fail to build if it ends up with wrong byteswapping / word size rather than apparently building successfully but then failing later (in my case, when trying to build wcslib). Isn't there some test program that could be run at build time? * Handle 64-bit ARM. diff -Nru cfitsio3-3.340/debian/patches/arm64.patch cfitsio3-3.340/debian/patches/arm64.patch --- cfitsio3-3.340/debian/patches/arm64.patch 1970-01-01 01:00:00.0 +0100 +++ cfitsio3-3.340/debian/patches/arm64.patch 2013-12-31 16:25:17.0 + @@ -0,0 +1,21 @@ +Description: Handle 64-bit ARM +Author: Colin Watson cjwat...@ubuntu.com +Forwarded: no +Last-Update: 2013-12-31 + +Index: b/fitsio2.h +=== +--- a/fitsio2.h b/fitsio2.h +@@ -136,6 +136,11 @@ + #error can't handle long size given by _MIPS_SZLONG + # endif + ++#elif defined(__aarch64__) ++ ++#define BYTESWAPPED TRUE ++#define LONGSIZE 64 ++ + /* == */ + /* the following are all 32-bit byteswapped platforms*/ + diff -Nru cfitsio3-3.340/debian/patches/series cfitsio3-3.340/debian/patches/series --- cfitsio3-3.340/debian/patches/series2012-06-03 01:12:20.0 +0100 +++ cfitsio3-3.340/debian/patches/series2013-12-31 16:23:56.0 + @@ -7,3 +7,4 @@ 07-dont-export-constants.patch 08-fits_compress_img.patch 09-off_t.diff +arm64.patch 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#733516: [request-tracker-maintainers] Bug#733516: request-tracker4: please update to 4.2
On Mon, Dec 30, 2013 at 01:36:48AM +0900, Hideki Yamane wrote: Upstream releases 4.2.1, so please consider to upgrade your package. (or just update to 4.0.18). Hi, Thanks for getting in touch. I should be able to work on both next month (and indeed started already). And 4.2.x is major update as upstream says - do you release it as request-tracker4.2, or just update its version? That's still an open question in my mind. I think I at least need to ask upstream how stable they consider the API for extensions between 4.0 and 4.2. Major incompatibilities there is probably the biggest reason to consider a move to request-tracker4.2, and it is quite a lot more work I'd be keen to avoid without due cause. Cheers, Dominic. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#727708: upstart and upgrading from sysvinit scripts
Simon McVittie s...@debian.org writes: On Sat, 28 Dec 2013 at 16:45:38 -0800, Russ Allbery wrote: The second supported option is DAEMON_OPTS, which sets additional flags to add to the process. For as long as we need to support multiple init systems, this option needs to stay in /etc/default/lbcd and be read from there by all supported init systems so that configuration is preserved as the user moves between init systems. I'd like to suggest that this should only be done for daemons where there is anything that a sysadmin can sensibly configure in this way. The patch proposed for #712167 (native Upstart init support in dbus) did this, but after checking the available command-line options in dbus-daemon, I couldn't actually find any command-line options that can be changed by a sysadmin without breaking system integration; so I think it's OK that the systemd unit doesn't read /etc/default/dbus, and I don't think the (potential future) Upstart job should either. I would argue (Perhaps this means /etc/init.d/dbus should stop reading /etc/default/dbus...) ...this. If /etc/default is not useful, then it's not useful for the sysvinit support either, and it seems better to just drop it in all supported init systems rather than have it be inconsistent. Either way, you'd need a NEWS entry, etc., so that seems cleaner to me. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733755: pybuild should show by default how the distutils/setuptools are called
Package: dh-python Version: 1.20131021-1 pybuild should show by default how the distutils/setuptools are called, at least for the build, install and test invocations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733756: Please add Bastiaan Franciscus van den Dikkenberg to Debian Maintainers keyring
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Package: debian-maintainers Severity: normal Please add me Bastiaan Franciscus van den Dikkenberg to Debian Maintainers keyring. below you find my key details. I switched today to a new key, to ensure my key is secure and have higher grade of encryption an instead of sha1 I sigend my new key with my old key, so can check that i am who i say i am :-D. pub 4096R/E231FCB2 2013-12-31 Key fingerprint = 0466 51D1 6AA2 6A01 A0B0 3072 3C84 0C0A E231 FCB2 uid Bastiaan Franciscus van den Dikkenberg b...@dikkenberg.net uid Bastiaan Franciscus van den Dikkenberg bas...@gmail.com uid Bastiaan Franciscus van den Dikkenberg b...@hobby.nl uid Bastiaan Franciscus van den Dikkenberg b.f.v.d.dikkenb...@kader.hcc.nl uid Bastiaan Franciscus van den Dikkenberg b...@cacert.org sub 4096R/FF9C28A9 2013-12-31 sub 3072D/0A244D42 2013-12-31 sub 4096g/0D6E36E2 2013-12-31 With kind regards, Bastiaan Franciscus van den Dikkenberg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iF4EAREIAAYFAlLC9HAACgkQ++KvngokTUK69AD+KOCdJY6QtaE/T0sUX+EiM0A7 qcdnXN3AAgLeY8RArnsA+wdMruFf71M30J4CYYUnXuxr3MB2kffeOb+aFJwE+Xdb =FY/m -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#727708: loose ends for init system decision
Russ Allbery writes (Bug#727708: loose ends for init system decision): Ian Jackson ijack...@chiark.greenend.org.uk writes: - avoid extra build-dependencies (eg on libsystemd) - avoid extra runtime dependencies (eg on deb-systemd-helper) These requirements, on the other hand, I find completely baffling. This approach seems completely contrary to Debian best practices. Our standard practice with all packages is to fully enable all available features that make sense on Debian and don't pose some concrete risk. The case in point is a little different. It's one thing to say that mail daemons should come with ldap support enabled, or whatever (and even then we sometimes have two versions e.g. heavy and light). For me it's a different proposition to suppose that _every_ daemon should bring in these kind of dependencies. This is particularly the case for build-dependencies on an avowedly and intentionally non-portable program. Of course this can be made conditional, but this is IMO too fiddly. We should recommend: - daemon authors and Debian maintainers should prefer command-line options to environment variables I disagree with including this in a statement. I think it's outside the scope of what we were asked to resolve, and I don't think it's the place of the TC to offer this sort of general advise to upstreams. It is very likely that Debian contributors will be implementing native support for whatever readiness protocol, in the upstream parts of the codebase. It is IMO appropriate for those contributors to get advice on how to do this. Policy already gives advice on this kind of thing. Given the context, and the fact that this advice is going to be read by a lot of people as part of a big enhancement project, I think it's appropriate for the TC to answer this question. If we're going to offer specific advice, we should limit it to the specific integrations that we're asked to consider. But I think we should be mindful of the restriction on the TC not doing design work and let Policy for packaging support of upstart and/or systemd be hashed out through the regular Policy process. Are you proposing then that the TC should decide the default init system, but asmk people NOT to start converting packages until the policy questions are settled ? Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733754: plymouth errors out during start-up
Version: 0.8.8-2 On 12/31/2013 05:30 PM, Mason Loring Bliss wrote: First, something Plymouth is doing either directly or indirectly results in a denied lookup for information associated with UID 0. Second, the plymouth init script returns failure consistently. (This is with a fresh install of Wheezy.) these have been fixed in above version. -- Address:Daniel Baumann, Donnerbuehlweg 3, CH-3012 Bern Email: daniel.baum...@progress-technologies.net Internet: http://people.progress-technologies.net/~daniel.baumann/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#726763: Bug#727708: systemd-shim uploaded to NEW
Steve Langasek writes (Bug#727708: systemd-shim uploaded to NEW): On Mon, Dec 30, 2013 at 06:29:10PM +, Ian Jackson wrote: This would be quite wrong; Replaces is not supposed to be used like that (but you apparently know that). Yes. Raphaël rightly points out that dpkg-divert can be used for this; if necessary, that's what I'll do. Right. I think it would be best if you did that for now. I'm right in thinking that that would get you (and non-systemd-users) unblocked ? But I still think the right thing here is for the systemd package to be split. I agree, but I think it would be best to postpone the resolution of this dispute until after the main conclusions in this TC thread. (One argument for delaying is that if the TC decides that systemd is not only default, but mandatory, for jessie, this becomes irrelevant.) Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#733747: Please apply patch from https://github.com/the-tcpdump-group/libpcap/commit/1a52c9a05758d162e331dc93d60c51ebeb7b0f55
Hi, Yes, libpcap 1.5.3 was supposed to come out two weeks ago with this change and other urgent fixes, but it hasn't happened. Stay tuned. Thanks, -- Romain Francoise rfranco...@debian.org http://people.debian.org/~rfrancoise/ -- 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 system other points, and conclusion
intrigeri writes (Bug#727708: init system other points, and conclusion): (Sorry if I am duplicating a point that was already made. These threads are huge, and don't fit entirely into my memory.) That's fine, of course. Ian Jackson wrote (30 Dec 2013 18:58:37 GMT) : Unless you are proposing to make systemd mandatory for all Debian installations, this is work that needs to be done anyway. Needs to be done anyway, possibly, but I find it important to make it clear that, depending on what decision is made, it affects the project as a whole, and many of its members, in very different ways: * In one case (upstart is chosen as the default init system), we, as a project, are committed to do this work, at the very least because Policy mandates it, and we want to release without too many RC-buggy packages. I think you have misunderstood. Or perhaps I hae misunderstood you. The work that I'm saying needs to be done anyway is the work to disentange the parts of systemd which are required by (say) GNOME from the parts which are only relevant for systemd as init. This is work that would have to be done by the systemd maintainers in Debian. The difference lies in who are the people who need to do this work anyway, and who else may instead dedicate their time to other tasks, lead by their own desires and needs. I think that it is right that the costs of undoing systemd's bundling, be borne by the systemd community (including systemd's advocates and maintainers in Debian) rather than by Debian (or the rest of the Free Software world) at large. Ian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
