Bug#732006: uscan: broken handling of filenames with whitespace
Control: tag -1 pending On Sun, Dec 22, 2013 at 01:17:01AM +0100, Stig Sandbeck Mathisen wrote: > I've pushed a proposed fix for this security issue to the packaging > repo git://anonscm.debian.org/collab-maint/devscripts.git as the > branch CVE-2013-7085-ruin-someones-yuletide Thanks for the patch. We've addressed this by other means and are just pending some final review before uploading. > The change also fixes a second bug, where one could not exclude a > non-empty top level directory, but had to use "somedirectory/*". Thanks for noticing that. I've made a change for this as well. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#733008: subversion: OpenSSL version mismatch
Control: reassign -1 src:openssh Control: forcemerge 732940 733008 Control: affects 732940 subversion On Mon, Dec 23, 2013 at 10:22:35PM +0100, Pierre Labastie wrote: >* What led up to the situation? > When typing "svn up" inside a working directory which had been downloaded > with svn+ssh protocol, got: > Updating '.': > OpenSSL version mismatch. Built against 1000105f, you have 10001060 > svn: E210002: Unable to connect to a repository at URL > 'svn+ssh://svn.linuxfromscratch.org/ALFS/jhalfs/trunk' > svn: E210002: To better debug SSH connection problems, remove the -q option > from 'ssh' in the [tunnels] section of your Subversion configuration file. > svn: E210002: Network connection closed unexpectedly Updating your openssh-client package to 1:6.4p1-2 should resolve this. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#733273: Acknowledgement (uscan: Using options causes it to check the status multiple times)
On Sat, Dec 28, 2013 at 12:36:38AM +0100, Kurt Roeckx wrote: > So this might be just my misunderstanding of the watch file syntax and > really be the same as #733272 Could you provide the watch file you're using? Thanks, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#733904: nmu: subversion_1.7.14-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu nmu subversion_1.7.14-1 . ALL . -m "Rebuild against libserf-1-1" Subversion is currently intertwined in the libunwind transition, but once it's appropriate, it should be rebuilt against the new serf ABI. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#734163: subversion: corrupted data
On Sat, Jan 04, 2014 at 02:24:26PM +0100, Vincent Lefevre wrote: > I'll try to downgrade, but for the moment: > > xvii:...www/contents/cine> =svn diff -r 51990 index.fr.xml > Index: index.fr.xml > === > Cannot display: file marked as a binary type. > svn:mime-type = (h)کb, ) > Index: index.fr.xml > === > --- index.fr.xml(revision 51990) > +++ index.fr.xml(working copy) > > Property changes on: index.fr.xml > ___ > xvii:...www/contents/cine> =svn diff -r 51990 index.fr.xml > Index: index.fr.xml > === > Cannot display: file marked as a binary type. > svn: E22: Valid UTF-8 data > (hex: 73 76 6e 3a 6d 69 6d 65 2d 74 79 70 65 20 3d 20 28) > followed by invalid UTF-8 sequence > (hex: a8 95 b9 0e) > zsh: exit 1 =svn diff -r 51990 index.fr.xml Is this a publicly accessible repository? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#734163: subversion: corrupted data
Control: severity -1 normal On Sat, Jan 04, 2014 at 03:13:00PM +0100, Vincent Lefevre wrote: > On 2014-01-04 14:53:11 +0100, Vincent Lefevre wrote: > > The bug occurs on a second Debian/unstable machine. > > It still occurs after downgrading to the original 1.7.14 > > (not the binNMU), but I get only the second behavior. > > I could also get the first behavior. This is really random. > The problem disappears after downgrading to 1.7.13-3. This is purely a display issue, so I'm downgrading the severity. It only happens on files with svn:mime-type set. I've emailed upstream, so we'll see what they say. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#605702: subversion: commit-email.pl is locale-dependent and does wrong things
On Thu, Dec 02, 2010 at 03:48:15PM +0100, Moritz Both wrote: > When mod_svn is used, it will run with the "C" locale, since the > startup script for apache2 sets it like that. > > commit-email.pl uses two locale-dependent things: > > - svnlook will recode commit messages to the locale-specific > standard character encoding > > - strftime will create a "Date:" header line for the commit message. Subversion 1.8 introduced a means to configure the locale in which mod_dav_svn hooks are run and to understand UTF-8 input/output (c.f., http://subversion.apache.org/docs/release-notes/1.8.html#hooks). It looks like this may address the issues you raised. I hope to have a 1.8.x upload ready in a week or so. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#738842: subversion: add debug package
Control: forcemerge 508147 -1 On Thu, Feb 13, 2014 at 03:57:32PM +0400, vita...@yourcmc.ru wrote: > While I was trying to catch bug #738840 I've discovered there is no > subversion-dbg package in Debian. Can you add it? Already done. Just waiting for the next upload. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#739137: [uscan] Please honor Referer
On Sat, Feb 15, 2014 at 09:11:17PM -0400, David Prévot wrote: > User: devscri...@packages.qa.debian.org Almost. :) No ".qa" though -- devscri...@packages.debian.org. > The attached trivial patch aims at honoring Referer on HTTP(S) download. I thought Referer typically wasn't sent for HTTPS connections. Ah, that's for transitioning from HTTPS → HTTP[0]. 0: https://tools.ietf.org/html/rfc2616#section-15.1.3 Looks good to me. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#739416: transition: ruby1.8 removal
On Tue, Feb 18, 2014 at 08:29:35PM +0100, Julien Cristau wrote: > Removing subversion doesn't seem reasonable. The sid version might be > fixed (I haven't checked), but it FTBFS. So that'll need to be taken > care of first. One of the FTBFS appears to be a transient issue. A gb would likely fix it, but the others are related to #735446. Upstream's next release (due this week) fix that. I've been monitoring the release process, so I should be able to get it uploaded to Debian ASAP once it's officially released. The only potential complication would be if the libdb5.1-dev package disappears in the mean time as Ondřej intends[0]. I haven't finished the bdb 5.3 work as I wanted to touch base with Peter on it. 0: <139230.17282.82981781.6e443...@webmail.messagingengine.com> If needed, I could look at backporting the upstream commits to fix the FTBFS, but I'd prefer to put that effort into ensuring I can get the next 1.8.x uploaded when it's out. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#739472: devscripts: wrap-and-sort deletes binary package entry from debian/control
On Tue, Feb 18, 2014 at 07:05:25PM -0700, sney wrote: > My hexchat package builds 2 binary packages: hexchat and hexchat-common. > I ran wrap-and-sort -s to sort my build-deps, which it did, but it also > deleted > the hexchat entry from debian/control, This is because the line after your hexchat binary package is non-empty (there's a trailing space). Empty lines should be used to separate stanzas in a deb-control file. This is another instance of #715558. The simple fix is to remove the trailing whitespace on the line. The real fix is to get python-debian fixed as I suggested[0] before. 0: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715558#31 Unless someone feels strongly about adding a workaround in wrap-and-sort for python-debian's bug, I'll merge this with the existing reports in the coming days. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#737160: [uupdate] symlink directory traversal
On Thu, Jan 30, 2014 at 09:06:38PM +0100, Jakub Wilk wrote: > A malicious .orig.tar file can trick uupdate into patching files > outside the source package directory. Proof of concept: Thanks for the report and PoC. Looking into it some, below is my understanding of the issue and concerns on fixing it. First, this is only a problem for 1.0 format source packages, since unpacking a 3.0 format's diff tarball will replace a, potentially malicious, symlink in upstream's source with the corresponding directory in the diff tarball. With it constrained to 1.0 format, the problem exists for any file the diff.gz is adding (or possibly, but much less likely, modifying) where one of the directories in the path is a symlink pointing outside of the upstream source tree. We basically need to add the following just inside the if on line 730: for link in $(find -type l); do resolved="$(readlink -f "$link")" if ! expr "$resolved" : "$(pwd)" >/dev/null; then complain loudly fi done The problem with the above is that it's not robust in the face of paths which contain whitespace. That means, at best, some paths aren't properly detected and therefore are still subject to original issue. If someone more familiar with the inrticacies of handling this sort of scenario in (ba)sh has an idea on how to properly implement this, I'm all ears. Otherwise, I'm tempted to rewrite the whole thing in Perl, but I'd rather taking the time to do that. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729977: vim-gtk: gvim fails with SIGSEV
On Sun, Feb 23, 2014 at 09:17:35PM +0100, Adam wrote: > (gdb) set pagination 0 > (gdb) run -f > Starting program: /usr/bin/gvim -f > warning: no loadable sections found in added symbol-file system-supplied > DSO at 0x77ffa000 > warning: Could not load shared library symbols for linux-vdso.so.1. > Do you need "set solib-search-path" or "set sysroot"? > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [New Thread 0x7fffe82f2700 (LWP 9738)] > > Program received signal SIGSEGV, Segmentation fault. > 0x74150c25 in ?? () from > /usr/lib/x86_64-linux-gnu/libpython2.7.so.1.0 > (gdb) Can you run "bt" at this point and send the results? Also, can you run terminal vim and provide the results of the ":scriptnames" command? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#735971: Downloading gpg signature via FTP fails - missing to pass "pasv"?
Control: forcemerge 735085 On Sun, Jan 19, 2014 at 01:43:12AM +0100, Daniel Leidert wrote: > I'm attaching the watch file. Is it possible, that the "pasv" option is not > passed through to downloading the signature file? Yes, as previously reported and pending upload. I'm hoping to get it uploaded in the next few days. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#733272: uscan: Clarify options syntax
On Sat, Dec 28, 2013 at 12:20:32AM +0100, Kurt Roeckx wrote: > Reading the uscan manpage, it says: > | PER-SITE OPTIONS > | A watch file line may be prefixed with `opts=options', > | where options is a comma-separated list of options. The > | whole options string may be enclosed in double quotes, > | which is necessary if options contains any spaces. The > | recognised options are as follows: > > But having something as: > opts=pasv > > will result in: > uscan warning: malformed opts=... in watchfile, skipping line: > opts=pasv > > The problem is that you need to add the site after that, and > that's not clear from the documentation. You're right that we don't explicitly define that the file is parsed line-wise, but we do use that sort of wording in the description of the file format, and specify that opts is the first field (emphasis added): There are two possibilities for the syntax of an HTTP watch file __line__, and only one for an FTP __line__. We begin with the common (and simpler) format. We describe the __optional opts=... first field__ below, and ignore it in what follows. Would it have helped to have something the accepted formats shown (something like below) in addition to the existing descriptions? [opts=…] [opts=…] Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#736760: uscan: debian/upstream/ (directory) vs. debian/upstream (file)
On Sun, Jan 26, 2014 at 04:12:31PM +0100, gregor herrmann wrote: > Since 2.14.1, uscan now uses debian/upstream/signing-key.* for the > upstream signatures. > > This seems to conflict with the debian/upstream file, as decribed in > https://wiki.debian.org/UpstreamMetadata > http://dep.debian.net/deps/dep12/ I think it was an unfortunate choice for DEP-12 to claim the debian/upstream name as a file instead of transitioning from debian/upstream-metadata.yml to debian/upstream/…. I hadn't heard about this file until you mentioned, but I had multiple people make the suggestion of placing the signing key under debian/upstream/ and some suggest that it would be nice to move the watch file there. There are existing source packages, although only 9 from my quick search, using debian/upstream/ already, which may or may not be in conflict with claiming debian/upstream/ as a place to keep “interesting” information about the upstream project. I realize this is a far cry from the ~280 source packages using debian/upstream as a file, however, I think it makes more sense to have debian/upstream/ (directory) rather than debian/upstream (file). That allows for the possibility of placing other content under the namespace instead of solely what fits into the metadata that DEP-12 describes. My inclination is to mark this wontfix and offer some cycles to help transition DEP-12 related stuff to something that's compatible with devscripts' changes. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729977: vim-gtk: gvim fails with SIGSEV
Hmm, I seem to have missed this initally. Sorry about that. On Tue, Nov 19, 2013 at 12:04:49PM -0800, J C wrote: > Running gvim fails with SIGSEV. Terminal vim runs fine. I'll need more information to be able to do anything with this bug. Could you install the vim-dbg and gdb packages? Then use gdb[0] to get a backtrace when running gvim with the -f arg. [0]: https://wiki.debian.org/HowToGetABacktrace#Running_gdb Hopefully that reproduces the problem and I'll have some information to work with. Also, can you try running "gvim -u NONE" to see if it's possibly related to some of your user configuration? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#713066: yaml indentation is faulty, could use improvement
Control: tag -1 unreproducible On Sat, Jun 22, 2013 at 11:56:32AM +0200, martin f krafft wrote: > It is possible to place these into a list as well, i.e. a list of > hashes: > > --- > - a: b > c: d > - 1: 2 > 3: 4 > > Unfortunately, when entering this, the list's indentation level is > not preserved, e.g. (▮ is cursor position, ▯ is where I think it > should be): > > --- > - a: b > ▮ ▯ The behavior you describe is what I see with Vim. The YAML indent file was introduced around 7.3.753 and hasn't changed since. Are you sure you aren't using a third party indent script? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#726591: vim-common: mailcap vim -R
On Thu, Oct 17, 2013 at 10:24:14AM +1100, Kevin Ryde wrote: > /usr/lib/mime/packages/vim-common contains > > text/plain; view %s; edit=vim %s; compose=vim %s; test=test -x > /usr/bin/vim; needsterminal; priority=4 > text/*; view %s; edit=vim %s; compose=vim %s; test=test -x /usr/bin/vim; > needsterminal; priority=2 > > I think the "view %s" in each might better be > > vim -R %s There was some discussion about the view alternative on debian-devel last year and the mime-support maintainer had agreed that /usr/bin/see shouldn't be part of that alternative set. It doesn't seem like that change has happened yet, though. I'd prefer to just leave things be and let things settle out on their own once the see alternative is gone. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729924: vim: Add Python 3 support
On Mon, Nov 18, 2013 at 05:59:02PM -0500, Barry Warsaw wrote:
> I'm not a vim user but I'm am very interested in porting the world to
> Python 3. To that end, I see that the current version of upstream vim
> supports Python 3, but building that is not currently enabled in the
> Debian package.
This is due to two things.
First, the way Debian builds Python prevents loading both libpython2 and
libpython3 in the same process, since Debian's builds necessitate
passing RTLD_GLOBAL to dlopen(). This means that when Vim is built to
support both Python 2 & 3, one has to choose between using plugins that
target Python 2 or Python 3 instead of the user being able to use both.
At the time, this meant I had to choose one and I went with Python 2 due
to the much higher prevalence of plugins targeting it. While Python 3
has gained a lot of ground since then and it's much more easy to write
code that works in both versions, my understanding is that the
RTLD_GLOBAL issue still exists. This means I still need to choose one
version and, while it's more of a toss up now, I think Python 2 is still
the right call here.
Second, I'm not keen on the state of dependency tracking with software
that dynamically loads libraries instead of linking against them. If
Vim dynamically loaded its own code that provides the language bindings,
and those were linked against the proper language libraries, then I
could easily provide vim-{lua,perl,python,ruby,tcl}-bindings packages
which expressed proper relationships on the corresponding language
libraries.
Since that isn't the case, we can then run into situations where bad
things happen during a library transition due to nothing telling the
transition trackers that Vim should actually be rebuilt or forcing the
users to upgrade Vim in sync with the library. See #611573 for some
previous discussion about this related to Vim's Perl support.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Bug#734267: [Debian add-on] setting distribution only works when distro is known
On Sun, Jan 05, 2014 at 12:34:36PM +0100, Eduard Bloch wrote: > When I try to set the distribution via the Changelog menu in gvim, it > fails when the head line looks like this: > > foo-pkg (0.7.25-1) UNRELEASED; urgency=low > > But it works when there is some known release branch like "frozen" > instead of UNRELEASED. Indeed. Thanks for the report. Looks like a simple fix. > This looks like a regression, I remember having > used this feature to change "UNRELEASED" many times in the last years. This functionality hasn't been touched in years (as evidenced by still referencing frozen :). Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#725979: [Cupt-devel] Bug#725979: cupt: Support version 3 of apt's Pre-Install-Pkgs
On Feb 2, 2014 2:09 PM, "Eugene V. Lyubimkin" wrote: > > Thank for you for the detailed analysis. > > This is now implemented in master (1040cab6). Testing is welcome. With this apt-listbugs works again. However, adequate doesn't work. I think this is likely due to cupt's limited handling of apt's config space. Adequate specifies a config variable named Adequate::Enabled which it expects to read when run during Pre-Install-Pkgs. My guess is that cupt isn't writing this out to adequate's stdin since it's not one of the recognized apt config variables. Cheers, James
Bug#725979: [Cupt-devel] Bug#725979: cupt: Support version 3 of apt's Pre-Install-Pkgs
On Feb 3, 2014 11:52 AM, "Eugene V. Lyubimkin" wrote: > > Hi, > > 2014-02-03 10:01, James McCoy: > [...] > > With this apt-listbugs works again. However, adequate doesn't work. > > > > I think this is likely due to cupt's limited handling of apt's config > > space. Adequate specifies a config variable named Adequate::Enabled which > > it expects to read when run during Pre-Install-Pkgs. My guess is that cupt > > isn't writing this out to adequate's stdin since it's not one of the > > recognized apt config variables. > > Right, good point. Any better with fresh master? Looks good. Thanks!
Bug#729924: vim: Add Python 3 support
On Mon, Feb 03, 2014 at 05:38:12PM -0500, Barry Warsaw wrote: > On Jan 31, 2014, at 11:04 PM, James McCoy wrote: > > >First, the way Debian builds Python prevents loading both libpython2 and > >libpython3 in the same process, since Debian's builds necessitate > >passing RTLD_GLOBAL to dlopen(). This means that when Vim is built to > >support both Python 2 & 3, one has to choose between using plugins that > >target Python 2 or Python 3 instead of the user being able to use both. > > I'd always envisioned that the end user would make a binary choice as to > whether their plugins were Python 2 or 3, and then use one or the other in > their vim process. I don't know whether that's a reasonable assumption > though. The user doesn't necessarily have a choice in the matter. If they find plugins A and B that they want to use, but one is implemented in Python 2 and the other in Python 3, then they're either a) running Debian and out of luck, b) running a distro that doesn't require RTLD_GLOBAL and happy, or c) trying to convince one of the plugin authors to port their plugin. > I think we have other such precedence in Debian; I remember hacking on some > package to dynamically load either Python 2 or Python 3 (but not both) support > at runtime, but now I can't remember which package that is. I personally > don't think you'd need to support *both* Python 2 and Python 3 in the same > process space, and I'm actually pretty skeptical that that would work! I was part of some discussion[0] on the vim-dev list when this was being fleshed out that shows it does work. The problem is that Debian's python builds don't link the C extensions against the relevant libpython. > Does it change anything in your mind if vim plugins were limited to either > Python 2 or Python 3, selectable at runtime by the end user? That's essentially what already happens with dynamic loading enabled, except the "user selection" is a matter of "run either :python or :python3 before Python-using plugins are loaded to force the bindings you want to be loaded." From my maintainer perspective, the bigger issue is the lack of traceability of dependencies to aid binNMUs and the like. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729924: vim: Add Python 3 support
On Mon, Feb 03, 2014 at 07:31:40PM -0500, James McCoy wrote: > On Mon, Feb 03, 2014 at 05:38:12PM -0500, Barry Warsaw wrote: > > I think we have other such precedence in Debian; I remember hacking on some > > package to dynamically load either Python 2 or Python 3 (but not both) > > support > > at runtime, but now I can't remember which package that is. I personally > > don't think you'd need to support *both* Python 2 and Python 3 in the same > > process space, and I'm actually pretty skeptical that that would work! > > I was part of some discussion[0] on the vim-dev list when this was being > fleshed out that shows it does work. The problem is that Debian's > python builds don't link the C extensions against the relevant libpython. [0]: http://article.gmane.org/gmane.editors.vim.devel/27270 Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#736760: [Debian-med-packaging] debian/upstream vs. debian/upstream/signing-key.pgp
On Sun, Feb 02, 2014 at 11:44:51AM +0900, Charles Plessy wrote:
> Le Thu, Jan 30, 2014 at 05:06:22PM +0100, Andreas Tille a écrit :
> >
> > While I perfectly agree that it would have been the correct way to
> > discuss claiming parts of the namespace first (heck, even if you do
> > discuss changes for uscan at length like I did for Files-Excluded people
> > raise their hands afterwards that should be implemented differently) I
> > would volunteer to *help* (not lead) in a transition which means
> >
> > * reuploading files of Debian Med (and if needed of Debian Science
> > and DebiChem)
Why does anything need to be reuploaded? I thought part of the benefit
of the upstream metadata was that it could be pulled from VCS
repositories. Therefore, only updating the VCS repository is required
and not an upload.
> > * working on the needed changes for UDD machine readable files gatherer
Attached patch should allow that to work on both debian/upstream and
debian/upstream/metadata, which is a name I've heard suggested and what
first came to mind when the issue was initially raised.
> > However, my prefered solution for this problem would to start an open
> > discussion on debian-devel for opinions about a potential new name for
> > the signature file. This would have two advantages:
> >
> > 1. We might find some better consensus which could make a stressfull
> > transition superfluous
> > 2. Readers of the list would hopefully *learn* about both things
> > (the signature file as well as the metadata file)
The recent "Misc Developer News" mail mentioned the uscan feature and
Lintian has a pedantic/certain check for watch files that don't include
pgpsigurlmangle.
> Hello James,
>
> what is your take on this ? Will you start a discussion on debian-devel ?
If people think that's worthwhile, I can. Unless I'm missing something,
it seems like just transitioning to debian/upstream/ would be easier.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
From 0576504585935c1878c8ada963bd5a64f66048ba Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Mon, 3 Feb 2014 21:33:48 -0500
Subject: [PATCH] fetch-machine-readable: Support debian/upstream and
debian/upstream/metadata
---
misc/machine_readable/fetch-machine-readable | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/misc/machine_readable/fetch-machine-readable b/misc/machine_readable/fetch-machine-readable
index f905243..e815028 100755
--- a/misc/machine_readable/fetch-machine-readable
+++ b/misc/machine_readable/fetch-machine-readable
@@ -42,7 +42,7 @@ svn_checkout_machine_readable () {
TMPLIST=`mktemp`
svn list --verbose svn://localhost/$1 --recursive | \
grep -v -e '/tags/' -e '/branches/' -e '/patches/' | \
-grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" | \
+grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" -e "/upstream/metadata$" | \
sed 's/^.*[[:space:]]\([^[:space:]]\+\)/\1/' \
> $TMPLIST
# debug
@@ -78,31 +78,31 @@ svn_checkout_machine_readable () {
echo "Vcs-Svn: svn://svn.debian.org/$1/$vcslocation" > $TARGETDIR/$firstletter/${srcname}.vcs
echo "Vcs-Browser: http://svn.debian.org/wsvn/$1/$vcslocation"; >> $TARGETDIR/$firstletter/${srcname}.vcs
echo "Blend: `echo $1 | sed 's?/.*??'`" >> $TARGETDIR/$firstletter/${srcname}.vcs
- for file in control copyright upstream ; do
+ for file in control copyright upstream upstream/metadata ; do
+srcfile=${file#upstream/}
+destfile=${file%/metadata}
getfile=`grep -e "/$pkg/trunk/debian/$file$" -e "^$pkg/trunk/debian/$file$" -e "^$pkg/debian/$file$" -e "trunk/$pkg/debian/$file$" -e "/$pkg/[a-z]\+/trunk/debian/$file$" $TMPLIST 2>/dev/null`
if [ "" != "$getfile" ] ; then
svn export svn://localhost/$1/$getfile >/dev/null 2>/dev/null
- if [ -e $file ] ; then
-mv $file $TARGETDIR/$firstletter/${srcname}.$file
+ if [ -e $srcfile ] ; then
+mv $srcfile $TARGETDIR/$firstletter/${srcname}.$destfile
else
echo "ERR 1: Can not obtain file ${file} of source ${srcname} of team $1 from ${getfile}" >> $ERRLOG
fi
else
if ! `echo $vcslocation | grep -q trunk` ; then
-if [ "$file" != "upstream" ] ; then
+if [ "$destfile" != "upstream&
Bug#736711: uscan signing-key locations (was Re: Bug#736711: [lintian] pending)
On Fri, Jan 31, 2014 at 02:08:37PM -0800, bastien ROUCARIES wrote: > control: tag -1 + pending Not quite. Your changes to Nicolas' patch broke the support he was trying to add. The keyring can be located at either debian/upstream/signing-key.pgp or, as an armored keyring, at debian/upstream/signing-key.asc. The previous debian/upstream-signing-key.pgp location is still being checked by uscan in order to ease the transition to one of the two other locations. There's also some discussion about the creation of the debian/upstream/ directory conflicting with DEP-12 in #736760, which will hopefully be settled soon. It's still unclear whether that will result in changing the location of the keyrings (again). Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#737530: New version gives error in netrw
Control: tag -1 confirmed upstream Control: retitle -1 "Invalid register name: '*'" error with NetRW On Mon, Feb 03, 2014 at 03:39:42PM +0100, Klaus Ethgen wrote: > With the newest version netrw at least for scp is broken. When opening a > remote file I get the error: >"/tmp/vMnWZwB/0.pl" 22L, 328C >Fehler beim Ausführen von "function > netrw#Nread..netrw#NetRead..79_NetrwOptionRestore": >Zeile 69: >E354: Ungültiger Register Name: '*' > > Maybe that is a regression of #732091, I am not sure about. No, just a bug in new functionality NetRW introduced. I had seen the thread on the Vim mailing list about this. I forgot to check whether a fix had already made it into Vim, though. I'll update once that's happened. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build
On Mon, Feb 03, 2014 at 06:18:40PM +0400, Vitaliy Filippov wrote: > subversion build still depends on GCJ. I think OpenJDK should be used instead, > because GCJ is a very outdated compiler. Does the use of GCJ cause any actual problems? Is the OpenJDK jre unable to load the GCJ-built modules? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#736760: [Debian-med-packaging] debian/upstream vs. debian/upstream/signing-key.pgp
On Mon, Feb 03, 2014 at 09:48:43PM -0500, James McCoy wrote:
> On Sun, Feb 02, 2014 at 11:44:51AM +0900, Charles Plessy wrote:
> > Le Thu, Jan 30, 2014 at 05:06:22PM +0100, Andreas Tille a écrit :
> > > * working on the needed changes for UDD machine readable files gatherer
>
> Attached patch should allow that to work on both debian/upstream and
> debian/upstream/metadata, which is a name I've heard suggested and what
> first came to mind when the issue was initially raised.
Updated patch attached which fixes detection of debian/upstream/metadata
in git repositories.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
From b3019a7ee3632b8f670aae7dae12283d57560fff Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Mon, 3 Feb 2014 21:33:48 -0500
Subject: [PATCH] fetch-machine-readable: Support debian/upstream and
debian/upstream/metadata
---
misc/machine_readable/fetch-machine-readable | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff --git a/misc/machine_readable/fetch-machine-readable b/misc/machine_readable/fetch-machine-readable
index f905243..a0d1c8a 100755
--- a/misc/machine_readable/fetch-machine-readable
+++ b/misc/machine_readable/fetch-machine-readable
@@ -42,7 +42,7 @@ svn_checkout_machine_readable () {
TMPLIST=`mktemp`
svn list --verbose svn://localhost/$1 --recursive | \
grep -v -e '/tags/' -e '/branches/' -e '/patches/' | \
-grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" | \
+grep -e "/control$" -e "/changelog$" -e "/copyright$" -e "/upstream$" -e "/upstream/metadata$" | \
sed 's/^.*[[:space:]]\([^[:space:]]\+\)/\1/' \
> $TMPLIST
# debug
@@ -78,31 +78,31 @@ svn_checkout_machine_readable () {
echo "Vcs-Svn: svn://svn.debian.org/$1/$vcslocation" > $TARGETDIR/$firstletter/${srcname}.vcs
echo "Vcs-Browser: http://svn.debian.org/wsvn/$1/$vcslocation"; >> $TARGETDIR/$firstletter/${srcname}.vcs
echo "Blend: `echo $1 | sed 's?/.*??'`" >> $TARGETDIR/$firstletter/${srcname}.vcs
- for file in control copyright upstream ; do
+ for file in control copyright upstream upstream/metadata ; do
+srcfile=${file#upstream/}
+destfile=${file%/metadata}
getfile=`grep -e "/$pkg/trunk/debian/$file$" -e "^$pkg/trunk/debian/$file$" -e "^$pkg/debian/$file$" -e "trunk/$pkg/debian/$file$" -e "/$pkg/[a-z]\+/trunk/debian/$file$" $TMPLIST 2>/dev/null`
if [ "" != "$getfile" ] ; then
svn export svn://localhost/$1/$getfile >/dev/null 2>/dev/null
- if [ -e $file ] ; then
-mv $file $TARGETDIR/$firstletter/${srcname}.$file
+ if [ -e $srcfile ] ; then
+mv $srcfile $TARGETDIR/$firstletter/${srcname}.$destfile
else
echo "ERR 1: Can not obtain file ${file} of source ${srcname} of team $1 from ${getfile}" >> $ERRLOG
fi
else
if ! `echo $vcslocation | grep -q trunk` ; then
-if [ "$file" != "upstream" ] ; then
+if [ "$destfile" != "upstream" ] ; then
echo "Package $pkg is lacking trunk directory in vcslocation ${vcslocation}. Try to find file $file anyway." >> $ERRLOG
getfile=`grep -e "$vcslocation/debian/$file$" $TMPLIST 2>/dev/null`
if [ "" != "$getfile" ] ; then
svn export svn://localhost/$1/$getfile >/dev/null 2>/dev/null
-if [ -e $file ] ; then
- mv $file $TARGETDIR/$firstletter/${srcname}.$file
+if [ -e $srcfile ] ; then
+ mv $srcfile $TARGETDIR/$firstletter/${srcname}.$destfile
else
echo "ERR 2: Can not obtain file ${file} of source ${srcname} of team $1 from ${getfile}" >> $ERRLOG
fi
else
-if [ "$file" != "upstream" ] ; then
- echo "Did not found $file for package $pkg (`grep "$pkg" $TMPLIST | grep "$file"`)" >> $ERRLOG
-fi
+echo "Did not found $file for package $pkg (`grep "$pkg" $TMPLIST | grep "$file"`)" >> $ERRLOG
fi
fi
fi
@@ -135,8 +135,9 @@ git_checkout_machine_readable () {
echo "Vcs-Git: git://git.debian.org$1" > $TARGETDIR/$firstletter/${
Bug#736760: debian/upstream vs. debian/upstream/signing-key.pgp
On Fri, Feb 07, 2014 at 08:50:11AM +0100, Andreas Tille wrote: > thanks for your patch. While this is welcome I guess this is the least > of Charles' problems. I guess he was more concerned about the umegaya > package which probably needs some more love than the simple shell > script. We also need to fix the UDD importer (but this is similarly > easy to do like the patch you provided) and lintian check for upstream > metadata files. I'm willing to offer more help. > I keep on wondering if we are doing the right thing to not include > debian-devel into this discussion. I did -- <20140207044923.gf3...@cerberus.jamessan.com>. -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#737527: subversion: Replace GCJ by OpenJDK in Subversion JavaHL build
On Fri, Feb 07, 2014 at 12:30:43PM +0400, Vitaliy Filippov wrote: > >>subversion build still depends on GCJ. I think OpenJDK should be > >>used instead, > >>because GCJ is a very outdated compiler. > > > >Does the use of GCJ cause any actual problems? Is the OpenJDK jre > >unable to load the GCJ-built modules? > > No, of course not! I think you'd already know if it would :) > > But why do you use GCJ given that OpenJDK is available? Why do you request the use of OpenJDK given that GCJ is availale? :) > Are there > any special concerns that force svn to be built with GCJ? Peter provided his reasoning behind using GCJ in #710498. Seeing as using GCJ doesn't break anything and I don't have any compelling reasons to do otherwise, I've deferred to Peter's reasoning. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#681635: devscripts.conf handling
On Sun, Jul 15, 2012 at 12:03:49AM +0200, Christoph Anton Mitterer wrote: > devscripts.conf handling seems to be a bit weird to me... Indeed. > AFAICS, the file is not installed on new installations, right? It actually is. The code snippet you're referring to is if dpkg --compare-versions "$2" lt 2.6.90 && [ ! -f /etc/devscripts.conf ] then cp /usr/share/devscripts/conf.default /etc/devscripts.conf On a new installation $2 is empty, so the dpkg call succeeds, the check for a missing devscripts.conf succeeds, and the copy takes place. > And on installations where it already exists, it's manually extended by > added config file snippets. Yes, and I notice that the code which does that is missing various snippets for config variables that were added since 2.11.70. > Can't this be managed as configfile, or via ucf or so? Or is the intended way > now to remove it, if nothing was changed from the defaults. It's been like that for the entirety of history in git. The two reasons that come to mind would be - Lack of good tooling for handling conffile changes when devscripts.conf was introduced - devscripts.conf contains the version of devscripts that generated it The latter aspect means that the user would be prompted about changes on every upgrade. However, I think at least passable tooling existed in 2002 when devscripts.conf was introduced, so I'm not really sure why this approach was chosen. I'd be fine with changing how this is handled, but that needs some investigation on how to handle that transition. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#677270: devscripts: Please provide a standard way of repacking upstream tarballs
Control: forcemerge 685787 -1 On Thu, Jun 13, 2013 at 10:09:17PM +0200, gregor herrmann wrote: > On Tue, 12 Jun 2012 19:37:55 +0100, Nicholas Bamber wrote: > > >* What outcome did you expect instead? > > I would like someone from the devscripts maintainers to adopt the tool and > > do whatever might > > be needed to make it suitable for inclusion in devscripts. The > > documentation is availavble at > > http://pkg-perl.alioth.debian.org/howto/repacking.html. The code is > > available at > > http://anonscm.debian.org/gitweb/?p=pkg-perl/scripts.git;a=blob_plain;f=repack.sh;hb=HEAD > > version=3 . > > Should this be merged with #685787? I think so. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#726169: Add reference to Dpkg::Progress-Fancy in apt-get.8
Ping. This should be a simple change and will help people actually know how to setup the progress display. On Sat, Oct 12, 2013 at 08:49:25PM -0400, James McCoy wrote: > diff --git a/doc/apt-get.8.xml b/doc/apt-get.8.xml > index 4c050ec..1ece004 100644 > --- a/doc/apt-get.8.xml > +++ b/doc/apt-get.8.xml > @@ -526,7 +526,7 @@ > terminal window when packages are installed, upgraded or > removed. For a machine parsable version of this data see > README.progress-reporting in the apt doc directory. > - DpkgPM::Progress. > + Configuration Item: DpkgPM::Progress and > Dpkg::Progress-Fancy. > > > -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#683480: add a way detect the version number automatically
On Wed, Aug 01, 2012 at 03:24:57PM +0800, jida...@jidanni.org wrote: >found bug [version] >Indicate that a bug was found to exist in a particular package >version. > > Mention on the man page what happens if you don't give a version number, > and the point thereof. http://bugs.debian.org/ is the canonical source for documentation about the BTS. We will add a note about this bit, though. > Also give a way to detect the version number automatically, > sort of like aptitude forbid-version does. I'd rather not guess what the user wants to do here. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#731769: subversion: .svn/pristine size gets huge over time
On Thu, Dec 12, 2013 at 02:38:09AM +0100, Vincent Lefevre wrote: > On 2013-12-11 13:46:40 -0600, Peter Samuelson wrote: > > > > [Vincent Lefevre] > > > About (2), svn could warn the user when a cleanup could be needed. > > > I don't know what is the best solution. > > > > Right ... there's not really an obvious time for such a warning to be > > issued. > > This could also be announced in NEWS.Debian. I think Peter was referring to runtime notices that a cleanup might be useful "now", not a general notice that the pristine directories exist. That's already documented in the 1.7 release notes. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#732564: devscripts: Please consider dropping the cvs-* programs
On Wed, Dec 18, 2013 at 10:30:51PM +0200, Adrian Bunk wrote: > Please consider dropping these programs - I doubt that anyone is > still using CVS for maintaining Debian packages. $ grep-dctrl -FVcs-Cvs -sPackage -e . /var/lib/apt/lists/*_Sources | wc -l 25 This would disagree. Now whether or not they're using any of devscripts' CVS-related scripts is another, and more relevant, question. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#726483: console-tools fails to install
Control: reassign -1 src:sysvinit 2.88dsf-43
Control: retitle -1 service incorrectly handles console-screen.service
Control: affects console-tools -1
On Wed, Oct 16, 2013 at 09:50:15AM +0200, David Weinehall wrote:
> When upgrading to the latest version of console-tools, I received the
> following error message:
>
> Setting up console-tools (2:0.2.3-71) ...
> update-rc.d: warning: start and stop actions are no longer supported;
> falling back to defaults
> Failed to issue method call: Unit console-screen.sh.service failed to
> load: No such file or directory. See system logs and 'systemctl status
> console-screen.sh.service' for details.
“/etc/init.d/console-screen.sh start” works fine but neither “service
console-screen.sh start” nor the equivalent invoke-rc.d does.
The difference is that /lib/lsb/init-functions.d/40-systemd correctly
trims the .sh off the service name while service does not. The attached
patch addresses the issue in both service and invoke-rc.d
James
diff -Nru sysvinit-2.88dsf/debian/changelog sysvinit-2.88dsf/debian/changelog
--- sysvinit-2.88dsf/debian/changelog 2013-07-16 16:10:10.0 -0400
+++ sysvinit-2.88dsf/debian/changelog 2013-10-17 09:47:20.0 -0400
@@ -1,3 +1,12 @@
+sysvinit (2.88dsf-43.1) UNRELEASED; urgency=low
+
+ * Non-maintainer upload.
+ * sysv-rc:
+- Update invoke-rc.d and service to trim .sh from service names when
+ calling systemctl.
+
+ -- James McCoy Thu, 17 Oct 2013 09:42:55 -0400
+
sysvinit (2.88dsf-43) unstable; urgency=low
[ Roger Leigh ]
diff -Nru sysvinit-2.88dsf/debian/service/service sysvinit-2.88dsf/debian/service/service
--- sysvinit-2.88dsf/debian/service/service 2013-07-14 16:57:26.0 -0400
+++ sysvinit-2.88dsf/debian/service/service 2013-10-17 09:40:50.0 -0400
@@ -163,9 +163,10 @@
# systemctl calls.
if [ -n "$is_systemd" ]
then
+ UNIT="${SERVICE%.sh}.service"
case "${ACTION}" in
restart|status)
- exec systemctl ${ACTION} ${SERVICE}.service
+ exec systemctl ${ACTION} ${UNIT}
;;
start|stop)
# Follow the principle of least surprise for SysV people:
@@ -173,32 +174,32 @@
# has one or more .socket files, we also stop the .socket units.
# Users who need more control will use systemctl directly.
for unit in $(systemctl list-unit-files --full --type=socket 2>/dev/null | sed -ne 's/\.socket\s*[a-z]*\s*$/.socket/p'); do
- if [ "$(systemctl -p Triggers show $unit)" = "Triggers=${SERVICE}.service" ]; then
+ if [ "$(systemctl -p Triggers show $unit)" = "Triggers=${UNIT}" ]; then
systemctl ${ACTION} $unit
fi
done
- exec systemctl ${ACTION} ${SERVICE}.service
+ exec systemctl ${ACTION} ${UNIT}
;;
reload)
- _canreload="$(systemctl -p CanReload show ${SERVICE}.service 2>/dev/null)"
+ _canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
if [ "$_canreload" = "CanReload=no" ]; then
# The reload action falls back to the sysv init script just in case
# the systemd service file does not (yet) support reload for a
# specific service.
run_via_sysvinit
else
-exec systemctl reload "${SERVICE}.service"
+exec systemctl reload "${UNIT}"
fi
;;
force-stop)
- exec systemctl --signal=KILL kill "${SERVICE}.service"
+ exec systemctl --signal=KILL kill "${UNIT}"
;;
force-reload)
- _canreload="$(systemctl -p CanReload show ${SERVICE}.service 2>/dev/null)"
+ _canreload="$(systemctl -p CanReload show ${UNIT} 2>/dev/null)"
if [ "$_canreload" = "CanReload=no" ]; then
-exec systemctl restart "${SERVICE}.service"
+exec systemctl restart "${UNIT}"
else
-exec systemctl reload "${SERVICE}.service"
+exec systemctl reload "${UNIT}"
fi
;;
*)
diff -Nru sysvinit-2.88dsf/debian/src/sysv-rc/sbin/invoke-rc.d sysvinit-2.88dsf/debian/src/sysv-rc/sbin/invoke-rc.d
--- sysvinit-2.88dsf/debian/src/sysv-rc/sbin/invoke-rc.d 2013-07-14 16:57:26.0 -0400
+++ sysvinit-2.88dsf/debian/src/sysv-rc/sbin/invoke-rc.d 2013-10-17 09:42:46.0 -0400
@@ -276,6 +276,7 @@
is_upstart=1
elif test -d /run/systemd/system ; then
is_systemd=1
+UNIT="${INITSCRIPTID%.sh}.service"
elif test ! -f "${INITDPREFIX}${INITSCRIPTID}" ; then
## Verifies if the given initscript ID is known
## For sysvinit, this error is critical
@@ -390,7 +391,7 @@
if [ -n "$
Bug#726694: devscripts: FTBFS: Test failure
Control: clone -1 -2 Control: reassign -2 distro-info-data 0.16 Control: retitle -2 Update needed for Ubuntu releases Control: severity -2 normal On Thu, Oct 17, 2013 at 08:58:01PM -0700, Daniel Schepler wrote: > OK > ./test_debchange > testDebianDistributions > testDebianIncrement > testUbuntuIncrement > ASSERT:error output of perl -I ./.. ./../scripts/debchange.pl -c > /tmp/shunit.YruOw0/tmp/changelog --vendor Ubuntu -i "Version test." > expected:<> but was: for distro-info-data. See /usr/share/doc/distro-info-data/README.Debian for > details. at /usr/share/perl5/Debian/DistroInfo.pm line 130. As the output states, distro-info-data needs to be updated since there's a new Ubuntu release out. We can make dch (and its tests) more robust in this scenario, but the real fix is for a new distro-info-data to be made available. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#710498: subversion: enable java components on mips and mipsel
On Fri, May 31, 2013 at 08:28:21AM -0400, Harry Prevor wrote: > I've noticed as per the buildd logs that subversion is built on mips > and mipsel only with the --disable-java flag, while on all other > architectures it is not built with this flag. All other Debian-supported architectures. There are debian-ports.org architectures which are also blacklisted. > Considering java works fine on mips and mipsel, I'd like that build > flag to be removed for those architectures so packages like > libsvn-java (which a lot of packages, including NetBeans, depend on) > can be built. I'd tend to agree. mips(el) were blacklisted 7 years ago. It seems the Java implementations have made some progress since then. I ran test builds (using both gcj and openjdk) on eder.d.o and gabrielli.d.o, both of which ran fine. Peter, what do you think of a) dropping the arch blacklists for Java and b) changing from gcj-jdk to default-jdk? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#727082: apt: dist-upgrade says "no longer required" and "will be installed" for the same packages
On Tue, Oct 22, 2013 at 03:08:16PM +0200, David Kalnischkies wrote: > Hi, > > On Tue, Oct 22, 2013 at 8:08 AM, Ph. Marek wrote: > > $ LANG=C apt-get dist-upgrade > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > Calculating upgrade... The following packages were automatically installed > > and > > are no longer required: > > gir1.2-gstreamer-1.0 python3-enchant python3-gtkspellcheck > > Use 'apt-get autoremove' to remove them. > > Done > > This shows a "display bug" – there shouldn't be code printing stuff between > "Calculating upgrade…" and "Done", but it looks like the recent reshuffling of > code made it happen. Is this possibly another instance of the problem described in #726174? Cheers, -- James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#727222: virtualbox-guest-dkms: Accessing shared folders causes an infinite loop in readdir with Linux 3.11
Package: virtualbox-guest-dkms Version: 4.2.16-dfsg-3 Severity: normal Tags: patch upstream Forwarded: https://www.virtualbox.org/ticket/12128 Upstream has a patch to fix the issue -- https://www.virtualbox.org/changeset/48529/vbox It would be very useful to include this since shared folders are practically broken on 3.11 without it. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-1-486 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 virtualbox-guest-dkms depends on: ii dkms2.2.0.3-1.2 ii dpkg1.17.1 ii virtualbox-guest-utils 4.2.16-dfsg-3+b1 virtualbox-guest-dkms recommends no packages. virtualbox-guest-dkms 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#726694: It seems like really bad design to ahve a package fail because of the date it is built
On Oct 23, 2013 4:27 PM, "Lennart Sorensen" wrote: > > Why should the testsuit fail just because of the date you rebuild it? It shouldn't, which is what I and Benjamin reiterated earlier in the bug trail.
Bug#728054: missing versioned dependency on libsqlite3-0
Control: reassign -1 libsvn1 1.7.13-2 Control: forcemerge 721878 728054 On Sun, Oct 27, 2013 at 6:14 PM, Robert Millan wrote: > Package: subversion > Version: 1.7.13-2 > Severity: normal > > $ svn co https://some-url/ > [] > svn: E200029: Couldn't perform atomic initialization > svn: E200030: SQLite compiled for 3.8.0.2, but running with 3.7.13 > > Updating the libsqlite3-0 package fixed it. This is a known problem in that simply an SONAME isn't enough to declare the proper relationship against SQLite and Subversion upstream took the tack of requiring the same version it was built against. Debian currently has a patch that relaxes that to the same major version, but even that dependency can be too strong as seen here. Upstream subversion has relaxed this requirement in 1.8.x, which we should hopefully be able to upload in the somewhat near future. James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#685787: Praat has serious bug #713597
Thanks Rafael for the feedback and Andreas for continued patience. On Mon, Oct 28, 2013 at 10:10:00PM +0100, Andreas Tille wrote: > On Mon, Oct 28, 2013 at 07:44:57PM +0100, Rafael Laboissiere wrote: > > It would be preferable that you had created a side branch in the Git > > repository for your changes, such that the merge would be trivial to > > do. This really wouldn't have made much of a difference. It's trivial to add Andrea's repo as a remote and then the functionality is the same as if the branch were in devscripts' repo. At the time that Andreas started work on this, devscripts wasn't in collab-maint so it made sense to just push his changes to a user repo on Alioth so people could access and review the changes. > > It will also be necessary to prepare a qpatched versions for uscan.1 > > and debian/control. > > I'd happily provide this if I could be sure that this effort is not > wasted in a way that uscan in devscripts simply moves on and I need > to redo the patch later again. Some signal of devscripts maintainer > regarding this would be helpful. As stated before, we were originally waiting for the (longish) Wheezy freeze to finish and release. Since that has happened, there has been a lack of time available from existing maintainers. Your work is not wasted, though, since we can integrate your changes regardless of whether they've been rebased on a recent version of uscan. It's "just" a matter of time to review and merge. I will work on this within the next month. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#728177: debcommit -r with darcs fails if the repo is clean
On Tue, Oct 29, 2013 at 09:02:56AM +0100, Joachim Breitner wrote: > like with git, debcommit -r should only call “darcs record” if the repo > is not clean, otherwise it fails. Thanks for noticing and fixing. > I noticed that debscripts is now in collab-maint. Please let me know if > I should commit my patch myself. Sure, go ahead and commit. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#728198: devscripts: debuild (& others) must reject debian/rules actions on unpatched source trees
On Oct 29, 2013 12:30 PM, "Ximin Luo" wrote: > > Thinking about this some more, I'm leaning towards the opinion that this is more correctly devscripts problem. dpkg-buildpackage is quite a low-level tool I would disagree with that. dpkg-buildpackage is the standard tool to perform package builds. debuild is an intentionally thin wrapper around it, and we are trying to push for more of the functionality to live in dpkg-buildpackage (c.f., #476221). > However, (and correct me if I'm wrong), but debuild is a user-facing tool, so you do not have that excuse. There is no need for debuild to "behave similar to dpkg-buildpackage -T $target". Sure there is. dpkg-buildpackage's behavior is the interface that people should expect when running builds. This doesn't mean that debuild can't add functionality (like the log file and hook points) but the functionality should be enhancing, not replacing, dpkg-buildpackage's behavior. For another discussion of the behavior you're questioning, see #649531. Cheers, -- James
Bug#734672: pu: package subversion/1.6.17dfsg-4+deb7u5
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: pu
Subversion's transition to the non-versioned ruby-svn package didn't
make it into Wheezy. Since ruby1.8 is planning on being removed for
Jessie, the libsvn-ruby1.8 → ruby-svn transition should be backported to
Wheezy so there's an upgrade path to what will be Jessie's ruby-svn
(built with something other than ruby1.8) package.
In addition, libsvn-dev contains a broken /usr/lib/$arch/libsvnjavahl-1.so
symlink (#711911) which is trivial to fix.
The attached debdiff contains both of these changes. Does this seem
reasonable?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
diffstat for subversion_1.6.17dfsg-4+deb7u4 subversion_1.6.17dfsg-4+deb7u5
debian/libsvn-ruby1.8.install |2 --
debian/libsvn-ruby1.8.links |1 +
debian/libsvn-ruby1.8.lintian-overrides |2 --
debian/libsvn-ruby1.8.postinst | 12
debian/ruby-svn.install |2 ++
debian/ruby-svn.lintian-overrides |2 ++
subversion-1.6.17dfsg/debian/changelog |9 +
subversion-1.6.17dfsg/debian/control| 13 -
subversion-1.6.17dfsg/debian/rules |5 +++--
9 files changed, 37 insertions(+), 11 deletions(-)
diff -u subversion-1.6.17dfsg/debian/control subversion-1.6.17dfsg/debian/control
--- subversion-1.6.17dfsg/debian/control
+++ subversion-1.6.17dfsg/debian/control
@@ -100,7 +100,7 @@
Recommends: python-subversion (>= 1.5), libsvn-perl (>= 1.5),
libconfig-inifiles-perl, liburi-perl,
exim4 | mail-transport-agent, xsltproc, rsync
-Suggests: libsvn-ruby1.8
+Suggests: ruby-svn
Description: Assorted tools related to Subversion
This package includes miscellaneous tools for use with Subversion
clients and servers:
@@ -144,22 +144,25 @@
manipulates a Subversion repository or working copy. See the
'subversion' package for more information.
-Package: libsvn-ruby1.8
+Package: ruby-svn
Section: ruby
Architecture: any
Multi-Arch: same
Pre-Depends: multiarch-support
+Breaks: libsvn-ruby1.8 (<< 1.6.17dfsg-4+deb7u5)
Depends: ruby1.8, ${shlibs:Depends}, ${misc:Depends}
+Replaces: libsvn-ruby1.8 (<< 1.6.17dfsg-4+deb7u5)
Description: Ruby bindings for Subversion
This is a set of Ruby interfaces to libsvn, the Subversion libraries.
It is useful if you want to, for example, write a Ruby script that
manipulates a Subversion repository or working copy. See the
'subversion' package for more information.
-Package: libsvn-ruby
-Section: ruby
+Package: libsvn-ruby1.8
+Section: oldlibs
+Priority: extra
Architecture: all
-Depends: libsvn-ruby1.8, ${misc:Depends}
+Depends: ruby-svn, ${misc:Depends}
Description: Ruby bindings for Subversion (dummy package)
This is a dummy package to install the Subversion library bindings for
the default version of Ruby.
reverted:
--- subversion-1.6.17dfsg/debian/libsvn-ruby1.8.lintian-overrides
+++ subversion-1.6.17dfsg.orig/debian/libsvn-ruby1.8.lintian-overrides
@@ -1,2 +0,0 @@
-# nobody but us will ever link to this, so we don't ship a shlibs file
-no-shlibs-control-file usr/lib/*/libsvn_swig_ruby-1.so.*
diff -u subversion-1.6.17dfsg/debian/rules subversion-1.6.17dfsg/debian/rules
--- subversion-1.6.17dfsg/debian/rules
+++ subversion-1.6.17dfsg/debian/rules
@@ -118,7 +118,7 @@
rb_defs := SWIG_RB_SITE_LIB_DIR=$(shell $(RUBY) -rrbconfig -e "print RbConfig::CONFIG['vendordir']")
rb_defs += SWIG_RB_SITE_ARCH_DIR=$(shell $(RUBY) -rrbconfig -e "print RbConfig::CONFIG['vendorarchdir']")
else
- DH_OPTIONS += -Nlibsvn-ruby -Nlibsvn-$(RUBY)
+ DH_OPTIONS += -Nruby-svn -Nlibsvn-$(RUBY)
RUBY := fooby
endif
@@ -346,13 +346,14 @@
cd debian/tmp/$(libdir); for lib in ra fs auth swig; do \
$(RM) libsvn_$${lib}_*.so libsvn_$${lib}_*.la; \
done
- cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl.a libsvnjavahl.la
+ cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl-1.a libsvnjavahl-1.la
# Intermediate hack, until we can remove the rest of the .la files.
sed -i "/dependency_libs/s/=.*/=''/" debian/tmp/$(libdir)/*.la
dh_install -s
ifdef DEB_OPT_WITH_JAVAHL
mkdir -p debian/libsvn-java/$(libdir)
mv debian/libsvn-java/usr/lib/jni debian/libsvn-java/$(libdir)/
+ $(RM) debian/libsvn-dev/$(libdir)/libsvnjavahl-1.so
endif
ln -s libsvn_ra_neon-1.so.1 debian/libsvn1/$(libdir)/libsvn_ra_dav-1.so.1
reverted:
--- subversion-1.6.17dfsg/debian/libsvn-ruby1.8.install
+++ subversion-1.6.17dfsg.orig/debian/libsvn-ruby1.8.install
@@ -1,2 +0,0 @@
-debian/tmp/usr/lib/*/libsvn_swig_ruby*.so.*
-debian/tmp/usr/lib/ruby
diff -u subversion-1.6.17dfsg/debian/changelog subversion-1.6.17dfsg/debian/changelog
--- subversion-1.6.17dfsg/debian/changelog
+++ subversion-1.6.17dfsg/debian/changelog
@@ -1,3 +1,12 @@
+sub
Bug#735840: Please allow binary file debian/upstream-signing-key.pgp by default
On Fri, Jan 17, 2014 at 09:48:27PM +0100, Artur R. Czechowski wrote: > For some time the debian/watch configuration file provides a way to verify > the pgp signature of upstream sources. It requires a keyring file put in > debian/ subdirectory. It result wit a following error: > dpkg-source: error: unwanted binary file: debian/upstream-signing-key.pgp > anytime the dpkg-source is run. For what it's worth, I intend to address #720957 (allow armored keyrings) soon to allow using this functionality with 1.0 source packages, but this would also address the warning. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729022: libgcj14: File conflict between libgcj14 and gcj-4.8-jre-headless
Package: libgcj14,gcj-4.8-jre-headless Version: 4.8.2-2 Severity: serious Justification: Policy 7.6.1 In version 4.8.2-2, libgcj14 gained /usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre/lib/security/java.security which is also shipped in gcj-4.8-jre-headless: Unpacking gcj-4.8-jre-headless (from .../gcj-4.8-jre-headless_4.8.2-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/gcj-4.8-jre-headless_4.8.2-2_amd64.deb (--unpack): trying to overwrite '/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre/lib/security/java.security', which is also in package libgcj14:amd64 4.8.2-2 -- 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.10-3-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages libgcj14 depends on: ii gcc-4.8-base 4.8.2-1 ii libasound2 1.0.27.2-3 ii libc6 2.17-93 ii libgcc11:4.8.2-1 ii libgcj-common 1:4.8.1-3 ii libgmp10 2:5.1.2+dfsg-3 ii multiarch-support 2.17-93 ii zlib1g 1:1.2.8.dfsg-1 Versions of packages libgcj14 recommends: ii gcj-4.8-jre-lib 4.8.2-2 Versions of packages libgcj14 suggests: ii libgcj14-awt 4.8.2-1 pn libgcj14-dbg -- 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#729022: libgcj14: File conflict between libgcj14 and gcj-4.8-jre-headless
On Fri, Nov 08, 2013 at 01:45:49AM +0100, Matthias Klose wrote: > Control: tag -1 + moreinfo help What more information do you need? gcj-4.8-jre-headless Depends on libgcj14. From libgcj14 4.8.2-1 to 4.8.2-2, libgcj14 gained a file that was already in gcj-4.8-jre-headless. > Am 08.11.2013 00:56, schrieb James McCoy: > > Package: libgcj14,gcj-4.8-jre-headless > > Version: 4.8.2-2 > > Severity: serious > > Justification: Policy 7.6.1 > > > > In version 4.8.2-2, libgcj14 gained > > /usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre/lib/security/java.security > > which is also shipped in gcj-4.8-jre-headless: > > > > Unpacking gcj-4.8-jre-headless (from > > .../gcj-4.8-jre-headless_4.8.2-2_amd64.deb) ... > > dpkg: error processing > > /var/cache/apt/archives/gcj-4.8-jre-headless_4.8.2-2_amd64.deb (--unpack): > > trying to overwrite > > '/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre/lib/security/java.security', > > which is also in package libgcj14:amd64 4.8.2-2 > > patch? Undo whatever caused that file to get added to libgcj14 or move the file completely to libgcj14? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729022: libgcj14: File conflict between libgcj14 and gcj-4.8-jre-headless
On Sun, Nov 10, 2013 at 11:45:51AM +0100, Rémi Vanicat wrote: > James McCoy writes: > > > On Fri, Nov 08, 2013 at 01:45:49AM +0100, Matthias Klose wrote: > >> Control: tag -1 + moreinfo help > > > > > What more information do you need? gcj-4.8-jre-headless Depends on > > libgcj14. From libgcj14 4.8.2-1 to 4.8.2-2, libgcj14 gained a file that > > was already in gcj-4.8-jre-headless. > > Removing gcj-4.8-jre-headless have solved the problem for me. That's not really an option when one wants gcj-4.8-jdk installed. > [...] > > >> patch? > > > > Undo whatever caused that file to get added to libgcj14 or move the file > > completely to libgcj14? > > May be add a conflict in libgcj14 with gcj-4.8-jre-headless. That would then make gcj-4.8-jdk uninstallable since it Depends on both the gcj-4.8-jre and libgcj14. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729426: Tighten versioned dependency on SQLite3
On Tue, Nov 12, 2013 at 03:27:07PM -0600, Peter Samuelson wrote: > [Wouter Bolsterlee] > > svn: E200029: Couldn't perform atomic initialization > > svn: E200030: SQLite compiled for 3.8.0.2, but running with > > 3.7.13 > > Thanks. The problem is that there's 3 different opinions on this > dependency, and none of them match: > > (1) sqlite3 shlibs and symbols files; > > (2) The configure + build process detects SQLite features and optimizes > the build to use whatever features it knows it can rely on; > > (3) To be on the safe side, as it were, libsvn1 does a runtime check to > make sure the SQLite version is at least as recent as the one it was > built with. (That's the error you see above.) > > So the problem is that what we need is (2), but what we actually get is > (1) which is unsafe because it is not strict enough, and (3) which is > too strict. At some point I patched (3) so it only cares about > 'major.minor' rather than 'major.minor.patch', but as you can see, that > is still too strict. Upstream 1.8.x has changed to allow specifying the minimum supported SQLite version as an argument to configure, so we could set that to max(stable's SQLite, minimum version SVN requires) and update the (Build-)Depends appropriately. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#725787: subversion: Please package major new upstream release 1.8
On Tue, Oct 08, 2013 at 01:26:39PM +0200, Thiemo Nagel wrote: > could you please be so kind to package the 1.8 upstream version? Once a new serf has been uploaded (which is required for svn 1.8), I'll work on getting 1.8 uploaded. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729779: devscripts: Does not report bugs in source packages
Control: tag -1 moreinfo Control: severity -1 normal On Sun, Nov 17, 2013 at 09:41:28AM +, Mark Brown wrote: > When I run rc-alert on my system which I know has some packages with RC > bugs it does not report anything. $ rc-alert | grep ^Bug | wc -l 185 > The same applies if one of the RC > buggy packages is explicitly selected on the command line. For example, > "rc-alert clc-intercal" does not report any bugs even though there is a > a bug against the source pacakge. $ rc-alert clc-intercal Package: src:clc-intercal Bug: 723960 Title: clc-intercal: FTBFS with perl 5.18: Invalid object - did not provide a type Flags: [] (none) Dists: [U] (unstable) Not sure what's different on your end. Are you familiar enough with Perl to step through the debugger and see where things are going wrong? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729779: devscripts: Does not report bugs in source packages
On Sun, Nov 17, 2013 at 12:50:21PM +, Mark Brown wrote: > On Sun, Nov 17, 2013 at 07:44:03AM -0500, James McCoy wrote: > > > Not sure what's different on your end. Are you familiar enough with > > Perl to step through the debugger and see where things are going wrong? > > No, I don't really understand perl at all. I *suspect* as I'm on a slow > network with some sort of transparent proxy that this is poor error > handling for zero length stuff coming back from the network or other > errors but I'm just guessing and there are no perceptible diagnostics. Well, we're basically just running wget -q -O - http://bugs.debian.org/release-critical/other/all.html and then parsing the output. Could you run that (redirected to a file), see if wget shows any errors, and attach the file? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#729779: devscripts: Does not report bugs in source packages
On Mon, Nov 18, 2013 at 11:13:33AM +, Mark Brown wrote: > On Sun, Nov 17, 2013 at 02:36:48PM -0500, James McCoy wrote: > > > Well, we're basically just running > > > wget -q -O - http://bugs.debian.org/release-critical/other/all.html > > > and then parsing the output. Could you run that (redirected to a file), > > see if wget shows any errors, and attach the file? > > No errors, file attached. Thanks. Looks like the proxy is reformatting the HTML, which confused the parsing. Easy to fix. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#728752: [getbuildlog] get compressed buildlogs
On Mon, Nov 04, 2013 at 10:12:45PM -0300, Lisandro Damián Nicanor Pérez Meyer wrote: > Since gcc became mor everbose on it builds it's not strange to find enourmous > build logs (200+MB). > > It would be really cool if getbuildlog could get the compressed buildlog > to save bandwith. As far as I know, there isn't a "compressed buildlog" available. We could change our wget call to specify "Accept-Encoding: deflate, gzip" but that relies on the server being configured to offer compression. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#730127: libclang1-3.3: trying to overwrite '/usr/lib/llvm-3.3/lib/libclang.so.1', which is also in package libclang1 1:3.3~svn179851-1~exp1
Package: libclang1-3.3 Version: 1:3.3-13 Severity: serious Justification: Policy 7.6.1 Selecting previously unselected package libclang1-3.3:i386. Unpacking libclang1-3.3:i386 (from .../libclang1-3.3_1%3a3.3-13_i386.deb) ... dpkg: error processing /var/cache/apt/archives/libclang1-3.3_1%3a3.3-13_i386.deb (--unpack): trying to overwrite '/usr/lib/llvm-3.3/lib/libclang.so.1', which is also in package libclang1 1:3.3~svn179851-1~exp1 Preparing to replace libclang1 1:3.3~svn179851-1~exp1 (using .../libclang1_1%3a3.3-21~exp1_i386.deb) ... Unpacking replacement libclang1:i386 ... Processing triggers for install-info ... Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/libclang1-3.3_1%3a3.3-13_i386.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Is libclang1-3.3 missing Breaks/Replaces on libclang1? -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.11-2-486 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 libclang1-3.3 depends on: ii libc6 2.17-96 iu libffi63.0.13-6 ii libgcc-4.8-dev 4.8.2-5 ii libgcc11:4.8.2-5 ii libllvm3.3 1:3.3-13 ii libobjc-4.8-dev4.8.2-5 ii libstdc++-4.8-dev 4.8.2-5 ii libstdc++6 4.8.2-5 ii multiarch-support 2.17-96 libclang1-3.3 recommends no packages. libclang1-3.3 suggests no packages. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#730438: UDD: bugs.cgi confused: lists bugs as affecting sid even if the package has been removed
On Mon, Nov 25, 2013 at 03:13:51AM +0100, Andreas Beckmann wrote: > UDD seems be be a bit confused about some bugs, too: > query for closed bugs affecting sid (all bugs), and you will find > several kfreebsd-8 bugs there, e.g. #725575 > but kfreebsd-8 has been removed from jessie and sid ... > Maybe the sid and jessie tags add to the confusion, but they are needed. Isn't this due to debian-installer-7.0-netboot-kfreebsd-* referencing kfreebsd-8 from their Built-Using field? This means the source for kfreebsd-8 is still part of sid: $ rmadison kfreebsd-8 kfreebsd-8 | 8.1+dfsg-8+squeeze3 | squeeze-security | source kfreebsd-8 | 8.1+dfsg-8+squeeze4 | squeeze | source kfreebsd-8 | 8.2-15~bpo60+1 | squeeze-backports | source kfreebsd-8 | 8.3-6 | wheezy| source Cheers, -- James -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#486594: timestamps
On Sat, Nov 30, 2013 at 11:47:15PM +0100, Louis Bettens wrote:
> Good evening developers,
> I'm a novice contributor and I have done some work on your scripts,
> which I would like to submit to you.
Thanks for your effort!
> I didn't found any library that can produce d/changelog files, so I
> decided to invoke dch with the right options, besides it can manage
> multi-maintainer releases, and since this feature is hardcoded, I
> thought there was no library supporting it at all. I needed to
> create entries with specific timestamps, so I started hacking dch to
> implement an option for that.
An alternative would be to use the faketime[0] tool to wrap your dch
calls.
[0]: http://packages.debian.org/sid/faketime
> Since there seems to be no way to feed a "%s" value to date, I
> decided to use strftime(), and thus get rid of the date -R
> invocation. It seems to me that globally setting the locale to "C"
> doesn't cause trouble ("dch Ìnîtíãl release." is fine) but I may be
> wrong. However, there could be a better solution with the
> Email::Date::Format package ; it takes care of formatting time
> according to RFC 2822 and doesn't touch the locale. It does exactly
> what we want in a clean way, so it's probably worth depending on it.
That does look useful, but if there aren't any side effects to setting
LC_TIME, I'd prefer that over adding a dependency. It's still simple
enough code.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Bug#486594: timestamps
On Sun, Dec 01, 2013 at 10:57:30AM +, Julian Gilbey wrote:
> On Sun, Dec 01, 2013 at 12:00:51AM -0500, James McCoy wrote:
> > > Since there seems to be no way to feed a "%s" value to date, I
> > > decided to use strftime(), and thus get rid of the date -R
> > > invocation. It seems to me that globally setting the locale to "C"
> > > doesn't cause trouble ("dch Ìnîtíãl release." is fine) but I may be
> > > wrong. However, there could be a better solution with the
> > > Email::Date::Format package ; it takes care of formatting time
> > > according to RFC 2822 and doesn't touch the locale. It does exactly
> > > what we want in a clean way, so it's probably worth depending on it.
> >
> > That does look useful, but if there aren't any side effects to setting
> > LC_TIME, I'd prefer that over adding a dependency. It's still simple
> > enough code.
>
> I personally prefer the locale-aware dates in the changelog: when I
> look at my own changelogs, I sometimes want to know when I wrote them;
This suggested change only ensures the text is in English. It doesn't
change what timezone is reported for the timestamp.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Bug#731101: dak/process_upload.py: handle an urgency with a comment
Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: dak
Tags: patch
Please consider the attached patch.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
From 482723d951ca6e877474d2c08ec777dc7b6c9cea Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Sun, 1 Dec 2013 20:29:15 -0500
Subject: [PATCH] dak/process_upload.py: handle an urgency with a comment
Policy allows a changes file's urgency to have a trailing comment
(separated by a space). If such a comment exists, the urgency needs to
be extracted so it is properly parsed. This ensures the urgency is
propagated properly.
Signed-off-by: James McCoy
---
dak/process_upload.py | 4
1 file changed, 4 insertions(+)
diff --git a/dak/process_upload.py b/dak/process_upload.py
index 1518d26..797df4e 100755
--- a/dak/process_upload.py
+++ b/dak/process_upload.py
@@ -273,6 +273,10 @@ def accept(directory, upload):
control = upload.changes.changes
if sourceful_upload and not Options['No-Action']:
urgency = control.get('Urgency')
+# As per policy 5.6.17, the urgency can be followed by a space and a
+# comment. Extract only the urgency from the string.
+if ' ' in urgency:
+ (urgency, comment) = urgency.split(' ', 1)
if urgency not in cnf.value_list('Urgency::Valid'):
urgency = cnf['Urgency::Default']
UrgencyLog().log(control['Source'], control['Version'], urgency)
--
1.8.5.rc3
signature.asc
Description: Digital signature
Bug#731101: dak/process_upload.py: handle an urgency with a comment
On Sun, Dec 01, 2013 at 08:52:19PM -0500, James McCoy wrote:
> Please consider the attached patch.
Updated patch which also changes dak/process_policy.py.
I didn't touch daklib/changes.py's add_known_changes since it seemed
like the original data should be preserved in the db. That may mean
other tools need to perform checks similar to what is being done in my
patch, though.
If eliding the comment in the db is appropriate, then would it be
simpler to just change the value of the urgency in daklib/upload.py's
Changes class?
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
From 7d4dec85efd7d05bf114ab37a2b1fd2b09ee4527 Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Sun, 1 Dec 2013 20:29:15 -0500
Subject: [PATCH] dak/process_{upload,policy}.py: handle an urgency with a
comment
Policy allows a changes file's urgency to have a trailing comment
(separated by a space). If such a comment exists, the urgency needs to
be extracted so it is properly parsed. This ensures the urgency is
propagated properly.
Signed-off-by: James McCoy
---
dak/process_policy.py | 4
dak/process_upload.py | 4
2 files changed, 8 insertions(+)
diff --git a/dak/process_policy.py b/dak/process_policy.py
index 7dd55a8..39fa62e 100755
--- a/dak/process_policy.py
+++ b/dak/process_policy.py
@@ -185,6 +185,10 @@ def comment_accept(upload, srcqueue, comments, transaction):
if upload.source is not None and not Options['No-Action']:
urgency = upload.changes.urgency
+# As per policy 5.6.17, the urgency can be followed by a space and a
+# comment. Extract only the urgency from the string.
+if ' ' in urgency:
+ (urgency, comment) = urgency.split(' ', 1)
if urgency not in cnf.value_list('Urgency::Valid'):
urgency = cnf['Urgency::Default']
UrgencyLog().log(upload.source.source, upload.source.version, urgency)
diff --git a/dak/process_upload.py b/dak/process_upload.py
index 1518d26..797df4e 100755
--- a/dak/process_upload.py
+++ b/dak/process_upload.py
@@ -273,6 +273,10 @@ def accept(directory, upload):
control = upload.changes.changes
if sourceful_upload and not Options['No-Action']:
urgency = control.get('Urgency')
+# As per policy 5.6.17, the urgency can be followed by a space and a
+# comment. Extract only the urgency from the string.
+if ' ' in urgency:
+ (urgency, comment) = urgency.split(' ', 1)
if urgency not in cnf.value_list('Urgency::Valid'):
urgency = cnf['Urgency::Default']
UrgencyLog().log(control['Source'], control['Version'], urgency)
--
1.8.5.rc3
signature.asc
Description: Digital signature
Bug#680624: vim-addon-manager - Create stuff in /var/lib/vim unreadable for users
Control: clone -1 -2
Control: severity -2 normal
Control: retitle -2 Honor root's umask when performing root-user (not system)
actions
On Mon, Jul 16, 2012 at 09:50:41PM -0300, Antonio Terceiro wrote:
> James McCoy escreveu isso aí:
> > On Sat, Jul 07, 2012 at 02:53:13PM +0200, Bastian Blank wrote:
> > > vim-addons respects umask a bit too much. It creates anything in
> > > /var/lib/vim, aka for any user, respecting the umask of the calling
> > > process, 027 in my case. So no user can read the stuff.
> >
> > Attached patch uses a specific mode when installing an addon as root.
> >
> > However, this doesn't correctly handle the case of an actual root user
> > installing addons for themself. This would be better handled by
> > tracking whether it's a "system" install or not, instead of an install
> > being performed by root.
>
> Right. I can't think ATM of a way to get that information ("is this a
> system-wide install?") available in a sane way down to the addon level
> without a major refactoring of the code ... :-/
Ok, I'm creating a separate issue to track detecting that difference and
I'll push my proposed fix for the original issue shortly.
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Bug#752314: Unknown Option: balloonexpr
On Sun, Jun 22, 2014 at 02:34:06PM +0100, Klaus Ethgen wrote: > With the newest version I get often the error "E518: Unbekannte Option: > balloonexpr=" (Unknown option) when using views. > > --- real paths of main Vim binaries --- > /usr/bin/vi is /usr/bin/vim.nox > /usr/bin/vim is /usr/bin/vim.nox > /usr/bin/gvim is /usr/bin/vim.gtk That's because your vim alternative is pointing to vim.nox. The balloon eval feature is only included in Vim builds that have GUI support. When you load a view in vim.nox with 'balloonexpr' set (from a gvim run), it complains because that's not an option that's available in vim.nox. You can remove "options" from the 'viewoptions' option to avoid caching mappings/options in the view file. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752314: Unknown Option: balloonexpr
On Sat, Jun 28, 2014 at 05:44:25PM +0100, Klaus Ethgen wrote: > Hello, > > Am Sa den 28. Jun 2014 um 17:17 schrieb James McCoy: > > On Sun, Jun 22, 2014 at 02:34:06PM +0100, Klaus Ethgen wrote: > > > With the newest version I get often the error "E518: Unbekannte Option: > > > balloonexpr=" (Unknown option) when using views. > > > > > > --- real paths of main Vim binaries --- > > > /usr/bin/vi is /usr/bin/vim.nox > > > /usr/bin/vim is /usr/bin/vim.nox > > > /usr/bin/gvim is /usr/bin/vim.gtk > > > > That's because your vim alternative is pointing to vim.nox. The balloon > > eval feature is only included in Vim builds that have GUI support. > > > > When you load a view in vim.nox with 'balloonexpr' set (from a gvim > > run), it complains because that's not an option that's available in > > vim.nox. > > I never changed this setting while upgrading vim: >~> ls -l /etc/alternatives/vim >lrwxrwxrwx 1 root root 16 Oct 20 2013 /etc/alternatives/vim -> > /usr/bin/vim.nox > > and I never ever use gvim. So this really has changed in that version > and was working before. No, it hasn't worked in vim-nox before. I've checked all previous uploads and the source. The 'balloonexpr' functionality requires a gvim build. Since you have vim-gtk installed, that should be used for all the alternatives that the Vim packages define, so I'd guess that the vi and vim alternatives are in manual mode instead of auto mode. “update-alternatives --display vim” will confirm that. > > You can remove "options" from the 'viewoptions' option to avoid caching > > mappings/options in the view file. > > That is no solution as it removes all local set options from the view > file. > > Proper behaviour would be to ignore that setting if it is set to empty > value in view. Why would that be proper behavior? If the option is set to a non-empty value in your vimrc, plugin, etc. but at the time the view was created the option was empty, then that's relevant for restoring the view and therefore should be saved in the view file. Vim explicitly leaves options out of the view file if they don't have a buffer/window-local value set and are at their default value. That means that when your view was created, there was a buffer-local value set for 'bexpr'. The problem is purely that the view was created with a vim build that had different capabilities than the vim you're trying to restore the view with. That is something you should be informed of because that means the view is not being faithfully restored. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#752914: ml-lpt: man page for ml-ulex cites the wrong PDF
On Fri, Jun 27, 2014 at 02:15:20PM -0400, Norman Ramsey wrote: > The man page for ml-ulex says: > >SEE ALSO >sml(1), ml-antlr(1), ml-lex(1), ml-yacc(1). >The programs are documented fully by CM: The SML/NJ Compilation and >Library Manager, User Manual, Matthias Blume, which is available via ><http://cm.bell-labs.com/cm/cs/what/smlnj/doc/CM/new.pdf>. > > The CM manual is not the place to look for documentation of ml-antlr > and ml-lex. Thanks for the notice. I'll fix that. > It would be good if the correct documentation (SML/NJ > Language Processing Tools: User Guid) were built as PDF and included > in /usr/share/doc/ml-lpt. It turns out the packaging is supposed to be shipping an smlnj-doc package which would have contained this, but there were some bugs preventing that package from ever being built. Thanks for causing me to notice this. :) I'll have both of these fixed soon. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#753076: UDD/ftpnew: Various packages missing
Package: qa.debian.org Severity: normal User: qa.debian@packages.debian.org Usertags: udd Not all of the packages from the NEW queue are showing up in UDD's tables. This affects rmadison/madison.cgi's information with respect to the affected packages. As a simple example, pyjamas has been in NEW for a few months: $ curl https://ftp-master.debian.org/new.822 2>/dev/null | grep-dctrl -FSource pyjamas Source: pyjamas Binary: pyjamas-pyjs, pyjamas-ui, pyjamas-gmap, pyjamas-canvas, pyjamas-doc, pyjamas, pyjamas-gchart Version: 0.8.1 Architectures: source, all Age: 3 months Last-Modified: 1395106402 Queue: new Maintainer: Luke Kenneth Casson Leighton Changed-By: lkcl Sponsored-By: ph...@debian.org Distribution: unstable Fingerprint: DFF1415ACE3227FCF20707D6D04BA3A00125D5C0 Closes: #710033 Changes-File: pyjamas_0.8.1_amd64.changes However it doesn't show up in UDD: $ rmadison -u new pyjamas $ -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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#753080: blhc: False positives when compiling Python files
Package: blhc
Version: 0.04+20130814+gitd569fff-1
Severity: normal
Tags: patch
% blhc ~/.cache/sbuild/logs/subversion_1.8.9-2_amd64-20140601-2135.build
NONVERBOSE BUILD: Compiling
/«PKGBUILDDIR»/debian/tmp/usr/lib/python2.7/dist-packages/libsvn/__init__.py ...
NONVERBOSE BUILD: Compiling
/«PKGBUILDDIR»/debian/tmp/usr/lib/python2.7/dist-packages/libsvn/client.py ...
The attached patch finishes the previous attempt (#714630) at fixing
these false positives.
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.14-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages blhc depends on:
ii libdpkg-perl 1.17.10
blhc recommends no packages.
blhc suggests no packages.
-- no debconf information
>From bb0d8f93123feb6d9ea80e7edf0e612c8ac569ca Mon Sep 17 00:00:00 2001
From: James McCoy
Date: Sat, 28 Jun 2014 23:26:23 -0400
Subject: [PATCH] Fix false positive when "compiling" python files
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Allow whitespace between the filename and the following “...” or end of
line.
Signed-off-by: James McCoy
---
bin/blhc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/bin/blhc b/bin/blhc
index 2624585..72918fe 100755
--- a/bin/blhc
+++ b/bin/blhc
@@ -466,7 +466,7 @@ sub is_non_verbose_build {
return 0 if $line =~ /^\s*C\+\+.+?:\s+(?:yes|no)\s*$/;
return 0 if $line =~ /^\s*C\+\+ Library: stdc\+\+$/;
# "Compiling" non binary files.
-return 0 if $line =~ /^\s*Compiling \S+\.(?:py|el)['"]?(?:\.\.\.)?$/;
+return 0 if $line =~ /^\s*Compiling \S+\.(?:py|el)['"]?\s*(?:\.\.\.)?$/;
# "Compiling" with no file name.
if ($line =~ /^\s*[Cc]ompiling\s+(.+?)(?:\.\.\.)?$/) {
# $file_extension_regex may need spaces around the filename.
--
2.0.0
Bug#745452: apt: Consistently use Dpkg::Progress* in documentation
Package: apt Version: 1.0.1 Severity: minor Dear Maintainer, Apt's documentation refers to DpkgPM::Progress, Dpkg::Progress-Fancy, and DpkgPM::Progress-Fancy. DpkgPM::Progress was renamed to Dpkg::Progress in 6c5ae8ed, although the former is still understood for backwards-compatibility, and DpkgPM::Progress-Fancy was renamed to Dpkg::Progress-Fancy in 1c6089d7. The attached patch updates the documentation to consistently use the Dpkg:: variants of the options. -- Package-specific info: -- (no /etc/apt/preferences present) -- -- (/etc/apt/sources.list present, but not submitted) -- -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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 apt depends on: ii debian-archive-keyring 2012.4 ii gnupg 1.4.16-1.1 ii libapt-pkg4.12 1.0.1 ii libc6 2.18-4 ii libgcc1 1:4.9-20140411-2 ii libstdc++6 4.9-20140411-2 apt recommends no packages. Versions of packages apt suggests: pn apt-doc ii aptitude0.6.10-1 ii dpkg-dev1.17.6 ii python-apt 0.9.3.5 -- no debconf information >From 10bc7148eedba84b237b3b91b41f97dc5596db80 Mon Sep 17 00:00:00 2001 From: James McCoy Date: Mon, 21 Apr 2014 16:35:28 -0400 Subject: [PATCH] Consistently use Dpkg::Progress* in documentation Signed-off-by: James McCoy --- doc/apt-get.8.xml | 2 +- doc/apt.8.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/apt-get.8.xml b/doc/apt-get.8.xml index 1ed0890..a3bfc33 100644 --- a/doc/apt-get.8.xml +++ b/doc/apt-get.8.xml @@ -536,7 +536,7 @@ terminal window when packages are installed, upgraded or removed. For a machine parsable version of this data see README.progress-reporting in the apt doc directory. - Configuration Item: DpkgPM::Progress and Dpkg::Progress-Fancy. + Configuration Item: Dpkg::Progress and Dpkg::Progress-Fancy. diff --git a/doc/apt.8.xml b/doc/apt.8.xml index 85e7276..bcad5ee 100644 --- a/doc/apt.8.xml +++ b/doc/apt.8.xml @@ -148,7 +148,7 @@ - The option DPkgPM::Progress-Fancy is enabled. + The option DPkg::Progress-Fancy is enabled. -- 1.9.2
Bug#530580: debcheckout: option to use git-svn instead of svn
On Mon, Apr 21, 2014 at 09:43:00PM +0100, Steve Cotton wrote:
> Are there any changes that would make this feature patch more
> likely to be accepted?
Specifying the alternative tool to use should be done like rmadison
handles URLs. Something like
DEBCHECKOUT_ALTERNATE_TOOL_SVN=git-svn …
The value should likely be run through Text::ParseWords' shellwords
function to translate it into an array that we can use to run the
command.
> Particularly, do you want the separate
> whitespace-cleanup patch to be dropped?
Yes, because the whitespace is consistent with our code base.
Indentation is expected to be 4-columns where multiples of 8 are tabs
and spaces otherwise ("set tabstop=8 shiftwidth=4 noexpandtab" in Vim
terms).
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745452: apt: Consistently use Dpkg::Progress* in documentation
On Mon, Apr 21, 2014 at 04:54:04PM -0400, James McCoy wrote: > The attached patch updates the documentation to consistently use the > Dpkg:: variants of the options. This will also fix LP#1310506. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745130: apt should tell if updates are available
On Fri, Apr 18, 2014 at 05:13:46PM +0200, David Kalnischkies wrote: > You could also use a hook script with APT::Update::Post-Invoke to > do/display whatever you might want to. Something like the daptup package? Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#745130: apt should tell if updates are available
On Tue, Apr 22, 2014 at 09:38:16AM +0530, shirish शिरीष wrote: > On 4/22/14, James McCoy wrote: > > On Fri, Apr 18, 2014 at 05:13:46PM +0200, David Kalnischkies wrote: > >> You could also use a hook script with APT::Update::Post-Invoke to > >> do/display whatever you might want to. > > > > Something like the daptup package? > > I just saw the dataup package. It seems to do the thing I want but > don't know how to use the 'hook script with APT::Update:Post-Invoke to > do/display whatever you might want to' . daptup provides an apt config file which defines APT::Update::Pre-Invoke and APT::Update::Post-Invoke hooks. Those hooks determine what packages are new/changed and display them to you. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#732999: libx11-protocol-perl: libio-socket-ip Recommends is incorrect
Package: libx11-protocol-perl Followup-For: Bug #732999 The fix for this bug added a "Recommends: libio-socket-ip" but the actual package name is libio-socket-ip-perl. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.13-1-486 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 libx11-protocol-perl depends on: ii perl 5.18.2-2+b1 libx11-protocol-perl recommends no packages. libx11-protocol-perl 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#740302: wheezy-pu: package subversion/1.6.17dfsg-4+deb7u5
Package: release.debian.org
Severity: normal
Tags: wheezy
User: release.debian@packages.debian.org
Usertags: pu
I would like to upload subversion for the next Wheezy point release to
address the following issues.
* Add patch CVE-2014-0032: mod_dav_svn crash when handling certain requests
with SVNListParentPath on (Closes: #737815)
* rules: Fix removal of libsvnjavahl-1.a/.la/.so from libsvn-dev (Closes:
#711911)
-- System Information:
Debian Release: jessie/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.12-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
diffstat for subversion_1.6.17dfsg-4+deb7u4 subversion_1.6.17dfsg-4+deb7u5
debian/patches/CVE-2014-0032| 39
subversion-1.6.17dfsg/debian/changelog |9 ++
subversion-1.6.17dfsg/debian/patches/series |1
subversion-1.6.17dfsg/debian/rules |3 +-
4 files changed, 51 insertions(+), 1 deletion(-)
diff -u subversion-1.6.17dfsg/debian/rules subversion-1.6.17dfsg/debian/rules
--- subversion-1.6.17dfsg/debian/rules
+++ subversion-1.6.17dfsg/debian/rules
@@ -346,13 +346,14 @@
cd debian/tmp/$(libdir); for lib in ra fs auth swig; do \
$(RM) libsvn_$${lib}_*.so libsvn_$${lib}_*.la; \
done
- cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl.a libsvnjavahl.la
+ cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl-1.a libsvnjavahl-1.la
# Intermediate hack, until we can remove the rest of the .la files.
sed -i "/dependency_libs/s/=.*/=''/" debian/tmp/$(libdir)/*.la
dh_install -s
ifdef DEB_OPT_WITH_JAVAHL
mkdir -p debian/libsvn-java/$(libdir)
mv debian/libsvn-java/usr/lib/jni debian/libsvn-java/$(libdir)/
+ $(RM) debian/libsvn-dev/$(libdir)/libsvnjavahl-1.so
endif
ln -s libsvn_ra_neon-1.so.1 debian/libsvn1/$(libdir)/libsvn_ra_dav-1.so.1
diff -u subversion-1.6.17dfsg/debian/changelog subversion-1.6.17dfsg/debian/changelog
--- subversion-1.6.17dfsg/debian/changelog
+++ subversion-1.6.17dfsg/debian/changelog
@@ -1,3 +1,12 @@
+subversion (1.6.17dfsg-4+deb7u5) UNRELEASED; urgency=medium
+
+ * Add patch CVE-2014-0032: mod_dav_svn crash when handling certain requests
+with SVNListParentPath on (Closes: #737815)
+ * rules: Fix removal of libsvnjavahl-1.a/.la/.so from libsvn-dev (Closes:
+#711911)
+
+ -- James McCoy Wed, 26 Feb 2014 21:19:57 -0500
+
subversion (1.6.17dfsg-4+deb7u4) wheezy; urgency=low
* Non-maintainer upload.
diff -u subversion-1.6.17dfsg/debian/patches/series subversion-1.6.17dfsg/debian/patches/series
--- subversion-1.6.17dfsg/debian/patches/series
+++ subversion-1.6.17dfsg/debian/patches/series
@@ -42,0 +43 @@
+CVE-2014-0032
only in patch2:
unchanged:
--- subversion-1.6.17dfsg.orig/debian/patches/CVE-2014-0032
+++ subversion-1.6.17dfsg/debian/patches/CVE-2014-0032
@@ -0,0 +1,39 @@
+Author: Ben Reser
+Subject: Disallow methods other than GET/HEAD for the parentpath list.
+
+Fixes the segfault for `svn ls http://svn.example.com` when SVN is handling
+the server root and SVNListParentPath is on.
+
+Origin: upstream, backported from commit:r1557320
+Bug-CVE: http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
+Bug-Debian: http://bugs.debian.org/737815
+Last-Update: 2014-02-26
+
+--- a/subversion/mod_dav_svn/repos.c
b/subversion/mod_dav_svn/repos.c
+@@ -1672,6 +1672,25 @@
+
+ if (strcmp(parentpath, uri) == 0)
+ {
++ /* Only allow GET and HEAD on the parentpath resource
++ * httpd uses the same method_number for HEAD as GET */
++ if (r->method_number != M_GET)
++{
++ int status;
++
++ /* Marshal the error back to the client by generating by
++ * way of the dav_svn__error_response_tag trick. */
++ err = dav_svn__new_error(r->pool, HTTP_METHOD_NOT_ALLOWED,
++ SVN_ERR_APMOD_MALFORMED_URI,
++ "The URI does not contain the name "
++ "of a repository.");
++ /* can't use r->allowed since the default handler isn't called */
++ apr_table_setn(r->headers_out, "Allow", "GET,HEAD");
++ status = dav_svn__error_response_tag(r, err);
++
++ return dav_push_error(r->pool, status, err->error_id, NULL, err);
++}
++
+ err = get_parentpath_resource(r, root_path, resource);
+ if (err)
+ return err;
Bug#740398: ITP: pangoterm -- GTK/Pango-based terminal emulator
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: pangoterm Version : 0~20140228 Upstream Author : Paul Evans * URL : http://www.leonerd.org.uk/code/pangoterm/ * License : MIT Programming Lang: C Description : GTK/Pango-based terminal emulator A minimal GTK/Pango-based terminal that uses libvterm to provide terminal emulation. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740400: ITP: libvterm -- abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator
Package: wnpp Severity: wishlist Owner: James McCoy * Package name: libvterm Version : 0~20140228 Upstream Author : Paul Evans * URL : http://www.leonerd.org.uk/code/libvterm/ * License : MIT Programming Lang: C Description : abstract library implementation of a VT220/xterm/ECMA-48 terminal emulator An abstract C99 library which implements a VT220 or xterm-like terminal emulator. It doesn't use any particular graphics toolkit or output system, instead it invokes callback function pointers that its embedding program should provide it to draw on its behalf. It avoids calling malloc() during normal running state, allowing it to be used in embedded kernel situations. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#740302: wheezy-pu: package subversion/1.6.17dfsg-4+deb7u5
On Thu, Feb 27, 2014 at 09:52:17PM -0500, James McCoy wrote:
> I would like to upload subversion for the next Wheezy point release to
> address the following issues.
>
>* Add patch CVE-2014-0032: mod_dav_svn crash when handling certain requests
> with SVNListParentPath on (Closes: #737815)
>* rules: Fix removal of libsvnjavahl-1.a/.la/.so from libsvn-dev (Closes:
> #711911)
Ping?
> diffstat for subversion_1.6.17dfsg-4+deb7u4 subversion_1.6.17dfsg-4+deb7u5
>
> debian/patches/CVE-2014-0032| 39
>
> subversion-1.6.17dfsg/debian/changelog |9 ++
> subversion-1.6.17dfsg/debian/patches/series |1
> subversion-1.6.17dfsg/debian/rules |3 +-
> 4 files changed, 51 insertions(+), 1 deletion(-)
>
> diff -u subversion-1.6.17dfsg/debian/rules subversion-1.6.17dfsg/debian/rules
> --- subversion-1.6.17dfsg/debian/rules
> +++ subversion-1.6.17dfsg/debian/rules
> @@ -346,13 +346,14 @@
> cd debian/tmp/$(libdir); for lib in ra fs auth swig; do \
> $(RM) libsvn_$${lib}_*.so libsvn_$${lib}_*.la; \
> done
> - cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl.a
> libsvnjavahl.la
> + cd debian/tmp/$(libdir); $(RM) libsvn_swig*.a libsvnjavahl-1.a
> libsvnjavahl-1.la
> # Intermediate hack, until we can remove the rest of the .la files.
> sed -i "/dependency_libs/s/=.*/=''/" debian/tmp/$(libdir)/*.la
> dh_install -s
> ifdef DEB_OPT_WITH_JAVAHL
> mkdir -p debian/libsvn-java/$(libdir)
> mv debian/libsvn-java/usr/lib/jni debian/libsvn-java/$(libdir)/
> + $(RM) debian/libsvn-dev/$(libdir)/libsvnjavahl-1.so
> endif
> ln -s libsvn_ra_neon-1.so.1
> debian/libsvn1/$(libdir)/libsvn_ra_dav-1.so.1
>
> diff -u subversion-1.6.17dfsg/debian/changelog
> subversion-1.6.17dfsg/debian/changelog
> --- subversion-1.6.17dfsg/debian/changelog
> +++ subversion-1.6.17dfsg/debian/changelog
> @@ -1,3 +1,12 @@
> +subversion (1.6.17dfsg-4+deb7u5) UNRELEASED; urgency=medium
> +
> + * Add patch CVE-2014-0032: mod_dav_svn crash when handling certain requests
> +with SVNListParentPath on (Closes: #737815)
> + * rules: Fix removal of libsvnjavahl-1.a/.la/.so from libsvn-dev (Closes:
> +#711911)
> +
> + -- James McCoy Wed, 26 Feb 2014 21:19:57 -0500
> +
> subversion (1.6.17dfsg-4+deb7u4) wheezy; urgency=low
>
>* Non-maintainer upload.
> diff -u subversion-1.6.17dfsg/debian/patches/series
> subversion-1.6.17dfsg/debian/patches/series
> --- subversion-1.6.17dfsg/debian/patches/series
> +++ subversion-1.6.17dfsg/debian/patches/series
> @@ -42,0 +43 @@
> +CVE-2014-0032
> only in patch2:
> unchanged:
> --- subversion-1.6.17dfsg.orig/debian/patches/CVE-2014-0032
> +++ subversion-1.6.17dfsg/debian/patches/CVE-2014-0032
> @@ -0,0 +1,39 @@
> +Author: Ben Reser
> +Subject: Disallow methods other than GET/HEAD for the parentpath list.
> +
> +Fixes the segfault for `svn ls http://svn.example.com` when SVN is handling
> +the server root and SVNListParentPath is on.
> +
> +Origin: upstream, backported from commit:r1557320
> +Bug-CVE: http://subversion.apache.org/security/CVE-2014-0032-advisory.txt
> +Bug-Debian: http://bugs.debian.org/737815
> +Last-Update: 2014-02-26
> +
> +--- a/subversion/mod_dav_svn/repos.c
> b/subversion/mod_dav_svn/repos.c
> +@@ -1672,6 +1672,25 @@
> +
> + if (strcmp(parentpath, uri) == 0)
> + {
> ++ /* Only allow GET and HEAD on the parentpath resource
> ++ * httpd uses the same method_number for HEAD as GET */
> ++ if (r->method_number != M_GET)
> ++{
> ++ int status;
> ++
> ++ /* Marshal the error back to the client by generating by
> ++ * way of the dav_svn__error_response_tag trick. */
> ++ err = dav_svn__new_error(r->pool, HTTP_METHOD_NOT_ALLOWED,
> ++ SVN_ERR_APMOD_MALFORMED_URI,
> ++ "The URI does not contain the name "
> ++ "of a repository.");
> ++ /* can't use r->allowed since the default handler isn't
> called */
> ++ apr_table_setn(r->headers_out, "Allow", "GET,HEAD");
> ++ status = dav_svn__error_response_tag(r, err);
> ++
> ++ return dav_push_error(r->pool, status, err->error_id, NULL,
> err);
> ++}
> ++
> + err = get_parentpath_resource(r, root_path, resource);
> + if (err)
> + return err;
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
signature.asc
Description: Digital signature
Bug#514307: pull request
On Mon, Mar 03, 2014 at 06:44:06PM +0800, Rolf Leggewie wrote: > hoping that this could land after lingering for about 5 years I've > pushed the relevant patch to alioth git in a branch called > pull-request1. The changes weren't applied to the "--diff" handling. Was that intentional? I'm not sure that sorting primarily on the type of WNPP bug is necessarily useful. The most relevant piece of information is the package name, so I think that should continue to be the primary key for sorting. This would also keep the sort stable if the answer to my earlier question is “no”. Also, now that the bug reference is larger, I think it looks a bit cleaner to have "bugUrl wnppType package -- desc". Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#741040: devscripts: Add a switch, variable to ask debcommit to gpg-sign commits
Control: forcemerge 738595 741040 On Fri, Mar 07, 2014 at 01:09:39PM -0600, Gunnar Wolf wrote: > I have just pushed my patch in the Git repo. Thanks for the patches. I have some pending work that will add support for bzr and hg, too. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#737843: [uscan] --repack replaces \r\n with \n in text files
On Thu, Feb 06, 2014 at 01:30:46PM +0100, Emmanuel Bourg wrote: > I've got some trouble with uscan when repacking the source zip [1] of > JavaMail. The file > 'mail/src/test/resources/javax/mail/internet/folddata' is altered in the > process. Its md5sum is 7ac9a5 in the source zip, and bbb321 in the > repacked tarball. > > After investigating it looks like the repacking replaced the \r\n line > terminators with \n, causing the unit tests to fail. Daniel requested this in #618513. I felt a little unsure of it at the time, but acquiesced. Given the above effects, and re-reading the reasoning provided by cryptlib's upstream[0], I'm thinking it may be best to revert this. 0: To unzip the code under Unix use the -a option to ensure that the text files are converted to the Unix format. I don't see why this requirement is imposed by cryptlib. If the source he's distributing uses dos line endings, why shouldn't that be the form they're modified in? If someone on a Windows system creates a patch, their files are going to have dos line endings, not Unix, so I don't think that suggestion has anything to do with feeding patches back to upstream. It's likely just a tip for ensuring the line endings are “correct” for the user's OS, which, as I stated initially, is less likely to cause problems for *nix tools if they aren't. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#685506: Modifying Files-Excluded pattern specification
On Sat, Mar 22, 2014 at 02:00:40PM +0100, Nicolas Boulenguez wrote: > In-Reply-To=<20140321105301.ge18...@an3as.eu> > > Joachim Breitner wrote: > > File-Excluded: foo/bar.js to exclude > > * foo/bar.js (in case of a dirty tarball) > > * pkg-1.0/foo/bar.js (as in your implementation) as well as > > * pkg-1.0/docs/foo/bar.js (this would be new > > the easiest, as it will conceivably stand less in the way of the > > developers, i.e. he would _not_ have to first look up the precise semantics. > > Andreas Tille wrote: > > it is really flexible > > The same effect was available with "*foo/bar.js" or the more accurate > "foo/bar.js */foo/bar.js". > > Imagine an upstream providing two implementations, a default non free > "imp.c" and a free alternative "gpl/imp.c". The maintainer cannot > remove the former while keeping the latter anymore. > > I call this less flexible, but I may miss your point. Agreed. We shouldn't be introducing divergence between how Files: and Files-Excluded: are interpreted. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743136: New scp does not allow to save
Control: tag -1 confirmed upstream On Sun, Mar 30, 2014 at 09:22:40PM +0100, Klaus Ethgen wrote: > With the newest vim, it is not possible anymore to save a file using scp > remote. Just for clarification, the following produces the problem: vimdiff foo scp://host/foo and then trying to save the scp://host/foo buffer. This is due to the 'buftype' option being set to “nofile”. A workaround is to “set buftype=” in the buffer and then save it. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743282: ITP: apt-get-snapshot -- Download a specific package version from snapshot.debian.org
On Apr 1, 2014 6:39 AM, "Mike Gabriel" wrote: > * Package name: apt-get-snapshot > Version : 1.1 > Upstream Author : Leandro Lisboa Penz > * URL : https://github.com/lpenz/apt-get-snapshot > * License : BSD > Programming Lang: Python > Description : Download a specific package version from snapshot.debian.org > > apt-get-snapshot is a command-line tool that downloads a specific version of > a debian package from snapshot.debian.org. This sounds a lot like the debsnap tool in the devscripts package. Cheers, James
Bug#743463: mercurial-git: "hg help git" fails due to missing help/ directory
Package: mercurial-git Version: 0.4.0-2 Severity: normal Dear Maintainer, Not all of the upstream files are included in the package, which leads to the following error: $ hg help git abort: No such file or directory: /usr/lib/python2.7/dist-packages/hgext/git/help/git.rst -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.13-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 mercurial-git depends on: ii mercurial 2.9.1-1 ii python 2.7.5-5 ii python-dulwich 0.9.5-2 mercurial-git recommends no packages. mercurial-git 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#743668: vim-gtk: guicursor modifications cause warning messages to be printed to terminal
On Fri, Apr 04, 2014 at 10:20:06PM +, brian m. carlson wrote: > In my .vimrc, I have the following: > > let &guicursor = &guicursor . ",a:blinkon0" > > This causes the following warning to be printed to the terminal as soon > as I press a key or move the window: > > (gvim:264919): GLib-CRITICAL **: Source ID 51 was not found when attempting > to remove it > > This, of course, messes up my prompt, which is very annoying. > > I've had this setting in my .vimrc for years, and I believe only the > last update of the package has caused this issue to appear. It was actually the update of libglib2.0-0 to 2.40.0: - g_source_remove() will now throw a critical in the case that you try to remove a non-existent source. We expect that there is some code in the wild that will fall afoul of this new critical but considering that we now reuse source IDs, this code is already broken and should probably be fixed. Now to figure out where Vim is screwing things up. > I've included a vimrc file which triggers this problem. Note that I can > only reproduce it with that file as ~/.vimrc; Indeed. I tried adding your guicursor modification to my vimrc and it worked fine. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#743721: libsvn-java: Please provide Maven artifacts
On Sat, Apr 05, 2014 at 12:41:17PM -0300, Miguel Landaeta wrote: > More and more Java software handles their dependencies through Maven, > so it would be very useful if this package installed their artifacts in > the Maven repository at /usr/share/maven-repo. The documentation for maven-repo-helper seems to assume that one of some set of tools (maven, ant, etc.) are used and that there's an accessible pom.xml, either as part of the project or available from a repository. I checked search.maven.org and mvnrepository.com, neither of which has one for Subversion's java bindings. It'd be preferable to have the distro-independent portions driven through upstream, both in terms of helping the broader community and working with people that are likely more familiar with what you're trying to achieve. I'd be open to making changes to support your goal, but I'm pretty unfamiliar with things Java related. If you could provide patches, I'll provide feedback. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#748465: Renaming repacked tarball (was Re: Excluded-Files feature reimplemented)
Adding #748465 since it also raised the issue of the renaming. On Tue, May 20, 2014 at 11:56:09PM +0200, Joachim Breitner wrote: > Am Dienstag, den 20.05.2014, 19:10 +0200 schrieb Andreas Tille: > > So what would be your suggestion to solve this issue to get some > > appendix to the version number. I think editing each debian/watch > > file an mangling names is a bit clumsy. > > I don’t think its too bad, and at least its explicit, but I don’t use > that feature myself (yet). > > Would it be less clumsy if you did not have to specify some specific sed > expression, but could rather had a simple way to flag uscan to „do the > usual and commonly accepted version mangling“? That would be more > declarative, less line-noisy and less for you to type. The type of suffix varies depending on the reason the tarball is being repacked. The two common ones are [+.]dsN and [+.]dfsgN where the former indicates the tarball has been repacked and the latter indicates that the repack was due to DFSG violations. Not everyone includes the N (+dfsg1 vs. +dfsg) but I think it's a good idea in case the same upstream version needs to be repacked differently for some reason. Given the above, how about a “--repack-suffix …” that gets passed through to mk-origtargz? So “uscan … --repack-suffix +dfsg1” or a similar mk-origtargz invocation repacks and adds +dfsg1 to the upstream version. This could possibly be exposed by a new opts value in the watch file itself -- opts=repacksuffix=+dfsg1 Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#747609: ruby2.0 removal transition: request for NMUs
On Tue, May 20, 2014 at 09:57:31AM -0300, Antonio Terceiro wrote: > Hello, in order to get rid of dependencies on ruby2.0, please schedule > NMUs for the following source packages: > > … > subversion I'm prepping a sourceful upload. Should be ready Wednesday, so no need to binNMU. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#605702: subversion: commit-email.pl is locale-dependent and does wrong things
On Wed, May 21, 2014 at 01:23:50PM +0200, Vincent Lefevre wrote: > On 2014-01-04 20:41:02 -0500, James McCoy wrote: > > On Thu, Dec 02, 2010 at 03:48:15PM +0100, Moritz Both wrote: > [...] > > Subversion 1.8 introduced a means to configure the locale in which > > mod_dav_svn hooks are run and to understand UTF-8 input/output (c.f., > > http://subversion.apache.org/docs/release-notes/1.8.html#hooks). It > > looks like this may address the issues you raised. > > > > I hope to have a 1.8.x upload ready in a week or so. > > The script should be able to work in any locale (if needed it can > also change the locale at the beginning of itself). I wasn't questioning the ability to run in any specific locale. I was responding to this: On Thu, Dec 02, 2010 at 03:48:15PM +0100, Moritz Both wrote: > - svnlook will recode commit messages to the locale-specific > standard character encoding > […] > Whilfe strftime works correctly only with the "C" locale, the commit > message may contain language-specific characters and not only ascii. > So svnlook should be called with the system locale which is more > likely to be correct. Supporting this without having everyone modify the script wasn't possible before the ability to configure the locale in which mod_dav_svn's hooks are run. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#749057: netsniff-ng: Supported Architectures: artificially restricted
Source: netsniff-ng Version: 0.5.8-2 Severity: normal The Architectures: list in debian/control is limited according to what liburcu supported the last time the line was updated. Instead of manually keeping this up to date, why not set it to "any" and let the availability of the liburcu-dev package determine whether netsniff-ng gets built? If liburcu-dev isn't available on that arch, then the netsniff-ng build will just sit in the BD-Uninstallable state. However, if liburcu-dev does become available, then you won't need a sourceful upload of netsniff-ng to take advantage of it. -- System Information: Debian Release: jessie/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: i386 (i686) Kernel: Linux 3.14-1-486 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#747901: Bug#749230: svn-upgrade --uscan requires a orig.tar.gz
On Sun, May 25, 2014 at 03:56:29PM +0200, gregor herrmann wrote: > On Sun, 25 May 2014 14:47:48 +0200, Vincent Bernat wrote: > > > svn-upgrade --uscan tells: > > > > ╭─ > > │python-xlrd: Newer version (0.9.3) available on remote site: > > │ http://pypi.python.org/packages/source/x/xlrd/xlrd-0.9.3.tar.gz > > │ (local version is 0.9.2) > > │uscan's output didn't give an obvious tarball name. the last line of it's > > output should include the name of the tarball, which should include .orig. > > at /usr/bin/svn-upgrade line 71. > > │Process ended with code 1 > > ╰─ > > I guess that's the next fallout from uscan changing its output. Except svn-upgrade wasn't using --dehs to get output that is intended to be machine parseable. Parsing output intended for humans rather than computers isn't generally a good idea. We do need to add that back to uscan, so the user has an idea of what the final tarball name is, though. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#749225: [uscan] does not work with bitbucket
On Sun, May 25, 2014 at 05:09:02PM +0200, Jakub Wilk wrote: > No idea why the verification fails, though. Other TLS clients I tested seem > to be happy with it. > > Unfortunately, there doesn't seem to be currently any way to disable > certificate verification in uscan. “env PERL_LWP_SSL_VERIFY_HOSTNAME=0 uscan …” should work. Having a devscripts-native way to do that could be useful, I guess. We have another report requesting that for dget. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#750247: devscripts: [wrap-and-sort] removes package definitions when wrapping control file
Control: reassign -1 src:python-debian Control: forcemerge 655988 -1 On Mon, Jun 02, 2014 at 10:09:08PM +0200, Benjamin Drung wrote: > The merged package definitions were separated by one line containing a > space (line 20 of your control file), but they should be separated by > one empty line. That's the reason why the package definitions were > joined. Which is a bug in python-debian that has yet to be fixed. Adding this one to the list. > wrap-and-sort should behave better in case of such an malformed control > file. It could strip all trailing spaces before parsing the file with > python-debian. That would be a viable workaround, but it would be better to fix python-debian. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#750563: uscan regressed recently, adding all groups to the version number match
On Wed, Jun 04, 2014 at 03:58:17PM +0200, Matthias Klose wrote: > libffi currently reports as version number 3.1.gz using > > ftp://sourceware.org/pub/libffi/libffi-(.*)\.tar.(bz2|gz|xz) Aside from what Adam already mentioned, you probably want to change “(bz2|gz|xz)” to “(?:bz2|gz|xz)”,that is a non-capturing group. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#750542: /usr/bin/debcheckout doesn't detect the new alioth https Git URLs
Control: retitle -1 debcheckout doesn't detect the non-anonscm Alioth URLs Control: user devscri...@packages.debian.org Control: usertag -1 debcheckout On Wed, Jun 04, 2014 at 12:07:56PM +0200, Didier Raboud wrote: > When trying to checkout a package which has a Vcs-Git field filled with > the Git URL as displayed on alioth repositories [0], the "authenticated" > checkout doesn't work: > > $ debcheckout -u odyx -a printer-driver-ptouch > can't use authenticated mode on repository > 'https://alioth.debian.org/anonscm/git/printing/ptouch-driver.git' since it is > not a known repository (e.g. alioth) The problem is actually that debcheckout recognizes “https://anonscm.debian.org/git/…” style URLs. Those still work, but apparently Alioth is now advertising different URLs. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy signature.asc Description: Digital signature
Bug#750722: libsvn1: libsvn_ra_local inexplicably gains 2044KiB of zero bytes
Control: reassign -1 binutils 2.24.51.20140604-3 On Fri, Jun 06, 2014 at 09:32:37AM +0100, RjY wrote: > During a recent package update I noticed libsvn1 grew a lot in > installed-size. Upon investigation it turned out this was: > > % for i in libsvn1_1.8.8-2_amd64.deb libsvn1_1.8.9-1_amd64.deb ; do dpkg > -c $i ; done | grep ra_local | grep -v '^l' > -rw-r--r-- root/root 39800 2014-04-01 03:20 > ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 > -rw-r--r-- root/root 2132856 2014-05-21 12:33 > ./usr/lib/x86_64-linux-gnu/libsvn_ra_local-1.so.1.0.0 > > Why would a (relatively simple) module for local file:// url access > suddenly gain 2044KiB in a minor update? The extra space appears to > consist entirely of zero bytes, as well. Good question. Rebuilding 1.8.8-2 in a current sid chroot causes the same thing. This seems to be caused by something in the toolchain. For reference, here are the differences in some key toolchain packages for the original 1.8.8-2 build and the one I just re-ran: package | small lib version | large lib version - binutils | 2.24-5| 2.24.51.20140604-3 g++4.8| 4.8.2-18 | 4.8.3-3 gcc-4.8 | 4.8.2-18 | 4.8.3-3 gcc-4.9 | n/a | 4.9.0-5 libc6-dev | 2.18-4| 2.19-1 libstdc++-4.8-dev | 4.8.2-18 | 4.8.3-3 libstdc++6| 4.8.2-18 | 4.9.0-5 Based on my minimal knowledge of what goes into building the shared libraries, I'll start this off in binutils' court. Cheers, -- James GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
