Bug#718272: [Pkg-bitcoin-devel] Bug#718272: Bitcoin still not ready for stable release in Debian
Hey Luke, Jonas, On Fri, Nov 03, 2017 at 08:31:33PM +, Luke Dashjr wrote: > > >> I believe Bitcoin is now stable enough for stable release. > > > Things have only gotten less stable upstream since 2013... > > Please provide references supporting that. 0.15 is certainly "stable" in the sense that it's a well-maintained piece of software, but it's not stable in the sense that it should be reliably used without changes over a period of years. For instance 0.15.1 is currently being prepared to work around p2p problems that are expected within a couple of weeks. > > > What is the plan for getting security and protocol change updates > > > backported to Debian stable? > > Debian standard procedures for updating stable packages. > In my experience, that has been "never update, even when fixes are available" > except for highly-visible security issues. :( Not sure if there's something more up to date, but https://lists.debian.org/debian-devel-announce/2016/11/msg9.html says: * Fixes must be minimal and relevant and include a sufficiently detailed changelog entry which seems like it generally precludes uploading new upstream releases (0.14 to 0.15 at least, perhaps 0.15 to 0.15.1 would be fine). I don't think upstream will generally be providing sufficiently "minimal and relevant" backports to satisfy that rule... AIUI, stable-updates is a subset of proposed-updates, so it's not easier to get in there than regular updates to stable? (If the release team are willing to accept new upstream releases into stable or stable-updates, this seems like a good idea; it just doesn't seem like they would be as far as I can see?) Cheers, aj
Bug#539993: sputnik: missing depends on coxpcall?
Package: sputnik
Version: 9.03.13+1-1
Severity: serious
Justification: Policy 3.5
>From /usr/share/lua/5.1/sputnik/actions/wiki.lua:
require("coxpcall")
But liblua5.1-coxpcall0 isn't listed amongst:
Depends: liblua5.1-wsapi1, liblua5.1-markdown0, liblua5.1-cosmo0,
liblua5.1-filesystem0, liblua5.1-md5-0, liblua5.1-logging,
liblua5.1-socket2, lua5.1
(xavante depends on it, though; but aiui you don't need xavante for
sputnik)
Cheers,
aj
-- System Information:
Debian Release: squeeze/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.28.2 (SMP w/2 CPU cores)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/bash
Versions of packages sputnik depends on:
ii liblua5.1-cosmo0 8.04.14-2 A template library for the lua lan
ii liblua5.1-filesystem0 1.4.2-1luafilesystem library for the Lua
ii liblua5.1-logging 1.1.4-2lualogging library for the lua lan
ii liblua5.1-markdown0 0.32-1 A pure lua5.1 implementation of th
ii liblua5.1-md5-0 1.1.2-1MD5 library for the lua language v
ii liblua5.1-socket2 2.0.2-3TCP/UDP socket library for Lua 5.1
ii liblua5.1-wsapi1 1.1.0-5Web server API abstraction layer f
ii lua5.15.1.4-3Simple, extensible, embeddable pro
Versions of packages sputnik recommends:
pn sputnik-goodies(no description available)
sputnik suggests no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#812275: bitcoin: FTBFS with GCC 6: test suite failures
Source: bitcoin Followup-For: Bug #812275 > This package fails to build with GCC 6. FWIW, this bug seems to be fixed upstream somewhere between 0.12.1 and 0.13.0rc2. I ran a git bisect, and the commit that fixes the issue seems to be: https://github.com/bitcoin/bitcoin/commit/89f71c68c0fecf63059f6055ebdd25f1eba4c982 Cheers, aj
Bug#736189: [gitit] Sourceless file
tag 736189 + fixed-upstream thanks This bug is reportedly fixed in the new upstream version 0.10.5 about a month ago: > I've released gitit 0.10.5. > > CHANGES: > ... > * Add full versions of minified JavaScript (#400) (Peter Gallagher). -- https://groups.google.com/forum/#!topic/gitit-discuss/7t_ew6pw7Ac Cheers, aj -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#736189: [gitit] Sourceless file
On 26 September 2014 00:36, Anthony Towns wrote: > This bug is reportedly fixed in the new upstream version 0.10.5 about a > month ago: Turns out the 0.10.5.1 tarball doesn't actually include the sources for the minified jquery -- it's just included in git. gitit 0.10.5.1 also adds a few dependencies, one of which isn't packaged for Debian (hoauth2). I've prepared a patch that: - updates to the current upstream - adds the new deps (except hoauth2) to debian/control - removes github oauth2 support, and hence the need for the hoauth2 dep - includes the jquery sources - updates debian/rules to replace the new names of jquery with the packed jquery bits It's available (unsigned) at http://azure.erisian.com.au/~aj/tmp/gitit-bug736189/ for now. I think that would be okay for the archive, but maybe it would be better to just do a patch to 0.10.4 that includes the corresponding jquery sources and try to get that into jessie? I've submitted a pull request upstream to get the sources included in the upstream tarball directly, see https://github.com/jgm/gitit/pull/454 Cheers, aj -- Anthony Towns -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 08:46:53AM -0500, Michael Poole wrote: > But nasm requires such assembly for useful execution! Dude, you're on crack. First, there's apparently free software in main that you can compile with nasm to your heart's content, namely crystalspace, drip, e3, effectv, extipl, flac, hermes1, libgpeg-mmx, libopenspc, mknbi, motion, pearpc, psemu-video-x11, sbm, scummvm, syslinux, visualboyadvance, vlc, xmms-openspc, zinf, and zsnes. But even if that weren't the case, nasm is an assembler -- it doesn't rely on assembler code to do anything useful, its purpose is to translate assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to allow existing drivers to run on Linux. If there aren't any free ones, or the free ones are useless toys, then it belongs in contrib because its purpose is to allow you to run non-free software. Cheers, aj signature.asc Description: Digital signature
Bug#353277: ndiswrapper in main (was: Bug#353277: should be in contrib)
On Sat, Feb 18, 2006 at 09:59:07AM -0500, Michael Poole wrote: > Anthony Towns writes: > > But even if that weren't the case, nasm is an assembler -- it doesn't > > rely on assembler code to do anything useful, its purpose is to translate > > assembler code. ndiswrapper isn't a driver compiler, it's a wrapper to > > allow existing drivers to run on Linux. > This apparently means that you object to translation at the binary > level but not translation at the source level. I guess that's > reasonable in a general sense, it's just not a distinction that policy > or the DFSG makes. You have no idea what you're talking about. Which isn't surprising, considering you're apparently not a developer, maintainer, applicant or any other sort of regular contributor to Debian. In future, if you've got questions, please ask, rather than degrading the quality of the lists by doing the Usenet troll thing of posting authoritative statements that are complete wrong in order to get other people to correct you. Cheers, aj signature.asc Description: Digital signature
Bug#353277: ndiswrapper in main
On Sat, Feb 18, 2006 at 05:04:54PM +0100, Goswin von Brederlow wrote: > > I see. From http://cipe-win32.sourceforge.net/ : > > "CIPE-Win32 is a port of Olaf Titz's CIPE package from Linux to Windows > > NT." > > I think this is the cipe-source package in debian. If this driver is > > already > > available, there's no much point in using it via ndiswrapper. > > Is there any other free ndis driver? > The availability to do this is enough even if there are other > (possibly better) ways to do the same. One free driver _in_ Debian and > the package should stay in main. Can the non developers on this list please stop posting as though they're in a position to make global policy decisions for Debian? > But does the cipe-source build or ship the windows driver for use with > ndiswraper? I doubt that. Even if it does, it shouldn't do so if there's no point to running the driver through ndiswrapper. Stuff in contrib is free software, that happens to be only useful in making non-free software work. There's no shame in that; it just means RMS won't bother running it. Cheers, aj signature.asc Description: Digital signature
Bug#353277: ndiswrapper in main
On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote: > I requested that ndiswrapper and ndiswrapper-modules-i386 be moved to contrib. ndiswrapper is a program to allow users to load Windows drivers for their hardware and use them on Linux. The drivers are executed on the main CPU; there are no free drivers that ndiswrapper is useful for, apart from a single example driver that is a port of a driver already in the kernel. We currently allow both emulators, that play non-free ROMs, and clients for network protocols for which there is no non-free server into main. ndiswrapper was accepted into main in November 2004. AFAICS, this would come under the "overrule a developer (3:1 majority)" power. > The maintainer refuses to move it unless you rule a formal decision or a > consensus is reached. I think the latter is impossible, and therefore I ask > you > to consider the issue. While I would personally rather see the "contrib" demarkation cover this, emulators, and clients for propietary protocols, I'm disinclined to override both the maintainer and the ftpmaster that accepted it, particularly on this single issue rather than as a global policy change for those issues. I expect I'll either abstain or vote against. Cheers, aj signature.asc Description: Digital signature
Bug#353277: Please reject to rule on the ndiswrapper question
On Thu, Mar 02, 2006 at 04:43:45PM -0300, Henrique de Moraes Holschuh wrote: > On Wed, 01 Mar 2006, Steve Langasek wrote: > Of course, I can be convinced that the constitution does give the ctte that > power, but so far, I am not. Otherwise, why didn't we pose to the ctte a > request for how the GFDL issue should be handled? I can answer that: first, because I didn't think the committee was ready to deal with such an important issue at the time (and still don't), and second because I think having ignored the GFDL for this long that it's not a simple matter to apply existing policy, and thus appropriate for ftpmaster/release team/tech ctte to decide off their own bat. Cheers, aj signature.asc Description: Digital signature
Bug#376777: apt-utils: apt-ftparchive fails to generate Contents files
package apt-utils
tag 376777 - help
tag 376777 + patch
thanks
I'm pretty sure this bug is simply due to misuse of auto_ptr in writer.cc
(causing old auto_ptr's not to be freed properly or similar which then
causes breakage after a few have built up). This is probably my fault;
the fix is just:
--- refapt/apt-0.6.44.2/ftparchive/writer.cc2006-03-29 17:01:29.0
-0800
+++ apt/ftparchive/writer.cc2006-07-05 05:10:04.0 -0700
@@ -398,7 +398,7 @@
ioprintf(c1out, _(" %s has no override entry\n"), Package.c_str());
}
- OverItem = auto_ptr(new Override::Item);
+ OverItem.reset(new Override::Item);
OverItem->FieldOverride["Section"] = Tags.FindS("Section");
OverItem->Priority = Tags.FindS("Priority");
}
Cheers,
aj
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#376777: apt-utils: apt-ftparchive fails to generate Contents files
On Wed, Jul 05, 2006 at 11:31:51PM +1000, Anthony Towns wrote: > package apt-utils > tag 376777 - help > tag 376777 + patch > thanks > > I'm pretty sure this bug is simply due to misuse of auto_ptr in writer.cc Okay, I've no idea if this is right or not now; but it's not the real bug; and if it were, there's more to it than just that one assignment. The real bug is in tagfile.cc, in particular the patch "fixing" Bug#350025 -- using MMap doesn't work if your Fd is a pipe, which it is if you point apt-ftparchive at a suite that doesn't have an uncompressed Packages file, and ask it to generate Contents. Fix is reverting the patch, at least for the case where your input file size is empty. Cheers, aj signature.asc Description: Digital signature
Bug#274705: mv: --reply doesn't work
tag 274705 + patch
thanks
So the relevant code seems to be in src/copy.c, where it checks if
"--reply=no" was set _and_ the file isn't overwritable; or if "-i" was
set, or if no option was given and the file isn't overwritable. So
"--reply=no" has an effect when you do:
touch a b
chmod 000 b
mv --reply=no a b # can't overwrite, so do nothing
This seems quite deliberate, but afaics it's a bug. I think the attached
patch fixes the problem.
Cheers,
aj
--- coreutils-5.2.1/src/copy.c.orig 2005-08-20 16:26:04.950327240 +1000
+++ coreutils-5.2.1/src/copy.c 2005-08-20 16:26:18.483269920 +1000
@@ -946,8 +946,7 @@
/* cp and mv treat -i and -f differently. */
if (x->move_mode)
{
- if ((x->interactive == I_ALWAYS_NO
- && UNWRITABLE (dst_path, dst_sb.st_mode))
+ if ((x->interactive == I_ALWAYS_NO)
|| ((x->interactive == I_ASK_USER
|| (x->interactive == I_UNSPECIFIED
&& x->stdin_tty
Bug#302519: ifupdown: postinst fails if /dev/shm/network/ does not exist
Stefan Kluth wrote: Setting up ifupdown (0.6.4-4.12) ... ifupdown.postinst: Error: The canonical path of /etc/network/run could not be determined. Aborting. After googling for a few minutes I found that $ mkdir /dev/shm/network I believe I had some weird, unreproducible, behaviour from /lib/init/readlink when trying some of this stuff out; so afaics the above should never happen, but I'm not sure it actually doesn't. The obvious explanation would've been that /dev/shm didn't exist, let alone /dev/shm/network, though that seems odd too. Anyway, new ifupdown in unstable doesn't use "readlink -f", instead having its own sh script fragment, so should work more reliably. This bug's already closed. FYI only. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#303656: ifupdown: can't write /etc/network/run/ifstate no space left on device
mike at dst wrote: Preparing to replace ifupdown 0.6.6 (using ifupdown_0.6.6_i386.deb) ... Unpacking replacement ifupdown ... Setting up ifupdown (0.6.6) ... Moving /etc/network/ifstate to /etc/network/run/ifstate mv: writing `/etc/network/run/ifstate': No space left on device dpkg: error processing ifupdown (--install): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: ifupdown There's been another report of this, that looks like it was caused by setting a bad value in /etc/default/tmpfs causing /dev/shm to have zero space (the value needs to be set in bytes, and is rounded down to a multiple of the page size, which I guess means anything less than 4096 is the same as zero). Is this what happened in your case, mike? If so, I think we'll probably want to put it down to operator error, and add some special casing in postinst. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#313400: dpkg: Please remove /usr/sbin/start-stop-daemon
Package: dpkg Version: 1.13.0 Severity: serious Hey, dpkg is now shipping both /sbin/s-s-d and /usr/sbin/s-s-d; only /sbin/s-s-d is required. Having both breaks bootstrapping since daemons get randomly started when they're not supposed to, because only /sbin/s-s-d is diverted. Presumably this is a still-glowing scar from: * Scorched-earth reimplementation of the build process and control files with debhelper and automake. Also, * Remove /usr/sbin/start-stop-daemon. Closes: #156437. -- Adam Heath <[EMAIL PROTECTED]> Thu, 29 Aug 2002 16:43:15 -0500 Advantage: doogie. Cheers, aj -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401354: package includes undistributable/non-free images
tag 401354 + confirmed retitle 401354 mailscanner: includes undistributable/non-free images thanks As well as the transtec logos which may or may not be distributable (given they're a sponsor of mailscanner), the package also includes some other logos (Google and O'Reilly) and a Dilbert cartoon about phishing, that probably doesn't fall under fairuse let alone an explicit license or the GPL as listed in debian/copyright. Cheers, aj signature.asc Description: Digital signature
Bug#402693: Apollon doesn't start saying that there's no libapollon.so.0
> The debian/rules script removes libapollon.so.0 during installation > claiming that it is statically linked. These bug reports suggest that it > is _not_ statically linked and therefore necessary. I attach a patch > which just leaves the library file in the apollon package; NMU debs and > source with this change can be found at [...] An alternative fix which forces it to be statically linked is to add: DEB_CONFIGURE_EXTRA_FLAGS = --enable-static --disable-shared to the debian/rules file. It seems to work for me, fwiw. Cheers, aj signature.asc Description: Digital signature
Bug#402179: tar: FTBFS: race condition in test-suite
This bug seems to only occur for the posix format tar archives. It's repeatable outside the tar test suite by doing: #!/bin/sh export TAR_OPTIONS="-H posix --pax-option=exthdr.name=%d/PaxHeaders/%f" echo hello > file1 echo goodbye > file2 while :; do tar cf archive.1 file1 file2 tar cfT archive.2 /dev/null tar rf archive.2 file1 tar rf archive.2 file2 if cmp archive.1 archive.2 >/dev/null; then echo -n . else echo -n + fi done The output should be all dots if the assumptions of the test are correct, but I get: +...+..+ ..++.++. .+.. ...+ .+.. ...+ .+.+ Which is to say it fails about 3% of the time on my system (stable over about 2000 iterations). I'd say that warrants downgrading this bug from serious. The fundamental problem seems to be that the POSIX format tarballs include the atime of the files in the archive (which may change between adding the file to the first archive and the second), and the mtime of the archive itself (which likewise may change). I don't see any way to work around that, though -- "--atime-preserve" helps (by eliminating the atimes), but that still leaves it failing around 1.7% of the time (when the mtimes don't match, presumably). If the test is run on a filesystem that preserves timestamps to the nanosecond (or possibly even the microsecond?), this test will always fail. Cheers, aj signature.asc Description: Digital signature
Bug#431883: dcraw license does not give permission to distribute modified versions or source alongside
On Fri, Jul 06, 2007 at 03:45:29AM -0700, Don Armstrong wrote:
> On Fri, 06 Jul 2007, Steve King wrote:
> > > You'll notice that we have no permission to distribute modified
> > > versions of dcraw.c as required by the DFSG.
> > I don't agree with you here. It seems to me that we do have
> > permission to distribute modified versions, provided source is
> > included.
> The license does not explicitely grant the ability to create a
> derivative work and distribute that work. It merely talks about
> "lawfully redistributing this code".
> Since it fails to specifically grant that right, we must assume that
> the default state ("All rights reserved") applies.
That's not true. It *might* be a good idea to assume it, but given the
intention is perfectly clear, it's certainly not a requirement.
It would be better if the intention were explicitly written out (ie,
"You may distribute and modify provided you do such and such") rather
than implied ("You must do such and such if you redistribute"), of course.
Cheers,
aj
signature.asc
Description: Digital signature
Bug#410666: update-notifier doesn't work with apt-secure
retitle 410666 update-notifier doesn't work with apt-secure tag 410666 + moreinfo unreproducible thanks Hi Alfie, AFAICS, update-notifier/update-manager just uses regular python-apt to handle all this stuff, which should go through the same code path as aptitude and apt-get. Unless you've got some way of reproducing the problem, I don't think there's a bug here. Cheers, aj signature.asc Description: Digital signature
Bug#411953: emacs-lisp-intro: The package has an invariant section
tag 411953 + confirmed thanks Hi, I emailed Richard Stallman (FSF) and Robert Chassell (the original author). Robert replied that he considered the Preface to be a secondary section because it described how he thought of his audience; but that he didn't really care; Richard replied that he Robert's reasons seemed sound, and that he didn't see any reason to take any action. So afaics this is a valid bug, and isn't going to be resolved upstream, so a move to non-free is definitely needed. Cheers, aj signature.asc Description: Digital signature
Bug#411953: emacs-lisp-intro: The package has an invariant section
FWIW, I've uploaded an NMU moving this to non-free. It'll need NEW processing (by someone else) before hitting the archive. Cheers, aj signature.asc Description: Digital signature
Bug#353277: Call for vote: ndiswrapper: Move to contrib
On Thu, Mar 29, 2007 at 10:16:52AM -0600, Bdale Garbee wrote: > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [ 2 ] Choice 1: ndiswrapper should move to contrib as per bugs #353277, > #353278 > [ 1 ] Choice 2: ndiswrapper should remain in main despite bugs #353277, > #353278 > [ 3 ] Choice 3: Further discussion > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Rationale: as per [0]: "The purpose of the ndiswrapper package is to provide an ABI layer on top of the Linux kernel that is compatible with the interface for Windows NDIS drivers, and that in order to provide this compatability layer, no non-free software is required." Cheers, aj [0] http://lists.debian.org/debian-ctte/2006/03/msg00037.html signature.asc Description: Digital signature
Bug#385665: Call for vote: fluidsynth: Move to contrib
On Thu, Mar 29, 2007 at 10:18:49AM -0600, Bdale Garbee wrote: > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- > [ 2 ] Choice 1: fluidsynth should move to contrib as per bug #385665 > [ 1 ] Choice 2: fluidsynth should remain in main despite bug #385665 > [ 3 ] Choice 3: Further discussion > - - - -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Rationale: based on bug log, fluidsynth doesn't require anything non-free. Cheers, aj signature.asc Description: Digital signature
Bug#439607: FWD: breaks debootstrap on ia64, d-i release blocker
On Fri, Aug 31, 2007 at 08:03:34PM -0400, Joey Hess wrote: > Please fix this immediately. Having debootstrap and thus all current sid > installs include gosmore and all its dependencies (including gpsd!!) is > a horrible bug, and it's breaking debootstrap entirely on at least ia64. Overrides updated. > ftpmasters: Please stop letting packages of > important priority through > without running them by the d-i team. This kind of breakage is happening > far too frequently. gosmore was accepted by Joerg on the 25th apparently. Cheers, aj signature.asc Description: Digital signature
Bug#503814: foo2zjs
On Fri, Oct 31, 2008 at 03:52:31PM +0100, Andreas Barth wrote: > 1. Currently, the submitter claims that the bug is serious, the > maintainer don't think so, and there is no decision by the release team > yet. So the current state of the bug isn't serious, but important. ie, the views (on serious severity) are prioritised as: - submitter's (default) - maintainer's (can override submitter, and in this case does) - release team's (can override maintainer and submitter) - tech-ctte (can override all three of the above) - general resolution (likewise) > 2. As per constitution, we (the tech ctte) only makes decision as last > resort. So currently, the next step would be for anyone who disagrees > with this bug not being release critical to ask the release team to > review the decision and maybe overrule it. I'm not sure I'd want the release team to be able to stop the tech-ctte from being involved simply by not making a decision, so I'm not sure I agree with this precisely. But in the general case, yes, I'd rather see the release team making the call on this. > tech ctte members, any opinion from you on that? Basically, +1. On a technical level, it seems to me there's two aspects: (1) can a package in main include a script that gets stuff from some random website really be considered DFSG-free/policy-compliant? (2) should we make sure that the stuff on the random website is also available from somewhere in Debian, in case the random website gets shut down, etc? (1) seems to be resolved as per Andi's comments, but I kind-of think (2) is actually the more important issue, and that the stuff getting downloaded should probably be packaged for non-free and possibly volatile, in order to remove the external dependency. The package in main would then get a "Suggests: foo2zjs-nonfree-drivers", and if the script gets moved to contrib, that could then become "Suggests: foo2zjs-nf-d | foo2zj-nf-d-getter-script". That assumes someones willing to do the legwork of packaging the drivers, of course, which might require negotiating permission to redistribute them from whoever owns them. Cheers, aj signature.asc Description: Digital signature
