Bug#692249: sata boot+grub unknown filesystem without boot=on
Hello. Do you still remember this old bug from late-2012? Do you still have any issues outlined there? I weren't able to reproduce it meantime, and both qemu and seabios undergone several releases. Can we close this bugreport now maybe? :) Thanks, /mjt 31.12.2012 01:03, Michael Tokarev wrote: 31.12.2012 00:43, Gianluigi Tiesi wrote: On 12/29/12 15:57, Michael Tokarev wrote: [] vm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw,boot=on -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 This is not scsi, this is ahci, FWIW. Yes true, but boot=on option was made for scsi, so why it makes work my ahci setup that instead would not work? I mean it should be unrelated but instead looks like related. Well. boot=on was made for general usage, it works (or worked) for any bootable device, including scsi and ahci and network and other stuff. It was a quick hack to allow booting from devices not directly supported by seabios, and is not supported by upstream anymore. but if I run: kvm -m 1024 -snapshot -device ahci,id=ahci0,bus=pci.0,addr=0x5 -drive file=/dev/sda,if=none,id=drive-sata0-0-0,format=raw -device ide-hd,bus=ahci0.0,drive=drive-sata0-0-0,id=sata0-0-0 grub loads but it's unable to identify the filesystem Well. Which version of seabios is that? I'm asking because this does not boot at all with current seabios+qemu-kvm from wheezy: guest bios does not find any boot device. If in your case guest bios finds the boot device and loads grub, it must be some other version of either qemu-kvm or seabios. I'm on sid, and the just updated seabios 1.7.1-1 exposes same behavior qemu-kvm is 1.1.2+dfsg-3 Interesting. Okay. So I need some way to reproduce this. Can you please tell us what do you use as the guest? What is it, how it was setup, etc? Maybe it is enough to do a fresh install of some distribution to expose this issue? [] Unfortunately bootindex options changes nothing Ok. here grub2 without boot=on Booting from Hard Disk... GRUB loading. Welcome to GRUB! error: unknown filesystem. Entering rescue mode... grub rescue ls (hd0) (hd0,msdos4) (hd0,msdos3) (hd0,msdos2) (hd0,msdos1) (fd0) grub rescue ls (hd0,msdos4) error: unknown filesystem. Oh well. It looks like grub is unable to _read_ the drive. I need a way to reproduce this :) I'll try doing some installing/booting here when time permits. Maybe you can provide some instructions or maybe a guest image to speed things up... ;) while it works fine with boot=on Ok. So it appears to be some grub+seabios issue with the correct/modern way of booting things, while old/legacy boot option works fine. Thank you! /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756729: [DSE-Dev] Bug#756729: selinux-policy-default: Setting SELinux to enforce results in not configured network interface at boot time
Hello Mika, some more observations: I found a workaround: Changing 'allowed-hotplug eth0' to 'auto eth0' in /etc/network/interfaces fixes the problem for me. In the cases where this problem occurs, the /sys/class/net/eth0/operstate is 'down'. Therefore the hotplug function will not pick up the device. But why and how does (not) enforcing influence the setting of the device's operstate? Kind regards Andre -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756734: ITP: python-xstatic-jquery -- jquery XStatic support
On 08/02/2014 01:42 AM, Jeremy Stanley wrote:
Great! Sorry, I hadn't spotted any of the other xstatic packages
you'd repackaged and uploaded yet so I didn't realize they were
going to omit the Javascript libraries themselves and just provide
the xstatic installation wrapper.
Well, I haven't uploaded any other xstatic package yet! :)
Only python-xstatic and python-xstatic-jquery are currently in NEW.
In that case I don't suppose there's any risk of having them
rejected, but it still may be worth a quick discussion with the
Horizon devs to confirm this is at all necessary, so you don't waste
your already limited available time (assuming this hasn't already
been discussed with them).
I agree. However, seeing how it seems to work, it's looking like having
the xstatic packages is the only way so that Horizon knows where to
search for the .js files.
I'll do some asking around as well... on
its face, at least, it seems dubious that you should actually need a
Debian wrapper around a Python wrapper around a Javascript library
which is itself already packaged in Debian.
If so, using which mechanism horizon may find (for example) the
jquery.min.js file then? Currently, within the standard
openstack_dashboard/settings.py, we have:
STATICFILES_DIRS = (
('horizon/lib/jquery',
xstatic.main.XStatic(xstatic.pkg.jquery).base_dir),
)
It is IMO more reasonable to package xstatic packages rather than
applying patches that would need constant rebasing. Also, this helps
making sure the distro package matches the current requirements.txt,
also regarding available versions.
Packaging the xstatic packages will not take a lot of my time. What
will, is the packaging of the Javascript libraries themselves. For
example, I'm not sure how to package bootstrap-scss which, upstream, is
part of some ruby code (if I'm not mistaking. I'm not sure that's the
correct one I'm talking about, because I had a look a few weeks ago...).
Your thoughts would be welcome.
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756722: lintian: false positive for embedded-library error
Hi Jakub, On Fri, 1 Aug 2014 11:15:57 +0200, Jakub Wilk wrote: * Atsuhito Kohda ko...@pm.tokushima-u.ac.jp, 2014-08-01, 11:08: rejected by ftp-master because of lintian output: 'embedded-library usr/lib/texmacs/TeXmacs/bin/texmacs.bin: freetype', automatically rejected package. [...] I rebuild the (accepted) former version of texmacs but got the same lintian error so I believe this should be false positive. Hmm, I can't reproduce it here. I rebuilt texmacs (1:1.0.7.18-1) in up-to-date unstable amd64 chroot, but the resulting packages don't trigger any such error. Sorry but I mean texmacs 1.99.1-1 (accepted one) and 1.99.1-2 (rejected one) in experimental. Due to some fonts license issue, I upload texmacs in experimental recently. Could you upload the packages somewhere (and preferably also the build log), so that we can take a close look at them? I'll upload the package to my homepage but my main machine is in my office so it will happen after monday. Thanks for your work. Best regards, 2014-8-2(Sat) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756722: lintian: false positive for embedded-library error
Control: tags -1 + confirmed * Atsuhito Kohda ko...@pm.tokushima-u.ac.jp, 2014-08-02, 15:28: 'embedded-library usr/lib/texmacs/TeXmacs/bin/texmacs.bin: freetype', automatically rejected package. [...] I rebuild the (accepted) former version of texmacs but got the same lintian error so I believe this should be false positive. Hmm, I can't reproduce it here. I rebuilt texmacs (1:1.0.7.18-1) in up-to-date unstable amd64 chroot, but the resulting packages don't trigger any such error. Sorry but I mean texmacs 1.99.1-1 (accepted one) and 1.99.1-2 (rejected one) in experimental. Oh, I didn't notice that there's a package in experimental. That was a bit of information I was missing. Even the package from the archive triggers the Lintian error: $ lintian -F texmacs_1.99.1-1_amd64.deb E: texmacs: embedded-library usr/lib/texmacs/TeXmacs/bin/texmacs.bin: freetype (The package was accepted to the archive, because at that point Lintian didn't have the check for freetype implemented yet.) To detect embedded copies of freetype, Lintian looks for the string FT_Get_CID_Is_Internally_CID_Keyed in the binaries. But this is a name of a public function, and texmacs just happens to use it. So it's indeed a false positive. I'm not sure why exactly FT_Get_CID_Is_Internally_CID_Keyed was chosen, and what would be a better string to use... Until we figure it out, please add an override for the tag. I'll upload the package to my homepage but my main machine is in my office so it will happen after monday. It's no longer necessary. :-) -- 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#756778: RFS: charmap.app/0.3~rc1-2 [RC] -- Character map for GNUstep
Eriberto wrote: Please, complete the Debian copyright years in d/copyright. I somehow missed that. Thanks; fixed. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755779: ruby-all-dev: please document how to query all-supported and default Ruby flavors
Quoting Antonio Terceiro (2014-07-23 16:57:40) On Wed, Jul 23, 2014 at 10:39:45AM +0200, Jonas Smedegaard wrote: For uWSGI packaging I need to know at build time which flavors of ruby are supported in the build environment and which of those is default for that environment. I can hardcode values for Sid (currently ruby2.1 for both), but would highly prefer to query the build environment as that eases backportability. Here is the current one-liner I currently use to resolve supported flavors: ruby -rruby_debian_dev -e 'include RubyDebianDev; SUPPORTED_RUBY_VERSIONS.select! do |version, binary|; puts version; end' Please consider documenting either that above command is correct, or which other shell command is more proper. Does http://anonscm.debian.org/cgit/collab-maint/ruby-defaults.git/commit/?id=24da0892ae3dd57581394ac7bf8fc8b44e8f0251 address your concerns? The easy way is `dh_ruby --print-supported` Yes, above is exactly what I was looking for. Thanks! I would not expect such detailed info to be documented in long description of a package, though, but instead in README file of said package. I recommend you to duplicate (or for the command options at least, move) the info to the README file. However, we decided to not support multiple interpreters in stable releases anymore, so keep in mind this support for multiple supported versions will be used solely for handling transitions in unstable without leaving testing broken while eventual issues are sorted out (we will hold new intepreters in unstable until we think it is safe enough to let it into testing). It is also OK to only build for the default version, and using just `ruby` (instead of harcoding the current default) will do that in a future-proof way. And please also document if default flavor is simply the first entry of (potentially) multi-entry list output of above command, or else which shell command can resolve default Ruby flavor of current system. the default is always what /usr/bin/ruby points to. That is very valuable information too. I recommend that you document that in a mini policy for the Ruby language somewhere - e.g. on a wiki page. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#754463: RFS: pdf2htmlex/0.11+ds-1
Hi, Quoting Jakub Wilk (2014-08-01 22:31:46) * Johannes Schauer j.scha...@email.de, 2014-07-30, 07:24: I do not understand why it fails for you but not for me. How did you run the tests? I ran sadt(1) in the freshly-unpacked source tree. I ran `adt-run -o /tmp/log --source pdf2htmlex_0.11+ds-1.dsc --- schroot sid-amd64-sbuild` This is what the adt-run manpage says about the --source option: By default the package will also be built and the resulting binaries will be used to satisfy test dependencies Presumably it also means that the built tree is used for running tests. (What I've been doing in my packages, as a defensive strategy against accidentally testing against not-installed code, is to copy all the bits necessary to run tests from the package directory to $ADTTMP, then chdir to $ADTTMP, and run tests from there.) I think the last bit makes most sense. I changed the test accordingly. Notice that there is also a dedicated git repository for tests. https://github.com/coolwanglu/pdf2htmlEX-tests But I'd have to ask upstream about copyright first. Also, maybe they can integrate that repository into their releases which would avoid having to make the upstream tarball generation more complex. Have you seen this thread on d-devel@? https://lists.debian.org/53ccf007.6020...@debian.org Yes, but how is it relevant to this? I'm a bit worried, because pdf2htmlex is built in C++11 mode, but it links to libraries built in C++98 mode. If I understand correctly, this is potentially a recipe for disaster. Maybe. I'm not familiar enough with the kind of disaster that may happen when linking C++11 compiled code to C++98 libraries and the thread does not expand much on that. I also do not see any advised fix or how to prevent the situation. What the thread is about is to ensure that the source is compiled with a C++11 capable compiler. I never tested building with an older compiler. Now, it's probably not something that would stop me from uploading the package. Just wanted to make sure that you are aware of this problem. I did not realize you were offering to sponsor the package but I'm very happy about it :) Upstream did a new release a few days ago. It turned out that it allows to drop nine patches because they integrated them. On the other hand I had to add another patch to be able to build with an older version of libfontforge. I uploaded the new version. I also noticed that the software allows to set ENABLE_SVG=ON which enables generating SVG backgrounds and converting type-3 fonts. But this feature requires CairoFontEngine, CairoRescaleBox and CairoOutputDev from the poppler sources. Should I integrate the required files into the upstream tarball so that we can build with ENABLE_SVG=ON? I also noticed that the required files are shipped by the emscripten binary package. But it'd be quite messy to depend on that binary package for the sources it ships for a different purpose. cheers, josch -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742229: fping: Fails to install if capabilities are not supported
When do you expect to have a fix for this in the archive? It would be useful to know when planning the Debian Edu testing. -- 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#756819: no support for xorg-xserver 1.16
On 08/02/2014 07:28 AM, Caitlin Matos wrote: I apologize, I'm not sure exactly which package this should be filed against, but I'm pretty sure this is the correct one. I am on a Windows 8.1 host running Debian jessie. I updated xorg-xserver etc. to the current version in testing, 1.16.0-1. However, I am no longer able to use the X11-related guest utilities. The relevant output from VBoxLinuxAdditions.run in the guest additions ISO: Installing the Window System drivers Warning: unknown version of the X Window System installed. Not installing X Window System drivers. Looking at the code, the issue is obvious. It is searching for /opt/VBoxGuestAdditions-4.3.14/lib/VBoxGuestAdditions/vboxvideo_drv_116.so, which does not exist. This support needs to be added. I'm sure that's easier said than done, and is probably an upstream problem. Meanwhile, however, this package needs to change its xorg-xserver-core dependency, adding ( 1.16.0). Gianfranco, This was fixed in 4.3.14 ?? -- Ritesh Raj Sarraf | http://people.debian.org/~rrs Debian - The Universal Operating System signature.asc Description: OpenPGP digital signature
Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution
On 07/31/2014 12:02 AM, Lucas Nussbaum wrote: Package: wnpp Severity: wishlist Owner: Lucas Nussbaum lu...@debian.org * Package name: kadeploy Version : 3.3 Upstream Author : Kadeploy developers kadeploy3-de...@lists.gforge.inria.fr * URL : http://kadeploy3.gforge.inria.fr/ * License : CeCILL version 2.0 Programming Lang: Ruby Description : Scalable, efficient and reliable cluster provisioning solution Kadeploy is a scalable, efficient and reliable deployment system (cluster provisioning solution) for cluster and grid computing. It provides a set of tools for cloning, configuring (post installation) and managing cluster nodes. It can deploy a 300-nodes cluster in a few minutes, and also supports authorizing users to initiate their own nodes deployments (including with concurrent deployments). A work-in-progress package is available from: Vcs-Git: git://scm.gforge.inria.fr/kadeploy3/kadeploy3.git Vcs-Browser: https://gforge.inria.fr/scm/browser.php?group_id=2026 Lucas Have you compared it to: https://github.com/enovance/edeploy which has nice role-based system, so you can deploy specific systems depending on what type of hardware (amount of RAM, number of HDD, or anything else you decide)... It's been a long time I was thinking about packaging edeploy, but never found the time to do it. It has a Makefile, but IMO, one would better write a setup.py for it. Your thoughts? Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756825: [ocrfeeder] Fails to start
Package: ocrfeeder Version: 0.7.11-3 Severity: normal Traceback (most recent call last): File /usr/bin/ocrfeeder, line 31, in module from ocrfeeder.studio.studioBuilder import Studio File /usr/lib/python2.7/dist-packages/ocrfeeder/studio/studioBuilder.py, line 21, in module from ocrfeeder.util import lib File /usr/lib/python2.7/dist-packages/ocrfeeder/util/lib.py, line 23, in module import Image ImportError: No module named Image Package was installed using: aptitude install ocrfeeder There were no errors during the installation -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#705212: Processed: RFP: chinese-checkers -- Multiplayer implementation of the chinese checkers game
retitle 705212 ITP: chinese-checkers -- Multiplayer implementation of the chinese checkers game owner 705212 Salvo Tomaselli tipos...@tiscali.it thanks On 31/07/14 at 09:48 +0200, Salvo Tomaselli wrote: retitle 705212 ITP: chinese-checkers -- Multiplayer implementation of the chinese checkers game. thanks Well anyways it's not an RFP since the package is done and ready. Please stop retitling. Sorry for the previous (broken) retitling. This one avoids cutting the bug title after the, and sets you as owner. Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756547: [Pkg-utopia-maintainers] Bug#756547: network-manager: Restarting NM with many connections breaks sshd via start rate limit
How about adding a blocking delay into if-up script?
LOCK_FILE=/tmp/openssh-server-delay
# if lock file exists and is less than 1 second old, do nothing.
# else create a lock file, wait 1 second, remove lock file, restart
if [ -e ${LOCK_FILE} ] [ $(( $(date +%s) - $(stat -c %Y ${LOCK_FILE})
)) -lt 1 ]
then
exit 0
else
touch ${LOCK_FILE}
sleep 1s
rm ${LOCK_FILE}
invoke-rc.d ssh restart /dev/null 21 || true
fi
This way if there is a burst of restart requests within one second, restart
would occur only once, with 1 second delay.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753013: ITP: cppdb -- SQL Connectivity Library
Package: wnpp Tags: -1 pending Followup-For: Bug #753013 Owner: Tobias Frost t...@debian.org cppdb is now in NEW. -- tobi -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#612615: == GOOD NEWS
GOOD NEWS AA1.docx Description: Binary data
Bug#756826: libselinux1: Please apply upstream patch that adds libpcre versions to file_context format
Package: libselinux1 Version: 2.3-1 Severity: serious Tags: sid jessie Owner: Laurent Bigonville bi...@debian.org Hi, libselinux is using a compiled version of the file_context files to speedup lookup. With the last libpcre release the representation of these compiled regex has changed and this could lead to file contexts not being applied properly or to some segfaults if the files are not regenerated after libpcre is upgraded. Upstream has fixed that by adding the libpcre version used to the headers of the compiled files. See the following patch: https://github.com/SELinuxProject/selinux/commit/ac33098a807671204720aae97d6bcf6429d3fa92 This bug is a reminder that we need this patch applied before jessie is released. Cheers, Laurent Bigonville -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/8 CPU cores) Locale: LANG=fr_BE.utf8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libselinux1:amd64 depends on: ii libc6 2.19-7 ii libpcre3 1:8.35-3 ii multiarch-support 2.19-7 libselinux1:amd64 recommends no packages. libselinux1:amd64 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#734634: [Pkg-freeipmi-devel] Bug#734634: Bug#734634: Updated to 1.4.4
]] Yaroslav Halchenko Please gimme a day or two first, May be I would be useful too :-) Of course, please take the time you need. Let me know if there's anything more I can do to get this updated. Cheers, -- 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#670679: python-debian: deb822 can't parse foreign architecture (package:any) relationships
Hi again
I've had a go at reworking the handling of multiarch qualifiers for Build-
Depends. My objectives here were:
* to support all the different qualifiers that are on the horizon (so :native,
:i386 etc as well as :any)
* to expose an API similar to dpkg's Deps.pm (or at least using the same
terminology)
At this stage, I've not exposed any API to interpret the special values like
native or any. I think to do so we should move away from the parsed
package relationship being only a dict and make it a real object and expose
methods or properties to test for these special values.
Following the spirit of Stefano's work on this, I've done a little
housekeeping on this part of the code too in an effort to help make it a little
easier to work with when making the later changes. I've actually done the
tidying first up as that then makes the later multiarch diffs much smaller
toand
hopefully easier to review. Thanks to Stefano Rivera for the original set of
patches which I made heavy use of in doing this work.
While I was touching this part of the code, I've also taken the opportunity to
take a stab at adding support for build profiles. There's no time like the
present to get these things sorted out!
I've done this work based upon my branch with the previous deb822 paragraphs
iterator work -- the patches should actually be portable across branches and
I'll do that if it's actually required. The patches are attached or, if you'd
rather see the context,
git clone ssh://git.nanonanonano.net/srv/git/python-debian.git -b multiarch
(if I update the patches based on comments, I can't promise not to rewrite
history on that branch!)
As with the work on the paragraphs iterator, I'd very much like some feedback
;)
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
From 3c06fe85f52524bbbee06ae514a424d7f1f4a3f9 Mon Sep 17 00:00:00 2001
From: Stefano Rivera stefa...@debian.org
Date: Fri, 27 Apr 2012 23:35:36 +0200
Subject: [PATCH 1/6] Break a very long regex up
---
lib/debian/deb822.py | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 86ceb7c..7862934 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -881,8 +881,11 @@ class PkgRelation(object):
# XXX *NOT* a real dependency parser, and that is not even a goal here, we
# just parse as much as we need to split the various parts composing a
# dependency, checking their correctness wrt policy is out of scope
-__dep_RE = re.compile( \
-r'^\s*(?Pname[a-zA-Z0-9.+\-]{2,})(\s*\(\s*(?Prelop[=]+)\s*(?Pversion[0-9a-zA-Z:\-+~.]+)\s*\))?(\s*\[(?Parchs[\s!\w\-]+)\])?\s*$')
+__dep_RE = re.compile(
+r'^\s*(?Pname[a-zA-Z0-9.+\-]{2,})'
+r'(\s*\(\s*(?Prelop[=]+)\s*'
+r'(?Pversion[0-9a-zA-Z:\-+~.]+)\s*\))?'
+r'(\s*\[(?Parchs[\s!\w\-]+)\])?\s*$')
__comma_sep_RE = re.compile(r'\s*,\s*')
__pipe_sep_RE = re.compile(r'\s*\|\s*')
__blank_sep_RE = re.compile(r'\s*')
--
1.9.1
From 700a36bae738b2fe454cdc7ef2f3ca261a7e6769 Mon Sep 17 00:00:00 2001
From: Stuart Prescott stu...@debian.org
Date: Sat, 2 Aug 2014 17:32:33 +1000
Subject: [PATCH 2/6] Tidy creation of relation parsing
Preliminary house keeping for multiarch work
---
lib/debian/deb822.py | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/debian/deb822.py b/lib/debian/deb822.py
index 7862934..07c1dd4 100644
--- a/lib/debian/deb822.py
+++ b/lib/debian/deb822.py
@@ -896,7 +896,7 @@ class PkgRelation(object):
Depends, Recommends, Build-Depends ...)
def parse_archs(raw):
-# assumption: no space beween '!' and architecture name
+# assumption: no space between '!' and architecture name
archs = []
for arch in cls.__blank_sep_RE.split(raw.strip()):
if len(arch) and arch[0] == '!':
@@ -909,14 +909,14 @@ class PkgRelation(object):
match = cls.__dep_RE.match(raw)
if match:
parts = match.groupdict()
-d = { 'name': parts['name'] }
+d = {
+'name': parts['name'],
+'version': None,
+'arch': None
+}
if not (parts['relop'] is None or parts['version'] is None):
d['version'] = (parts['relop'], parts['version'])
-else:
-d['version'] = None
-if parts['archs'] is None:
-d['arch'] = None
-else:
+if parts['archs']:
d['arch'] = parse_archs(parts['archs'])
return d
else:
--
1.9.1
From
Bug#751448: netexpect: FTBFS with wireshark 1.12.0~rc1-2 from experimental
Control: severity -1 serious On 2014-06-13 00:40:39, Bálint Réczey wrote: Package: netexpect Version: 0.21-2 Severity: important Hi Eloy, Wireshark will be updated to the next major upstream release (1.12.0) in unstable in a few weeks. Please make sure that netexpect builds with the new release. For helping the transition wireshark 1.12.0~rc1-2 has been uploaded to experimental. The severity of this bug will be bumped to serious when 1.12.0 enters unstable. 1.12.0+git+4fab41a1-1 is now in unstable causing 0.22-1 to FTBFS everywhere. Please see https://buildd.debian.org/status/package.php?p=netexpect for the full build logs. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#756827: urjtag: FTBFS on arm*
Source: urjtag Version: 0.10+r2007-1.1 Severity: serious Justification: fails to build from source (but built successfully in the past) urjtag FTBFS on arm* with: | libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -I../../include/urjtag -I../.. -I../../include -D_FORTIFY_SOURCE=2 -Wall -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall -c cmd_bfin.c -fPIC -DPIC -o .libs/cmd_bfin.o | In file included from /usr/include/signal.h:352:0, | from /usr/include/arm-linux-gnueabi/sys/wait.h:29, | from cmd_bfin.c:30: | ../../include/urjtag/bfin.h:40:5: error: redeclaration of enumerator 'REG_R0' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, | ^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:41:3: note: previous definition of 'REG_R0' was here |REG_R0 = 0, |^ | ../../include/urjtag/bfin.h:40:23: error: redeclaration of enumerator 'REG_R1' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:43:3: note: previous definition of 'REG_R1' was here |REG_R1 = 1, |^ | ../../include/urjtag/bfin.h:40:31: error: redeclaration of enumerator 'REG_R2' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:45:3: note: previous definition of 'REG_R2' was here |REG_R2 = 2, |^ | ../../include/urjtag/bfin.h:40:39: error: redeclaration of enumerator 'REG_R3' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:47:3: note: previous definition of 'REG_R3' was here |REG_R3 = 3, |^ | ../../include/urjtag/bfin.h:40:47: error: redeclaration of enumerator 'REG_R4' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:49:3: note: previous definition of 'REG_R4' was here |REG_R4 = 4, |^ | ../../include/urjtag/bfin.h:40:55: error: redeclaration of enumerator 'REG_R5' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:51:3: note: previous definition of 'REG_R5' was here |REG_R5 = 5, |^ | ../../include/urjtag/bfin.h:40:63: error: redeclaration of enumerator 'REG_R6' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:53:3: note: previous definition of 'REG_R6' was here |REG_R6 = 6, |^ | ../../include/urjtag/bfin.h:40:71: error: redeclaration of enumerator 'REG_R7' | REG_R0 = T_REG_R, REG_R1, REG_R2, REG_R3, REG_R4, REG_R5, REG_R6, REG_R7, |^ | /usr/include/arm-linux-gnueabi/sys/ucontext.h:55:3: note: previous definition of 'REG_R7' was here |REG_R7 = 7, |^ | make[4]: *** [cmd_bfin.lo] Error 1 Full build logs are available from https://buildd.debian.org/status/package.php?p=urjtag. Please take a look. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#756828: qemu(1) not correct man page
Package: qemu-kvm Version: 2.1+dfsg-2 Severity: minor File: /usr/share/man/man1/kvm.1.gz This man page refers to qemu(1) but it seems that is not the correct name of that man page anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756830: can't break line
Package: libvirt-clients Version: 1.2.7~rc2-1 Severity: wishlist File: /usr/share/man/man1/virsh.1.gz I see $ man virsh paused The domain has been paused, usually occurring through the standard input:616: warning [p 7, 11.0i]: can't break line administrator running virsh suspend. When in a paused state the domain will still consume allocated resources like memory, but will not be eligible for scheduling by the hypervisor. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756829: qemu-i386 is not the exact name of the command anymore
Package: qemu-system-common Version: 2.1+dfsg-2 Severity: minor File: /usr/share/doc/qemu-system-common/qemu-doc.html In many places in the docs we see e.g., 5.2.1 Quick Start In order to launch a Linux process, QEMU needs the process executable itself and all the target (x86) dynamic libraries used by it. * On x86, you can just try to launch any process by using the native libraries: qemu-i386 -L / /bin/ls However it seems qemu-i386 is not the exact name of the command anymore. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756026: init: Please support Multi-Arch
]] Dimitri John Ledkov Given the nature of this metapackage, it should be declared as Multi-Arch:init to satisfy init dependencies across multi-arch boundaries. Why would anything depend on init? It's an Essential: yes package, so you shouldn't add Depends on it. -- 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#756314: libidl: use dh-autoreconf to fix FTBFS on ppc64el
Control: tags -1 + pending
Hi,
The unability to compile this package is a problem for ports being
added recently (OpenRISC/or1k, ppc64el, ...) since they don't have
older versions to rely on, and many packages depend on them as
build-dependencies to compile, so this package (among many others) is
blocking a good portion of the archive to compile cleanly for these
ports.
I am preparing a NMU (diff attached) to fix the bugs above (see
headers), uploaded immediately as per guidelines in [1] -- since this
package is needed to compile many other packages, the package is
orphan, and the changes should not affect the behaviour of the package
in the other architectures.
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
Please let me know if you want me to cancel the upload, or can assist
you in any way.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -u libidl-0.8.14/debian/changelog libidl-0.8.14/debian/changelog
--- libidl-0.8.14/debian/changelog
+++ libidl-0.8.14/debian/changelog
@@ -1,3 +1,12 @@
+libidl (0.8.14-0.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Run dh-autoreconf to update config.{sub,guess} and
+{libtool,aclocal}.m4, necessary for some new ports. Thanks
+Brahadambal Srinivasan. (Closes: #756314)
+
+ -- Manuel A. Fernandez Montecelo m...@debian.org Sat, 02 Aug 2014 10:09:24
+0100
+
libidl (0.8.14-0.3) unstable; urgency=low
* Non-maintainer upload.
diff -u libidl-0.8.14/debian/control libidl-0.8.14/debian/control
--- libidl-0.8.14/debian/control
+++ libidl-0.8.14/debian/control
@@ -3,7 +3,7 @@
Maintainer: Sebastian Rittau srit...@debian.org
Standards-Version: 3.8.3
Section: libs
-Build-Depends: libglib2.0-dev, pkg-config, bison, flex, texinfo, cdbs,
debhelper (= 4.1.0)
+Build-Depends: libglib2.0-dev, pkg-config, bison, flex, texinfo, cdbs,
debhelper (= 4.1.0), dh-autoreconf
Package: libidl0
Architecture: any
diff -u libidl-0.8.14/debian/rules libidl-0.8.14/debian/rules
--- libidl-0.8.14/debian/rules
+++ libidl-0.8.14/debian/rules
@@ -1,6 +1,7 @@
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
include /usr/share/cdbs/1/class/autotools.mk
DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
Bug#756829: qemu-i386 is not the exact name of the command anymore
02.08.2014 13:12, 積丹尼 Dan Jacobson wrote: Package: qemu-system-common Version: 2.1+dfsg-2 Severity: minor File: /usr/share/doc/qemu-system-common/qemu-doc.html In many places in the docs we see e.g., 5.2.1 Quick Start In order to launch a Linux process, QEMU needs the process executable itself and all the target (x86) dynamic libraries used by it. * On x86, you can just try to launch any process by using the native libraries: qemu-i386 -L / /bin/ls However it seems qemu-i386 is not the exact name of the command anymore. This is not correct. qemu-i386 is the right name of the command. It is part of qemu-user package (for a userspace-level emulation). You're filing the bugreport against qemu-SYSTEM, which is part of whole system hardware emulation. The documentation in there is generic, it covers all aspects of qemu. It is included in both -system and -user packages. If you have better idea of how to provide documentation (without rewriting it from upstream), please share it. Overwise, I'm closing this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750883: gnome-keyring: ftbfs on kfreebsd
On Sat, 7 Jun 2014 23:26:44 -0400 Michael Gilbert mgilb...@debian.org wrote: package: src:gnome-keyring severity: grave version: 3.12.0-2 The test suite failed on both kfreebsd architectures: https://buildd.debian.org/status/package.php?p=gnome-keyringsuite=unstable GNOME has become dependant upon Linux-specific features such as systemd anyhow, so the Arch field can probably be changed to linux-any as a fix. Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#756829: qemu-i386 is not the exact name of the command anymore
MT == Michael Tokarev m...@tls.msk.ru writes: MT The documentation in there is generic, it covers all aspects of MT qemu. It is included in both -system and -user packages. Maybe some notes should be added about that near those examples. Else we beginners trying the examples will think something was outdated or something. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756831: mountmedia: /hd-media unmounted during an installation
Package: mountmedia Version: 0.22 Severity: normal Tags: d-i I have a USB stick with the hd-media kernel and initrd, a preseed file and firmware-7.5.0-i386-netinst.iso. Booting is with grub. The preseed file has a late_command which copies files from /hd-media to /target. 1. With an ethernet connection the install is flawless. 2. With a wireless connection the late_command fails. This is because /hd-media is unmounted when Detect network hardware is activated. The WiFi device requires non-free firmware. Commenting out the line umount $dir 2/dev/null || true in mountmedia gets 1. The behaviour would appear to be connected more with the provision of firmware than the type of connection. I'm unsure what is going on but the fix does point to mountmedia as being involved in the issue. Identical inconsistent behaviour was discussed at https://lists.debian.org/debian-user/2013/04/msg01115.html I have CCed Julien Groselle because he may have some further insight. I did not test the Jessie images because the changelog for 0.23 doesn't indicate any relevant intervening change in mountmedia. -- System Information: Debian Release: 7.4 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/1 CPU core) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#739867: librest: FTBFS on kfreebsd-*
Package: librest Followup-For: Bug #739867 GNOME has become dependant upon Linux-specific features such as systemd anyhow, so the Arch field can probably be changed to linux-any as a fix. -- Martin-Éric -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/debian-bugs-dist
Bug#756832: ITP: RioFS -- An userspace filesystem for accessing Amazon S3 buckets.
Package: wnpp Severity: wishlist Owner: Paul Ionkin paul.ion...@gmail.com * Package name: RioFS Version : 0.7.0 Upstream Author : Paul Ionkin paul.ion...@gmail.com * URL : https://github.com/skoobe/riofs * License : GPL Programming Lang: C Description : An userspace filesystem for accessing Amazon S3 buckets. RioFS is an userspace filesystem for Amazon S3 buckets for servers that run on Linux and MacOSX. It supports versioned and non-versioned buckets in all AWS regions. It handles buckets with many thousands of keys and highly concurrent access gracefully. The project is quite active and popular. We are looking for co-maintainers to help with packaging.
Bug#706128: issue affect Atheros chips also
Hi, I've Atheros board which I believe is one of the best supported by kernel. But have the same issue as Michael does. kernel: 3.14.13-2 Wi-Fi board: Qualcomm Atheros AR93xx Wireless Network Adapter (rev 01) Subsystem: D-Link System Inc DWA-566 Wireless N 300 Dual Band PCIe Desktop Adapter Kernel driver in use: ath9k -- Best regards, Alexander Betaev
Bug#754441: gmastermind.app
You can add this yourself in the task list, they should be self explanatory. Are you talking about this task list: http://blends.debian.org/junior/tasks/puzzle ? If so, I don't see anywhere that I can edit it. Do I need to be part of the Alioth project first? This is maintained by the Debian Blends team (currently - there is no practical need to but there was no request to change this). I'd happily proxy this entry for you. However, for the moment the package is not yet in Debian nor the packaging in any Blends VCS. I have recommended to create a Debian Jr. VCS to do the packaging which has not yet happened as far as I know. Perhaps also Debian Games Git would fit and than the information about the package becomes available for the tasks page you mentioned above ... Ah, okay, it would be better to wait until the package is in Debian before editing the page. As for a VCS, I've heard a lot about having one. tbh, gmastermind.app probably won't need one, as it doesn't look like it will be upgraded any time in the future, but I'm fine either way. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754317: Upstream problem
tag 754317 + upstream confirmed thanks This is due to an incompatibility with recent libmagic. See for instance: https://bugzilla.redhat.com/show_bug.cgi?id=576 Building binwalk from source (https://github.com/devttys0/binwalk) fixes the issue. Cheers, --Seb -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756722: lintian: false positive for embedded-library error
On Sat, 2 Aug 2014 09:11:41 +0200, Jakub Wilk wrote: * Atsuhito Kohda ko...@pm.tokushima-u.ac.jp, 2014-08-02, 15:28: (snip) Sorry but I mean texmacs 1.99.1-1 (accepted one) and 1.99.1-2 (rejected one) in experimental. Oh, I didn't notice that there's a package in experimental. That was a bit of information I was missing. Even the package from the archive triggers the Lintian error: $ lintian -F texmacs_1.99.1-1_amd64.deb E: texmacs: embedded-library usr/lib/texmacs/TeXmacs/bin/texmacs.bin: freetype (The package was accepted to the archive, because at that point Lintian didn't have the check for freetype implemented yet.) To detect embedded copies of freetype, Lintian looks for the string FT_Get_CID_Is_Internally_CID_Keyed in the binaries. But this is a name of a public function, and texmacs just happens to use it. So it's indeed a false positive. I'm not sure why exactly FT_Get_CID_Is_Internally_CID_Keyed was chosen, and what would be a better string to use... Until we figure it out, please add an override for the tag. I see. Thanks for your clarification. Best regards, 2014-8-2(Sat) -- Debian Developer - much more I18N of Debian Atsuhito Kohda kohda AT debian.org Department of Math., Univ. of Tokushima -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756833: e500 emulation: missing firmware u-boot.e500
Package: qemu-system-ppc Version: 2.1+dfsg-1 Severity: normal Tags: confirmed Since qemu 2.1, there's a e500 ppc emulation implemented in qemu. However, due to DFSG, we have to strip blobs from the source packages, and while qemu do provide u-boot.e500 sources, it can only be built on a powerpc platform. Since debian already have u-boot package, we need to modify it so it provides this firmware, so that qemu can use it. See also #684909 which is the same issue for s390x emulation. /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754336: qemu-mips-static doesn't recognize ELF header correctly
Control: retitle -1 qemu-mips-static doesn't recognize broken ELF headers I'm retitling this bugreport to reflect reality. Qemu implements its own ELF parser, and it looks like it is a bit stricter than the one in linux kernel. I'm not sure whenever to treat it as a bug or a feature. And these binaries are indeed broken. Qemu can be made less strict ofcourse. I'm also forwarding this upstream, let's see what upstream will say... Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756816: apt: apt-get upgrade packagename should not set packagename to manually installed
Control: retitle -1 document apt(-get) (dist-)upgrade pkga pkgb- On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote: it seems that -- despite the documentation suggests otherwise -- you now can pass package names as parameter to apt-get upgrade and it does what you expect: Try to upgrade only that package. No, they don't do that, at least it is not intended. (dist-)upgrade is performed as usual, the packages you can provide are just hints. Imagine a dist-upgrade which has to decide between A | B and chooses A, while you prefer B. apt-get dist-upgrade B will take care of this – as well as apt-get dist-upgrade A- in that case. In the past you would have to either manually upgrade certain packages earlier or set them on hold or something to make such a choice. Michael (git d8a8f9d7) should have documented that though. But it also seems to set the given package to manually installed for which there is no reason at all: Well, there is apts usual reason: If you care enough to mention the package explicitly on the commandline, you properly don't want apt to suggest its removal later on. I can't say I am a huge fan of that, but it is at least very consistent and avoids that the autoremoval is overagressive – or do I really want it to remove my favorite shell because it isn't needed anymore? ;) If you want to upgrade a 'single' package, install is for you (which has the exact same behavior regarding the autobit). Partial upgrades tend to lead to disaster, so that we see no real point in exposing them more directly – at least not in favor of more useful cases. An interactive tool like aptitude can do that differently of course, but we have only the commandline available for decision making… Best regards David Kalnischkies signature.asc Description: Digital signature
Bug#756834: use https://tracker.d.o links to point to source packages
Package: how-can-i-help
Version: 6
Severity: minor
Tags: patch
Given tracker.d.o is on its way to replace the old PTS interface, it would be
nice for how-can-i-help to use the new adress scheme.
The attached patch should implement this,
Cheers.
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (500, 'testing'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages how-can-i-help depends on:
ii ruby 1:2.1.0.1
ii ruby-debian 0.3.8+b4
ii ruby-json1.8.1-1+b1
how-can-i-help recommends no packages.
how-can-i-help suggests no packages.
-- no debconf information
From 850bbb372c8cb2be194f7ddf571441bef81a721f Mon Sep 17 00:00:00 2001
From: Stefano Zacchiroli z...@debian.org
Date: Sat, 2 Aug 2014 12:26:55 +0200
Subject: [PATCH] use https://tracker.d.o links to point to source packages
---
bin/how-can-i-help | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/bin/how-can-i-help b/bin/how-can-i-help
index a3ad7b9..28b0497 100755
--- a/bin/how-can-i-help
+++ b/bin/how-can-i-help
@@ -229,7 +229,7 @@ end
if notesting.length 0
puts $old ? 'Packages removed from Debian \'testing\' (the maintainer might need help):' : 'New packages removed from Debian \'testing\' (the maintainer might need help):'
notesting.sort { |a, b| a['source'] = b['source'] }.each do |r|
-puts - #{r['package']} - https://packages.qa.debian.org/#{r['source']}
+puts - #{r['package']} - https://tracker.debian.org/pkg/#{r['source']}
end
puts
end
@@ -245,7 +245,7 @@ if autoremoval.length 0
else
bugs = (bug: #{bugs[0]})
end
-puts - #{r['source']} - https://packages.qa.debian.org/#{r['source']} - removal on #{Time.at(r['removal_time']).to_date.to_s}#{bugs}
+puts - #{r['source']} - https://tracker.debian.org/pkg/#{r['source']} - removal on #{Time.at(r['removal_time']).to_date.to_s}#{bugs}
end
puts
end
--
2.0.1
Bug#754441: gmastermind.app
As for a VCS, I've heard a lot about having one. tbh, gmastermind.app probably won't need one, as it doesn't look like it will be upgraded any time in the future, but I'm fine either way. That's no point. The *packaging* might change over time and if you want some help in packaging you can most effectively get it if the packaging is in VCS. I have set one precondition for my Sponsoring of Blends effort that the package is maintained in VCS for good reasons. Oh, okay. I was actually offered a VCS with pkg-gnustep, but I turned it down because I assumed that I wouldn't need one. Seeing as I'll probably need a VCS for maintaining this package, I'll try asking them if the offer is still valid. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732117: mount: loop mounting fails with LOOP_SET_FD failed
Hello! Given that there was no followup on my last quite verbose mail to this bug report where I investigated the reported problem I have to conclude that there is nothing left to fix and thus closing the bug report. Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756835: First steps towards source-only uploads
Package: debian-policy Severity: wishlist Version: 3.9.5.0 Le Fri, Aug 01, 2014 at 12:25:05PM +0200, Ansgar Burchardt a écrit : On 08/01/2014 12:17, martin f krafft wrote: also sprach Paul Wise p...@debian.org [2014-08-01 11:33 +0200]: * The source package includes a Package-List field that also has an arch=* column. dpkg (= 1.17.7) will include this. Can we read up more on this somewhere? It is the default if you are using dpkg-dev from jessie and you don't need to do anything other than generating your .dsc with dpkg-source as per usual. I want to understand purpose and syntax of this new field. The field was originally discussed in https://bugs.debian.org/619131 to allow easier processing of packages that build arch-specific binaries such as src:linux[1]. The architecture information was only (re)introduced later, as far as I know to help with bootstrapping, but it turns out that I also want this for source-only uploads to catch uploads introducing NEW binary packages. Hi Ansgar, Martin, and Policy Editors, here is a proposed update for the description of the Package-List field in the Policy's section 5.6.27. (patch attached). For the busy people, here is the current content of §5.6.27–8. - 5.6.27 Package-List Multiline field listing all the packages that can be built from the source package, considering every architecture. The first line of the field value is empty. Each one of the next lines describes one binary package, by listing its name, type, section and priority separated by spaces. Fifth and subsequent space-separated items may be present and parsers must allow them. See the Package-Type field for a list of package types. 5.6.28 Package-Type Simple field containing a word indicating the type of package: deb for binary packages and udeb for micro binary packages. Other types not defined here may be indicated. In source package control files, the Package-Type field should be omitted instead of giving it a value of deb, as this value is assumed for paragraphs lacking this field. - Everybody's suggestions are welcome ! Have a nice week-end, and big thank you to Ansgar and the other FTP Masters for the source-only uploads ! -- Charles Plessy Debian Med packaging team, http://www.debian.org/devel/debian-med Tsurumi, Kanagawa, Japan From b1aa1bf72723e4594557f9898da97afe23f0c900 Mon Sep 17 00:00:00 2001 From: Charles Plessy ple...@debian.org Date: Sat, 2 Aug 2014 19:30:57 +0900 Subject: [PATCH] =?UTF-8?q?Document=20the=20=E2=80=98arch=E2=80=99=20and?= =?UTF-8?q?=20=E2=80=98profile=E2=80=99=20options=20in=20the=20Package-Lis?= =?UTF-8?q?t=20field.?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- policy.sgml | 8 1 file changed, 8 insertions(+) diff --git a/policy.sgml b/policy.sgml index ae9d173..33c4f1a 100644 --- a/policy.sgml +++ b/policy.sgml @@ -3826,6 +3826,14 @@ Checksums-Sha256: qref id=f-Package-TypePackage-Type/qref field for a list of package types. /p + p + The optional fields currently in use add informations related to +architectures build profiles, with a syntax such as +ttname=value1,value2/tt and names ttarch/tt and +ttprofile/ttfootnote + They were introduced in prgndpkg/prgn version + tt1.17.7/tt in emJessie/em/footnote. + /p /sect1 sect1 id=f-Package-Type -- 2.0.1
Bug#756836: Please update basic256 to latest upstream release
Package: basic256 Version: 0.9.6.69a-1 Severity: wishlist Please update basic256 to latest upstream release. This is pending on sorting out licensing issues. The latest upstream release introduces new sound files, images, and documentation without proper licensing information or which are outright non-free. In particular, the documentation is now distributed under CC by-nc-sa, which is not DFSG compatible and will need to be removed unless upstream accepts to relicense it. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_CA.UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages basic256 depends on: ii libc62.19-7 ii libespeak1 1.48.04+dfsg-1 ii libgcc1 1:4.9.0-7 ii libqtcore4 4:4.8.6+git49-gbc62005+dfsg-1 ii libqtgui44:4.8.6+git49-gbc62005+dfsg-1 ii libqtwebkit4 2.2.1-7 ii libsdl-mixer1.2 1.2.12-11+b1 ii libsdl1.2debian 1.2.15-10 ii libsqlite3-0 3.8.5-2 ii libstdc++6 4.9.0-7 basic256 recommends no packages. basic256 suggests no packages. -- no debconf information signature.asc Description: Digital signature
Bug#756521: ITP: kadeploy -- Scalable, efficient and reliable cluster provisioning solution
On 02/08/14 at 15:38 +0800, Thomas Goirand wrote: On 07/31/2014 12:02 AM, Lucas Nussbaum wrote: Package: wnpp Severity: wishlist Owner: Lucas Nussbaum lu...@debian.org * Package name: kadeploy Version : 3.3 Upstream Author : Kadeploy developers kadeploy3-de...@lists.gforge.inria.fr * URL : http://kadeploy3.gforge.inria.fr/ * License : CeCILL version 2.0 Programming Lang: Ruby Description : Scalable, efficient and reliable cluster provisioning solution Kadeploy is a scalable, efficient and reliable deployment system (cluster provisioning solution) for cluster and grid computing. It provides a set of tools for cloning, configuring (post installation) and managing cluster nodes. It can deploy a 300-nodes cluster in a few minutes, and also supports authorizing users to initiate their own nodes deployments (including with concurrent deployments). A work-in-progress package is available from: Vcs-Git: git://scm.gforge.inria.fr/kadeploy3/kadeploy3.git Vcs-Browser: https://gforge.inria.fr/scm/browser.php?group_id=2026 Lucas Have you compared it to: https://github.com/enovance/edeploy which has nice role-based system, so you can deploy specific systems depending on what type of hardware (amount of RAM, number of HDD, or anything else you decide)... Hi, I don't remember the exact details, but I think that edeploy's design made it scale poorly (especially for the image broadcast part). This might not be a problem for the typical use case for edeploy (one-time deployment of small/medium-scale clusters to build an OpenStack infrastructure), but it would definitely be a problem for the typical use case for Kadeploy ((re)install medium to large scale HPC clusters during maintenances). Cloning 112 nodes with a standard Debian image with Kadeploy takes about 5.5 minutes, with most of it spent waiting for the nodes to reboot. We are working on using Kexec to make reboots faster, but unfortunately there are quite a lot lof bugs to work around there. Lucas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754441: pkg-gnustep VCS
Hi Yavor, A while ago, you offered me a VCS with pkg-gnustep's Alioth project, and I declined because I thought that my package would be too trivial to need one. What I didn't know was, that practically all packages are expected to have a VCS. Would it still be possible to set up a VCS with pkg-gnustep's Alioth project? Yours thankfully, Riley Baird -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754275: pu: package php5/5.4.4-14+deb7u13
Control: tags -1 + confirmed On Wed, 2014-07-09 at 12:58 +0200, Ondřej Surý wrote: trying to keep the s-p-u smaller here's another batch of upstream fixes as reported by our users. This update includes 5 upstream fixes to issues reported to our BTS and one backport of debian sessionclean script that has been plaguing heavily used sites. (Several people has reported that the backported scripts has helped them.) Please go ahead; thanks. Regards, Adam -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756816: apt: apt-get upgrade packagename should not set packagename to manually installed
On Sat, Aug 2, 2014 at 12:20 PM, David Kalnischkies da...@kalnischkies.de wrote: Well, there is apts usual reason: If you care enough to mention the package explicitly on the commandline, you properly don't want apt to suggest its removal later on. I can't say I am a huge fan of that, but it is at least very consistent and avoids that the autoremoval is overagressive – or do I really want it to remove my favorite shell because it isn't needed anymore? ;) Could we get rid of it for the apt tool? We have apt-mark to set manual/automatic, so there's not much point anymore. Especially since this often happens by accident (at least for me, with install). -- Julian Andres Klode - Debian Developer, Ubuntu Member See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#754441: pkg-gnustep VCS
Riley Baird wrote: A while ago, you offered me a VCS with pkg-gnustep's Alioth project, and I declined because I thought that my package would be too trivial to need one. Well, packages that are not actively maintained upstream usually accumulate a lot of Debian modifications as time goes by. Do not assume that the app will always work as it is... this applies to trivial ones, too. Would it still be possible to set up a VCS with pkg-gnustep's Alioth project? Sure, no problem. Just apply as a project member and I will approve you. Then you can use git-import-dsc/gbp-create-remote-repo to create and push the repository at Alioth. If you prefer to use another VCS, feel free to. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756819: no support for xorg-xserver 1.16
Control: reassign -1 virtualbox-guest-additions-iso 4.3.14-1 Hi, On 02.08.2014 09:34, Ritesh Raj Sarraf wrote: On 08/02/2014 07:28 AM, Caitlin Matos wrote: I apologize, I'm not sure exactly which package this should be filed against, but I'm pretty sure this is the correct one. I am on a Windows 8.1 host running Debian jessie. I updated xorg-xserver etc. to the current version in testing, 1.16.0-1. However, I am no longer able to use the X11-related guest utilities. The relevant output from VBoxLinuxAdditions.run in the guest additions ISO: Installing the Window System drivers Warning: unknown version of the X Window System installed. Not installing X Window System drivers. Looking at the code, the issue is obvious. It is searching for /opt/VBoxGuestAdditions-4.3.14/lib/VBoxGuestAdditions/vboxvideo_drv_116.so, which does not exist. You are using the non-free guest additions. We have no way of changing them beyond what upstream provides. Please uninstall them and instead install the virtualbox-guest-x11 Debian package. It is built from source against the current Xorg server. Cheers, Felix -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756837: new version 3.2 available
Package: quodlibet Version: 3.0.2-3 Severity: wishlist Version 3.2 of exfalso and quodlibet have been released. I did a test build on a jessie machine without any problems. Note, that according to the documentation, since 3.2 all plugins are included in the main tarball, so it would probably make sense just to drop the quodlibet-plugins package. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756677: libvigraimpex: [hdf5 transition] please support hdf5 1.8.13 new packaging layout
Andreas Metzler a écrit , Le 01/08/2014 18:55: On 2014-08-01 Gilles Filippini p...@debian.org wrote: Source: libvigraimpex Version: 1.9.0+dfsg-8 Severity: important Tags: patch User: p...@debian.org Usertags: HDF5-transition Hi, The hdf5 1.8.13 package in experimental features a new layout for headers and libraries, so that all the binary packages are now co-installable. Please find attached a patch proposal to support both the current and the new layouts. Because this bug is in the way of the hdf5 transition I intend to NMU in a few days. I apologize for the urge, and I hope this approach won't offend you. Please tell me otherwise. [...] Hello, please be aware that libvigraimpex is orphaned/QA maintained. And it is also somewhat broken. * 1.9.0 nowadays FTBFS with a testsuite error in ix86 * 1.10 (experimental) FTBFS on mips (I could not reproduce the amd64 error there.) Hi Andreas, Thanks for the notice. Would you mind applying the hdf5 fix to both versions? It is a fairly simple one :) Thanks in advance, _g. signature.asc Description: OpenPGP digital signature
Bug#651016: Bug#755156: libiec61883: use dh-autoreconf to fix FTBFS on ppc64el
Control: tags -1 + pending
Hi,
The unability to compile this package is a problem for ports being
added recently (OpenRISC/or1k, ppc64el, ...) since they don't have
older versions to rely on, and many packages depend on them as
build-dependencies to compile, so this package (among many others) is
blocking a good portion of the archive to compile cleanly for these
ports.
I am preparing a NMU (diff attached) to fix the bugs above (see
headers), uploaded immediately as per guidelines in [1] -- since this
package is needed to compile many other packages and the package seems
to be orphan since more than 5 years ago for all purposes.
I am also including a fix for the long-standing request to add
multi-arch.
[1] http://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu
Cheers.
--
Manuel A. Fernandez Montecelo manuel.montez...@gmail.com
diff -u libiec61883-1.2.0/debian/compat libiec61883-1.2.0/debian/compat
--- libiec61883-1.2.0/debian/compat
+++ libiec61883-1.2.0/debian/compat
@@ -1 +1 @@
-5
+9
diff -u libiec61883-1.2.0/debian/libiec61883-dev.install
libiec61883-1.2.0/debian/libiec61883-dev.install
--- libiec61883-1.2.0/debian/libiec61883-dev.install
+++ libiec61883-1.2.0/debian/libiec61883-dev.install
@@ -1,5 +1,5 @@
usr/include/*
-usr/lib/lib*.a
-usr/lib/lib*.so
-usr/lib/pkgconfig/*
+usr/lib/*/lib*.a
+usr/lib/*/lib*.so
+usr/lib/*/pkgconfig/*
usr/bin/plug*
diff -u libiec61883-1.2.0/debian/libiec61883-0.install
libiec61883-1.2.0/debian/libiec61883-0.install
--- libiec61883-1.2.0/debian/libiec61883-0.install
+++ libiec61883-1.2.0/debian/libiec61883-0.install
@@ -1 +1 @@
-usr/lib/lib*.so.*
+usr/lib/*/lib*.so.*
diff -u libiec61883-1.2.0/debian/rules libiec61883-1.2.0/debian/rules
--- libiec61883-1.2.0/debian/rules
+++ libiec61883-1.2.0/debian/rules
@@ -1,6 +1,7 @@
#!/usr/bin/make -f
include /usr/share/cdbs/1/rules/debhelper.mk
+include /usr/share/cdbs/1/rules/autoreconf.mk
include /usr/share/cdbs/1/class/autotools.mk
#If you use autotools.mk, be sure to include
# dpatch.mk after autotools.mk.
@@ -20,6 +21,9 @@
#
DEB_OPT_FLAG := -O2 -fno-strict-aliasing
#
+# something for multiarchification
+DEB_CONFIGURE_EXTRA_FLAGS += --libdir=\$${prefix}/lib/$(DEB_HOST_MULTIARCH)
+
install/libiec61883-dev:: doc
doc: manpages
diff -u libiec61883-1.2.0/debian/control libiec61883-1.2.0/debian/control
--- libiec61883-1.2.0/debian/control
+++ libiec61883-1.2.0/debian/control
@@ -2,7 +2,7 @@
Priority: optional
Maintainer: Marcio Roberto Teixeira marcio...@gmail.com
Uploaders: Loic Minier l...@dooz.org
-Build-Depends: debhelper (= 5), autotools-dev, libraw1394-dev (= 2.0.2),
cdbs, pkg-config, xsltproc, docbook-xsl
+Build-Depends: debhelper (= 9~), dh-autoreconf, autotools-dev, libraw1394-dev
(= 2.0.2), cdbs (= 0.4.93~), pkg-config, xsltproc, docbook-xsl
Standards-Version: 3.8.0
Section: libs
@@ -31,7 +31,9 @@
Package: libiec61883-0
Section: libs
Architecture: any
+Pre-Depends: ${misc:Pre-Depends}
Depends: ${shlibs:Depends}, ${misc:Depends}
+Multi-Arch: same
Description: an partial implementation of IEC 61883
This library is an implementation of IEC 61883, part 1 (CIP, plug
registers, and CMP), part 2 (DV-SD), part 4 (MPEG2-TS), and part 6
diff -u libiec61883-1.2.0/debian/changelog libiec61883-1.2.0/debian/changelog
--- libiec61883-1.2.0/debian/changelog
+++ libiec61883-1.2.0/debian/changelog
@@ -1,3 +1,17 @@
+libiec61883 (1.2.0-0.2) unstable; urgency=medium
+
+ * Non-maintainer upload.
+
+ [ Matto Marjanovic ]
+ * Multiarch'ification (Closes: #651016)
+
+ [ Brahadambal Srinivasan ]
+ * Run dh-autoreconf to update config.{sub,guess} and
+{libtool,aclocal}.m4, necessary for some new ports. Thanks
+Brahadambal Srinivasan. (Closes: #755156)
+
+ -- Manuel A. Fernandez Montecelo m...@debian.org Sat, 02 Aug 2014 12:06:03
+0100
+
libiec61883 (1.2.0-0.1) unstable; urgency=low
* Non-maintainer upload.
Bug#756816: apt: apt-get upgrade packagename should not set packagename to manually installed
Hi David, thanks for the explanations. David Kalnischkies wrote: Control: retitle -1 document apt(-get) (dist-)upgrade pkga pkgb- Yeah, I would have done that after your mails if you wouldn't have done that. JFTR: I looked IIRC in the man-page for apt-get, maybe also in the one for apt. On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote: it seems that -- despite the documentation suggests otherwise -- you now can pass package names as parameter to apt-get upgrade and it does what you expect: Try to upgrade only that package. No, they don't do that, at least it is not intended. (dist-)upgrade is performed as usual, the packages you can provide are just hints. IMHO such a behaviour is highly non-intuitive. This is definitely a thing where aptitude's behaviour is way more consistent and intuitive. aptitude full-upgrade ~slibs just does what I mean: Upgrade all package in the section libs without marking them suddenly as not automatically installed. Imagine a dist-upgrade which has to decide between A | B and chooses A, while you prefer B. apt-get dist-upgrade B will take care of this – as well as apt-get dist-upgrade A- in that case. Ah, that kind of hints. Should be documented at least, yes. I though still think aptitude's behaviour is the more intuitive one. In the past you would have to either manually upgrade certain packages earlier or set them on hold or something to make such a choice. Well, that is one of the reasons why I usually prefer aptitude for dist-upgrades. I don't have to press Ctrl-C and think about which packages I have to pass to apt-get to make it understand what I want. In aptitude I can do that just interactively and I'm done. (I don't want to start a flamewar here. I just want to point out what I used to. It likely explains how I come to my expectations. :-) But it also seems to set the given package to manually installed for which there is no reason at all: Well, there is apts usual reason: If you care enough to mention the package explicitly on the commandline, you properly don't want apt to suggest its removal later on. I definitely disagree here. IMHO this is very non-intuitive behaviour. When doing dist-upgrades from oldstable to stable, I do them in very small bits, so that no service has a downtime longer than necessary. One of these steps usually includes bigger bunches of libsomething packages which I surely never want to have the automatically installed mark removed. (aptitude has one or more bugs which causes that and it's already very annoying. But at least it doesn't do that on purpose unless explicitly requested.) I can't say I am a huge fan of that, but it is at least very consistent and avoids that the autoremoval is overagressive – or do I really want it to remove my favorite shell because it isn't needed anymore? ;) Yes! Yes indeed. Otherwise I would not have marked it automatically installed. All my favourite packages are in a local metapackages. If that metapackages drops a dependency/recommends/suggests on a package, I want this package to be removed. I mean, that's what the automatically installed mark is for! The way apt handles it currently looks as if apt thinks it knows better than the local admin which package got the automatically installed mark for good reasons and which not. Which IMHO is clearly wrong. If you want to upgrade a 'single' package, install is for you (which has the exact same behavior regarding the autobit). Which I disagree, too. For the very same reasons. Partial upgrades tend to lead to disaster, Huh? Works fine for me for ages in general. Just not with apt-get but with aptitude. ;-) That's one of things I like aptitude for a lot. And is one of the reasons why I use apt-get so seldomly. An interactive tool like aptitude can do that differently of course, but we have only the commandline available for decision making… Ok, maybe I'm really too much of an aptitude user to fully unterstand that reasoning. :-D Anyway, thanks again for all these explanations. I think, I understand apt-get a little more than before. And IMHO it clearly shows why there are both, apt-get and aptitude, and what's their use cases. Much appreciated, despite my disagreement. :-) 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#657405: Info received (subscribe)
ok On Fri, Aug 01, 2014 at 11:27:05AM +, Debian Bug Tracking System wrote: Thank you for the additional information you have supplied regarding this Bug report. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. Your message has been sent to the package maintainer(s): w...@debian.org Simon Fondrie-Teitler simo...@riseup.net If you wish to submit further information on this problem, please send it to 657...@bugs.debian.org. Please do not send mail to ow...@bugs.debian.org unless you wish to report a problem with the Bug-tracking system. -- 657405: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=657405 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732117: mount: loop mounting fails with LOOP_SET_FD failed
On Sat, Aug 02, 2014 at 12:33:53PM +0200, Andreas Henriksson wrote: Hello! Given that there was no followup on my last quite verbose mail to this bug report where I investigated the reported problem I have to conclude that there is nothing left to fix and thus closing the bug report. I thought that I had provided all follow up info. I don't have the original report on screen just now, but I thought that it amounted to a bug in the man page. I will try to find time to review it soon, but I have been away, and have much to dod before I will have time to spare. ael -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756838: acpica-unix: FTBFS on big-endian architectures
Source: acpica-unix Version: 20140724-1 Severity: serious Justification: fails to build from source (but built successfully in the past) acpica-unix failed to build on big endian architectures with: | # misc tests | /«PKGBUILDDIR»/debian/run-misc-tests.sh /«PKGBUILDDIR» 20140724 | + CURDIR=/«PKGBUILDDIR» | + BINDIR=/«PKGBUILDDIR»/generate/unix/bin | + DEBDIR=/«PKGBUILDDIR»/debian | + VERSION=20140724 | + cd /«PKGBUILDDIR»/tests/misc | + /«PKGBUILDDIR»/generate/unix/bin/iasl -h | iASL is not currently supported on big-endian machines. | ++ dpkg-architecture -qDEB_HOST_ARCH_BITS | + BITS=32 | ++ stat --format=%Y /«PKGBUILDDIR»/generate/unix/bin/iasl | ++ cut '-d ' -f1 | + FDATE=1406598005 | ++ date --date=@1406598005 '+%b %_d %Y' | + WHEN='Jul 29 2014' | + sed -e 's/XXX/Jul 29 2014/' -e s//32/ -e s//20140724/ /«PKGBUILDDIR»/debian/badcode.asl.result | + sed -e 's/XXX/Jul 29 2014/' -e s//32/ -e s//20140724/ /«PKGBUILDDIR»/debian/grammar.asl.result | + /«PKGBUILDDIR»/generate/unix/bin/iasl -f badcode.asl | + tee badcode | iASL is not currently supported on big-endian machines. | + diff badcode badcode.asl.result | + '[' 1 -eq 0 ']' | + exit 1 | make[2]: *** [check] Error 1 Full build logs are available from https://buildd.debian.org/status/package.php?p=acpica-unix. Please take a look. Cheers -- Sebastian Ramacher signature.asc Description: Digital signature
Bug#756839: yasat's SetUID db doesn't contain much
Package: yasat Version: 755-1 There is a large number of complaints about UNKNOWN setuid binaries... and among them, quite a few standard debian programs (like /usr/bin/passwd), so I guess the database needs some work! Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756840: Crashes on not finding /etc/apache2/envvars
Package: yasat Version: 755-1 Not finding a file makes the program stop: /usr/bin/yasat: 73: .: Can't open /etc/apache2/envvars Snark on #debian-science -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#711904: [roundcube] can't modify identities since wheezy
On Thu, Mar 06, 2014 at 12:48:04AM +0100, Vincent Bernat wrote: What was your previous version of roundcube? The line has been commented because it is applied in postinst in an attempt to fix #610725 and #613586. It sould be interesting to know what was your upgrade path and why the postinst script didn't work for you. It was the regular squeeze version of roundcube before upgrade. However, IIRC there have been some problem during the upgrade (I think mysql server didn't start soon enough, so it need changing delay in init script, then manually starting and then doing dpkg --configure -a), but eventually it all finished. -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756754: mime-support: Add support for application/x-xz mime type, ie xz files
Le Fri, Aug 01, 2014 at 01:37:12PM +0200, Diederik de Haas a écrit : According to http://filext.com/file-extension/XZ the mime type for xz files is application/x-xz. Unfortunately the mime type doesn't seem registered (yet) with iana according to http://www.iana.org/assignments/media-types/media-types.xhtml#application I tried to read through the document about registering a new mime type, but got lost pretty quickly. Sorry. Hello Diederik, perhaps you can contact (http://tukaani.org/contact.html) the upstream authors and ask them if they would like to submit a media type to the IANA ? Have a nice week-end, -- Charles Plessy Tsurumi, Kanagawa, Japan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#732117: mount: loop mounting fails with LOOP_SET_FD failed
Hello ael! On Sat, Aug 02, 2014 at 01:03:07PM +0100, ael wrote: [...] I don't have the original report on screen just now, but I thought that it amounted to a bug in the man page. The man page contains all the relevant information, so the bug would in that case be that it's too verbose and contains too much information that are not really all that useful to an average user. Or maybe that it contains the right information but it would be restructured to be easier to read. (eg. most relevant things first as many users don't have the patience to read it all.) I will try to find time to review it soon, but I have been away, and have much to dod before I will have time to spare. If you really want to make a difference here, please clone the upstream git repository and do an attempt at rewording/restructuring the relevant chapter in the manpage and submit your changes to the upstream mailing list would be the best way. Thanks for following up! Regards, Andreas Henriksson -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756841: tasksel: --task-desc no more works
Package: tasksel
Version: 3.20
Severity: important
Dear Tasksel Maintainers,
acording to the man page, tasksel --task-desc $task should give a
description of a task. But all I get is an empty blank line per task:
abe@c-cactus:~$ tasksel --list-tasks
u desktop Debian desktop environment
u web-serverweb server
u print-server print server
u database-server SQL database
u dns-serverDNS Server
u file-server file server
u mail-server mail server
i ssh-serverSSH server
i laptoplaptop
abe@c-cactus:~$ tasksel --task-desc ssh-server
abe@c-cactus:~$ tasksel --task-desc mail-server
abe@c-cactus:~$ tasksel --list-tasks | awk '{print $2}' | xargs -n1 tasksel
--task-desc
abe@c-cactus:~$ echo $LANG
C.UTF-8
abe@c-cactus:~$
I've seen screenshots where this worked in the past. I though don't know
if they are from Debian Wheezy or Squeeze.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (990, 'unstable'), (600, 'testing'), (110, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.15-trunk-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages tasksel depends on:
ii apt 1.1~exp2
ii debconf [debconf-2.0] 1.5.53
ii liblocale-gettext-perl 1.05-8
ii perl-base 5.18.2-7
ii tasksel-data3.20
tasksel recommends no packages.
tasksel suggests no packages.
-- debconf information:
tasksel/tasks:
tasksel/title:
tasksel/desktop: xfce
tasksel/first: ssh-server, laptop
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750883: Preparing (lib)gnome-keyring for the freeze.
On Sat, Aug 02, 2014 at 08:47:54AM +0200, Andreas Henriksson wrote: There has been discussions about the use of mlock(all) and we have over the past year not been able to reach a consensus. I don't feel comfortable making the descision to rip out security features on my own as proposed by porters and noone has been willing to take the discussion upstream. Why do you think this is related to the use of mlock? A quick check in the source shows that an error in mlock is not fatal. Also building on Linux with a locked memory limit of 0 does not trigger this error. But several lines below this warning in the build-log is the simple statement: | Build killed with signal TERM after 150 minutes of inactivity So you found yourself a dead lock. Did you ever try to run this on a kfreebsd-* porter machine? You completely forgot to actually mention what you tried and what you observed yourself. If for some reason (a) is not possible, please tell me and I'll implement (b). I would propose (c): understand the problem. Anyway, I did that for you. The problem lies within build/tap-driver, aka the tool that executes the tests. In some cases it misses EOF on stderr of the executed test program, I'm however not sure why. For more background, see: https://packages.qa.debian.org/libg/libgnome-keyring.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=628383 https://packages.qa.debian.org/g/gnome-keyring.html https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750883 This misses a link to the build-log: https://buildd.debian.org/status/fetch.php?pkg=gnome-keyringarch=kfreebsd-i386ver=3.12.0-2stamp=1398611094 As this is a simple bug, this is off-topic on debian-release. Bastian -- Earth -- mother of the most beautiful women in the universe. -- Apollo, Who Mourns for Adonais? stardate 3468.1 -- To UNSUBSCRIBE, email to debian-release-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140802111814.ga29...@mail.waldi.eu.org -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#750883: reason
Hi I traced myself through this mess and found the following: tap-driver - calls tap-gtester with stdout/stderr as pipes - calls test-startup with stdout as new pipe and stderr inherited - for each test - starts dbus-daemon - does test - kills dbus-daemon _if test was sucessful_ in case of a failed test the dbus-daemon remains running and keeps stderr open - waits for EOF on stdout/stderr as stderr is still open by the running dbus-daemons, this blocks Bastian -- It is a human characteristic to love little animals, especially if they're attractive in some way. -- McCoy, The Trouble with Tribbles, stardate 4525.6 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756842: [linux-image-3.16-rc6-amd64] please enable CONFIG_SND_BEBOB
Package: linux-image-3.16-rc6-amd64 Version: 3.16~rc6-1~exp1 Severity: wishlist Hello, Please enable CONFIG_SND_BEBOB which has been newly added to the kernel in 3.16. This provides a in-kernel driver for BeBob Firewire audio devices. You probably might also want to enable CONFIG_SND_DICE CONFIG_SND_ISIGHT CONFIG_SND_SCS1X CONFIG_SND_FIREWORKS to support the other Firewire chip sets too. Greetings, Maxi signature.asc Description: This is a digitally signed message part.
Bug#756843: open-iscsi: 7e1ae42 patch only mounting first target disk, then always failing in the end even on success
Package: open-iscsi Version: 2.0.873+git0.3b4b4500-2 Severity: important Dear Ritesh and Turbo, this new patch is causing trouble for two reasons. Here are the relevant lines from patch 7e1ae42: + while read fs; do + set -- $(eval echo $fs | sed 's@:@ @') + case $1 in + swap) + swapon $2 + ;; + *) + fsck -a $2 + + if mount $2 /dev/null 21; then + MOUNT_RESULT=0 - this does NOT change the value for the last line + break- this is the break line I removed + fi + ;; + esac + done log_end_msg $MOUNT_RESULT - this will stay on 1 from inital setting 1) The “break is exiting the while loop after mounting the first found target disk successfully, ignoring all further disks which might still be in the loop value list. I fixed this behaviour for myself by just removing the break line. This should be the correct fix. 2) MOUNT_RESULT=0 is NOT changing the value to 0 because MOUNT_RESULT was initially set to 1 outside the nested loops/pipes. So the function/script will always call log_end_msg with the initial value of 1, displaying a “failed” after the init script finishes. I fixed this for myself by just explicitely setting the value of MOUNT_RESULT to 0 before the log_end_msg line. Of course, this is not representing the correct result of the mount calls - but currently it is not doing that as well. This is only a workaround. Best regards, Torben -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages open-iscsi depends on: ii libc6 2.19-7 ii udev 208-6 open-iscsi recommends no packages. open-iscsi suggests no packages. -- Configuration Files: /etc/init.d/open-iscsi changed [not included] /etc/iscsi/initiatorname.iscsi changed [not included] /etc/iscsi/iscsid.conf changed [not included] -- 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#753621: [libgnomecanvas2-0] RE: [libgnomecanvas2-0] Unbounded Memory leak in libgnomecanvas/gnome-canvas.c:paint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This upstream bug has now been closed wontfix as they're officially declaring the project unmaintained. Please can this patch be put in the Debian package, otherwise I guess this is unmaintained in Debian too, meaning I'll need to release my own package for people to use. -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJT3OT2AAoJEBfSPH39wvOPtdsP/28gH3z54DOVm/m8t3JcmQK7 Nts1peZHazCzYVQHusJ8LnzmfTmOIXSt+Ie9JWtLCu2bE/0qQEfTMjYzHDAhBP2v GWewpzCbUkcpXLoFCWhHhvQfzmj/YDAiwwy9iKPnbm+jrJMdA1iIphxQLpKV29fz XVfaL4Jgdy20zVMVqOp0wgAs/n/n27dekLEnPtbLEBLjQ3PO9ogK0hGySYQxT4Ol jDeK+WQN3Ln1QexenGzbj/XuFhJ9og7fRZ5qcHi10MvD9SOrZCc+fB3SrxRpDoIe lZ4F/vfBLjCbmQIXKJpIiNlpKnhWYOmkqOHLF65yZzxCWdvXbf/y8CairQsZ5C7V CfgsJVhyEbdMkkFOMS1TBLbjCFk5NuC8BNEEDEVf4HHlwf1Ojxml44RRoSeEiUM5 IE9Kp19m4E6Puk2fr9KmP4hbxJ5Xs3MjgSWub1KaHkA8ZgPkUbF4k41Bzk2q/YpL Tby0AvE6CKe8xZ6ThkteE1+y6wj+71vX/cOzmqWJYnH3vJwLWhAWJWjnULELgL+w njG2RJOh2yTYfw6zXNcVp7kYGGrOXkj7bR/+bKVr92q7C5zOe3PWWrXgByQToikV 0j6FH51rP3PF9dMhPSTluop7ZyHYrVkaMDoYJRcKE6Zo+v7n4c9ldlXKC9jibyf3 dFOEQ6OSpoG4x9LHQFaJ =f2Yh -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#756841: tasksel: --task-desc no more works
Axel Beckert a...@debian.org (2014-08-02):
Package: tasksel
Version: 3.20
Severity: important
Dear Tasksel Maintainers,
acording to the man page, tasksel --task-desc $task should give a
description of a task. But all I get is an empty blank line per task:
abe@c-cactus:~$ tasksel --list-tasks
u desktop Debian desktop environment
u web-serverweb server
u print-server print server
u database-server SQL database
u dns-serverDNS Server
u file-server file server
u mail-server mail server
i ssh-serverSSH server
i laptoplaptop
abe@c-cactus:~$ tasksel --task-desc ssh-server
abe@c-cactus:~$ tasksel --task-desc mail-server
abe@c-cactus:~$ tasksel --list-tasks | awk '{print $2}' | xargs -n1 tasksel
--task-desc
abe@c-cactus:~$ echo $LANG
C.UTF-8
abe@c-cactus:~$
I've seen screenshots where this worked in the past. I though don't know
if they are from Debian Wheezy or Squeeze.
FWIW: Building 3.14.1 (wheezy's version) in a sid chroot, or testing
tasksel in a wheezy chroot doesn't seem to get any better results.
Mraw,
KiBi.
signature.asc
Description: Digital signature
Bug#657405: subscribe
On Fri, 1 Aug 2014 13:18:59 +0200 Matija Nalis mnalis-debian...@voyager.hr wrote: subscribe -- Opinions above are GNU-copylefted. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756841: tasksel: --task-desc no more works
Control: found -1 3.14.1 Hi, Cyril Brulebois wrote: I've seen screenshots where this worked in the past. I though don't know if they are from Debian Wheezy or Squeeze. FWIW: Building 3.14.1 (wheezy's version) in a sid chroot, or testing tasksel in a wheezy chroot doesn't seem to get any better results. In the meanwhile I was able to reproduce the issue on an existing Wheezy installation, too. So the mentioned screenshots were likely from Squeeze. Marking as found in Wheezy. 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#756843: open-iscsi: 7e1ae42 patch only mounting first target disk, then always failing in the end even on success
Thank you for the bug report Torben. Sigh!! I think that whole patch was buggy. I don't see the $fs variable ever having been initialized. Was it ?? My bad. :-( @Turbo: Do you have an opinion here? I am inclined to reverting that patch completely. Let me know. On 08/02/2014 06:23 PM, Torben Frey wrote: Package: open-iscsi Version: 2.0.873+git0.3b4b4500-2 Severity: important Dear Ritesh and Turbo, this new patch is causing trouble for two reasons. Here are the relevant lines from patch 7e1ae42: + while read fs; do + set -- $(eval echo $fs | sed 's@:@ @') + case $1 in + swap) + swapon $2 + ;; + *) + fsck -a $2 + + if mount $2 /dev/null 21; then + MOUNT_RESULT=0 - this does NOT change the value for the last line + break- this is the break line I removed + fi + ;; + esac + done log_end_msg $MOUNT_RESULT - this will stay on 1 from inital setting 1) The “break is exiting the while loop after mounting the first found target disk successfully, ignoring all further disks which might still be in the loop value list. I fixed this behaviour for myself by just removing the break line. This should be the correct fix. 2) MOUNT_RESULT=0 is NOT changing the value to 0 because MOUNT_RESULT was initially set to 1 outside the nested loops/pipes. So the function/script will always call log_end_msg with the initial value of 1, displaying a “failed” after the init script finishes. I fixed this for myself by just explicitely setting the value of MOUNT_RESULT to 0 before the log_end_msg line. Of course, this is not representing the correct result of the mount calls - but currently it is not doing that as well. This is only a workaround. Best regards, Torben -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages open-iscsi depends on: ii libc6 2.19-7 ii udev 208-6 open-iscsi recommends no packages. open-iscsi suggests no packages. -- Configuration Files: /etc/init.d/open-iscsi changed [not included] /etc/iscsi/initiatorname.iscsi changed [not included] /etc/iscsi/iscsid.conf changed [not included] -- no debconf information -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. signature.asc Description: OpenPGP digital signature
Bug#756734: ITP: python-xstatic-jquery -- jquery XStatic support
On 2014-08-02 15:00:46 +0800 (+0800), Thomas Goirand wrote: [...] seeing how it seems to work, it's looking like having the xstatic packages is the only way so that Horizon knows where to search for the .js files. [...] After talking with David Lyle a bit in #openstack-horizon yesterday, I agree. It seems that xstatic provides some standardized glue to tell Django where to find JS libraries, so this probably is the sanest way to integrate them even distro-side. In the case of JS libs which are heavily co-mingled with other software upstream, probably the cleanest solution is to convince the authors to separate those libs out and distribute them isolated from the larger bundle... otherwise you're looking at either forking your own stripped-down source package, or carrying lots of dead code in the source package which won't end up in the binary package (and the latter could lead to conflicts in the future when someone else comes along who actually wants to package the software which is shipping with that library). Anyway, apologies for the detour and thanks for the ongoing packaging effort--that hard work doesn't go unnoticed! -- Jeremy Stanley -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756042: RFS: sandboxgamemaker/2.8.2+dfsg-1 [ITA][RC]
reopen 756042 ! thanks Reopening this bug. I am sponsoring it. Anthony , please, reupload the package because the Bart Martens uses automated scripts and the bug will be closed again if no package in mentors. Cheers, Eriberto PS: Thanks Bart for your work. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756844: [libhtml-embperl-perl] Insert Bug Report Subject here
Package: libhtml-embperl-perl Version: Severity: Optional: Choose between important, normal, minor, wishlist Tags: Optional: tags X-Debbugs-CC: Optional: add mails to send copies of this bug report to Dear Maintainer, *** Please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (orineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these lines ***
Bug#756843: open-iscsi: 7e1ae42 patch only mounting first target disk, then always failing in the end even on success
Hi Ritesh, oh yes, the fs variable is initialized before the loops are starting, together with the MOUNT_RESULT: # Now let's mount log_daemon_msg Mounting network filesystems MOUNT_RESULT=1 fs= And I guess functionality is good after removing the “break” command. I just don’t exactly know how the MOUNT_RESULT could summarize the result of all single mounts. Setting it to 0 after the first successful mount will just not catch if a following mount fails since the value would still be 0 (and I guess the exit code of the script should be an error code if one single mount is failing, right?). Maybe it could be done by touching a temporary file on the first failed mount and if we have that in the end setting MOUNT_RESULT to 1 and removing the temporary file again before calling log_end_msg? Else it would be necessary to get rid of the variable scope problem :) Best regards, Torben On Aug 2, 2014, at 3:45 PM, Ritesh Raj Sarraf r...@researchut.com wrote: Thank you for the bug report Torben. Sigh!! I think that whole patch was buggy. I don't see the $fs variable ever having been initialized. Was it ?? My bad. :-( @Turbo: Do you have an opinion here? I am inclined to reverting that patch completely. Let me know. On 08/02/2014 06:23 PM, Torben Frey wrote: Package: open-iscsi Version: 2.0.873+git0.3b4b4500-2 Severity: important Dear Ritesh and Turbo, this new patch is causing trouble for two reasons. Here are the relevant lines from patch 7e1ae42: +while read fs; do +set -- $(eval echo $fs | sed 's@:@ @') +case $1 in +swap) +swapon $2 +;; +*) +fsck -a $2 + +if mount $2 /dev/null 21; then +MOUNT_RESULT=0 - this does NOT change the value for the last line +break- this is the break line I removed +fi +;; +esac +done log_end_msg $MOUNT_RESULT - this will stay on 1 from inital setting 1) The “break is exiting the while loop after mounting the first found target disk successfully, ignoring all further disks which might still be in the loop value list. I fixed this behaviour for myself by just removing the break line. This should be the correct fix. 2) MOUNT_RESULT=0 is NOT changing the value to 0 because MOUNT_RESULT was initially set to 1 outside the nested loops/pipes. So the function/script will always call log_end_msg with the initial value of 1, displaying a “failed” after the init script finishes. I fixed this for myself by just explicitely setting the value of MOUNT_RESULT to 0 before the log_end_msg line. Of course, this is not representing the correct result of the mount calls - but currently it is not doing that as well. This is only a workaround. Best regards, Torben -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages open-iscsi depends on: ii libc6 2.19-7 ii udev 208-6 open-iscsi recommends no packages. open-iscsi suggests no packages. -- Configuration Files: /etc/init.d/open-iscsi changed [not included] /etc/iscsi/initiatorname.iscsi changed [not included] /etc/iscsi/iscsid.conf changed [not included] -- no debconf information -- Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com Necessity is the mother of invention. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#755834: I can't reproduce this
Hi, I can't reproduce this and I run a dhcp server with DHCP_INTERFACES= Is there anything in /var/log/daemon.log which shows why dhcpd didn't start? Cheers, Scott -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756841: tasksel: --task-desc no more works
Control: found -1 3.00 Axel Beckert a...@debian.org (2014-08-02): In the meanwhile I was able to reproduce the issue on an existing Wheezy installation, too. So the mentioned screenshots were likely from Squeeze. Marking as found in Wheezy. Tracked it to: | commit 9efc98df74352433af747463bc44404f332f2ee8 | Author: Joey Hess j...@kitenet.net | Date: Sun Feb 27 22:38:07 2011 -0400 | | remove Description and Packages fields | | Only the manual and standard tasks need those fields now. aka. 3.00~5 Mraw, KiBi. signature.asc Description: Digital signature
Bug#756845: jekyll: uninitialized constant Jekyll::Converters::Scss
Package: jekyll Version: 2.0.3+dfsg-1 Severity: important -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Dear Maintainer, after installing jekyll from unstable, it does not start anymore. Instead I immediately get a stacktrace: $ jekyll --version /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:6:in `module:Converters': uninitialized constant Jekyll::Converters::Scss (NameError) from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:5:in `module:Jekyll' from /usr/lib/ruby/vendor_ruby/jekyll/converters/sass.rb:4:in `top (required)' from /usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/vendor_ruby/jekyll.rb:11:in `block in require_all' from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `each' from /usr/lib/ruby/vendor_ruby/jekyll.rb:10:in `require_all' from /usr/lib/ruby/vendor_ruby/jekyll.rb:64:in `top (required)' from /usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/lib/ruby/2.0.0/rubygems/core_ext/kernel_require.rb:55:in `require' from /usr/bin/jekyll:6:in `main' - -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable'), (250, 'unstable'), (125, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages jekyll depends on: ii ruby 1:2.0.0.2 ii ruby-classifier 1.3.4-1 ii ruby-colorator0.1-3 ii ruby-commander4.1.6-1 ii ruby-jekyll-coffeescript 1.0.0-1 ii ruby-jekyll-sass-converter1.0.0-1 ii ruby-kramdown 1.3.3-2 ii ruby-liquid 2.6.1-1 ii ruby-listen 2.4.0-4 ii ruby-maruku 0.7.1-1 ii ruby-pygments.rb 0.5.4~ds1-1 ii ruby-rdiscount2.1.7.1-1 ii ruby-redcarpet3.1.1-2 ii ruby-redcloth 4.2.9-3+b1 ii ruby-safe-yaml1.0.1-1 ii ruby-toml 0.1.1-1 ii ruby1.9.1 [ruby-interpreter] 1.9.3.484-2 ii ruby2.0 [ruby-interpreter]2.0.0.484+really457-3 ii ruby2.1 [ruby-interpreter]2.1.1-4 Versions of packages jekyll recommends: pn ruby-mysql none pn ruby-rouge none pn ruby-sequel none pn ruby-sequel-pg none jekyll suggests no packages. - -- no debconf information -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBCAAGBQJT3PFmAAoJEKfJ/wY/PS4DDxgP/iwCMCd6OuN5jGOCYHYB20Yn iGRd2GS4ZZRCwGzZC/b/OnMBRzd4MAktohdGL1cavSakUI/s+ihNUSiaXIPqAG+0 odpXYP44G5q49yx/rNYkAFlJAahsWuv2DHUSX/tNwSg0KET/FqteiRurOmCXhxoL Yt7CiamHh2tvGeMexB9WLeXHBTfIdhmVu5tQZNOSHrV9lgjnKhHkl/+vW9x4dG5R jEFna7uK+yYphoSGFYv25mHF8cxPWwurg3GR7jcB8cAAEwS1m2PZtMptTNHAuGUw aLuK5CnzXJnn4rHnxQ7SlbuRdF4yk8TLzXPdlh19V5Nl29kH5vBhv8E2aT1c2K/g AdtwyDEjPll8HkLKAyB8M+oSNCZL7IlGtUzQs1bs32QEt6tiilI1ZlnaJ8JFIgGV hfxIOPdaESgVIKFZ99iHxSY8oDtXtgLQUV5s8HRvJUi0gDQVtvfHuw5BjFUQnlDJ uPBKwFAcYBxYiVBGhwFLO1eDL+glyFl+5SmOBN6oulYuZD9/5jcwYL0AD4Ci09uh KCat5h8Ncjnpn2dOZ52fJ1rGMVb/5tJlkP/jqB29YhqR/wMEbRgwHhUxxml9LFTW 3h9J3WkfJmnX39/1IqPEpH8dtZQg7IUJVxNo7G0rwufCV2oPR2ZO+UoujX65W3fJ yP/gBmtE/opyW1zHP3gF =c/k8 -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#756042: RFS: sandboxgamemaker/2.8.2+dfsg-1 [ITA][RC]
Thanks for notifying me Eriberto, i'd removed it as i was about to upload last night and then noticed another issue. I'm going to look into it again later on today or tommorow, please feel free to check i've done everything else correctly. The current issue now revolves around the postrm and postinst files, which is because as we agreed i tried to remove them to not bother with the extra nonfree data. As before please check all the other issues you raised previously are sorted and hopefully by tommorow i'll have a working package. Please note I have not at this point changed the rules file, and after looking at the current one i think i'd like to reupload this without changing it first. Many Thanks Anthony
Bug#686638: Bug#649220: ftp.debian.org: please allow for whitespace around , when splitting Uploaders
Control: tags -1 + moreinfo
python-debian does not parse Uploaders field correctly when separated
by commas and multiple spaces in control file
$ cat */debian/control | grep Uploaders
Uploaders: Foo f...@debian.org , Bar b...@debian.org
$ python
from debian.debfile import Deb822
fields = Deb822(open('test_0.1.dsc', 'r'))
print fields['Uploaders']
Foo f...@debian.org , Bar b...@debian.org
I don't believe that python-debian actually attempts to parse Uploaders at
all, let alone doing so incorrectly. Like most other fields, the data in
Uploaders is just added to the dict entry and python-debian is neither parsing
nor normalising this data.
Other fields are parsed correctly:
root@debomatic64:/haha# cat */debian/control | grep Build-Depends:
Build-Depends: debhelper , quilt
$ python
from debian.debfile import Deb822
fields = Deb822(open('test_0.1.dsc', 'r'))
print fields['Build-Depends']
debhelper, quilt
In contrast to most other fields, Build-Depends *is* actually parsed, data
structures are created and the print statement is then flattening that data
structure back into a string. That has the effect of normalising the data as
well.
Normalisation of Uploaders implies loading the list of uploaders into some
sort of data structure. Any suggestions on what data structure should be used
(bearing in mind that changing from a string to a list would be API breaking
and there are users of this API both inside and outside the archive)?
Moreover, I'm not sure whether Policy §5.6.3 and §5.6.2 is actually saying
that you could naively split on \s*,\s* in any case -- is the maintainer's
name allowed to contain commas and be quoted in an rfc822-compliant way?
cheers
Stuart
--
Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net
Debian Developer http://www.debian.org/ stu...@debian.org
GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756831: mountmedia: /hd-media unmounted during an installation
On Sat 02 Aug 2014 at 10:31:33 +0100, Brian Potkin wrote: Commenting out the line umount $dir 2/dev/null || true in mountmedia gets 1. The behaviour would appear to be connected more with the provision of firmware than the type of connection. I'm unsure what is going on but the fix does point to mountmedia as being involved in the issue. The quoted line is preceded by the helpful comment: # umount can legitimatly fail if something is keeping # it open So we will keep /hd-media mounted with d-i preseed/early_command string \ mkdir /xxx;\ mount --bind /hd-media /xxx Which makes me wonder whether there is a bug of any consequence here. Regards, Brian. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753012: [Tails-dev] Bug#753012: RFP: vagrant-libvirt -- Vagrant provider for libvirt
On Sat, Jun 28, 2014 at 10:23:20PM +0200, intrigeri wrote: Dear libvirt / Vagrant maintainers, [...] Would you be interested in maintaining vagrant-libvirt in Debian? It would greatly help at least Tails [1] and Freepto [2]. Hi, I'm not a libvirt or Vagrant maintainer but I can take care of this package. However, I think vagrant needs to be updated. Otherwise, this package is not really useful. If nobody objects I'll maintain this package under pkg-ruby. I can take a look at vagrant during DebConf and check if can update it. Cheers, -- Miguel Landaeta, nomadium at debian.org secure email with PGP 0x6E608B637D8967E9 available at http://miguel.cc/key. Faith means not wanting to know what is true. -- Nietzsche signature.asc Description: Digital signature
Bug#756846: owncloud: forcibly sets /etc/owncloud to www-data in postinst
Package: owncloud Version: 7.0.0+dfsg-1 Severity: normal Dear Maintainer, The owncloud package forcibly changes the owner and group of /etc/owncloud to www-data. This is problematic if you run owncloud as another user, since you need to set the owner back on every upgrade. Please preserve user-made modifications to the config file permissions. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable'), (110, 'testing-updates'), (110, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/6 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 owncloud depends on: ii apache2 2.4.10-1 ii apache2-bin [httpd] 2.4.10-1 ii apache2-mpm-prefork [httpd] 2.4.10-1 ii fonts-font-awesome 4.1.0~dfsg-1 ii fonts-liberation 1.07.2-6 ii fonts-linuxlibertine 5.1.3-1 ii fonts-lohit-deva 2.5.1-1 ii fonts-sil-gentium-basic 1.1-5 ii fonts-wqy-microhei 0.2.0-beta-2 ii libjs-chosen 0.9.11-1 ii libjs-dojo-dojox 1.7.2+dfsg-1 ii libjs-jcrop 0.9.12+dfsg-1 ii libjs-jquery-minicolors 1.2.1-1 ii libjs-jquery-mousewheel 6-1 ii libjs-jquery-timepicker 1.2-1 ii libjs-pdf1.0.277-1 ii libphp-phpmailer 5.1-1 ii owncloud-doc 0~20140721-2 ii php-assetic 1.1.2-1 ii php-doctrine-dbal2.4.2-3 ii php-getid3 1.9.8-1 ii php-mssql-bundle 0~20140212-1 ii php-opencloud1.10.0-2 ii php-patchwork-utf8 1.1.24-1 ii php-pear 5.4.4-14+deb7u12 ii php-pimple 1.1.1-1 ii php-sabre-dav1.8.10-1 ii php-seclib 0.3.7-1 ii php-symfony-classloader 2.3.6-1 ii php-symfony-console 2.3.1+dfsg-1 ii php-symfony-routing 2.0.19-1 ii php5 5.4.4-14+deb7u12 ii php5-gd 5.6.0~rc2+dfsg-5 ii php5-json1.3.5-3 ii php5-pgsql 5.6.0~rc2+dfsg-5 ii zendframework1.11.13-1.1 Versions of packages owncloud recommends: pn libav-tools none pn libreoffice none pn php-aws-sdk none pn php-crypt-blowfish none ii php-dropbox 1.0.0-1 ii php-google-api-php-client 0.6.7-2 pn php5-apcu | php5-xcache none ii php5-cli5.6.0~rc2+dfsg-5 ii php5-curl 5.6.0~rc2+dfsg-5 pn php5-imagicknone pn php5-intl none ii php5-ldap 5.6.0~rc2+dfsg-5 pn php5-mcrypt none ii postfix [mail-transport-agent] 2.9.6-2 ii smbclient 2:4.1.9+dfsg-1~bpo70+1 Versions of packages owncloud suggests: pn libapache2-mod-xsendfile none ii mariadb-server-5.5 [virtual-mysql-server] 5.5.38-1 -- Configuration Files: /etc/owncloud/htaccess [Errno 13] Permission denied: u'/etc/owncloud/htaccess' -- 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#754637: ck: FTBFS on kfreebsd-i386: PIC register clobbered by '%ebx' in 'asm'
On 31/07/14 07:10, Devon H. O'Dell wrote: Concurrency Kit 0.4.3 has been released and fixes this issue. Sorry for the delay. Thanks for the update, I just uploaded to Debian Build reports will appear here over the next few hours: https://buildd.debian.org/status/package.php?p=cksuite=unstable Would anybody from the ConcurrencyKit community be interested in joining the Debian Maintainer program? Then you will be able to upload directly to Debian and Ubuntu when you release. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756816: apt: apt-get upgrade packagename should not set packagename to manually installed
On Sat, Aug 02, 2014 at 02:02:50AM +0200, Axel Beckert wrote: But it also seems to set the given package to manually installed for which there is no reason at all: Well, there is apts usual reason: If you care enough to mention the package explicitly on the commandline, you properly don't want apt to suggest its removal later on. I definitely disagree here. IMHO this is very non-intuitive behaviour. When doing dist-upgrades from oldstable to stable, I do them in very small bits, so that no service has a downtime longer than necessary. One of these steps usually includes bigger bunches of libsomething packages which I surely never want to have the automatically installed mark removed. (aptitude has one or more bugs which causes that and it's already very annoying. But at least it doesn't do that on purpose unless explicitly requested.) This is a pretty unusual thing to do, so don't expect the defaults to be helping you with this. The release notes are pretty specific in how you should be doing a dist-upgrade… (more of a general remark, not specific to this one here). I can't say I am a huge fan of that, but it is at least very consistent and avoids that the autoremoval is overagressive – or do I really want it to remove my favorite shell because it isn't needed anymore? ;) Yes! Yes indeed. Otherwise I would not have marked it automatically installed. All my favourite packages are in a local metapackages. If that metapackages drops a dependency/recommends/suggests on a package, I want this package to be removed. I mean, that's what the automatically installed mark is for! The way apt handles it currently looks as if apt thinks it knows better than the local admin which package got the automatically installed mark for good reasons and which not. Which IMHO is clearly wrong. Yes, and no. Active management of the autobit requires exactly that: active management. Something not everyone wants to do. A lot of people got really scared then they removed iceweasel and apt(itude) suggested to remove all of gnome with it. Technically completely correct and the solution is easy for each user, but the chosen solution in the end was to handled metapackages differently (which isn't really nice either, which I want to change/discuss at some point, but different beast… I just mention it here, because some of what you think are bugs above are probably caused by this). I think active management is something aptitude users are more or less used to, as an interactive tool allows to deal with that easily, while a tool like apt-get, but also the higher-level tools like the various now-called software stores are expected to provide the perfect solution on first try without any tweaking – as the user either doesn't want or simply can't do the tweaking. (which in fact is how I use apt as I usually don't have an opinion on or-groups and stuff. I tend to check the removes – which unfortunately many people consider optional even in unstable – but thats it. I choose the stuff I interact with directly, for the rest I don't care…) I think you will agree that not everyone in the world is doing local metapackages. Or wants to deal with package management below the level of install/remove what he likes (not). And do you really think it is that surprising that if you manually request the installation of a (new version of a) package that it isn't marked as automatically installed anymore? After all, you manually installed it… I think the problem is more that we try to encode everything in a boolean flag here. In my book it would be more sensible to have more states here and options for the autoremover to switch between shades of I don't want to think, please only propose something if you are really sure and *I* have marked packages explicitly, the rest is fair game for you as I will check what you propose. If you want to upgrade a 'single' package, install is for you (which has the exact same behavior regarding the autobit). I actually lied a bit: apt-get install pkgA --only-upgrade will actually do what you want without changing the autobit. Partial upgrades tend to lead to disaster, Huh? Works fine for me for ages in general. Just not with apt-get but with aptitude. ;-) That's one of things I like aptitude for a lot. And is one of the reasons why I use apt-get so seldomly. That wasn't a remark on apt-get/aptitude. It was more a remark on how untested partial upgrades usually are, so that it isn't unlikely that someone forgot to raise a = on a -common/-data/-whatever package. It is also a remark on how people think they have installed a security fix by installing pkgA, while the fix is actually in libobscureA… Best regards David Kalnischkies P.S.: I will be offline starting tomorrow, so don't be suprised if I don't answer in the next ~weeks. signature.asc Description: Digital signature
Bug#754637: ck: FTBFS on kfreebsd-i386: PIC register clobbered by '%ebx' in 'asm'
Yeah, I could be convinced. We use Ubuntu and Debian at work, and I'm noticing build failures for a couple other supported architectures. The issues look to just be problems with the configure script. Are those build machines available for testing? N.B. I know basically 0 about deb packaging, so I might need a little bit of up-front hand-holding. --dho 2014-08-02 7:57 GMT-07:00 Daniel Pocock dan...@pocock.pro: On 31/07/14 07:10, Devon H. O'Dell wrote: Concurrency Kit 0.4.3 has been released and fixes this issue. Sorry for the delay. Thanks for the update, I just uploaded to Debian Build reports will appear here over the next few hours: https://buildd.debian.org/status/package.php?p=cksuite=unstable Would anybody from the ConcurrencyKit community be interested in joining the Debian Maintainer program? Then you will be able to upload directly to Debian and Ubuntu when you release. Regards, Daniel -- You received this message because you are subscribed to the Google Groups Concurrency Kit group. To unsubscribe from this group and stop receiving emails from it, send an email to concurrencykit+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#736040: prima: diff for NMU version 1.28-1.3
tags 736040 + patch
tags 736040 + pending
tags 752805 + pending
thanks
Dear maintainer,
I've prepared an NMU for prima (versioned as 1.28-1.3) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
diff -u prima-1.28/debian/changelog prima-1.28/debian/changelog
--- prima-1.28/debian/changelog
+++ prima-1.28/debian/changelog
@@ -1,3 +1,12 @@
+prima (1.28-1.3) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Do not hardcode /usr/lib/perl5 (Closes: #752805), taking the patch from the
+BTS (authored by Gregor Herrmann)
+ * Do not B-D on libtiff4-dev, but on libtiff-dev (Closes: #736040)
+
+ -- Tobias Frost t...@debian.org Sat, 02 Aug 2014 17:03:18 +0200
+
prima (1.28-1.2) unstable; urgency=medium
* Non-maintainer upload. Announced with this bug: (Closes: #734974)
diff -u prima-1.28/debian/control prima-1.28/debian/control
--- prima-1.28/debian/control
+++ prima-1.28/debian/control
@@ -2,7 +2,7 @@
Section: perl
Priority: extra
Maintainer: Bas Zoetekouw b...@debian.org
-Build-Depends:
+Build-Depends:
debhelper (= 5),
perl (= 5.8),
libx11-dev,
@@ -14,7 +14,7 @@
libpng-dev,
libxpm-dev,
libjpeg-dev,
- libtiff4-dev
+ libtiff-dev
Standards-Version: 3.8.2
Homepage: http://search.cpan.org/dist/Prima/
diff -u prima-1.28/debian/rules prima-1.28/debian/rules
--- prima-1.28/debian/rules
+++ prima-1.28/debian/rules
@@ -1,6 +1,8 @@
#!/usr/bin/make -f
DEST = $(CURDIR)/debian/libprima-perl
+VENDORARCH := $(shell perl -MConfig -e 'print substr($$Config{vendorarch}, 1)')
+SITEARCH := $(shell perl -MConfig -e 'print substr($$Config{sitearch}, 5)')
ifneq ($(findstring parallel=,$(DEB_BUILD_OPTIONS)),)
PARALLEL = -j$(subst parallel=,,$(filter parallel=%,$(DEB_BUILD_OPTIONS)))
@@ -64,21 +66,21 @@
# Fix the messed up paths
#
cd $(DEST) \
- mkdir -p usr/share/doc/prima usr/lib/perl5
usr/share/perl5/Prima/VB \
- mv local/lib/perl/*/Prima/*.pod usr/share/perl5/Prima/
\
- mv local/lib/perl/*/Prima/*.gif usr/share/perl5/Prima/
\
- mv local/lib/perl/*/Prima/VB/*.gif usr/share/perl5/Prima/VB/
\
- mv local/lib/perl/*/* usr/lib/perl5/
\
+ mkdir -p usr/share/doc/prima $(VENDORARCH)
usr/share/perl5/Prima/VB \
+ mv $(SITEARCH)/Prima/*.pod usr/share/perl5/Prima/
\
+ mv $(SITEARCH)/Prima/*.gif usr/share/perl5/Prima/
\
+ mv $(SITEARCH)/Prima/VB/*.gif usr/share/perl5/Prima/VB/
\
+ mv $(SITEARCH)/* $(VENDORARCH)/
\
mv bin usr/
\
- mv usr/lib/perl5/manusr/share/
\
- mv usr/lib/perl5/Prima/tutorial usr/share/doc/prima/
\
- mv usr/lib/perl5/Prima/examples usr/share/doc/prima/
\
- mv usr/lib/perl5/Prima/VB/examples
usr/share/doc/prima/examples/VB
+ mv $(VENDORARCH)/manusr/share/
\
+ mv $(VENDORARCH)/Prima/tutorial usr/share/doc/prima/
\
+ mv $(VENDORARCH)/Prima/examples usr/share/doc/prima/
\
+ mv $(VENDORARCH)/Prima/VB/examples
usr/share/doc/prima/examples/VB
cd $(DEST) \
- rmdir local/lib/perl/* local/lib/perl local/lib/ local/
\
- rm usr/lib/perl5/auto/Prima/.packlist
\
- rm -r usr/lib/perl5/Prima/sys/win32
+ rmdir --ignore-fail-on-non-empty --parents $(SITEARCH)
\
+ rm $(VENDORARCH)/auto/Prima/.packlist
\
+ rm -r $(VENDORARCH)/Prima/sys/win32
###
# Fix overly generic names of binaries
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#753012: [Tails-dev] Bug#753012: RFP: vagrant-libvirt -- Vagrant provider for libvirt
Hi Miguel, Miguel Landaeta wrote (02 Aug 2014 14:44:20 GMT) : I'm not a libvirt or Vagrant maintainer but I can take care of this package. This would totally rock. \o/ However, I think vagrant needs to be updated. Otherwise, this package is not really useful. Right. There's been WIP documented on Debian#741996 a month ago. Cheers, -- intrigeri -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756847: wpasupplicant: systemd wpa_supplicant.service wrong behavior on target isolate
Package: wpasupplicant Version: 1.1-1 Severity: normal Dear Maintainer, I switched from sysvinit to systemd in Debian Jessie. I created a personalized systemd target similar to graphical.target, just adding some Conflicts directives in order to stop some daemons (mysql and apache2). When I switch from graphical.target to personalized.target and vice-versa (using systemctl isolate name.target), everything works fine, except that WiFi connection in Gnome3 Network Manager drops and then restart. Syslog reports that it is wpa_supplicant.service that stops and then restarts. I think that it is not a desiderable behaviour of wpa_supplicant.service, unless it is explicitly stopped by a target. I tried to edit wpa_supplicant.service configuration: 1) I created a wpa_supplicant.service.d directory in /etc/systemd/system 2) I edited a personalized.conf file in it, in which I added the following 2 lines: [Unit] IgnoreOnIsolate=true 3) Then I restarted daemons and reloaded wpa_supplicant.service 4) systemd-delta reports that wpa_supplicant.service has been EXTENDED 5) switching from graphical.target to my personalize.target works fine, Wifi connection is not stopped. 6) errors happens when I switch to rescue.target and then back to graphical or personalized targets: - rescue shell is not closed - gnome3 doesn't load properly (just shows desktop image, but no login window) - I need to force a reboot - I suspect that it is an issue related to DBus (I am not an expert.) Do you think it is possible to fix wpa_supplicant.service ? thanks -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (990, 'testing'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-2-686-pae (SMP w/2 CPU cores) Locale: LANG=it_IT.UTF-8, LC_CTYPE=it_IT.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages wpasupplicant depends on: ii adduser 3.113+nmu3 ii initscripts 2.88dsf-53.2 ii libc6 2.19-7 ii libdbus-1-3 1.8.6-1 ii libnl-3-200 3.2.24-2 ii libnl-genl-3-200 3.2.24-2 ii libpcsclite1 1.8.11-3 ii libreadline6 6.3-6 ii libssl1.0.0 1.0.1h-3 ii lsb-base 4.1+Debian13 wpasupplicant recommends no packages. Versions of packages wpasupplicant suggests: pn libengine-pkcs11-openssl none pn wpaguinone -- 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#756848: xserver-xorg-video-radeon: Random segfaults with glamor enabled on Southern Islands card
Package: xserver-xorg-video-radeon Version: 1:7.4.0-2 Severity: important -- Package-specific info: X server symlink status: lrwxrwxrwx 1 root root 13 Jul 19 2013 /etc/X11/X - /usr/bin/Xorg -rwxr-xr-x 1 root root 2356320 Jul 17 18:25 /usr/bin/Xorg Diversions concerning libGL are in place diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so to /usr/lib/mesa-diverted/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1 to /usr/lib/mesa-diverted/libGL.so.1 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so by glx-diversions diversion of /usr/lib/i386-linux-gnu/libGL.so.1.2 to /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1.2 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so.1.2.0 to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so.1.2.0 to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/arm-linux-gnueabihf/libGL.so to /usr/lib/mesa-diverted/arm-linux-gnueabihf/libGL.so by glx-diversions diversion of /usr/lib/libGL.so.1.2 to /usr/lib/mesa-diverted/libGL.so.1.2 by glx-diversions diversion of /usr/lib/libGL.so.1.2.0 to /usr/lib/mesa-diverted/libGL.so.1.2.0 by glx-diversions diversion of /usr/lib/x86_64-linux-gnu/libGL.so to /usr/lib/mesa-diverted/x86_64-linux-gnu/libGL.so by glx-diversions VGA-compatible devices on PCI bus: -- 01:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Pitcairn PRO [Radeon HD 7850] [1002:6819] /etc/X11/xorg.conf does not exist. /etc/X11/xorg.conf.d does not exist. KMS configuration files: /etc/modprobe.d/radeon-kms.conf: options radeon modeset=1 Kernel version (/proc/version): --- Linux version 3.14-1-amd64 (debian-ker...@lists.debian.org) (gcc version 4.8.2 (Debian 4.8.2-21) ) #1 SMP Debian 3.14.2-1 (2014-04-28) Xorg X server log files on system: -- -rw-r--r-- 1 root root 55494 Aug 2 09:01 /var/log/Xorg.0.log Contents of previous Xorg X server log file (/var/log/Xorg.0.log.old): - [ 37166.444] X.Org X Server 1.16.0 Release Date: 2014-07-16 [ 37166.444] X Protocol Version 11, Revision 0 [ 37166.444] Build Operating System: Linux 3.14-1-amd64 x86_64 Debian [ 37166.444] Current Operating System: Linux nebula 3.14-1-amd64 #1 SMP Debian 3.14.2-1 (2014-04-28) x86_64 [ 37166.444] Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.14-1-amd64 root=UUID=10f3f61b-ebec-461b-8c72-94ba1cbcc165 ro quiet [ 37166.444] Build Date: 17 July 2014 10:22:36PM [ 37166.444] xorg-server 2:1.16.0-1 (http://www.debian.org/support) [ 37166.444] Current version of pixman: 0.32.4 [ 37166.444]Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 37166.444] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 37166.444] (==) Log file: /var/log/Xorg.0.log, Time: Sat Aug 2 09:00:49 2014 [ 37166.445] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 37166.445] (==) No Layout section. Using the first Screen section. [ 37166.445] (==) No screen section available. Using defaults. [ 37166.445] (**) |--Screen Default Screen Section (0) [ 37166.445] (**) | |--Monitor default monitor [ 37166.445] (==) No monitor specified for screen Default Screen Section. Using a default monitor configuration. [ 37166.445] (==) Automatically adding devices [ 37166.445] (==) Automatically enabling devices [ 37166.445] (==) Automatically adding GPU devices [ 37166.445] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [ 37166.445]Entry deleted from font path. [ 37166.445] (==) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1,
Bug#754637: ck: FTBFS on kfreebsd-i386: PIC register clobbered by '%ebx' in 'asm'
On 02/08/14 17:05, Devon H. O'Dell wrote: Yeah, I could be convinced. We use Ubuntu and Debian at work, and I'm noticing build failures for a couple other supported architectures. The issues look to just be problems with the configure script. Are those build machines available for testing? Yes, all Debian Developers have access to porting machines for all those architectures. We can also sponsor temporary access requests for outside developers in cases like this. Do you have a PGP key, preferably with signatures from any Debian people you have met? N.B. I know basically 0 about deb packaging, so I might need a little bit of up-front hand-holding. mentors.debian.net and the debian-mentors mailing list and IRC channels are there to help. As the package already exists, it is even easier than creating a new package from scratch. Regards, Daniel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752347: highlight: diff for NMU version 3.9-1.1
tags 752347 + pending
thanks
Dear maintainer,
I've prepared an NMU for highlight (versioned as 3.9-1.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Don McLean: Profiteering Blues
diff -Nru highlight-3.9/debian/changelog highlight-3.9/debian/changelog
--- highlight-3.9/debian/changelog 2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/changelog 2014-08-02 17:41:32.0 +0200
@@ -1,3 +1,14 @@
+highlight (3.9-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix hardcodes /usr/lib/perl5:
+- make debian/libhighlight-perl.install executable and use
+ $Config{vendorarch} there
+- use debhelper (compat level) 9
+(Closes: #752347)
+
+ -- gregor herrmann gre...@debian.org Sat, 02 Aug 2014 17:41:29 +0200
+
highlight (3.9-1) unstable; urgency=low
* New upstream release.
diff -Nru highlight-3.9/debian/compat highlight-3.9/debian/compat
--- highlight-3.9/debian/compat 2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/compat 2014-06-30 23:22:13.0 +0200
@@ -1,2 +1,2 @@
-7
+9
diff -Nru highlight-3.9/debian/control highlight-3.9/debian/control
--- highlight-3.9/debian/control 2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/control 2014-06-30 23:22:27.0 +0200
@@ -3,7 +3,7 @@
Priority: optional
Maintainer: Ayman Negm n...@debian.org
Uploaders: David Bremner brem...@debian.org
-Build-Depends: debhelper (= 7.0.50), swig, liblua5.1-0-dev, libboost-dev,
+Build-Depends: debhelper (= 9), swig, liblua5.1-0-dev, libboost-dev,
pkg-config
Standards-Version: 3.9.3
Homepage: http://www.andre-simon.de
diff -Nru highlight-3.9/debian/libhighlight-perl.install highlight-3.9/debian/libhighlight-perl.install
--- highlight-3.9/debian/libhighlight-perl.install 2012-05-23 18:32:13.0 +0200
+++ highlight-3.9/debian/libhighlight-perl.install 2014-06-30 23:23:15.0 +0200
@@ -1,2 +1,8 @@
-examples/swig/highlight.so usr/lib/perl5/auto/highlight
-examples/swig/highlight.pm usr/lib/perl5
+#!/usr/bin/perl -w
+
+use Config;
+
+my $vendorarch = substr($Config{vendorarch}, 1);
+
+print examples/swig/highlight.so $vendorarch/auto/highlight\n;
+print examples/swig/highlight.pm $vendorarch\n;
signature.asc
Description: Digital Signature
Bug#756684: minc: [hdf5 transition] please support hdf5 1.8.13 new packaging layout
On August 1, 2014 12:39:30 AM Gilles Filippini wrote: Because this bug is in the way of the hdf5 transition I intend to NMU in a few days. I apologize for the urge, and I hope this approach won't offend you. Please tell me otherwise. The changes look fine and don't offend me. I think I'll be able to do an upload today, but if not, please go ahead with your NMU. -Steve -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#752349: nflog-bindings: diff for NMU version 0.2-3.1
tags 752349 + pending
thanks
Dear maintainer,
I've prepared an NMU for nflog-bindings (versioned as 0.2-3.1) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Rolling Stones: Nevertoointo
diff -Nru nflog-bindings-0.2/debian/changelog nflog-bindings-0.2/debian/changelog
--- nflog-bindings-0.2/debian/changelog 2012-05-19 16:29:28.0 +0200
+++ nflog-bindings-0.2/debian/changelog 2014-08-02 17:46:34.0 +0200
@@ -1,3 +1,13 @@
+nflog-bindings (0.2-3.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix hardcodes /usr/lib/perl5:
+Make debian/libnflog-perl.install executable and use $Config{vendorarch}
+to determine install directory.
+(Closes: #752349)
+
+ -- gregor herrmann gre...@debian.org Sat, 02 Aug 2014 17:46:31 +0200
+
nflog-bindings (0.2-3) unstable; urgency=low
* Add missing CPPFLAGS hardening flags (Closes: #670239).
diff -Nru nflog-bindings-0.2/debian/libnflog-perl.install nflog-bindings-0.2/debian/libnflog-perl.install
--- nflog-bindings-0.2/debian/libnflog-perl.install 2011-09-22 21:28:38.0 +0200
+++ nflog-bindings-0.2/debian/libnflog-perl.install 2014-07-01 16:59:53.0 +0200
@@ -1 +1,4 @@
-usr/lib/perl5
+#!/usr/bin/perl -w
+
+use Config;
+print 'usr/lib/perl5/* ' . substr($Config{vendorarch}, 1) . \n;
signature.asc
Description: Digital Signature
Bug#756843: open-iscsi: 7e1ae42 patch only mounting first target disk, then always failing in the end even on success
On Aug 2, 2014, at 3:58 PM, Torben Frey wrote: And I guess functionality is good after removing the “break” command. I just tested this with multiple _netdev entries, and they all work! So I couldn't reproduce this problem. I just don’t exactly know how the MOUNT_RESULT could summarize the result of all single mounts. Indeed. I'll see what I can come up with. Maybe it could be done by touching a temporary file on the first failed mount and if we have that in the end setting MOUNT_RESULT to 1 and removing the temporary file again before calling log_end_msg? There's always log_progress_msg (for each success/fail). -- I love deadlines. I love the whooshing noise they make as they go by. - Douglas Adams -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756851: ITP: astroquery -- Set of python tools for querying astronomical web forms and databases
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-as...@lists.debian.org --- Please fill out the fields below. --- Package name: astroquery Version: 0.1 Upstream Author: Adam Ginsburg adam.g.ginsb...@gmail.com URL: https://github.com/astropy/astroquery Description: Astroquery is an astropy http://www.astropy.org affiliated package that contains a collection of tools to access online Astronomical data.
Bug#752469: clearsilver: diff for NMU version 0.10.5-1.4
tags 752469 + pending
thanks
Dear maintainer,
I've prepared an NMU for clearsilver (versioned as 0.10.5-1.4) and
uploaded it to DELAYED/5. Please feel free to tell me if I
should delay it longer.
Regards.
--
.''`. Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
: :' : Debian GNU/Linux user, admin, and developer - http://www.debian.org/
`. `' Member of VIBE!AT SPI, fellow of the Free Software Foundation Europe
`- NP: Element of Crime: Weit ist der Weg
diff -Nru clearsilver-0.10.5/debian/changelog clearsilver-0.10.5/debian/changelog
--- clearsilver-0.10.5/debian/changelog 2011-12-29 21:58:10.0 +0100
+++ clearsilver-0.10.5/debian/changelog 2014-08-02 17:51:15.0 +0200
@@ -1,3 +1,14 @@
+clearsilver (0.10.5-1.4) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix hardcodes /usr/lib/perl5:
+- Make libclearsilver-perl.install executable and use $Config{vendorarch}.
+- Use $Config{vendorarch} also in debian/rules.
+- Bump debhelper compat level and dependency to 9.
+(Closes: #752469)
+
+ -- gregor herrmann gre...@debian.org Sat, 02 Aug 2014 17:51:13 +0200
+
clearsilver (0.10.5-1.3) unstable; urgency=high
* Non-maintainer upload.
diff -Nru clearsilver-0.10.5/debian/compat clearsilver-0.10.5/debian/compat
--- clearsilver-0.10.5/debian/compat 2006-06-05 19:27:40.0 +0200
+++ clearsilver-0.10.5/debian/compat 2014-07-01 17:38:06.0 +0200
@@ -1 +1 @@
-5
+9
diff -Nru clearsilver-0.10.5/debian/control clearsilver-0.10.5/debian/control
--- clearsilver-0.10.5/debian/control 2011-04-08 21:49:32.0 +0200
+++ clearsilver-0.10.5/debian/control 2014-07-01 17:38:04.0 +0200
@@ -1,7 +1,7 @@
Source: clearsilver
Section: devel
Priority: optional
-Build-Depends: python-all-dev (= 2.5.4-1~), debhelper (= 5.0.37.2), cdbs (= 0.4.41), zlib1g-dev, autotools-dev, quilt, python-support
+Build-Depends: python-all-dev (= 2.5.4-1~), debhelper (= 9), cdbs (= 0.4.41), zlib1g-dev, autotools-dev, quilt, python-support
XS-Python-Version: all
Maintainer: Jesus Climent jesus.clim...@hispalinux.es
Uploaders: Otavio Salvador ota...@debian.org, Lars Kruse de...@sumpfralle.de
diff -Nru clearsilver-0.10.5/debian/libclearsilver-perl.install clearsilver-0.10.5/debian/libclearsilver-perl.install
--- clearsilver-0.10.5/debian/libclearsilver-perl.install 2006-08-23 15:41:06.0 +0200
+++ clearsilver-0.10.5/debian/libclearsilver-perl.install 2014-07-01 17:39:52.0 +0200
@@ -1 +1,3 @@
-debian/tmp/usr/lib/perl5
+#!/usr/bin/perl -w
+use Config;
+print substr($Config{vendorarch}, 1) . \n;
diff -Nru clearsilver-0.10.5/debian/rules clearsilver-0.10.5/debian/rules
--- clearsilver-0.10.5/debian/rules 2011-04-08 21:20:26.0 +0200
+++ clearsilver-0.10.5/debian/rules 2014-07-01 17:34:44.0 +0200
@@ -17,11 +17,13 @@
CFLAGS += -fPIC
+PERL_ARCHLIB := $(shell perl -MConfig -e 'print $$Config{vendorarch}')
+
# retrieve supported python versions (2.3 and 2.4 as of June 02006)
PYVERS=$(shell pyversions -vr debian/control)
DEB_MAKE_INSTALL_TARGET := install DESTDIR=$(CURDIR)/debian/tmp
-DEB_SHLIBDEPS_INCLUDE_libclearsilver-perl := debian/libclearsilver-perl/usr/lib/perl5
+DEB_SHLIBDEPS_INCLUDE_libclearsilver-perl := debian/libclearsilver-perl$(PERL_ARCHLIB)
DEB_SHLIBDEPS_INCLUDE_python-clearsilver := $(patsubst %,debian/python-clearsilver/usr/lib/python-%/$(call py_sitename, %),$(PYVERS))
build/python-clearsilver:: $(PYVERS:%=build-python-%)
signature.asc
Description: Digital Signature
Bug#740953: [xserver-xorg-video-nouveau]: No devices detected. (anymore)
Could be the VBIOS problem which upstream is adressing on their website: http://nouveau.freedesktop.org/wiki/TroubleShooting/#index10h3 Adding the follwoing kernel boot parameter solved the problem on my laptop with kernels 3.13 or higher: nouveau.config=NvBios=PRAMIN The error message I got when booting without this parameter was: nouveau E[ VBIOS][:05:00.0] 0xc581[ ]: unknown opcode 0x00 nouveau E[ DEVINIT][:05:00.0] init failed, -22 nouveau E[ DRM] failed to create 0x8080, -22 Regards, Markus Huber -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#756852: lusernet.app: Links with OpenSSL without license exception
Package: lusernet.app Version: 0.4.2-6+b2 Severity: serious LuserNET links with OpenSSL via Pantomime and is released under GPL without the OpenSSL exception. -- System Information: Debian Release: 7.6 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-4-amd64 (SMP w/2 CPU cores) Locale: LANG=bg_BG.UTF-8, LC_CTYPE=bg_BG.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages lusernet.app depends on: ii gnustep-back0.20 0.20.1-2.1 ii gnustep-base-runtime 1.22.1-4 ii gnustep-common [gnustep-fslayout-fhs] 2.6.2-2 ii gnustep-gpbs 0.20.1-2.1 ii gnustep-gui-runtime0.20.0-3+b1 ii libc6 2.13-38+deb7u3 ii libgnustep-base1.221.22.1-4 ii libgnustep-gui0.20 0.20.0-3+b1 ii libobjc4 4.7.2-5 ii libpantomime1.21.2.0~pre3+snap20071004+dfsg-4+b1 lusernet.app recommends no packages. lusernet.app 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
