Bug#815871: ITP: holoviews -- visualization library for scientific or engineering data

[Sandro Tosi]

Package: wnpp
Severity: wishlist
Owner: Sandro Tosi 

* Package name: holoviews
  Version : 1.4.3
  Upstream Author : Jean-Luc R. Stevens, Philipp Rudiger, and James A. Bednar.
* URL : http://holoviews.org/
* License : BSD
  Programming Lang: Python
  Description : visualization library for scientific or engineering data

 HoloViews is a Python library that makes analyzing and visualizing scientific
 or engineering data much simpler, more intuitive, and more easily reproducible.
 Without HoloViews, there are typically many steps required before you can see
 your data, whether you use a GUI interactively or write a function or script to
 build up a plot. HoloViews instead lets you store your data in an annotated
 format that is instantly visualizable, with immediate access to both the
 numeric data and its visualization.

Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space

[Thomas Goirand]

On 02/24/2016 03:57 PM, Arturo Borrero Gonzalez wrote:
> On 23 February 2016 at 20:52, Jose-Luis Rivas  wrote:
>> On 23/02/16, 08:37am, Nikolaus Rath wrote:
>>>
>>> I'm actually rather shocked that a Debian Developer would consider
>>> letting this into the archive. Carl, I hope you just filed the ITP
>>> before having looked at the program?
>>>
>>
>> He wrote it.
>>
>> L6: # Copyright © 2013-2016 Carl Chenet 
>>
> 
> You are all late, the package seems to be in NEW already [0].
> 
> [0] https://ftp-master.debian.org/new/ftpbackup_0.3-1.html

It's even in unstable right now:
https://tracker.debian.org/pkg/ftpbackup

Cheers,

Thomas Goirand (zigo)

Re: [DH] Mass bug file for removal of deprecated features incl. compat 4

[Bastien ROUCARIES]

On Wed, Feb 24, 2016 at 7:39 PM, Niels Thykier  wrote:
> Hi,
>
> In continuation of [1], there is the next round of deprecated debhelper
> features that I would like to remove from debhelper.
>
>  * dh_desktop - 24 packages remaining
>  * No compat file - 119 packages remaining
>- Due to #811059 and #805405
>  * compat 4 - 402 packages remaining
>
>
> In total 489 /unique/ packages will be affected by this removal (some
> packages are affected by more than one deprecation).
>
>  * Deadline for comments on this: 9th of March
>- My deadlines below assumes I will be doing the mass bug filing
>  on (or shortly after) the 9th of March.

Could we raise  the tag during mass bug filling to error ?

Bastien
>
>  * Please see the attached "dd-list-20160224" to see if your packages
>are affected by one or more of the listed deprecations.
>
>  * I have attached the templates I intend to use for the mass bug
>filing.
>
>  * All data is based on lintian tags[2][3][4].
>- I used codesearch to check for usages of "DH_COMPAT=4 dh_foo",
>  but I did not find any uses of that pattern.
>
>
> Deadlines
> =
>
> I envisioned the following deadlines for these removals:
>
>  * dh_desktop: 1st of April (3 weeks from the bug filing)
>  * No compat file: 15th of April (5 weeks from the bug filing)
>  * compat 4: 15th of June (~3 months from the bug filing)
>
> Thanks,
> ~Niels
>
>
> [1] https://lists.debian.org/debian-devel/2015/09/msg00257.html
>
> [2] https://lintian.debian.org/tags/dh_desktop-is-deprecated.html
>
> [3] https://lintian.debian.org/tags/debhelper-compat-file-is-missing.html
>
> [4]
> https://lintian.debian.org/tags/package-uses-deprecated-debhelper-compat-version.html
>
> Note this includes packages that have not been updated and still declare
> compat 1, 2 and 3.  These are already RC buggy and have been removed
> from my count above.
>

Re: Debian package on Windows

[Guillem Jover]

Hi!

On Mon, 2016-02-22 at 14:05:33 +, Jonathan Dowland wrote:
> [ for -devel: this is a reply to a post to debian-apache, please see
>   https://lists.debian.org/debian-apache/2016/02/msg4.html ]

Inlining parts of that mail here:

> On Sat, 20 Feb 2016 01:09:18 +, Eric Mittelette wrote:
> > I contact you today about a crazy idea, but I hope it is a right kind of
> > crazy!

I have no problem with crazy, this one seems to me more shocking than
anything else. :)

> > I'm PM in the Visual C++ Team (VC Lib to be precise here at Microsoft),
> > we started to think about lib acquisition (still a painful process for
> > C++ on Windows) and we are imaging different options, one is to port
> > apt-get on Windows.

I'd assume that porting apt itself should be not too difficult. As
Jonathan has pointed out, you might want to get in contact with the
apt team though.

  

> > Porting Apt-Get mean using Debian format (we love it) and providing
> > Windows binary inside the package...

If by that you mean you'd also want to use dpkg, then that might be a
bit more difficult, as dpkg relies heavily on the underlying system to
provide POSIX semantics. Such as being able to remove opened files, or
replacing opened files with other opened files. Extensive use of fork(2).
And other similar things.

I'd be quite uncomfortable working around several of those things to
make dpkg work on such a best though. Because some of those are IMO
the basis for a sane package manager.

  

> > For doing that we imagine a light way process to adapt your actual build
> > script to generate Windows binaries using our latest Clang/c2 compiler
> > integration (meaning in theory just changing an env variable to switch
> > from gcc or Clang to our Clang/C2 compiler will be enough...)

Over the years there's been attempts to create various Windows ports
based on different runtimes:

  Debian GNU/Interix
  
  

Hmm it seems we even have a mailing list, which seems pretty dead to me,
but might give background information on previous attempts:

  

I think people in general have concluded that such a port would be mostly
useful only to cross-build, but not to run stuff.

There are other teams that have worked to use clang instead of gcc in
Debian proper:

  

> > The main idea here is to not reinvent the wheel for packaging management
> > and use something existing, powerful and well known by the community.
> >
> > Of course all the project will be open source (the new Microsoft J)

That sounds great. And it would be an interesting curiosity to end up
adding this "thing" to . :)

> > Do you want to be included in future discussions and provide feedback as
> > we get more details fleshed out?

I'm not sure if there's interest in a Windows port of Debian, but
porting specific projects might be of interest to the particular
teams, so you'd want to contact those individually perhaps.

Also if you'd like for any changes you end up doing to be included in
the original projects, I'd recommend including those upstream teams in
your discussions, so that they can tell you what is and what is not
acceptable, or a direction they'll agree to take or not.

Thanks,
Guillem

Re: [DH] Mass bug file for removal of deprecated features incl. compat 4

[Andreas Henriksson]

Hello.

On Wed, Feb 24, 2015 at 06:39:25PM +, Niels Thykier wrote:
> Hi,
> 
> In continuation of [1], there is the next round of deprecated debhelper
> features that I would like to remove from debhelper.
> 
>  * dh_desktop - 24 packages remaining
>  * No compat file - 119 packages remaining
>- Due to #811059 and #805405
>  * compat 4 - 402 packages remaining
[...]
> Utopia Maintenance Team 
>mdns-scan
[...]

I've team-uploaded a new mdns-scan which I hope should take this package
off the list.

Regards,
Andreas Henriksson

Re: Debian package on Windows

[Paul Wise]

On Thu, Feb 25, 2016 at 6:37 PM, Guillem Jover wrote:

> I think people in general have concluded that such a port would be mostly
> useful only to cross-build, but not to run stuff.

I could be useful to create a Debian GNU/ReactOS port to avoid the
proprietary software dependency of a cross-compiled-only port.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Adding SONAME to a shared object in KLEE

[Vincent Danjean]

Le 24/02/2016 08:30, Marko Dimjašević a écrit :
> Which brings us back to the original question - how to add the SONAME
> attribute to the library?

Did you try what have been said in this thread?

If yes, what did you do *exactly*?
Else, why not?

  Regards,
Vincent

Bug#815890: ITP: eccodes -- ECMWF decoding/encoding software library for GRIB, BUFR and GTS formats

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: eccodes
  Version : 0.13.1
  Upstream Author : ECMWF (The European Centre for Medium-Range Weather 
Forecasts)
* URL : https://software.ecmwf.int/wiki/display/ECC/ecCodes+Home
* License : Apache
  Programming Lang: C
  Description : ECMWF  decoding/encoding software library for GRIB, BUFR 
and GTS formats

ecCodes is an application programming interface developed by ECMWF for decoding 
and encoding messages in the following formats:

WMO FM-92 GRIB edition 1 and edition 2
WMO FM-94 BUFR edition 3 and edition 4
WMO GTS abbreviated header (only decoding in this release).

ecCodes is an evolution of GRIB-API, already a package in Debian.

A useful set of command line tools provide quick access to the messages. C, 
Fortran 90 and Python interfaces provide access to the main ecCodes 
functionality.

Bug#815893: ITP: python-jpy -- Bi-directional Python-Java bridge

[Alastair McKinstry]

Package: wnpp
Severity: wishlist
Owner: Alastair McKinstry 

* Package name: python-jpy
  Version : 0.8
  Upstream Author : Brockmann Consult GmbH
* URL : http://www.brockmann-consult.de
* License : Apache Version 2
  Programming Lang: Java, Python
  Description : Bi-directional Python-Java bridge

jpy is a bi-directional Java-Python bridge which you can use
to embed Java code in Python programs or the other way round.

Re: Bug#815675: ITP: ftpbackup -- Script to backups your data from a Debian system to a ftp space

[Carl Chenet]

On 24/02/2016 18:49, Nikolaus Rath wrote:
> On Feb 24 2016, Carl Chenet  wrote:
>> - First please Nikolau, spare me the "I don't believe Debian developers
>> blablabla", this try to patronize me is offending. Don't like the script
>> and you think it should not be in Debian or even exist? Fine, let's
>> discuss about it.
> [..]
>> - I'm really aware it is a simple script, but I was not aware that the
>> "simple is beautiful" motto was dead. 47 lines so? You want to refuse
>> any program with line numbers <= bigvalue? That's a weird argument.
>>
>> - The script makes the job for me. It is simple, dead simple and suits a
>> usecase , my use case, and, moreover, it is a really early release.
>> Buggy? It's not perfect, It does not pretend to. But it will improve, as
>> any other free software project.
> 
> Alright. In your opinion, what should be the standard for getting
> something packaged into Debian?
> 
> I think it's hard to draw a line, but it's not hard to see that
> ftpbackup is on the wrong side of it.
> 
> There is no minimum number of lines of code in a package, but that
> doesn't mean that any 47 line script needs to be packaged. There is no
> requirement for packages to be bug-free, but that doesn't mean that
> quality is not a criterion.
> 
> The fact that the script does the job *for you*, and is indeed *dead
> simple* are actually arguments *against* packaging it. Your private
> script doesn't need to be in Debian, nor we need something that is
> dead-simple yet still extremely fragile (you will not even get a
> notification if some files couldn't be backed up).
> 
> So please, Carl and ftpmasters, don't put this into Debian. 

Hi,

Following this discussion on debian-devel, I realize the program is not
ready to integrate Debian and so I requested ftpmasters to remove it
from the archive.

Thanks for the feedbacks to all participants,
-- 
Carl Chenet

Re: Bug#815893: ITP: python-jpy -- Bi-directional Python-Java bridge

[Adrien CLERC]

Le 25/02/2016 13:59, Alastair McKinstry a écrit :
>   Upstream Author : Brockmann Consult GmbH
> * URL : http://www.brockmann-consult.de
>
Hi,
I understand that the author want some credits, but unless I misread the
webpage, there is no mention of this project on it.
It should be better to have a link to https://github.com/bcdev/jpy or
https://pypi.python.org/pypi/jpy/ or http://jpy.readthedocs.org/en/latest/

Adrien

Bug#815910: ITP: libisa-l -- Intel(R) Intelligent Storage Acceleration Library

[Ondřej Nový]

Package: wnpp
Severity: wishlist
Owner: "Ondřej Nový" 

* Package name: libisa-l
  Version : 2.14
  Upstream Author : Intel Corporation
* URL :
   https://01.org/intel%C2%AE-storage-acceleration-library-open-source-version
* License : BSD
  Programming Lang: ASM, C
  Description : Intel(R) Intelligent Storage Acceleration Library

Collection of low-level functions used in storage applications.
Contains fast erasure codes that implement a general
Reed-Solomon type encoding for blocks of data that helps protect against
erasure of whole blocks. The general ISA-L library contains an expanded
set of functions used for data protection, hashing, encryption, etc.

I want to maintain this package inside openstack-pkg. It's optional
dependency for python-pyeclib/liberasurecode, which is used in Swift
object storage.

Re: Debian package on Windows

[Simon Richter]

Hi,

Eric Mittelette wrote:

> I'm PM in the Visual C++ Team (VC Lib to be precise here at Microsoft),
> we started to think about lib acquisition (still a painful process for
> C++ on Windows) and we are imaging different options, one is to port
> apt-get on Windows.

> Porting Apt-Get mean using Debian format (we love it) and providing
> Windows binary inside the package...

Heh. I like the MSI format (although it is a bit complex), because it
manages to pull everything into a descriptive rather than imperative
format, something I would've liked to see in dpkg for ages.

I'm currently organizing my toolchain around MSIs and MSMs -- shared
libraries exist as an MSM that installs the DLL along with the program,
and the MSM is distributed along with the header and import library
inside its own MSI, so in principle we could treat libraries in the same
way the VC runtime is handled.

The main difficulty in Windows is not so much the package format, but
rather the ecosystem. There is no central repository of trusted
libraries, because there are no curators, so every vendor must ship
their own copies of everything, and keep them up to date. The App store
cannot be used, because apps are heavily sandboxed, and I wouldn't trust
anything from that place anyway.

To share libraries between many projects, ABI tracking is needed (as the
Unix world does with the SONAME numbering), and libraries with different
ABI versions need to be concurrently installable. At the same time, a
mechanism is needed to update older ABI versions if needed (e.g. OpenSSL
and its many releases would definitely profit here).

Within Debian, that is easy, because we can simply recompile everything
that is linked against an old ABI, and even patch it if it fails to
compile, but that is not a real option in the Windows ecosystem.

Last but not least: The Windows ecosystem is easy in terms of licenses.
In general, if you link against something, you also ship it, so there
are very few debates on whether linking is allowed, because there are
only system libraries, and libraries distributed with the app, and
people generally read the licenses of libraries they ship, and make sure
they have the necessary rights.

In contrast, linking against a library that can be pulled in with a
single dependency declaration sometimes even happens by accident as an
indirect dependency, and create a situation where debian-legal needs to
sort out whether the package is distributable at all. This is not an
unsolvable problem, but it is something that the community needs to be
prepared for.

Putting my CI hat on: it is absolutely great to be able to install a
library into the build environment without having it globally registered
and available, so I can test different versions in parallel on the same
machine.

On Unix, this is easiest done with a chroot, so the "global"
availability isn't actually global. On Windows, I install packages below
the CI workspace, and point the current package build there. Any system
that loses me the ability to isolate would be difficult to use.

That said, it was a lot of work to set up the VC build for KiCad[1], and
I would welcome anything to make this easier. I've started on a simple
system that will make building MSI, MSM and MSP packages easier, but
that is still focused at generating a single installation package, and
possibly a few patch packages to ship incremental updates.

   Simon

[1] http://ci.kicad-pcb.org/view/Windows/



signature.asc
Description: OpenPGP digital signature

Making Debian ports less burdensome

[Steven Chamberlain]

Hi.

Packages are auto-removed from testing when they are RC-buggy.
Could we do something similar in unstable, for Debian's ports?

A FTBFS on any *one* release arch, delays testing migration on all
arches.  It makes the package RC-buggy, which could trigger its
autoremoval from testing if not handled.  Before release, the
out-of-date package must either be fixed, or ftpmaster requested to
remove it on the release arches where it FTBFS.

There are some things I think we should do routinely, and I suggest we
start to automate:

  * FTBFS bugs should be filed.  Perhaps not immediately, but when a
particular port is starting to delay testing migration.  Porters
need to actually be copied on these bugs, either to a mailing list
and/or usertagged would be nice;  since a lot of the time the
porters simply don't get any notification.

  * If left unfixed, the bugs should trigger an auto-removal from
unstable so that the package can migrate on the other arches.  It
also means the FTBFS bugs can be downgraded to non-RC, and helps
packages to get back into a releaseable state.  And it cleans up
the archive, allowing old source packages to go away after
transitions complete.

  * Some packages are too essential to autoremove.  The testing
autoremoval script has some list of those and we'd like to define
something similar for each port.  Then, the bulk of porting efforts
can be concentrated here, where it matters most.  RC bugs in these
packages might be reasonable justification for a port not being part
of the official release.

Hopefully we'd see ports with the 'core' packages in good shape, and
therefore being releaseable.  Even if some of them are very lightweight,
not having all the desktop environments, tasks, or OpenJDK for example.

Having a stable set of build-essential packages is important for ports
to get DSA-administered buildds, for developers to be able to run it,
and for the port to progress further.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Projects and mentors wanted for our participation in upcoming outreach programmes

[Hans-Christoph Steiner]

I'm proposing AndroidTools+Java again, like last summer.  We were quite
productive: got gradle 2.x, groovy, and lots of Android SDK tools
working and updated, and still more to be done:

https://wiki.debian.org/SummerOfCode2016/AndroidSDKToolsInDebian

.hc

Nicolas Dandrimont:
> Hey everyone,
> 
> Some of you have been waiting for it, and it's finally time: we are looking 
> for
> mentors and project ideas for Debian's next participation in outreach
> programmes, from May to August 2016.
> 
> Thanks to our sponsors, we will be participating in the 12th round of 
> Outreachy
> [1], and we have applied as a mentoring organization for the 2016 edition of
> Google Summer of Code [2].
> 
> [1] https://wiki.debian.org/Outreachy/Round12
> [2] https://wiki.debian.org/SummerOfCode2016
> 
> We now need your help to make Outreachy a success, and to secure our
> participation in GSoC: the Outreachy application period is about to start, and
> the GSoC organization selection process will happen shortly too, and we need 
> to
> show that we have project ideas :)
> 
> If you would like an intern to participate in your corner of Debian during the
> next few months, here is your opportunity! Go to our Projects Ideas page [3],
> describe your idea using our template, and give us a heads-up on the mailing
> list [4]. As we're participating in Outreachy, all kinds of projects are 
> welcome,
> whether technical in nature or not.
> 
> [3] https://wiki.debian.org/SummerOfCode2016/Projects (for both Outreachy and 
> GSoC)
> [4] soc-coordinat...@lists.alioth.debian.org (pending creation of a lists.d.o 
> list [5])
> [5] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798199
> 
> If you have any question about the programs, please let us know either via the
> mailing-list, or through our alias[6] for more private matters.
> 
> [6] outre...@debian.org
> 
> Cheers,
> 

Re: Making Debian ports less burdensome

[John Paul Adrian Glaubitz]

On 02/25/2016 06:41 PM, Steven Chamberlain wrote:
> Packages are auto-removed from testing when they are RC-buggy.
> Could we do something similar in unstable, for Debian's ports?

We have a testing distribution in debian-ports?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Making Debian ports less burdensome

[Adam Borowski]

On Thu, Feb 25, 2016 at 09:54:30PM +0100, John Paul Adrian Glaubitz wrote:
> On 02/25/2016 06:41 PM, Steven Chamberlain wrote:
> > Packages are auto-removed from testing when they are RC-buggy.
> > Could we do something similar in unstable, for Debian's ports?
> 
> We have a testing distribution in debian-ports?

We don't, which is a shame.  This badly hinders stuff like porting d-i to a
-ports architecture or making an unofficial release (mostly because of not
knowing when to binNMU and in-archive binNMUs conflicting with yours).

But it appears like Steven meant official release archs.  And here, it would
practically mean declaring everything but i386/amd64 unimportant -- I'd say
that while something like half of maintainers are helpful towards porters, a
big part ignores every architecture they don't personally use, and a small
minority is outright hostile.  Let's keeps the current system for release
archs -- it doesn't force you to port new stuff but requires a manual action
(filing an arch-specific RM) to allow regressions.

-- 
A tit a day keeps the vet away.

Re: Making Debian ports less burdensome

[Matthias Klose]

On 25.02.2016 22:45, Adam Borowski wrote:

On Thu, Feb 25, 2016 at 09:54:30PM +0100, John Paul Adrian Glaubitz wrote:

On 02/25/2016 06:41 PM, Steven Chamberlain wrote:

Packages are auto-removed from testing when they are RC-buggy.
Could we do something similar in unstable, for Debian's ports?


We have a testing distribution in debian-ports?


We don't, which is a shame.  This badly hinders stuff like porting d-i to a
-ports architecture or making an unofficial release (mostly because of not
knowing when to binNMU and in-archive binNMUs conflicting with yours).From


I cross built gcc-5 for m68k, sh4 and sparc64 (including gnat). However this is 
a pain if you have to deal with different binNMUs, either on the release archs 
or the ports. Cross built openjdk-8 for sh4 and sparc64 as well, however no 
success so far with m68k. Two reasons for this: mismatching binNMUs, or binNMUs 
not done across all archs, and binary-indep -dev packages, which make the 
situation just worse when unstable is out of sync, and should be forbidden for a 
set of core packages from my point of view.



But it appears like Steven meant official release archs.  And here, it would
practically mean declaring everything but i386/amd64 unimportant -- I'd say
that while something like half of maintainers are helpful towards porters, a
big part ignores every architecture they don't personally use, and a small
minority is outright hostile.


Well, if you see some architecture popping up as a release architecture for 
years now, you see the release team waving these archs for years on the promise 
that things will improve despite release criteria not being met, and you don't 
see any improvement, why would you care? Even security updates on some release 
architectures don't build.  I was told at a Debconf taking Debian as hostage 
when asking for the removal of such architectures, but as seen with kfreebsd, 
this seems to work fine as well.


Matthias

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Adam Borowski wrote:
> John Paul Adrian Glaubitz wrote:
> > > We have a testing distribution in debian-ports?
> 
> We don't, which is a shame.  This badly hinders stuff like porting d-i
> [...]

Without those things, many will struggle to install the port or
do much development on it.  Some options are:

 1. snapshot sid during the freeze, patch some packages and build
install media mostly by hand - I think hurd releases are done
something like this;

 2. debian-ports.org having one or more Britney instances that produce
'testing' suites - rolling releases basically;

 3. or make it easier somehow for ports to become release arches?

where I think the latter, stable releases, are mandatory to ever have
DSA-administered buildds, which in turn is a requirement for getting
into the official release.

> But it appears like Steven meant official release archs.

Yes.  I was thinking of https://bugs.debian.org/815885
(FTBFS on mips was blocking security fixes from migrating)

That was quite easily fixed by the porters, but it could have been
handled much better I think:

  * porters are typically not notified, unless someone files a FTBFS bug
and copies the appropriate mailing list - sometimes it never happens
at all;

  * it seems a patch was sent but wasn't attached to any BTS bug so it
got lost and not applied earlier;

  * *if* the bug stayed unfixed for weeks, delaying fixes from migrating
to testing, that's will annoy maintainers.  If no porters fixed this
bug, isn't it fair that doko could remove the out-of-date binaries
on that arch?  (Essentially leaving it without Java unless fixed).

For example, with kfreebsd it got too difficult to port many GNOME3
packages.  Removing GNOME3 and dependencies from kfreebsd took huge
pressure off maintainers and porters;  everyone was able to concentrate
on other things that really mattered - making GNOME3 better on linux;
and defaulting kfreebsd to another desktop that simply worked, so
porters could spend time on other things.

I saw another example of an arm64 FTBFS keeping a video driver for
MIPS systems out of testing.  An arch-specific removal is obviously
the right thing to do there.

> it would practically mean declaring everything but i386/amd64
> unimportant

I don't want that outcome, I value the ports very highly.  (OTOH
some might even say i386 is unimportant now...)

I want the opposite, making ports more convenient to have in the
official releases, so we can actually have more of them.  Perhaps
slimming them down to something really small (perhaps some not having
Java, or even no X11).  It is nice to be able to release *something*
from the official archive that is installable, stable and you can build
other packages on.  You can easily enough put a testing/sid chroot on
that system to install things that get ported later.

> it doesn't force you to port new stuff but requires a manual action
> (filing an arch-specific RM) to allow regressions.

I hope porters get notified first, and a chance to fix the issue.  A
FTBFS bug that gets no answer is supporting evidence for removal.
Filing those things can be tedious (which is why it often stays
unhandled for so long) so I like the idea of it being somewhat
automated.

Recently, Andreas Beckmann filed dozens of FTBFS-on-kfreebsd bugs.
Once I had them in my mailbox, it was really easy for me to reply to
each one, and I even attached a patch for more than half.  The effort
of filing the bug had actually put me off working on them.

In other cases the package really did want de-crufting;  if kfreebsd was
still in testing, we'd have needlessly held up those from migrating.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Matthias Klose wrote:
> [...] when unstable is out of sync, and should be forbidden for a set
> of core packages from my point of view.

Exactly;  there are some packages that can't just be removed, or
the whole port would be broken.  We could say that fixing RC bugs in
those packages is a requirement for the port to be releaseable.  I think
the architecture release criteria is really lacking that kind of detail
to judge ports by.  But now, we have a quite good definition of what are
'core' packages of each port, from the rebootstrapping work.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Re: Making Debian ports less burdensome

[Steven Chamberlain]

Steven Chamberlain wrote:
> Matthias Klose wrote:
> > [...] when unstable is out of sync, and should be forbidden for a set
> > of core packages from my point of view.
> 
> [...] We could say that fixing RC bugs in
> those packages is a requirement for the port to be releaseable.

This reminds me of:
https://wiki.debian.org/ReleaseGoals/CrossBuildableBase

To successfully rebootstrap, a set of core packages all must be able to
build, their build-depends must be installable, and (IIRC) sometimes
must have the same binNMU version.

Npt being able to re-bootstrap a port is probably an indication its
toolchain is in bad shape, so this is probably where porters need to be
more active.

I would like to think kfreebsd toolchain has improved a bit since I
started working in that area, and the feedback I get from Helmut when
things break is incredible helpful.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Work-needing packages report for Feb 26, 2016

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 737 (new: 12)
Total number of packages offered up for adoption: 186 (new: 0)
Total number of packages requested help for: 47 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   bgfinancas (#815702), orphaned 2 days ago
 Description: Personal finance manager
 Installations reported by Popcon: 11

   double-conversion (#815264), orphaned 5 days ago
 Description: routines to convert IEEE floats to and from strings
 Reverse Depends: hhvm libdouble-conversion-dbg
   libdouble-conversion-dev libinsighttoolkit4-dev libinsighttoolkit4.9
   libqt5qml5 python-minieigen python3-minieigen
 Installations reported by Popcon: 8721

   dvdwizard (#815228), orphaned 5 days ago
 Installations reported by Popcon: 481

   fomp (#815229), orphaned 5 days ago
 Installations reported by Popcon: 193

   gscanbus (#815232), orphaned 5 days ago
 Installations reported by Popcon: 116

   libfinance-quote-perl (#815261), orphaned 5 days ago
 Description: Perl module for retrieving stock quotes from a variety
   of sources
 Reverse Depends: gnucash webgui
 Installations reported by Popcon: 3823

   libofx (#815259), orphaned 5 days ago
 Description: library to support the Open Financial Exchange format
 Reverse Depends: gnucash grisbi homebank kmymoney libofx-dev
   libofx6-dbg ofx skrooge
 Installations reported by Popcon: 3709

   m2vrequantiser (#815334), orphaned 5 days ago
 Installations reported by Popcon: 442

   python-turbokid (#815696), orphaned 2 days ago

   silan (#815492), orphaned 4 days ago
 Installations reported by Popcon: 152

   videotrans (#815732), orphaned yesterday
 Installations reported by Popcon: 260

   volti (#815327), orphaned 5 days ago
 Reverse Depends: design-desktop parl-desktop
 Installations reported by Popcon: 476

725 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



No new packages have been given up for adoption, but a total of 186 packages
are awaiting adoption.  See http://www.debian.org/devel/wnpp/rfa_bypackage
for a complete list.



For the following packages help is requested:

   athcool (#278442), requested 4139 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 32

   awstats (#755797), requested 582 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4183

   balsa (#642906), requested 1614 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 701

   cardstories (#624100), requested 1767 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 5

   cups (#532097), requested 2455 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 168363

   cyrus-sasl2 (#799864), requested 155 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-admin 389-ds-base 389-ds-base-libs 389-dsgw
   adcli autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper (126 more
   omitted)
 Installations reported by Popcon: 191490

   developers-reference (#759995), requested 544 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 19041

   devscripts (#800413), requested 149 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (27 more
   omitted)
 Installations reported by Popcon: 13107

   ejabberd (#767874), requested 479 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-mam-mnesia ejabberd-mod-message-log
   ejabberd-mod-muc-log-http ejabberd-mod-post-log ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 771

   fbcat (#565