Bug#913783: ITP: hexyl -- Command-line hex viewer with colored output

2018-11-14 Thread Wolfgang Silbermayr
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

   Package name: hexyl
Version: 0.2.0
Upstream Author: David Peter 
URL: https://github.com/sharkdp/hexyl
License: MIT/Apache-2.0
Description: hexyl is a simple hex viewer for the terminal. It uses
 colored output to distinguish different categories of
 bytes (NULL bytes, printable ASCII characters, ASCII
 whitespace characters, other ASCII characters and
 non-ASCII).



Re: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread James Clarke
On 15 Nov 2018, at 00:41, Michael Biebl  wrote:
> 
> Am 15.11.18 um 01:14 schrieb Michael Biebl:
>> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>> 
> I don't have experience with archive management for non-release
> architectures at all.
 
 The problem that we have is that it's not possible to upload a package
 to Debian which does not build any binaries on the release architectures,
 the archive would be removed from the archive immediately.
>> 
>> Is that really true?
>> Fwiw, the consolekit package, before it was removed completely, was
>> !linux-any, ie. it was only built for non-release architectures.
>> 
> 
> Forgot to add: src:consolekit did not build any arch:all package.
> 
> If you say, that this should not be possible, why did this work for
> consolekit?

Because it's not non-release, it's non-ftp-master, and hurd/kfreebsd are on
ftp-master despite being very non-release.

James



Re: Tornado 5 and salt

2018-11-14 Thread Paul Wise
On Thu, Nov 15, 2018 at 2:33 AM Benjamin Drung wrote:

> What do you think? Any reasons against it or do you have a better idea?

Sounds reasonable as a temporary measure, although it would be good to
ensure it doesn't become a permanent change :)

Please ensure you let the security team know about the duplicated codebase:

https://wiki.debian.org/EmbeddedCodeCopies

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread Michael Biebl
Am 15.11.18 um 01:14 schrieb Michael Biebl:
> Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
>> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
> 
 I don't have experience with archive management for non-release
 architectures at all.
>>>
>>> The problem that we have is that it's not possible to upload a package
>>> to Debian which does not build any binaries on the release architectures,
>>> the archive would be removed from the archive immediately.
> 
> Is that really true?
> Fwiw, the consolekit package, before it was removed completely, was
> !linux-any, ie. it was only built for non-release architectures.
> 

Forgot to add: src:consolekit did not build any arch:all package.

If you say, that this should not be possible, why did this work for
consolekit?



-- 
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: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread James Clarke
On 14 Nov 2018, at 23:15, Jeremy Bicha  wrote:
> 
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
>  wrote:
>> 
>> Hi Jeremy!
>> 
>> On 11/14/18 10:52 PM, Jeremy Bicha wrote:
>>> As requested, this is librsvg reintroduced for ports that don't
>>> supported the rustified librsvg yet. The name is because this is
>>> librsvg written in the C programming language (instead of in Rust).
>> 
>> Thanks a lot for your effort and the initiative, I really appreciate
>> the idea. I also apologize for my harsh wording in the heated the
>> discussion we had. I'm very glad that this - as it is always the case
>> in Debian - is leading to a productive solution. Great!
>> 
>>> Currently, the packaging builds the same binary package names as
>>> src:librsvg. There was a suggestion to use different binary names with
>>> versioned Provides (against the existing librsvg binary package
>>> names). I'm not sure that provides much benefit but we can discuss
>>> that.
>>> 
>>> I don't have the ability to do the initial upload for this package
>>> since I don't have easy access to do the binary build required for
>>> ftp-master NEW.
>>> 
>>> I don't have experience with archive management for non-release
>>> architectures at all.
>> 
>> The problem that we have is that it's not possible to upload a package
>> to Debian which does not build any binaries on the release architectures,
>> the archive would be removed from the archive immediately.
>> 
>> I assume what we could do is maybe have a package that is built from
>> multiple sources so that it builds different binary packages for the
>> Rust and non-Rust targets.
>> 
>> I have CC'ed James Clarke and Adrian Bunk who might be interested in
>> this discussion as well and probably can maybe help in the process.
>> 
>> Again, thanks a lot for the efforts and sorry for my heated and
>> unprofessional behavior.
>> 
>> Thanks a lot!
>> 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
> 
> Would an arch:all librsvg-c-doc package be sufficient for the "must
> build a binary package on a release architecture" requirement?

People might frown on it, but other source packages (ab)use this, and it
certainly works from a technical standpoint. I would hope there are no
objections to this approach. However, kfreebsd-* and hurd-i386 are on
ftp-master and don't (yet) have rust, so those will also keep the source
package around.

James



Re: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread Michael Biebl
Am 15.11.2018 um 00:15 schrieb Jeremy Bicha:
> On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz

>>> I don't have experience with archive management for non-release
>>> architectures at all.
>>
>> The problem that we have is that it's not possible to upload a package
>> to Debian which does not build any binaries on the release architectures,
>> the archive would be removed from the archive immediately.

Is that really true?
Fwiw, the consolekit package, before it was removed completely, was
!linux-any, ie. it was only built for non-release architectures.

Why not just upload librsvg-c as regular any package.
Once it has passed NEW, I would make a second, source-only upload which
lists only the non-rust architectures and I'd ask ftp-masters for the
removal of the binaries on the rust architectures.

Michael


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



Re: Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread Jeremy Bicha
On Wed, Nov 14, 2018 at 5:22 PM John Paul Adrian Glaubitz
 wrote:
>
> Hi Jeremy!
>
> On 11/14/18 10:52 PM, Jeremy Bicha wrote:
> > As requested, this is librsvg reintroduced for ports that don't
> > supported the rustified librsvg yet. The name is because this is
> > librsvg written in the C programming language (instead of in Rust).
>
> Thanks a lot for your effort and the initiative, I really appreciate
> the idea. I also apologize for my harsh wording in the heated the
> discussion we had. I'm very glad that this - as it is always the case
> in Debian - is leading to a productive solution. Great!
>
> > Currently, the packaging builds the same binary package names as
> > src:librsvg. There was a suggestion to use different binary names with
> > versioned Provides (against the existing librsvg binary package
> > names). I'm not sure that provides much benefit but we can discuss
> > that.
> >
> > I don't have the ability to do the initial upload for this package
> > since I don't have easy access to do the binary build required for
> > ftp-master NEW.
> >
> > I don't have experience with archive management for non-release
> > architectures at all.
>
> The problem that we have is that it's not possible to upload a package
> to Debian which does not build any binaries on the release architectures,
> the archive would be removed from the archive immediately.
>
> I assume what we could do is maybe have a package that is built from
> multiple sources so that it builds different binary packages for the
> Rust and non-Rust targets.
>
> I have CC'ed James Clarke and Adrian Bunk who might be interested in
> this discussion as well and probably can maybe help in the process.
>
> Again, thanks a lot for the efforts and sorry for my heated and
> unprofessional behavior.
>
> Thanks a lot!
> 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

Would an arch:all librsvg-c-doc package be sufficient for the "must
build a binary package on a release architecture" requirement?

Thanks,
Jeremy Bicha



Bug#913769: ITP: treepy-el -- generic tree traversal tools

2018-11-14 Thread Matteo F. Vescovi
Package: wnpp
Owner: Matteo F. Vescovi 
Severity: wishlist

* Package name: treepy-el
  Version : 0.1.1
  Upstream Author : Daniel Barreto
* URL or Web page : https://github.com/volrath/treepy.el
* License : GPL-3+
  Description : generic tree traversal tools

A set of generic functions for traversing tree-like data structures
recursively and/or iteratively, ported from clojure.walk and
clojure.zip respectively.


-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature


Bug#913767: ITP: graphql-el -- domain-specific language for creating and executing GraphQL queries

2018-11-14 Thread Matteo F. Vescovi
Package: wnpp
Owner: Matteo F. Vescovi 
Severity: wishlist

* Package name: graphql-el
  Version : 0.1.1
  Upstream Author : Sean Allred
* URL or Web page : https://github.com/vermiculus/graphql.el
* License : GPL-3+
  Description : domain-specific language for creating and executing GraphQL 
queries

GraphQL.el provides a generally-applicable domain-specific language
for creating and executing GraphQL queries against your favorite
web services.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature


Bug#913766: ITP: librsvg-c -- the pre-Rust version of librsvg

2018-11-14 Thread Jeremy Bicha
Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org, glaub...@physik.fu-berlin.de
Owner: jbi...@debian.org

Package Name: librsvg-c
Version: 2.40.20
Upstream Authors: Ximian, Eazel, Red Hat, Igalia, etc.
License : LGPL-2+
Programming Lang: C
Homepage: https://wiki.gnome.org/Projects/LibRsvg
Description: SAX-based renderer library for SVG files
 The rsvg library is an efficient renderer for Scalable Vector Graphics
 (SVG) pictures.

Other Info
--
As requested, this is librsvg reintroduced for ports that don't
supported the rustified librsvg yet. The name is because this is
librsvg written in the C programming language (instead of in Rust).

Packaging can be found at https://salsa.debian.org/gnome-team/librsvg-c

Currently, the packaging builds the same binary package names as
src:librsvg. There was a suggestion to use different binary names with
versioned Provides (against the existing librsvg binary package
names). I'm not sure that provides much benefit but we can discuss
that.

I don't have the ability to do the initial upload for this package
since I don't have easy access to do the binary build required for
ftp-master NEW.

I don't have experience with archive management for non-release
architectures at all.

Thanks,
Jeremy Bicha



Tornado 5 and salt

2018-11-14 Thread Benjamin Drung
Hi,

The salt package has been broken in unstable for several month now
since python-tornado upgraded to version 5. salt needs major changes to
support tornado 5 (which uses asyncio) [1]. I have waited for upstream
to support tornado 5, but the tornado 5 support is still work in
progress and I lost the hope that it will land in the development
branch or a release in time for the buster freeze. I don't want to ship
salt with a big patch to support tornado 5 risking to introduce bugs.

Therefore I like to:

1) Create a python3-tornado4 package containing the latest tornado 4.x
release. This package would rename the tornado module to tornado4 to
make it co-installable with python3-tornado.

2) Patch salt to use python3-tornado4 instead of python3-tornado.

Once salt supports tornado 5, the patch and the python3-tornado4
package can be dropped.

What do you think? Any reasons against it or do you have a better idea?

[1] https://github.com/saltstack/salt-jenkins/issues/995#issuecomment-424168351
[2] https://github.com/saltstack/salt/pull/49398

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

1&1 IONOS Cloud GmbH | Greifswalder Str. 207 | 10405 Berlin | Germany
E-mail: benjamin.dr...@cloud.ionos.com | Web: www.ionos.de

Head Office: Berlin, Germany
District Court Berlin Charlottenburg, Registration number: HRB 125506 B
Executive Management: Christoph Steffens, Matthias Steinberg, Achim
Weiss

Member of United Internet



Re: Opt-in to continue as DD/DM? (was: I resigned in 2004)

2018-11-14 Thread Jonathan Dowland

On Mon, Nov 12, 2018 at 09:43:20PM +0200, Lars Wirzenius wrote:

I support automatically retiring DDs and DMs that don't repond to a
ping, or don't upload, or don't vote, or otherwise show activity.


Me too.

I think "otherwise show activity" would need to be formally captured. I
suggest the exact algorithm(s) used by ;
any shortcomings there should be fixed there.

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄ Please do not CC me, I am subscribed to the list.