Bug#782988: (no subject)

[Tim Potter]

Package: wnpp
Severity: wishlist
Owner: Tim Potter 

* Package name: dwarf
  Version : 0.1.7
  Upstream Author : Juerg Haefliger 
* URL : https://github.com/juergh/dwarf
* License : Apache-2.0
  Programming Lang: Python
  Description : OpenStack API on top of libvirt/KVM

Dwarf is the OpenStack API on top of local libvirt/KVM. It supports
a subset of the Keystone, Glance and Nova APIs to manage images and
instances on the local machine.

This package is useful for virtualisation developers interested
in the OpenStack API as it allows a portion of the OpenStack REST
interface to be used without having to install a full version of
OpenStack.  Only libvirt and a few other packages are required.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420065711.11778.71930.reportbug@bf975a3c4a9c

Re: Experimental ddeb support in debhelper and lintian (Was: Re: -dbg packages; are they actually useful?)

[David Kalnischkies]

On Mon, Apr 20, 2015 at 09:50:00AM +0800, Paul Wise wrote:
> On Mon, Apr 20, 2015 at 1:10 AM, David Kalnischkies wrote:
> 
> >   I would presume most derivatives aren't using it either
> 
> Most derivatives appear to use reprepro but there is one using apt-ftparchive
> 
> https://wiki.debian.org/Derivatives/CensusFull

I knew it. I had a look at the census page especially as the list had
a discussion about it recently, but couldn't find the field there. Not
all derivatives seem to declare it and I looked at the wrong ones…

I know that a "few" are using it which haven't declared it. Ubuntu e.g.
does (at least that is what I figure from the bugreports).
The point was mainly: apt-ftparchive/jessie doesn't support it out of
the box, but its easy to change that if someone would need it.

(I have my doubts that all others do support it out of the box either)


> https://wiki.debian.org/Derivatives/Census/Lihuen

That is an interesting. The script they use does use the manual steps
'packages' and so on, it does mention 'generate' in a comment through.
Gonna talk to them (and d-derivatives@ at large) later. They aren't
supporting InRelease nor .xz for example which would be nice if they do.


> > I think there will be some work upon us to make ddebs supported well
> > (I invision something like a "apt-get debugsymbols foo" which installs
> > the package foo-dbgsym and maybe optionally also the debug packages of
> > the direct dependencies libfoo1 (libfoo-dbgsym) and libbar0.1
> > (python3-bar-dbgsym as it is the c-binding of a python library as you
> > might (not) have guessed).) but lets get them first, shall we? :)
> 
> As a user of debug packages I'd like installing foo-dbg to pull in all
> the -dbg packages I would need to dump a backtrace from GDB. So
> basically all recursive reverse dependencies.

That can be very quickly quite a set of packages. apt ~23, apititude
~40, mpv (similar to mplayer) ~159, kate (KDEs "notepad") ~465. [0]
That can be tuned by excluding non-libraries, but that has its own
drawbacks (private libraries shared between a very closely related set
of packages for example), aka:

For a quickshot direct dependencies are probably enough (personal
observation; the times I needed debug symbols for non-direct
dependencies are far and in between, but maybe I am just lucky).
If you wanna go fullcircle, its probably better to analyse a core-dump
for which symbols are needed exactly instead of getting everything.

I think Ubuntu has a tool dubbed apport-retrace (Debian has it in
experimental only) which is supposed to do that (but I just remember
hearing the name in this context, nothing more)

[0] very hacky approximation with
apt-cache depends apt --important --no-conflicts --no-replaces
--no-breaks --recurse -o APT::Architectures="amd64" -o
APT::Cache::ShowOnlyFirstOr=1 | grep -v '^ ' | wc -l


Best regards

David Kalnischkies


signature.asc
Description: Digital signature

Re: Work-needing packages report for Mar 27, 2015

[Fabian Greffrath]

Dear Geert,

Am Sonntag, den 19.04.2015, 15:48 +0200 schrieb Geert Stappers: 
> Ta ta the patch:

great, thank you! I had no idea that the patch for this would be so
straightforward.

> Visiting  http://bugs.debian.org/655889  didn't reveal any usertags yet to me.

Not yet, but this is a chicken-and-egg problem. I am afraid people won't
tag their bug reports if this feature is not available yet, whereas this
feature won't probably get implemented without the proper usertags
already in place. :/

> Thanks for sharing the idea.

Thank you very much for looking into this!

Cheers,

Fabian



-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1429516193.22351.8.ca...@greffrath.com

Re: Bits from the dpkg project: 1.17.x series, general news

[Mehdi Dogguy]

Le 2015-04-19 10:25, Cyril Brulebois a écrit :

Guillem Jover  (2015-04-18):

General News


* Raphaël Hertzog has stepped down as maintainer.


It seems a little sad there's not even a thanks or two, so here it is:
Thanks so much for all the hard (and not only technical) work, 
Raphaël!




Thanks buxy for all your (past and future) work on dpkg!

--
Mehdi


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/2fceaa864216ed26d856c61f089cc...@dogguy.org

Bug#782988: (no subject)

[Tobias Frost]

Package: wnpp
Followup-For: Bug #782988
Owner: Tobias Frost 

Did you want to file an ITP or RFP?
Please retitle the subject accordingly.

Thanks!

tobi


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420113102.10950.6347.report...@thecus.loewenhoehle.ip

Bug#782749: All browsers except Links2 crash constantly and iceweasel is broken

[Peter Spiess-Knafl]

The crash of browser could be affected through the following bug in
libcairo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767858

There is already a patch available, which Tobi and I verified that it
works for this specific bug.

Greetings
Peter


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5534eec3.9070...@spiessknafl.at

Bug#782749: All browsers except Links2 crash constantly and iceweasel is broken

[Paul Wise]

On Mon, Apr 20, 2015 at 8:19 PM, Peter Spiess-Knafl wrote:

> The crash of browser could be affected through the following bug in
> libcairo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767858
>
> There is already a patch available, which Tobi and I verified that it
> works for this specific bug.

So all that needs to happen now is someone needs to do an update in
the next wheezy point release.

https://www.debian.org/doc/manuals/developers-reference/developer-duties.html#maintain-stable
https://www.debian.org/doc/manuals/developers-reference/pkgs.html#upload-stable

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAKTje6GhHxg8V0zdsCQe1XRaDd0XQHLAWOmJDUCpgvTU8WtC=w...@mail.gmail.com

Re: Bits from the dpkg project: 1.17.x series, general news

[Thibaut Paumard]

Hi,

Le 18/04/2015 21:27, Guillem Jover a écrit :

>   Portability in dpkg is very important, to be able to support downstreams
>   and people who use it on other systems, or even package it in other
>   (non-GNU/Linux) distributions. But for many such systems I'm currently
>   porting purely through documentation. And as such, subsequent build and
>   run-time issues are clearly reactive, but I'd like to switch to a more
>   proactive model. So I'd very much appreciate if either interested
>   parties could provide access to such systems, or setup some kind of
>   continuous integration system from git. I'm thinking specifically of
>   systems such as non-glibc based Linux, FreeBSD, NetBSD, OpenBSD, Minix,
>   Solaris, Mac OS X, HP-UX and AIX.
> 


Possibly stating the obvious, but a you aware that fink (a package
management system for Mac OS X/Darwin) is based on a dpkg fork? Have you
been in touch with them?

The MacPorts projects also packaged dpkg (1.14.29).

I can presumably update, build and test the macports package
occasionally (it doesn't have an individual maintainer atm), but I
cannot set up an automated framework (although MacPorts does have
autobuilders).

Kind regards, Thibaut.


-- 




signature.asc
Description: OpenPGP digital signature

Bug#782749: All browsers except Links2 crash constantly and iceweasel is broken

[Adam D. Barratt]

On 2015-04-20 13:47, Paul Wise wrote:

On Mon, Apr 20, 2015 at 8:19 PM, Peter Spiess-Knafl wrote:


The crash of browser could be affected through the following bug in
libcairo: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767858

There is already a patch available, which Tobi and I verified that it
works for this specific bug.


So all that needs to happen now is someone needs to do an update in
the next wheezy point release.


Given that nothing about the patch appears to be sparc-specific, it 
should probably be applied in unstable first in case of regressions on 
other architectures (assuming that the bug meta-data is correct and the 
versions of cairo in unstable and experimental are affected).


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/ebdbdda048666f847aaf90ce1ad87...@mowgli.jungle.funky-badger.org

Re: GitHub “pull request” is useful and can be easily integrated'’

[Ondřej Surý]

On Mon, Apr 20, 2015, at 02:09, Brian May wrote:
> I have never actually used GitLab, so I can't actually comment on how
> good it is...

Perhaps you should, before you start suggesting thing based on
GitLab... ;-)

Anyway - GitLab is quite good these days and it has matured[1], but it's
a typical Ruby project - impossible to package and constant updates. I
finally gave up and I am running our work instance of Ruby projects
inside isolated RVM environments that includes GitLab and Redmine.

Also it still doesn't solve the issue the quarrel here is about - you
still need some account - in this case a local GitLab instance account
(well, Alioth could be used if that's in LDAP) to contribute.

This would make a strong sense only if we were to dump ForceForge and
replace it completely with GitLab (and finally replace all inferior VCSs
that makes my head to hurt with git :), but we all know that's not going
to happen (at least not in foreseeable future), so I personally think
that throwing DSA's resources on maintaining Debian GitLab instance
would be a huge waste.

I strongly think that Debian should own his data, but refusing external
services that could be used to improve Debian and DD/DM lives is not
helpful either. So I support setting up a Debian umbrella organization
on github, so DD/DM have an option to collaborate on packaging using
Github if they want to. Since we don't mandate any SCM for our packaging
work I don't think we should set up blacklist right now. Heck, there are
still packages with no VCS or with patches mangled inside upstream
sources. And in the worst case (GitHub closes without announcement) -
it's still a git (so we all have our local repositories), and we also
still have our source packages, right?

1. That said - it's by no means perfect and bugs still creep in, etc...

O.
--
Ondřej Surý  Knot DNS (https://www.knot-dns.cz/) – a
high-performance DNS server

Re: Bits from the dpkg project: 1.17.x series, general news

[Paul Wise]

On Mon, Apr 20, 2015 at 9:01 PM, Thibaut Paumard wrote:

> Possibly stating the obvious, but a you aware that fink (a package
> management system for Mac OS X/Darwin) is based on a dpkg fork?

There is also Cydia for Apple iOS systems, it uses APT, presumably dpkg too:

http://cydia.saurik.com/
https://en.wikipedia.org/wiki/Cydia

This project for Windows seems to have some sort of relationship with
dpkg, not sure exactly what:

https://en.wikipedia.org/wiki/Wpkg

Found both of these here:

https://en.wikipedia.org/wiki/Category:Dpkg

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6gn50ppeow0ejn7qa0zp+neqyyk_b_keihrs88abhx...@mail.gmail.com

Re: GitHub “pull request” is useful and can be easily integrated'’

[Antonio Terceiro]

On Mon, Apr 20, 2015 at 03:06:04PM +0200, Ondřej Surý wrote:
> On Mon, Apr 20, 2015, at 02:09, Brian May wrote:
> > I have never actually used GitLab, so I can't actually comment on how
> > good it is...
> 
> Perhaps you should, before you start suggesting thing based on
> GitLab... ;-)
> 
> Anyway - GitLab is quite good these days and it has matured[1], but it's
> a typical Ruby project - impossible to package and constant updates.

That is the case for any non-trivial, relatively new, free software
project *in any technology* these days.

And yet, we will get there eventually. Diaspora¹ is almost done, and
GitLab will follow at some point.

¹ not the existing diaspora-installer package, an actual diaspora
  package with its dependency tree properly packaged.

-- 
Antonio Terceiro 


signature.asc
Description: Digital signature

Bug#783008: ITP: orocos-utilrb -- Ruby toolkit: collection of useful Ruby classes

[Leopold Palomo-Avellaneda]

Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: orocos-utilrb
  Version : 2.8.0
  Upstream Author : Orocos Developers 
* URL : https://github.com/orocos-toolchain/utilrb
* License : CeCILL-B (BSD-like)
  Programming Lang: ruby
  Description : Ruby toolkit: collection of useful Ruby classes

Utilrb is yet another Ruby toolkit, in the spirit of facets. It includes
all the standard class extensions used in other projects.

- why is this package useful/relevant? is it a dependency for
  another package? 

Yes, orocos-utilrb belongs to orocos-toolchain (as project)

- do you use it? if there are other packages providing similar functionality, 
  how does it compare?

We use it in our lab. Not known. Orocos developers use it.

- how do you plan to maintain it? inside a packaging team (check list at
https://wiki.debian.org/Teams)? 

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/utilrb.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. All orocos-toolkit is a complex piece
of software.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420145342.23821.59518.report...@soho.upc.es

Bug#783015: ITP: easea -- EAsy specification of evolutionary algorithms

[Daniel Stender]

Package: wnpp
Severity: wishlist
Owner: Daniel Stender 

* Package name: easea
  Version : 1.0.3
  Upstream Author : Pierre Collet 
* URL : http://easea.unistra.fr/easea/index.php
* License : AGPL-3.0
  Programming Lang: C++
  Description : EAsy specification of evolutionary algorithms

EASEA (pronounced "easy") is an artificial evolution platform that allows
scientists with only basic skills in computer science to implement evolutionary
algorithms (EA) and to exploit the massive parallelism of many-core 
architectures
in order to optimize virtually any real-world problems (continous, discrete,
combinatorial, mixed and more (with Genetic Programming)).

EASEA provides an own high-level language for the specification of EAs. Many
elements for EAs are already pre defined. It features a compiler to
generate C++ object files from its .ez-files. It uses the CUDA development
toolkit to parallelize massively over graphic cards. Very easy to use.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420171012.2976.23071.report...@varuna.home

Bug#783016: ITP: orocos-typelib -- C/C++ type introspection library

[Leopold Palomo-Avellaneda]

Package: wnpp
Severity: wishlist
Owner: "Leopold Palomo-Avellaneda" 

* Package name: orocos-typelib
  Version : 2.8.0
  Upstream Author : Orocos Developers 
* URL : https://github.com/orocos-toolchain/typelib
* License : CeCILL-B (BSD-like)
  Programming Lang: C++ and Ruby
  Description : C/C++ type introspection library

This library offers an introspection mechanism for C/C++ value-types. I.e.
it offers a way to represent types, and to manipulate in-memory values
that are instances of those types.

A Ruby binding is included, which gives a fast and transparent
modification of C/C++ in-memory types from Ruby.

- why is this package useful/relevant? is it a dependency for
  another package? 

Yes, orocos-typelib belongs to orocos-toolchain (as project)

- do you use it? if there are other packages providing similar functionality, 
  how does it compare?

We use it in our lab. Not known is there's another with similar
functionality. 

- how do you plan to maintain it? inside a packaging team (check list at 
https://wiki.debian.org/Teams)? 

Inside debian-science team. I have done a preliminary work in:

http://anonscm.debian.org/cgit/debian-science/packages/orocos/typelib.git

- are you looking for co-maintainers? do you need a sponsor?

Yes, both. Any help will be welcome. All orocos-toolkit is a complex piece
of software.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420172400.20326.95327.report...@soho.upc.es

Bug #778876: linux-kbuild-3.19 missing from experimental

[Nick Morrott]

Bug #778876 is as yet unresolved after 2 months. I can't see any
discussion of this issue on this list or in the linux-image changelog
to explain its omission.

Obviously no DKMS support is available "out of the box as a result of
this. The linux-image-3.19* and linux-headers-3.19* packages are all
available.

linux-kbuild-3.18 and linux-tools-3.18 /are/ still listed as available
in experimental (along with a few armel/sh4 kernel images) - but with
no reverse dependencies as everything else kernel-wise in experimental
is now 3.19-based AFAICS.

Thanks for any input,
Nick


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CAOQWjw0uvLFPJyGr2FPsvfVir3O1YDERrhd2Rs=qlkcwvdm...@mail.gmail.com

Re: linking perl statically against libperl

[Niko Tyni]

On Sun, Apr 19, 2015 at 02:25:55PM +0200, Axel Beckert wrote:
> Niko Tyni wrote:
> > Cons:
> > E increased memory usage on systems running multiple perl processes
> > F possibly increased startup time for short perl scripts
> >   (but that may be a non-issue due to caching anyway?)
> 
> This sounds rather concerning to me. The again, I've never noticed any
> issues on i386 and kfreebsd-i386.

Right. I suspect the choice between static and dynamic linking doesn't
matter much on most systems in the real world, but I'd be interested
in arguments to the contrary.

> Since you wrote in #781476 that both, statically and dynamically
> linked perl binaries are built anyways and then one is thrown away
> depending on the architecture, what about letting the user
> respectively administrator choose?

I think this is overkill and we don't need more choice here.

> Either by
> 
> * shipping both in the perl package and using /etc/alternatives/perl
>   to choose between the two (perl-dynamic and perl-static) for
>   /usr/bin/perl, or

Even though update-alternatives is nowadays written in C and not
Perl, I still wouldn't trust the alternatives system enough to handle
Essential:yes functionality.

> * by providing two conflicting packages perl-base and
>   perl-base-static.

dpkg cries loudly (and rightly so) if you try to remove an Essential:yes
package like perl-base.

What I could do is to ship the dynamically linked binary separately
as something else than /usr/bin/perl, as it's basically just a tiny
wrapper for libperl. It's a bit tempting to put it in libperl5.20
and anticipate future Multi-Arch:same libperl packages by naming it
/usr/bin/perl-x86_64-linux-gnu or something like that...
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420183217.GA13981@estella.local.invalid

Re: Bits from the dpkg project: 1.17.x series, general news

[Guillem Jover]

Hi!

On Mon, 2015-04-20 at 15:01:48 +0200, Thibaut Paumard wrote:
> Le 18/04/2015 21:27, Guillem Jover a écrit :
> >   Portability in dpkg is very important, to be able to support downstreams
> >   and people who use it on other systems, or even package it in other
> >   (non-GNU/Linux) distributions. But for many such systems I'm currently
> >   porting purely through documentation. And as such, subsequent build and
> >   run-time issues are clearly reactive, but I'd like to switch to a more
> >   proactive model. So I'd very much appreciate if either interested
> >   parties could provide access to such systems, or setup some kind of
> >   continuous integration system from git. I'm thinking specifically of
> >   systems such as non-glibc based Linux, FreeBSD, NetBSD, OpenBSD, Minix,
> >   Solaris, Mac OS X, HP-UX and AIX.

> Possibly stating the obvious, but a you aware that fink (a package
> management system for Mac OS X/Darwin) is based on a dpkg fork? Have you
> been in touch with them?

Yeah, I'm aware (). I
try to keep track of the delta in all downstreams I know of, and try
to fix stuff on my own or merge what looks good. In the case of the fink
project, I've been in contact with them on and off and merged patches
from them and tracked down issues or got patches tested with their help.
But given that they are stuck with dpkg 1.10.x switching to the latest
branch has been a slow moving target for them. Also there's still at
least an unresolved reported test suite failure for dpkg-divert.

> The MacPorts projects also packaged dpkg (1.14.29).

Getting this to 1.17.x would be great.

> I can presumably update, build and test the macports package
> occasionally (it doesn't have an individual maintainer atm), but I
> cannot set up an automated framework (although MacPorts does have
> autobuilders).

Barring anything better, testing git master (or a released tarball if
that's easier) from time to time and reporting build or test suite
failures would already be great!

Thanks,
Guillem


--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420184631.ge12...@gaara.hadrons.org

Re: linking perl statically against libperl

[Axel Beckert]

Hi,

Niko Tyni wrote:
> > * shipping both in the perl package and using /etc/alternatives/perl
> >   to choose between the two (perl-dynamic and perl-static) for
> >   /usr/bin/perl, or
> 
> Even though update-alternatives is nowadays written in C and not
> Perl, I still wouldn't trust the alternatives system enough to handle
> Essential:yes functionality.

I agree. Essential:yes packages must work in general even if
unconfigure, hence this is no choice.

> > * by providing two conflicting packages perl-base and
> >   perl-base-static.
> 
> dpkg cries loudly (and rightly so) if you try to remove an Essential:yes
> package like perl-base.

Good point. I forgot about that, too.

Regards, Axel
-- 
 ,''`.  |  Axel Beckert , http://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-|  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420190315.gd5...@sym.noone.org

Re: Debian Archive architecture removals

[Samuel Thibault]

Hello,

Joerg Jaspert, le Mon 20 Apr 2015 00:22:08 +0200, a écrit :
> hurd-i386
> =
> Well before wheezy was released, we talked with the HURD porters, and
> they agreed to re-check their archive status just after the wheezy
> release[1]. The plan was to move the HURD port off ftp-master if it
> wasn't included as a technology preview or full release arch. HURD
> wasn't a part of Wheezy, and it's highly unlikely it will be in Jessie.
> 
> We'll be removing HURD, as discussed, from the ftp-master archive after
> the Jessie release.
> 
> [1] https://lists.debian.org/debian-hurd/2013/05/msg00018.html

I was thinking about coordinating a reply to this from the Hurd team, so
went back to re-read that thread from 2 years ago, and then got reminded
what bad time it happened at, and don't want to repeat that again.

I believe there is some discussion we want to have about debian
architecture ports, but can we delay that to *after* having happily
celebrated the Jessie release?

Thanks,
Samuel


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150420195221.ge3...@type.youpi.perso.aquilenet.fr

Re: Bug #778876: linux-kbuild-3.19 missing from experimental

[Adam Borowski]

On Mon, Apr 20, 2015 at 07:15:53PM +0100, Nick Morrott wrote:
> Bug #778876 is as yet unresolved after 2 months. I can't see any
> discussion of this issue on this list or in the linux-image changelog
> to explain its omission.

Experimental kernels hardly ever get their kbuilds uploaded, and even more
rarely on a timely basis.

> Obviously no DKMS support is available "out of the box as a result of
> this. The linux-image-3.19* and linux-headers-3.19* packages are all
> available.

If you need a newer kernel, you'd be better off using kernel-package
instead.  This way you're not tied by uploads, while still keeping the
benefits of dpkg.

Or, you can wait as we can expect a new kernel in unstable soon.

-- 
// If you believe in so-called "intellectual property", please immediately
// cease using counterfeit alphabets.  Instead, contact the nearest temple
// of Amon, whose priests will provide you with scribal services for all
// your writing needs, for Reasonable and Non-Discriminatory prices.


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150420224711.ga29...@angband.pl

Re: Bug #778876: linux-kbuild-3.19 missing from experimental

[James McCoy]

On Tue, Apr 21, 2015 at 12:47:11AM +0200, Adam Borowski wrote:
> On Mon, Apr 20, 2015 at 07:15:53PM +0100, Nick Morrott wrote:
> > Obviously no DKMS support is available "out of the box as a result of
> > this. The linux-image-3.19* and linux-headers-3.19* packages are all
> > available.
> 
> If you need a newer kernel, you'd be better off using kernel-package
> instead.

Or just the deb-pkg target in the upstream Makefile.

Cheers,
-- 
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy 


signature.asc
Description: Digital signature

Bug#783043: ITP: unibilium -- Simple, self-contained terminfo library

[James McCoy]

Package: wnpp
Severity: wishlist
Owner: James McCoy 

* Package name: unibilium
  Version : 1.1.2
  Upstream Author : Lukas Mai 
* URL : https://github.com/mauke/unibilium
* License : LGPL-3+
  Programming Lang: C
  Description : Simple, self-contained terminfo parsing library

Unibilium is a very basic terminfo library. It doesn't depend on curses
or any other library. It also doesn't use global variables, so it should
be thread-safe.

why is this package useful/relevant? is it a dependency for another
package?
- Dependency of Neovim (#752264)

how do you plan to maintain it?
- In collab-maint git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150421025140.13901.69101.report...@freya.jamessan.com

All Git workflows lack review / extras interchange format & thus decentralised unauthenticated review system

[Dimitri John Ledkov]

Heya,

Interesting points. Looking at bzr/launchpad it has a nifty feature:
email-in bzr bundle. Bzr bundle is like git-format-patch, however one can
pull from it rather than merely apply. (Essentially it has bencoded objects
at the end of the patch). The difference is complete round-trip (identical
commit id, preserved gpg signed commits). And launchpad accepts emailed in
bundles, constructs identical branch and can create merge proposal from it
(pull request) which is then managed by email for the originator. (Not sure
about account, I believe a ghost account is created that originator can
later "claim" if they wish to sign up). That's quite good, however the
coments are still managed in "server-side" database.

Gerrit has another cool thing. When I backed up git repositories, dropped
the instance and moved the repos back in, I was surprised to find all of
the reviews and comments back in place. Turns out all reviews are stored as
git notes essentially.

I hate that format-patch/am workflow does not preserve git commit-id and
gpg signatures. Request-pull workflow inflicts the pain of publicly hosting
git repository and keeping it accessible. Email is better - cause once one
receive it one can process it offline/disconnected. Loosing information is
not acceptable.

Ideally we should be able to support unauthenticated,
distributed/synchronised, lossless code review. Email round tripping is a
must, potentially generating git repo, store review comments as git notes,
and allow unauthenticated clone of that. Syndicating reviews would be cool
as well - that is allow pulling/mirroring reviews in from satellite
git-review repos. (E.g. consider a patch posted to two mailing lists, both
have active review on it, both generating review-git-repos, if one clones
both one should get combined review thread. Or if Admins actively mirror
each other, a combined review should be accessible).

Then I would expect e.g. Jenkins review manage it's own reviews of things,
that one can choose to combine with "human" review. And so on.

Pura Vida!
- Dimitri.

On 19 Apr 2015 2:01 am, "Ben Finney"  wrote:
>
> Neil Williams  writes:
>
> > On Sat, 18 Apr 2015 17:55:17 +1000
> > Ben Finney  wrote:
> >
> > > GitHub's pull request feature is proprietary to GitHub, it can only
> > > work between repositories hosted inside the GitHub silo, and any
> > > project using that feature is thereby locking its workflow to the
> > > single-vendor GitHub service.
> >
> > Not true. Simply and completely untrue.
> >
> > The pull request exists on github, fine.
>
> How can a collaborator Alice, with no GitHub account, get the pull
> request?
>
> > I can either choose to manually pick that out of the github interface
>
> I don't know what this means. How does that interact with the repository
> a collaborator Alice, with no GitHub account, is using with standard
> Git?
>
> > or I can choose to use my github account to merge that pull request
> > into a local branch.
>
> So this option supports my point that the GitHub pull request is siloed,
> and one must have an account with the single vendor in order to access
> it.
>
> > > Git repositories outside GitHub cannot interact with the GitHub pull
> > > request workflow using Git's own features.
> >
> > Untrue. I use github and git.linaro.org side by side and have applied
> > github pull requests as reviews on review.linaro.org
>
> How does a person Bob, using their GitHub repository, send a pull
> request to Carol using only their ‘review.linaro.org’ repository?
>
> Does Carol need a GitHub account and repository hosted at GitHub? If so,
> that's the point I'm making: GitHub's pull request can only be received
> and handled by another GitHub repository.
>
> > > They have chosen (or have never been aware they made the choice) to
> > > make it much harder to interact with them using the existing,
> > > standard, federated Git ‘request-pull’ feature, instead opting to
> > > exclude anyone who doesn't want an account on a specific vendor's
> > > service.
> >
> > Sorry, that makes no sense. Working with github as a second remote is
> > trivial.
>
> How does a collaborator Alice, with no GitHub account, access Bob's
> repository on GitHub and use the standard ‘git-request-pull’ to make a
> pull request to Bob? How does this interact with the GitHub pull request
> feature?
>
> How does Bob make a pull request to Alice, using GitHub's pull request
> feature, such that Alice can handle it using standard Git?
>
> Your descriptions so far seem to support the position that Git
> ‘request-pull’ is equal for all peers, is incompatible with a
> workflow based on GitHub pull requests, and that GitHub pull requests
> cannot be received and handled using standard Git commands.
>
> My point is to refute the notion that GitHub pull requests are open and
> equal for all peer repositories. Please show specifically where I'm
> wrong on that.
>
> --
>  \“Don't worry about people stealing your ideas. If your ideas |
>   `

Bug#783044: ITP: busted -- Lua unit testing framework focused on ease of use

[James McCoy]

Package: wnpp
Severity: wishlist
Owner: James McCoy 

* Package name: busted
  Version : 2.0.rc8
  Upstream Author : Olivine Labs, LLC.
* URL : http://olivinelabs.com/busted/
* License : MIT
  Programming Lang: Lua
  Description : Lua unit testing framework focused on ease of use

 busted test specs read naturally without being too verbose. You can
 even chain asserts and negations, such as assert.not.equals. Nest
 blocks of tests with contextual descriptions using describe, and add
 tags to blocks so you can run arbitrary groups of tests.
 .
 An extensible assert library allows you to extend and craft your own
 assert functions specific to your case with method chaining. A modular
 output library lets you add on your own output format, along with the
 default pretty and plain terminal output, JSON with and without
 streaming, and TAP-compatible output that allows you to run busted
 specs within most CI servers. You can even register phrases for
 internationaliation with custom or built-in language packs. 


why is this package useful/relevant? is it a dependency for
another package?
- Dependency for testing Neovim

how do you plan to maintain it?
- collab-maint git


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150421040757.15344.63464.report...@freya.jamessan.com

Re: linking perl statically against libperl

[Damyan Ivanov]

-=| Niko Tyni, 19.04.2015 11:43:09 +0300 |=-
> Cons:
> F possibly increased startup time for short perl scripts
>   (but that may be a non-issue due to caching anyway?)

I guess this needs some benchmarking. There is some penalty imposed by 
the dynamic linker when resolving a library symbols. That would slow 
a bit the perl+libperl compared to static-perl.


-- dam


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150421044954.ge3...@ktnx.net

Bug#783045: ITP: r-cran-seroincidence -- GNU R seroincidence calculator tool

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-seroincidence
  Version : 1.0.3
  Upstream Author : Chantal Quinten 
* URL : 
http://ecdc.europa.eu/en/data-tools/seroincidence-calculator-tool/Pages/default.aspx
* License : GPL
  Programming Lang: R
  Description : GNU R seroincidence calculator tool
 Antibody levels measured in a cross-sectional population samples can be
 translated into an estimate of the frequency with which seroconversions
 (new infections) occur. In order to interpret the measured
 cross-sectional antibody levels, parameters which predict the decay of
 antibodies must be known. In previously published reports (Simonsen et
 al. 2009 and Versteegh et al. 2005), this information has been obtained
 from longitudinal studies on subjects who had culture-confirmed
 Salmonella and Campylobacter infections. A Bayesian back-calculation
 model was used to convert antibody measurements into an estimation of
 time since infection. This can be used to estimate the seroincidence in
 the cross-sectional sample of population. For both the longitudinal and
 cross-sectional measurements of antibody concentrations, the indirect
 ELISA was used. The models are only valid for persons over 18 years. The
 seroincidence estimates are suitable for monitoring the effect of
 control programmes when representative cross-sectional serum samples are
 available for analyses. These provide more accurate information on the
 infection pressure in humans across countries.


Remark: This package is maintained by the Debian Med team at
   Vcs-Svn: 
svn://anonscm.debian.org/debian-med/trunk/packages/R/r-cran-seroincidence/trunk/


-- 
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/20150421051200.32127.20503.report...@mail.an3as.eu