Re: Move awk implementations from /usr/bin to /bin
❦ 31 décembre 2013 01:30 CET, m...@linux.it (Marco d'Itri) : >> Any thoughts? > The correct solution is completing #652459, which mounts /usr in the > initramfs. It is quite unclear why this bug is stalled. -- Let the machine do the dirty work. - The Elements of Programming Style (Kernighan & Plauger) signature.asc Description: PGP signature
Bug#733720: ITP: r-bioc-gviz -- Plotting data and annotation information along genomic coordinates
Package: wnpp Severity: wishlist Owner: Andreas Tille * Package name: r-bioc-gviz Version : 1.6.0 Upstream Author : Florian Hahne, Steffen Durinck, e.a. * URL : http://bioconductor.org/packages/release/bioc/html/Gviz.html * License : Artistic-2.0 Programming Lang: R Description : Plotting data and annotation information along genomic coordinates Genomic data analyses requires integrated visualization of known genomic information and new experimental data. Gviz uses the biomaRt and the rtracklayer packages to perform live annotation queries to Ensembl and UCSC and translates this to e.g. gene/transcript structures in viewports of the grid graphics package. This results in genomic information plotted together with your data. This package is the last missing precondition to upgrade r-bioc-cummerbund and maintained by the Debian Med team at svn://anonscm.debian.org/debian-med/trunk/packages/R/r-bioc-gviz/trunk/ -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231081655.9962.2362.report...@mail.an3as.eu
Re: Release sprint results - team changes, auto-rm and arch status
On 2013-11-29 04:14, Steve Langasek wrote: > Hi Niels, > Hi Steve, Sorry for the long overdue answer, > On Thu, Nov 28, 2013 at 09:04:56PM +0100, Niels Thykier wrote: >> kFreeBSD was a technology preview, and has not generated enough user >> interest to bring in sufficient install base to continue in this >> state. > > I wonder, how is the release team measuring this? For the other ports that > you mention, you've pointed to concrete technical problems that are in line > with the previously-documented release qualification guidelines. kfreebsd, > OTOH, is only listed as having "insufficient install base". But what is > sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are > greater than a number of our ports. > The formulation is very poor indeed. What we are concerned about is that kFreeBSD basically have not improved since it became a "technical preview". There is a related mailing thread only on d-release[1] > You rightly point out that keeping the architectures in testing has a cost, > because the architectures will block testing migration. But are the > kfreebsd archs actually causing testing blockages, in practice? If there > are such blockages, can you give us more information about how this has been > the case? > > Cheers, > I have been seeing quite a few packages FTBFS on kFreeBSD being stuck in sid with fixes for RC bugs in testing. Of course, this problem is by no means exclusive to kFreeBSD - other architectures (sometimes, even i386 or amd64) also "features" on that list of blockers. The only purely factual data I got currently, is the little snippet at the bottom of Britney's log. I am not sure how reliable it is, so I'll refrain from using it as an argument. But I think we (i.e. the distribution) could do with an accurate data source on this topic! On a related note, I suspect a good part of this problem would go away if we had an automated tool to deal with the case where a (sid-only) FTBFS is ignored. It happens sometimes that the maintainer does nothing (or, maybe, does not realise the package FTBFS on arch X) and neither the porters nor the buildd admins filed a bug for it. Then it is not until the package gets in way of a transition (or some other RC bug fix), that the package gets its RC bug. I have seen a package stuck in sid for at least 90 days and still no RC bug - the "only" thing wrong was an "Out of date binaries" on some architecture (don't remember which package nor which architecture). ~Niels [1] https://lists.debian.org/debian-release/2013/12/msg00416.html -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52c28fb9.9090...@thykier.net
Re: Move awk implementations from /usr/bin to /bin
On 31 December 2013 08:11, Vincent Bernat wrote: > ❦ 31 décembre 2013 01:30 CET, m...@linux.it (Marco d'Itri) : > >>> Any thoughts? >> The correct solution is completing #652459, which mounts /usr in the >> initramfs. > > It is quite unclear why this bug is stalled. I believe there were reservations about /etc portions of the patch series, which were asked to be "unbundled" and to be considered separately. I don't know if this was done, if not I guess I should come up with such patch on top of the proposed patch series, as one of the interested parties to get this resolved. -- Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhluj1kpjmlat1dgqteojwvdfpeyxhbqmu7ybkyvahju8...@mail.gmail.com
Bug#733743: ITP: libnih.la -- portable libnih implementation
Package: wnpp Owner: Dimitri John Ledkov Severity: wishlist * Package name: libnih.la Version : 1.0.4 (git snapshot) Upstream Author : Dimitri John Ledkov (DD), Scott James Remnant (DD) * URL or Web page : https://github.com/xnox/libnih/tree/kfreebsd http://libnih.la/ * License : GPL v2 Architecture: kfreebsd-any (hurd-any - maybe later) Description : portable libnih implementation I would like to package a temporary fork of libnih, which has been ported to kFreeBSD/eglibc platform. My plan for this package is to provide same packages as the src:libnih, but for non-Linux ports only. At the moment I have a port to kFreeBSD/eglibc. This is separate source package as the supported set of APIs is not yet fully same as of the Linux port of libnih. For example kqueue/kevent technology is not yet used to provide, e.g. file level notification as done with inotify in the linux port. Some of my patches have already been accepted upstream (https://github.com/keybuk/libnih), others are under review and some are not ready for submission yet. All libnih test-suite passes on kFreeBSD for those components that have been ported. Together with this effort, I am staging patches for Upstart itself for kFreeBSD/eglibc https://code.launchpad.net/~xnox/upstart/kfreebsd. It compiles, but at the moment is still incomplete. The test-suite does not pass yet and there are no kFreeBSD specific bridges yet (e.g. devd events, instead of udev, etc.). I'm hoping to have a bootable kFreeBSD/eglibc port soon, with full support ahead of Jessie freeze on 5th of November 2014. The requirements for libnih/kfreebsd, at the moment are, eglibc 2.18 & kFreeBSD kernels with fixed waitid/wait6 syscalls. These are all present in Debian experimental. Alternatively, if lower eglibc versions are required I could easily use wait6 syscall directely, without eglibc wrapper. In that case only requirements would be patched kFreeBSD kernels for the kern/184002 http://www.freebsd.org/cgi/query-pr.cgi?pr=184002&cat= bug which I discovered in FreeBSD. It's fixed in current/11, and is on track to be fixed in 9.2, 10 stable updates. I believe patch for that issue is already in debian packaging of FreeBSD kernels. I haven't started HURD port just yet, as I'm more familiar with FreeBSD. Regards, Dimitri. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87wqil13jl@ubuntu.com
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: > Apart from the termination clause, the GPLv2 is far more concise, > I don't see tivoization as a problem (it's the software I want to > protect, not anyone's combination of it with hardware), nor do I care > about compatibility with Apache 2.0 -- I do, however, care about > compatibility with GPL v2, which GPL v3 isn't. So your doomsday scenario is that if you license something GPLv2+, someone might fork and modify it to be GPLv3+, and then someone else with a different doomsday scenario can't incorporate those modifications into GPLv2-only software? -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231145450.ga20...@scru.org
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams wrote: > On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: >> Apart from the termination clause, the GPLv2 is far more concise, >> I don't see tivoization as a problem (it's the software I want to >> protect, not anyone's combination of it with hardware), nor do I care >> about compatibility with Apache 2.0 -- I do, however, care about >> compatibility with GPL v2, which GPL v3 isn't. > > So your doomsday scenario is that if you license something > GPLv2+, someone might fork and modify it to be GPLv3+, I was under the impression that forks couldn't change licenses. Is the scenario which Clint describes (legally) possible? -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3uoxx+f0_ca9lwe-n6p50y-cb4gs683w6cvfqvydw4...@mail.gmail.com
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
Matt, Yes, it is possible, but only the contributions of the fork would be GPLv3 only, the original GPLv2+ code would still be just that. Nevertheless, the final product would be GPLv3 only. Cameron Norman On Tue, Dec 31, 2013 at 6:59 AM, Matt Zagrabelny wrote: On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams wrote: On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: Apart from the termination clause, the GPLv2 is far more concise, I don't see tivoization as a problem (it's the software I want to protect, not anyone's combination of it with hardware), nor do I care about compatibility with Apache 2.0 -- I do, however, care about compatibility with GPL v2, which GPL v3 isn't. So your doomsday scenario is that if you license something GPLv2+, someone might fork and modify it to be GPLv3+, I was under the impression that forks couldn't change licenses. Is the scenario which Clint describes (legally) possible? -mz -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caolfk3uoxx+f0_ca9lwe-n6p50y-cb4gs683w6cvfqvydw4...@mail.gmail.com
Re: GPLv2-only considered harmful [was Re: GnuTLS in Debian]
On Tue, Dec 31, 2013 at 08:59:53AM -0600, Matt Zagrabelny wrote: > On Tue, Dec 31, 2013 at 8:54 AM, Clint Adams wrote: > > On Sun, Dec 29, 2013 at 03:50:06AM +0100, David Weinehall wrote: > >> Apart from the termination clause, the GPLv2 is far more concise, > >> I don't see tivoization as a problem (it's the software I want to > >> protect, not anyone's combination of it with hardware), nor do I care > >> about compatibility with Apache 2.0 -- I do, however, care about > >> compatibility with GPL v2, which GPL v3 isn't. > > > > So your doomsday scenario is that if you license something > > GPLv2+, someone might fork and modify it to be GPLv3+, > > I was under the impression that forks couldn't change licenses. Is the > scenario which Clint describes (legally) possible? The boilerplate says: "you can redistribute it and/or modify it [...] either version X of the License, or (at your option) any later version." As I understand it, assuming X is 2, this means I can redistribute this under 2, 2+, 3, 3+ without needing any persmissions from the copyright holder because they already said I can redistribute and modify it under "2 or later". But people of course aren't going to be interested in my version just because I change the license, but they might if I make some changes under this new license. Please note that that doesn't mean that if I get something from someone and it says "2 or later" that I can say I received it under 3. I received the 2 version, but I can change it to 3 if I wanted to. Kurt -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231154839.ga17...@roeckx.be
Bug#733763: ITP: libjs-optparse -- Command-line option parser for JavaScript applications
Package: wnpp Severity: wishlist Owner: Tonnerre LOMBARD * Package name: libjs-optparse Version : 1.0.5 Upstream Author : Johan Dahlberg * URL : http://github.com/jfd/optparse-js * License : Expat Programming Lang: JavaScript Description : Command-line option parser for JavaScript applications Optparse-js is a command line option parser for Javascript. It's slightly based on Ruby's implementation optparse but with some differences (different languages has different needs) such as custom parsers. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231172926.31983.626.report...@phileas.roam.internetputzen.com
Re: Release sprint results - team changes, auto-rm and arch status
On Tue, Dec 31, 2013 at 4:34 AM, Niels Thykier wrote: >> I wonder, how is the release team measuring this? For the other ports that >> you mention, you've pointed to concrete technical problems that are in line >> with the previously-documented release qualification guidelines. kfreebsd, >> OTOH, is only listed as having "insufficient install base". But what is >> sufficient? http://popcon.debian.org/ shows numbers for kfreebsd-* that are >> greater than a number of our ports. >> > > The formulation is very poor indeed. What we are concerned about is > that kFreeBSD basically have not improved since it became a "technical > preview". Out of curiosity, what metric are you using to quantify improvement? One metric that may worth thinking about is usage growth. Since the first kfreebsd release (Feb 2011), kfreebsd-amd64 usage [1] has grown about 400% (100 * 80 popcon submissions / 20 popcon submissions). kfreebsd-i386 [2] got a spike of adoption with squeeze and has indeed sort of stagnated since then. Looking at the popular architectures over the same timeframe, amd64 [3] grew at a very similar rate to kfreebsd-amd64 of about 333% (100 * 100,000 popcon submissions / 30,000 popcon submissions). i386 [4] also stagnated over the same timeframe, and may be on the decline. So, at least with respect to usage growth, similar results are seen for the popular linux architectures and kfreebsd over the last 3 years. As for absolute usage numbers, of course kfreebsd is much smaller than the most popular linux archs, with their 20 years of growth (vice 3). Assume debian had popcon in 1996 (3 years after the first linux release), I doubt the absolute popcon numbers would differ much from what we see today with kfreebsd. We would probably see somewhere in the 100s of submissions, with (and this is really hand wavy) something like 10x that number of actual installations. Best wishes, Mike [1] http://popcon.debian.org/stat/sub-kfreebsd-amd64.png [2] http://popcon.debian.org/stat/sub-kfreebsd-i386.png [3] http://popcon.debian.org/stat/sub-amd64.png [4] http://popcon.debian.org/stat/sub-i386.png -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CANTw=mm1yw8rjx1jpgtyu_dofyutoh4qd9f1son4ubs0-uc...@mail.gmail.com
Bug#733772: ITP: node-static -- RFC2616 compliant HTTP static-file server module, with built-in caching
Package: wnpp Severity: wishlist Owner: Tonnerre LOMBARD * Package name: node-static Version : 0.7.2 Upstream Author : Alexis Sellier * URL : https://github.com/cloudhead/node-static * License : Expat Programming Lang: JavaScript Description : RFC2616 compliant HTTP static-file server module, with built-in caching node-static has an in-memory file cache, making it highly efficient. It understands and supports conditional GET and HEAD requests. It was inspired by some of the other static-file serving modules, such as node-paperboy and antinode. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231190753.5414.7773.report...@phileas.roam.internetputzen.com
Bug#733821: ITP: sockjs-client -- WebSocket emulation - Javascript client
Package: wnpp Severity: wishlist Owner: Tonnerre LOMBARD * Package name: sockjs-client Version : 0.3.4 Upstream Author : Marek * URL : http://github.com/sockjs/sockjs-client * License : Expat Programming Lang: JavaScript Description : WebSocket emulation - Javascript client SockJS is a browser JavaScript library that provides a WebSocket-like object. SockJS gives you a coherent, cross-browser, Javascript API which creates a low latency, full duplex, cross-domain communication channel between the browser and the web server. Under the hood SockJS tries to use native WebSockets first. If that fails it can use a variety of browser-specific transport protocols and presents them through WebSocket-like abstractions. SockJS is intended to work for all modern browsers and in environments which don't support WebSocket protocol, for example behind restrictive corporate proxies. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20131231212851.1727.99541.report...@phileas.roam.internetputzen.com
Bug#733849: ITP: libb2 -- BLAKE2 family of hash functions
Package: wnpp Severity: wishlist Owner: Robert Ransom X-Debbugs-Cc: debian-devel@lists.debian.org * Package name: libb2 Version : 0.9 Upstream Author : cont...@blake2.net * URL : https://blake2.net/ * License : mostly CC0, but some files currently have no license Programming Lang: C Description : BLAKE2 family of hash functions The BLAKE2 family of hash functions is an improved version of the SHA-3 finalist BLAKE. . BLAKE2b is optimized for 64-bit platforms and produces up to 64 bytes of output; BLAKE2s is optimized for 32-bit platforms and produces up to 32 bytes of output. . BLAKE2bp and BLAKE2sp are parallel versions of BLAKE2b and BLAKE2s designed for increased performance on multicore and large-vector SIMD processors. . libb2 provides a portable implementation of BLAKE2, optimized implementations for IA-32 and AMD64 processors, and an interface layer that automatically selects the best implementation for the processor it is run on. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/cabqy+sq-rdnnzvrhvxwqzayazvjf8fqhgnmvv5sqlujyt3n...@mail.gmail.com
