Re: Bug#802595: ITP: node-defined -- return the first argument that is `!== undefined`
Jonathan Dowland wrote: > On Thu, Oct 22, 2015 at 09:16:59PM -0700, Josh Triplett wrote: > > "why" is because node (and other modern languages) make it easy to > > create a package for any particular bit of reusable code. That Debian > > fails to support that is Debian's problem, not upstream's. > > That's not a counter-argument to Steve's complaint. If we don't support > it, why are we uploading these packages? We support it just fine for individual packages; we only have (minor) problems in aggregate many such packages are 1) we have far more metadata and boilerplate per package, such that a small package wastes a slightly less small amount of mirror space (though still quite small), and 2) because of (1), ftp-masters and folks on -devel sometimes (inconsistently) push back on such packages. (1) is something we should work on, and it's a mild argument against gratuitously packaging things that *aren't* part of the depends or build-depends of some specific package we want in Debian (as in this case where the "tape" package needs node-defined). However, whether we fix (1) or not, (2) needs to stop. It's completely ridiculous to go to an upstream and say "your package is tiny, could you combine it with other unrelated tiny packages to make a less tiny package?". And any package needed for the (recursive) build-depends or depends of a more substantial package should not get pushback based on small package size. - Josh Triplett
Bug#803213: ITP: golang-gopkg-olivere-elastic.v2 -- Elasticsearch client for Golang
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-devel@lists.debian.org, pkg-go-maintain...@lists.alioth.debian.org Owner: Dmitry Smirnov * Package name: golang-gopkg-olivere-elastic.v2 Version : 2.0.12-1 Upstream Author : Oliver Eilhard * URL : https://github.com/olivere/elastic * License : Expat Programming Lang: Go Description : Elasticsearch client for Golang Provides an interface to the Elasticsearch server (http://www.elasticsearch.org/). It can manage full text indices, index documents, and search them. This is a dependency of "cadvisor". signature.asc Description: This is a digitally signed message part.
Re: Linux kernels v3.18.x and v4.2.x in sid
On 27/10/2015 10:31, Ian Campbell wrote: >> Hm, kernel.org says that 3.18 is the long-term support kernel. > > I'm afraid that LTS from kernel.org != stable support from Debian. > > Debian typically picks a single kernel version for a stable release and > supports it for the lifetime of that release. Of course the LTS support > from kernel.org for that particular version is valuable in achieving > that. For Jessie the chosen release is 3.16 (LTS in this case is by > Canonical not kernel.org) I got it, many thanks for the information. Branch 3.18 at kernel.org has now version 3.18.22 and will keep on increasing. Does it mean that Debian team ports commits from 3.18.x to 3.16 branch to provide LTS for it? > For the testing and unstable releases the Debian kernel team typically > tracks the regular mainline kernel releases (perhaps one or two behind > depending on $factors) with a view to arriving at a suitable LTS kernel > at some appropriate point before the freeze for the next Debian > release. > > Experimental is usually tracking upstream rcs more closely. > > This is why testing+unstable currently have moved on to 4.2 and > experimental has a 4.3 rc in it and 3.18 is no longer current in any > suite. -- With best regards, Dmitry
Bug#803195: RFA: spark -- SPARK programming language toolset
Package: wnpp Severity: normal I request an adopter for the spark package. The current upstream version of the package will not be updated. There is a new version of Spark, but it is very different from this one, see also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=713928 The package description is: SPARK is a formally-defined computer programming language based on the Ada programming language, intended to be secure and to support the development of high integrity software used in applications and systems where predictable and highly reliable operation is essential either for reasons of safety or for business integrity. . This package contains the tools necessary for checking if programs adhere to the SPARK rules and the tools to show freedom of runtime exceptions in those programs. To compile SPARK programs use any standards-compliant Ada compiler, such as GNAT.
Bug#803196: RFA: swi-prolog -- ISO/Edinburgh-style Prolog interpreter
Package: wnpp Severity: normal I request an adopter for the swi-prolog package. The package is actively maintained upstream, there are new releases every several months. The package description is: SWI-Prolog is a fast and powerful ISO/Edinburgh-style Prolog compiler with a rich set of built-in predicates. It offers a fast, robust and small environment which enables substantial applications to be developed with it. . SWI-Prolog additionally offers: . * A powerful module system * Garbage collection * Unicode character set handling * Unbounted integer and rational number arithmetic * Multithreading support * A powerful C/C++ interface * GNU Readline interface
Bug#803180: ITP: tboot -- Trusted Boot VMM module that uses Intel Trusted Execution
Package: wnpp Severity: wishlist Owner: Paulo Roberto Alves de Oliveira (aka kretcheu) * Package name: tboot Version : 1.8.3 Upstream Author : Intel Corporation * URL : http://sourceforge.net/projects/tboot/ * License : BSD Programming Lang: C Description : Trusted Boot, pre-kernel/VMM module that uses Intel Trusted Execution Trusted Boot (tboot) is pre-kernel/VMM module that uses Intel Trusted Execution Technology (Intel TXT) to perform a measured and verified launch of an OS kernel/VMM. . This version of tboot supports Intel (both retail and Software Development Platforms (SDPs)) and OEM systems that are Intel TXT-capable. . This version of tboot only supports both the Xen virtual machine monitor (versions >= 3.4) and Linux kernel versions >= 2.6.33.
Re: [Pkg-netatalk-devel] Bug#685878: Another year has passed, still no netatalk3
Adrian Knoth writes ("Re: [Pkg-netatalk-devel] Bug#685878: Another year has
passed, still no netatalk3"):
> We need to escalate this. Apparently, none of us has time to work on it,
> so external help is the only way forward I see.
>
> Looks like we're talking about ~10 FIXMEs in debian/copyrights. This is
> http://bugs.debian.org/751121.
>
> Any takers?
Thanks for showing us a good example and asking for help.
Thanks particularly to Jonas for his exemplary messages in the later
parts of this thread.
(I'm sorry that I don't have interest in netatalk so I'm not
volunteering.)
Regards,
Ian.
Re: Linux kernels v3.18.x and v4.2.x in sid
On Mon, 2015-10-26 at 14:55 +0100, Dmitry Katsubo wrote: > On 2015-10-25 07:11, Adam Borowski wrote: > > On Sat, Oct 24, 2015 at 10:59:47PM +0100, Simon McVittie wrote: > > > On 24/10/15 22:17, Dmitry Katsubo wrote: > > > > I would be happy to. However it does not allow me to use the latest > > > > kernel from 3.x branch (3.16 is now 1 year old). > > > > > > All Debian stable releases are intended to be used with the latest > > > kernel from the same suite. For Debian 8 that's the 3.16.y series, which > > > has long term support from Canonical, and receives security and > > > stability bug fixes in the Debian stable and security archives. > > Hm, kernel.org says that 3.18 is the long-term support kernel. I'm afraid that LTS from kernel.org != stable support from Debian. Debian typically picks a single kernel version for a stable release and supports it for the lifetime of that release. Of course the LTS support from kernel.org for that particular version is valuable in achieving that. For Jessie the chosen release is 3.16 (LTS in this case is by Canonical not kernel.org) For the testing and unstable releases the Debian kernel team typically tracks the regular mainline kernel releases (perhaps one or two behind depending on $factors) with a view to arriving at a suitable LTS kernel at some appropriate point before the freeze for the next Debian release. Experimental is usually tracking upstream rcs more closely. This is why testing+unstable currently have moved on to 4.2 and experimental has a 4.3 rc in it and 3.18 is no longer current in any suite. Ian.
Re: Linux kernels v3.18.x and v4.2.x in sid
On 2015-10-25 07:11, Adam Borowski wrote:
> On Sat, Oct 24, 2015 at 10:59:47PM +0100, Simon McVittie wrote:
>> On 24/10/15 22:17, Dmitry Katsubo wrote:
>>> I would be happy to. However it does not allow me to use the latest
>>> kernel from 3.x branch (3.16 is now 1 year old).
>>
>> All Debian stable releases are intended to be used with the latest
>> kernel from the same suite. For Debian 8 that's the 3.16.y series, which
>> has long term support from Canonical, and receives security and
>> stability bug fixes in the Debian stable and security archives.
Hm, kernel.org says that 3.18 is the long-term support kernel.
>> If you have hardware or software requirements that mean the stable
>> kernel is unsuitable for you, then the next most stable option is to use
>> the latest kernel from the corresponding backports repository. For
>> Debian 8 that's jessie-backports, which currently has Linux 4.2.y.
Thanks for the information that 4.2.x is backported. Actually what is
also important for me is the availability of btrfs-tools v4.2.x, which
is now available in sid. Perhaps there are plans to backport btrfs-tools
as well (or how does it happen with kernel-dependant utilities)?
>> Anything in snapshots.debian.org is entirely "as is"; if it has critical
>> bugs, they will never be fixed. Do not use snapshots.debian.org on
>> production systems.
>
> If you insist on using a 3.* kernel but 3.16 is too old for you, 3.18 _is_ a
> long-term support release, maintained by Sasha Levin until Jan 2017.
> You'd just need to compile it yourself. It's available from:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git
> branch linux-3.18.y.
>
> To do that, apt-get install kernel-package then:
> cp /boot/config-${your_old_kernel_version} .config
> make menuconfig #edit the config to your heart's content
> make-kpkg --rootcmd fakeroot --initrd -j`grep ^processor /proc/cpuinfo|wc -l`
> linux-image
> make-kpkg --rootcmd fakeroot --initrd -j`grep ^processor /proc/cpuinfo|wc -l`
> linux-headers
Compilation of the kernel is an option, but as builds are available in
snapshots, there is no strong need in that. Thanks for advise anyway. I
used to another way of compiling the kernel
$ apt-get source linux-image-3.2.0-4-686-pae; cd linux-3.2.35
$ fakeroot make -f debian/rules.gen binary-arch_i386_none_686-pae
which assures that all Debian-specific patches are applied on the top of
vanilla kernel. I am not sure if that is still preferable for latest
kernels.
--
With best regards,
Dmitry
