Bug#918961: ITP: httpdirfs -- filesystem client for HTTP directory listings

[Jerome Charaoui]

Package: wnpp
Severity: wishlist
Owner: Jerome Charaoui 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: httpdirfs
  Version : 1.0
  Upstream Author : Fufu Fang 
* URL : https://github.com/fangfufu/httpdirfs
* License : GPLv3
  Programming Lang: C
  Description : filesystem client for HTTP directory listings

httpdirfs is program that can be used to mount HTTP directory listings
(generated using an Apache DirectoryIndex, for example) as a virtual filesystem
through the FUSE interface. It supports HTTP basic authentication.




-BEGIN PGP SIGNATURE-

iQJGBAEBCgAwFiEEC1ozuKJtYBCcUJxsg+M719TdTKEFAlw3/SMSHGplcm9tZUBy
aXNldXAubmV0AAoJEIPjO9fU3Uyh0AQP/1P//XK9Q4ae//AWz/RoixHYelAKLUf0
lMwMcU6ZqpAOOnFMc+hbibjtYJUGK0TUK0kgYdCo4vqHxMunyP8qNkdzXUkt3CRl
FzTS+0o5KcFP6Hx19nCzT7fNEZKgNDVUAJVWILvRGdyOMowneJY+GME1KAkOW/Pa
9gj91y1ZalQeDaS4hDTvET7VYGU9SbmsyJbX5IQYCRP2ZKxQ3VEyFWTwxXML975Q
MQ4MBXI7zOGgAeS4TGnzGIz+alQKESOZB8fKQSShjWqDPZtZ9MCs/279na4W6Zo9
IZ2LFSfMTpKqNUBcCuOAMs7uLTVbEme0cRVuh9tEcFpc+QkM6IaKQusiY0KTJd3G
w8MQbrAx9t0RJrtZiv10/kAnQprnjRQt1oOLIJIXcJJPwnThKtSJ2FWk3WMrUetJ
qY8E+fLsDU0qNocvzNQliL2n/HnExpNt8BYFTVC1ZRBKciBR2AI1DrsyhiOvMzjn
Zx5037VC44FkMjujxECOktgogpuqC2jbup/uJW0nms0wo4Tn60xlKiv8p4mQUJBH
n4xvzcZsDyiMYtIVqI0aAMd2XCAAw7qZwzwL8cXUN7s+PJ5he/m7l/cADvWZWkXn
vXBCkNDuoOfIA1FZ+c/+ndcKVsJcG26SXCtNN00QMfuLFSglKCPRzEhOikojVHD9
PbaWFavGKhxO
=7LGx
-END PGP SIGNATURE-

Work-needing packages report for Jan 11, 2019

[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: 1331 (new: 14)
Total number of packages offered up for adoption: 153 (new: 2)
Total number of packages requested help for: 57 (new: 0)

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



The following packages have been orphaned:

   adplug (#918955), orphaned today
 Reverse Depends: adplay adplug-utils libadplug-dev mpd
   opencubicplayer
 Installations reported by Popcon: 2520
 Bug Report URL: https://bugs.debian.org/918955

   antpm (#918906), orphaned today
 Description: ANT+ information retrieval client for Garmin GPS
   products
 Reverse Depends: antpm-dbg
 Installations reported by Popcon: 66
 Bug Report URL: https://bugs.debian.org/918906

   cairo-clock (#918483), orphaned 4 days ago
 Description: Analog clock drawn with vector-graphics
 Installations reported by Popcon: 293
 Bug Report URL: https://bugs.debian.org/918483

   cmdpack (#918484), orphaned 4 days ago
 Description: cd image compress
 Installations reported by Popcon: 250
 Bug Report URL: https://bugs.debian.org/918484

   empty-expect (#918490), orphaned 4 days ago
 Description: Run processes and applications under pseudo-terminal
 Installations reported by Popcon: 90
 Bug Report URL: https://bugs.debian.org/918490

   flashplugin-nonfree (#918482), orphaned 4 days ago
 Description: installer package for adobe flash player
 Installations reported by Popcon: 12467
 Bug Report URL: https://bugs.debian.org/918482

   freedroidrpg (#918485), orphaned 4 days ago
 Description: rpg game influenced by paradroid
 Reverse Depends: freedroidrpg
 Installations reported by Popcon: 315
 Bug Report URL: https://bugs.debian.org/918485

   garmin-forerunner-tools (#918907), orphaned today
 Description: retrieve data from Garmin Forerunner/Edge GPS devices
 Reverse Depends: garmin-plugin
 Installations reported by Popcon: 219
 Bug Report URL: https://bugs.debian.org/918907

   garmin-plugin (#918908), orphaned today
 Description: browser plugin for communication with the fitness
   websites
 Installations reported by Popcon: 117
 Bug Report URL: https://bugs.debian.org/918908

   grdesktop (#918489), orphaned 4 days ago
 Description: GNOME frontend for the rdesktop client
 Installations reported by Popcon: 905
 Bug Report URL: https://bugs.debian.org/918489

   libio-lockedfile-perl (#918487), orphaned 4 days ago
 Description: IO::LockedFile Class - supply object methods for
   locking files
 Reverse Depends: libauthen-htpasswd-perl liblog-loglite-perl
 Installations reported by Popcon: 105
 Bug Report URL: https://bugs.debian.org/918487

   num-utils (#918486), orphaned 4 days ago
 Description: dealing with numbers on command line
 Installations reported by Popcon: 153
 Bug Report URL: https://bugs.debian.org/918486

   openambit (#918909), orphaned today
 Description: utilities for Suunto Ambit sport watches
 Reverse Depends: openambit
 Installations reported by Popcon: 24
 Bug Report URL: https://bugs.debian.org/918909

   pepperflashplugin-nonfree (#918488), orphaned 4 days ago
 Description: pepper flash installer package
 Installations reported by Popcon: 4660
 Bug Report URL: https://bugs.debian.org/918488

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



The following packages have been given up for adoption:

   docdiff (#918886), offered today
 Description: Compares two files word by word / char by char
 Reverse Depends: hiki
 Installations reported by Popcon: 120
 Bug Report URL: https://bugs.debian.org/918886

   quickml (#918887), offered today
 Description: Very-easy-to-use mailing list system
 Installations reported by Popcon: 9
 Bug Report URL: https://bugs.debian.org/918887

151 older packages have been omitted from this listing, see
https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 771 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: autodeb-worker debci-worker
 Installations reported by Popcon: 1167
 Bug Report URL: https://bugs.debian.org/846328

   balsa (#642906), requested 2664 days ago
 Description: An e-mail client for GNOME
 Installations reported by Popcon: 685
 Bug Report URL: https://bugs.debian.org/642906

   broadcom-sta 

Debian Bug Squashing Party in Austin, TX, USA - Jan 25-27 2019

[Kurt Kremitzki]

Hello,

I'm organizing a BSP in Austin, TX at the end of this month. The venue
is the ATX Hackerspace [1], a collaborative workspace which is open
24/7, and so the plan is to have a weekend-spanning bug squashing party.
I plan on focusing on Debian Science packages and stuff in the FreeCAD
ecosystem, but no matter your interest, please come and join us in
squashing some bugs!

You can find more info on the Debian Wiki page for the event [2].

- Kurt

[1] https://atxhs.org
[2] https://wiki.debian.org/BSP/2019/01/us/Austin

Bug#918942: ITP: pcg-cpp -- PCG Random Number Generation (C++ Edition)

[Alexander GQ Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander GQ Gerasiov 

* Package name: pcg-cpp
  Version : 0.98.1
  Upstream Author : Melissa O'Neill and PCG Project contributors
* URL : https://github.com/imneme/pcg-cpp
* License : Apache-2.0 OR MIT
  Programming Lang: C, C++
  Description : PCG Random Number Generation (C++ Edition)

implementation of the PCG family of random number generators, which are fast, 
statistically excellent, and offer a number of useful features.

Full details can be found at the PCG-Random website. This version of the code 
provides many family members -- if you just want one simple generator, you may 
prefer the minimal C version of the library.

pcg random lib is needed by ClickHouse DBMS

Bug#918941: ITP: metrohash -- library with a set of state-of-the-art hash functions for non-cryptographic use cases

[Alexander GQ Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander GQ Gerasiov 

* Package name: metrohash
  Version : 1.1.3
  Upstream Author : Andrew Rogers
* URL : https://github.com/jandrewrogers/MetroHash
* License : Apache
  Programming Lang: C++
  Description : library with a set of state-of-the-art hash functions for 
non-cryptographic use cases


MetroHash is a set of state-of-the-art hash functions for non-cryptographic use 
cases. They are notable for being algorithmically generated in addition to 
their exceptional performance. The set of published hash functions may be 
expanded in the future, having been selected from a very large set of hash 
functions that have been constructed this way.

Fastest general-purpose functions for bulk hashing.
Fastest general-purpose functions for small, variable length keys.
Robust statistical bias profile, similar to the MD5 cryptographic hash.
Hashes can be constructed incrementally (new)
64-bit, 128-bit, and 128-bit CRC variants currently available.
Optimized for modern x86-64 microarchitectures.
Elegant, compact, readable functions.

metrohash lib is needed by ClickHouse DBMS

Bug#918932: ITP: libdivide -- header-only C/C++ library for optimizing integer division

[Alexander GQ Gerasiov]

Package: wnpp
Severity: wishlist
Owner: Alexander GQ Gerasiov 

* Package name: libdivide
  Version : 1.0
  Upstream Author : ridiculous_fish 
* URL : https://github.com/ridiculousfish/libdivide
* License : Zlib or Boost
  Programming Lang: C/C++
  Description : header-only C/C++ library for optimizing integer division

libdivide.h is a header-only C/C++ library for optimizing integer division, it
has both a C API and a C++ API. This is a summary of how to use libdivide's
testing tools to develop on libdivide itself.

See https://libdivide.com for more information on libdivide.

Package is used by ClickHouse dbms.

Re: Handling of entropy during boot

[Michael Stone]

On Thu, Jan 10, 2019 at 03:57:00PM +0100, Michael Biebl wrote:

with possible solutions like installing haveged


It still isn't clear to me that this is actually secure, so I'm not sure 
we should be telling people to do it in release notes.


Mike Stone

Bug#918924: ITP: datalad-container -- DataLad extension for working with containerized environments

[Yaroslav Halchenko]

Package: wnpp
Severity: wishlist
Owner: Yaroslav Halchenko 

* Package name: datalad-container
  Version : 0.2.2
  Upstream Author : DataLad Team 
* URL : http://www.datalad.org
* License : Expat
  Programming Lang: Python
  Description : DataLad extension for working with containerized 
environments

 This extension enhances DataLad (http://datalad.org) for working with
 computational containers.

Re: Handling of entropy during boot

[Stefan Fritsch]

On Thu, 10 Jan 2019, Michael Biebl wrote:

> Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> > On Thu, 10 Jan 2019, Michael Biebl wrote:
> >>> ACK, we also had to do the same in Grml[.org] and our latest release
> >>> (2018.12). Now we automatically enable haveged when users boot using
> >>> the ssh boot option (which is something Grml specific, taking care
> >>> of setting user password and invoking the ssh service).
> >>
> >> And this is a perfect example why crediting the seed file (#914297) is
> >> not a solution to this problem.
> > 
> > While I still think this case should be handled by documentation, let's 
> > try to find a way forward that we can agree upon.
> > 
> > I think the absolute minimum we need something that prints a big fat 
> > warning during boot if the RNG is not yet initialized, points out that 
> > further services may block and that the admin should add entropy sources 
> > like virtio-rng or rdrand. The time when this warning should be printed 
> > should probably be before network is started, because if the admin has 
> > configured vpn services in /etc/network/interfaces, those will already 
> > block because of lack of entropy.
> > 
> > A second thing we need is a service that finishes when the RNG is 
> > initialized and that has a suitable large timeout for starting (maybe one 
> > day?). Services that need randomness can then depend on that service and 
> > don't need to set their own timeout to huge values. Also it is a lot 
> > easier to see what's wrong if the "wait for RNG" service is blocking than 
> > if some random network service is blocking.
> > 
> > More things should be done but maybe we can figure those out while we 
> > implement the above two things. Can we agree on this?
> > 
> 
> I'd prefer having this documented in the release notes:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916690
> with possible solutions like installing haveged, configuring virtio-rng,
> etc. depending on the situation.

That would be an extremely user-unfriendly "solution" and would lead to 
countless hours of debugging and useless bug reports.

Re: Handling of entropy during boot

[Michael Biebl]

Am 10.01.19 um 15:51 schrieb Stefan Fritsch:
> On Thu, 10 Jan 2019, Michael Biebl wrote:
>>> ACK, we also had to do the same in Grml[.org] and our latest release
>>> (2018.12). Now we automatically enable haveged when users boot using
>>> the ssh boot option (which is something Grml specific, taking care
>>> of setting user password and invoking the ssh service).
>>
>> And this is a perfect example why crediting the seed file (#914297) is
>> not a solution to this problem.
> 
> While I still think this case should be handled by documentation, let's 
> try to find a way forward that we can agree upon.
> 
> I think the absolute minimum we need something that prints a big fat 
> warning during boot if the RNG is not yet initialized, points out that 
> further services may block and that the admin should add entropy sources 
> like virtio-rng or rdrand. The time when this warning should be printed 
> should probably be before network is started, because if the admin has 
> configured vpn services in /etc/network/interfaces, those will already 
> block because of lack of entropy.
> 
> A second thing we need is a service that finishes when the RNG is 
> initialized and that has a suitable large timeout for starting (maybe one 
> day?). Services that need randomness can then depend on that service and 
> don't need to set their own timeout to huge values. Also it is a lot 
> easier to see what's wrong if the "wait for RNG" service is blocking than 
> if some random network service is blocking.
> 
> More things should be done but maybe we can figure those out while we 
> implement the above two things. Can we agree on this?
> 

I'd prefer having this documented in the release notes:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916690
with possible solutions like installing haveged, configuring virtio-rng,
etc. depending on the situation.

Michael

-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Handling of entropy during boot

[Stefan Fritsch]

On Thu, 10 Jan 2019, Michael Biebl wrote:
> > ACK, we also had to do the same in Grml[.org] and our latest release
> > (2018.12). Now we automatically enable haveged when users boot using
> > the ssh boot option (which is something Grml specific, taking care
> > of setting user password and invoking the ssh service).
> 
> And this is a perfect example why crediting the seed file (#914297) is
> not a solution to this problem.

While I still think this case should be handled by documentation, let's 
try to find a way forward that we can agree upon.

I think the absolute minimum we need something that prints a big fat 
warning during boot if the RNG is not yet initialized, points out that 
further services may block and that the admin should add entropy sources 
like virtio-rng or rdrand. The time when this warning should be printed 
should probably be before network is started, because if the admin has 
configured vpn services in /etc/network/interfaces, those will already 
block because of lack of entropy.

A second thing we need is a service that finishes when the RNG is 
initialized and that has a suitable large timeout for starting (maybe one 
day?). Services that need randomness can then depend on that service and 
don't need to set their own timeout to huge values. Also it is a lot 
easier to see what's wrong if the "wait for RNG" service is blocking than 
if some random network service is blocking.

More things should be done but maybe we can figure those out while we 
implement the above two things. Can we agree on this?


Now, in which packages should those services be shipped? Should they be 
part of the individual init system packages or into some central package 
like initscripts? Any opinions?

Re: Handling of entropy during boot

[Stefan Fritsch]

On Wed, 9 Jan 2019, Theodore Y. Ts'o wrote:

> On Wed, Jan 09, 2019 at 09:58:22AM +0100, Stefan Fritsch wrote:
> > 
> > There have been a number of bug reports and blog posts about this, despite 
> > buster not being release yet. So it's not that uncommon.
> 
> Pointers, please?  Let's see them and investigate.  The primary issue
> I've been aware of to date has been on Fedora systems, and it's due to
> some Red Hat specific changes that they made for FEDRAMP compliance
> --- and Red Hat has dealt with those issues.
> 
> If there are problems for people using Debian Testing, we should
> investigate them and understand what is going on.

Some other people already have sent you a few pointers (thanks!). The 
reason why I am looking into this is that it affects apache2 (see 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914297 ). Apache does 
not call getrandom itself but libssl does, and it definitely needs secure 
randomness for diffie-hellman. So there is nothing that can or should be 
fixed in apache.

More links are at the end of 
https://lists.debian.org/debian-devel/2018/12/msg00184.html

Also, the thread on debian-kernel pointed to by Ben Hutchings is an 
interesting read, I had not noticed that before.


> > No, that's utterly wrong. If it's a hassle to use good entropy, people 
> > will use gettimeofday() for getting "entropy" and they will use it for 
> > security relevant purposes. In this way, you would achieve exactly the 
> > opposite of what you want.
> 
> If *users* do this, then if they end up releasing credit card numbers
> or PII or violate their customers privacy which brings the EU's GDPR
> enforcers down on then, it's on *their* heads.  If *Debian* makes a
> local Debian-specific change which causes these really bad outcomes,
> then it's on *ours*.

Since many users and developers will take the shortest path to a "working" 
service, we must make sure that the secure way just works.

> > Any program that does secure network connections needs entropy for 
> > Diffie-Hellman. And even seeds for hash buckets can be security relevant. 
> > You really don't want that people need to distinguish between 
> > security-critical and stupid uses of entropy, because they WILL get it 
> > wrong.
> 
> Sure, this is why developers need to investigate the bugs.  You said
> you provided links, but I couldn't find any in your e-mail messages or
> earlier ones on this thread.  Perhaps I missed them; in which case, my
> apologies.   Can you please send/resend those links?
> 
> Can you please prioritize reports from people running Debian Unstable
> or Debain Testing?  As I said above, these issues tend to be very
> distro specific, especially when distros are messing around with
> crypto-related libraries in order to keep the US Government happy.

As far as I can see, all reports are from unstable/testing only, because 
stable does not cause getrandom() to block (see 
https://lists.debian.org/debian-release/2018/05/msg00130.html ).

Re: Handling of entropy during boot

[Michael Biebl]

Am 10.01.19 um 14:23 schrieb Michael Prokop:
> * Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]:
>> On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
> 
>>> Pointers, please?  Let's see them and investigate.  The primary issue
>>> I've been aware of to date has been on Fedora systems, and it's due to
>>> some Red Hat specific changes that they made for FEDRAMP compliance
>>> --- and Red Hat has dealt with those issues.
> 
>> In Kali I had to install haveged by default due to this problem.
>> We got reports of having to wait up to 5 minutes to get to their desktop.
>> We got reports of sshd not working on first boot (in fact just taking too
>> long to start).
> 
> ACK, we also had to do the same in Grml[.org] and our latest release
> (2018.12). Now we automatically enable haveged when users boot using
> the ssh boot option (which is something Grml specific, taking care
> of setting user password and invoking the ssh service).

And this is a perfect example why crediting the seed file (#914297) is
not a solution to this problem.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#918910: ITP: resvg -- SVG rendering library in Rust

[Andrej Shadura]

Package: wnpp
Severity: wishlist
Owner: Andrej Shadura 

* Package name: resvg
  Version : 0.5.0
  Upstream Author : Evgeniy Reizner
* URL : https://github.com/RazrFalcon/resvg
* License : MPL-2.0
  Programming Lang: Rust
  Description : SVG rendering library in Rust

resvg is:
* a Rust library
* a C library
* a CLI application

to render SVG files based on a static SVG Full 1.1 subset (see SVG
support for details).

The core idea is to make a fast, small, portable, multiple backend SVG
library designed for edge-cases.

SVG can be rendered to a raster image or to a backend's canvas (e.g. to
a QWidget via QPainter).

One of the major differences from other rendering libraries is that
resvg does a lot of preprocessing before rendering. It converts shapes
to paths, resolves attributes, removes groups and invisible elements,
fixes a lot of issues in malformed SVG files. Then it creates a simple
render tree with all elements and attributes resolved. And only then it
starts to render. So it's very easy to implement a new rendering
backend.

Re: Handling of entropy during boot

[Michael Prokop]

* Raphael Hertzog [Thu Jan 10, 2019 at 12:24:45PM +0100]:
> On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:

> > Pointers, please?  Let's see them and investigate.  The primary issue
> > I've been aware of to date has been on Fedora systems, and it's due to
> > some Red Hat specific changes that they made for FEDRAMP compliance
> > --- and Red Hat has dealt with those issues.

> In Kali I had to install haveged by default due to this problem.
> We got reports of having to wait up to 5 minutes to get to their desktop.
> We got reports of sshd not working on first boot (in fact just taking too
> long to start).

ACK, we also had to do the same in Grml[.org] and our latest release
(2018.12). Now we automatically enable haveged when users boot using
the ssh boot option (which is something Grml specific, taking care
of setting user password and invoking the ssh service).

We saw exactly what Daniel documented at
https://daniel-lange.com/archives/152-Openssh-taking-minutes-to-become-available,-booting-takes-half-an-hour-...-because-your-server-waits-for-a-few-bytes-of-randomness.html

regards,
-mika-
-- 
https://michael-prokop.at/  || https://adminzen.org/
https://grml-solutions.com/ || https://grml.org/


signature.asc
Description: Digital signature

Re: Remainings of old versions of packages in UDD / tracker

[Andreas Tille]

Hi Mattia,

On Thu, Jan 10, 2019 at 11:38:18AM +0100, Mattia Rizzolo wrote:
> > using rmadison is a very quick way to notice this, as you will see the
> > discrepancy in the architecture list.
> 
> I see that you started filing a lot of RM requests to remove many of
> such outdated binaries.

Yes.  I'm close to finished.  One riddle is remaining:


$ rmadison r-other-mott-happy | grep  " unstable "
r-other-mott-happy | 2.4-2 | unstable   | source
r-other-mott-happy | 2.4-3 | unstable   | source


> However I need to ask whether you try to understand what was blocking
> those builds.  For example, looking at one of the last bugs you opened
> to remove outdated binaries of r-cran-luminescence, I see those don't
> seem to build just because r-cran-sp is missing a binNMUs against a new
> enough r-base, which is something simple to take care of.

Well, all cases where unreleased architectures (kfreebsd-*) and I need
to admit that I do not invest much time into this question since we have
currently way more urgent open issues.  I'm pretty sure it is because of
missing Build-Depends but I did not checked.

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Handling of entropy during boot

[Raphael Hertzog]

Hi,

On Wed, 09 Jan 2019, Theodore Y. Ts'o wrote:
> Pointers, please?  Let's see them and investigate.  The primary issue
> I've been aware of to date has been on Fedora systems, and it's due to
> some Red Hat specific changes that they made for FEDRAMP compliance
> --- and Red Hat has dealt with those issues.

In Kali I had to install haveged by default due to this problem.
We got reports of having to wait up to 5 minutes to get to their desktop.
We got reports of sshd not working on first boot (in fact just taking too
long to start).

https://bugs.kali.org/view.php?id=5124
https://bugs.kali.org/view.php?id=4994
https://bugs.kali.org/view.php?id=5011

I haven't looked, but it seems likely that thin.service is trying to
generate some keys on initial startup. Which explains why it gets stalled.

Cheers,
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: https://www.freexian.com/services/debian-lts.html
Learn to master Debian: https://debian-handbook.info/get/

Bug#918887: RFA: quickml -- Very-easy-to-use mailing list system

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wnpp
Severity: normal

I request a maintainer for quickml package.
This program is implemented in Ruby language.

Unfortunately upstream development was dead
a long long time ago.
Codes are bit old and would be better to update for
newer Ruby version.

Even so, I believe this list server software is
very unique and useful.

Thanks,
- -- 
Kenshi Muto
km...@debian.org
-BEGIN PGP SIGNATURE-
Comment: Processed by Mailcrypt 3.5.9 

iQIzBAEBCAAdFiEEnMxcIsEJVbWPVaUbHSHIPcRS4PwFAlw3JQQACgkQHSHIPcRS
4PzuJBAAk7yDEjofjQpEC2x3XO9f/PxJF+bKWImtkbrpq313vOC4Gw0o/KJWYe7N
6AdO5ZeJnxzobIfWdMUWSKErTAcM5yIA1kZBGunCrWK5YIRhPML8zlALjEDMFzhU
ZscRiBwKKyGP0pwWg7Xdkn4K/Ze86F4IfNfLfYIauqQLkNfdIkJ+thxq7hYWb7ld
ovc9uYDkqrUu5WKikJT9lKKJJ9EaGO9/+SjEkP2eotzy/4B0Q+Y+GeolRmkq5kJk
OgA8V6MjcyefUfj2x6YgjZFACxDSqf14BRRDqiJzPDvV9a3/y3kd0IPpl5mjYWDi
l2/KdsyHdQwsYqhaDW0bBwfaS6CttfbyMNMBUGY7pzbRF+17G0RArIxxDEV7YQSW
NtFo8MX0VDvVPz1n0cVyehh1tUiYmoRvENXZJ73WiwkjdAWQdEIwcQWqxTWzs5oh
gU795mIhbyrD9/PfvitzrRNIJJPrxmZCHaC+Zjbt+0l92lRwqybzOnVCcOT8swP9
f2n1h7jJrflfn6zeJzeZfBZaERGETaC0w5wdAYIDEk+ts6G7it8uPQV2wdLiQRNo
y8BeHCsmFc+GDQXtfGCGKTYilBb0wi72+w/n0/oXWm1DeT9DYR1Ct9uQIPPnWhUm
3t8xh3+2eTaxPscB/Xke50hC/wueBYCwZO6xVZFJfq8dTpH1mkE=
=Jvro
-END PGP SIGNATURE-

Bug#918886: RFA: docdiff -- Compares two files word by word / char by char

[Kenshi Muto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Package: wnpp
Severity: normal

I request a maintainer for docdiff package.
This program is implemented in Ruby language.

Upstream Development had been suspended a long time but
recent days it boots again https://github.com/hisashim/docdiff

Thanks,
- -- 
Kenshi Muto
km...@debian.org
-BEGIN PGP SIGNATURE-
Comment: Processed by Mailcrypt 3.5.9 

iQIzBAEBCAAdFiEEnMxcIsEJVbWPVaUbHSHIPcRS4PwFAlw3I+MACgkQHSHIPcRS
4Pw8xA/9EIA4NlFTaRVF6YYmunUvqEJ5bNBgSLiaJ2T+cbOcYa763B+2IBc2OC39
OASx4wwDSLI/Wez0G4Y21/J+Ng264Gt4SgtEfgieAD/xk/3fC+UCcubHlv/IPaKa
6YNoRy4Cq3xuEVg9Ig2lxit5FJtEvj4WrfyIYNwPtzhtYe23dTjFdSMicUMy75sg
h+FlT/X9mQIjbL8qe7uyDif4IBUIePUY0eYDS+LYuHGuuvUUHeHiPVCX/ojgzGkt
Gxaocl01KhYVHC7mf51Gjm41y07CicOZ9H3+O1VZXa3JQQDFus+CcdsiRtw7fu33
NQ9ZIR7SdDQzLSMQCKj95OvAS/ZVA6N6mglA/HVLYmG20O3P2xJfDkDW/IpymF8k
cc2zNae7r3egL/856yL54yAmLcprzCP+eKytCN87hpCGZb0m/UjNTEqiY3PUykhD
CLcbZaacA5ohMmjyZGIZqjrmgSFyTv9HZJayUO8jYpXeKgt/GqKpWAvD3TYV93m5
E8rTkKbT0PzGtmag7xiTEAOHyt5RuAM3/3KHlV45cj06YB4M0LdpTDLXwg2kq0Rx
1pWeU6fFOgpDQ8hLcu1tIfDAE3QDR1lzPjarr+hJlGz0jmsLorhDEgHI7zUQnqLy
b5vrwzWx4D+5AGduOwrzW3HJI5BjNgsGM16uyKEI5GzBmidIeN0=
=b4w9
-END PGP SIGNATURE-

Re: Remainings of old versions of packages in UDD / tracker

[Mattia Rizzolo]

Hi Andreas,

On Tue, Jan 08, 2019 at 01:30:08PM +0100, Mattia Rizzolo wrote:
> cruft versions, usually hold up due to outdated binaries.
> 
> In this case of r-bioc-deseq2, the reason is outdated binaries in
> kfreebsd-amd64 and kfreebsd-i386.
> 
> 
> using rmadison is a very quick way to notice this, as you will see the
> discrepancy in the architecture list.

I see that you started filing a lot of RM requests to remove many of
such outdated binaries.
However I need to ask whether you try to understand what was blocking
those builds.  For example, looking at one of the last bugs you opened
to remove outdated binaries of r-cran-luminescence, I see those don't
seem to build just because r-cran-sp is missing a binNMUs against a new
enough r-base, which is something simple to take care of.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature