Bug#958294: ITP: dmlc-core -- A common bricks library for building scalable and portable distributed machine learning.

[Mo Zhou]

Package: wnpp
Severity: wishlist
Owner: Mo Zhou 

* Package name: dmlc-core
* URL : https://github.com/dmlc/dmlc-core/
* License : Apache-2.0
  Programming Lang: C++
  Description : A common bricks library for building scalable and portable 
distributed machine learning.

under deep learning team.

Bug#958295: RFH: clipit -- lightweight GTK+ clipboard manager

[Andrej Shadura]

Package: wnpp
Severity: normal

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

I request assistance with maintaining the clipit package.

The package was previously maintained by Dmitry Smirnov, who gave up
on it at some point; I attempted to take it over, but with upstream
not taking care of it, and unable to fix bugs, I switched to diodon[1]
myself, so I’m not using ClipIt anymore, and I cannot take it over
upstream, unfortunately; I have too many other things on my plate at
the moment.

Parcellite, from which ClipIt was forked, had had some life breathed
into it temporarily, and I believe the annoying UTF-8 support bug has
been fixed, but otherwise it’s been equally dead upstream for years[2].

Diodon seems to be the least buggy of the three, and it also supports
images, which neither ClipIt or Parcellite do. I’ve been using it for
about a year now, and so far I’ve not had any troubles with it.

In the more than half a year since I orphaned the package (#941081),
nobody volunteered to take this over but since I’m still set as the
maintainer in the currently uploaded release, I see that people are
still using it and there are more annoying bugs than just what I
observed.

My biggest complaint about ClipIt was that since the last upstream
release it became very unreliable: items sometimes don’t get copied into
the clipboard, sometimes wrong items get pasted, and also it somehow
mangles with the selection making it disappear immediately in some apps
like GNOME Terminal and LibreOffice.

Since the upstream developer disappeared a year ago, there’s been some
user activity on GitHub, but nobody seems to have fixed the most
annoying issues.

The best course of action now would be to take this package over
upstream and get it fixed, or at least get it fixed in Debian. A
lighter-weight alternative would be reverting it in Debian (sans the
icon changes I made) to the previous upstream version, which, while less
performant, was much more stable. Another way of fixing this would be
removing clipit completely and recommending users to switch over to
diodon; maybe also automatically migrate them over?

If you intend to take this package over, please please make sure that you
actually can get it sorted, it is not a trivial job, as I have painfully
learnt myself.

As I described in #909309, given all this, I’m not very motivated to do any
work myself since migrating to diodon have got my clipboard preserving
needs sorted, at least for now.

References:
 [0]: https://github.com/CristianHenzel/ClipIt
 [1]: https://packages.qa.debian.org/d/diodon.html
 [2]: https://github.com/rickyrockrat/parcellite/commits/master
 [3]: https://bugs.debian.org/941081
 [4]: https://bugs.debian.org/909309

- -- 
Cheers,
  Andrej

-BEGIN PGP SIGNATURE-

iQFIBAEBCAAyFiEEeuS9ZL8A0js0NGiOXkCM2RzYOdIFAl6dZFgUHGFuZHJld3No
QGRlYmlhbi5vcmcACgkQXkCM2RzYOdKTGwgAreBK6k1Br7PZS3SOWnRQC11Q0+SM
0tC4kuyE8BMNcDyaLuyI+VboCCgX6+RiO5MP1cSGcgLC56ErMWUCs/2kCdrSd2T6
VkT1TPCv4Osoz9xX4ymQ68wmnkuhQRlEoPm8sVvMsqLX2g86e1lNKv1PaNCgso0V
Q6hcjoPZnKTdDnBvLpSAKOKTnpfotcgbdLsdbINP2tAM5HbXE139NBtDtxp+0D6T
3IaxoR+ScyQkC2y4+PPwZiMMGQwSbSPSMjctzgdr9CkU0WTVZ66x50RTEq660iQh
n9ruosgiJtTh30HW7mfs6iKV54BVb2rrJ9laURicaih7X7iNOOUQD34SAw==
=8lzZ
-END PGP SIGNATURE-

Re: Is there any way to refuse Janitor changes in team git?

[Paul Wise]

On Mon, Apr 20, 2020 at 6:21 AM Andreas Tille wrote:

> To be clear about this:  The command line tools used by the janitor are
> considered extremely helpful.  Lintian-brush became a fixed part of our
> workflow.  But since we do it anyway automatically any extra merging or
> checking for merge requests is just an extra step we would love to avoid.

Would having the janitor commit directly be a better option? I assume
here that you already git pull before doing work in case your team
members did some work.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Is there any way to refuse Janitor changes in team git?

[Andreas Tille]

On Mon, Apr 20, 2020 at 09:54:23AM +, Paul Wise wrote:
> > To be clear about this:  The command line tools used by the janitor are
> > considered extremely helpful.  Lintian-brush became a fixed part of our
> > workflow.  But since we do it anyway automatically any extra merging or
> > checking for merge requests is just an extra step we would love to avoid.
> 
> Would having the janitor commit directly be a better option? I assume
> here that you already git pull before doing work in case your team
> members did some work.

There was another hint to this possibility in this thread.  Well, yes,
it would slighly enhance things.  But it happens that someone is
forgetting a pull.  And even then, I need to check the routine-upload
script since its broken about injecting a "Team upload" if there is just
a new changelog entry.  I'm simply not motivated to spent time on this
since I see just no advantage on those commits for our teams workflow.

The Janitor changes are not exposed to the user before a package is
uploaded.  I just told that the said changes will be done before an
upload anyway.  So what exactly is the advantage to parse random
repositories on salsa and do changes that are not exposed to the user
anyway?

I repeat:  Thanks a lot for the tools Janitor is running.  These are
extremely helpful.  Please do not do any automatic changes in our teams
git repositories.  They require an (admittedly slight) overhead we need
to do for no visible use.

Kind regards

 Andreas.

-- 
http://fam-tille.de

Bug#958303: ITP: golang-github-containers-ocicrypt -- Encryption libraries for Encrypted OCI Container images

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-containers-ocicrypt
  Version : 1.0.2-1
  Upstream Author : Brandon Lum , Stefan Berger 

* URL : https://github.com/containers/ocicrypt
* License : Apache-2.0
  Programming Lang: Go
  Description : Encryption libraries for Encrypted OCI Container images

 OCIcrypt Library The ocicrypt library is the OCI image
 spec implementation of container image encryption. More
 details of the spec can be seen in the OCI repository
 (https://github.com/opencontainers/image-spec/pull/775). The purpose of
 this library is to encode spec structures and consts in code, as well as
 provide a consistent implementation of image encryption across container
 runtimes and build tools.

Bug#958306: ITP: golang-github-fullsailor-pkcs7 -- Implements a subset of PKCS#7/Crytpographic Message Syntax (rfc2315, rfc5652)

[Reinhard Tartler]

Package: wnpp
Severity: wishlist
Owner: Reinhard Tartler 

* Package name: golang-github-fullsailor-pkcs7
  Version : 0.0~git20190404.d7302db-1
  Upstream Author : Andrew Smith
* URL : https://github.com/fullsailor/pkcs7
* License : Expat
  Programming Lang: Go
  Description : Implements a subset of PKCS#7/Crytpographic Message Syntax 
(rfc2315, rfc5652)

 pkcs7 implements parsing and creating signed and enveloped messages.

Re: Recommendations around Git Packaging in Debian

[Wouter Verhelst]

Hi Sam,

Thanks for following up on this.

On Sat, Apr 18, 2020 at 02:38:04PM -0400, Sam Hartman wrote:
> *   We had a discussion of using native packages [2].

I wanted to read up on this a bit more, but your footnote is missing.
What was that meant to point to?

Thanks,

-- 
 Home is where you have to wash the dishes.
  -- #debian-devel, Freenode, 2004-09-22

Re: Recommendations around Git Packaging in Debian

[Paulo Henrique de Lima Santana]

Hi Sam,

Em 18/04/2020 15:38, Sam Hartman escreveu:
> 
> 
> Tl;DR: This is a summary of discussion held during the summer and fall
> of 2019 surrounding Git packaging in Debian. 
I would like to remember we are not a north hemisphere community, so,
please, don't say "summer and fall" because here on the south, it's not
the same from you :-)

best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450



signature.asc
Description: OpenPGP digital signature

Re: Recommendations around Git Packaging in Debian

[Sam Hartman]

> "Wouter" == Wouter Verhelst  writes:

Wouter> Hi Sam, Thanks for following up on this.

Wouter> On Sat, Apr 18, 2020 at 02:38:04PM -0400, Sam Hartman wrote:
>> * We had a discussion of using native packages [2].

Wouter> I wanted to read up on this a bit more, but your footnote is
Wouter> missing.  What was that meant to point to?

I don't think it's missing, it's just a backref to the first couple
paragraphs in a long message:

  [3]: https://lists.debian.org/tslo909kqlx@suchdamage.org

Re: Final Bits from the Outgoing DPL

[Paulo Henrique de Lima Santana]

Hi Sam,

Em 19/04/2020 14:33, Sam Hartman escreveu:
> TL;DR: It was fun.  I hope to do this again some day.  Thank you all.

Thank you for dedicate one year as DPL!

Among other things, your help was very important to us to organize a
nice DebConf19, and thanks for supporting other initiatives from Brazil.

I hope you can get a rest now :-)

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450



signature.asc
Description: OpenPGP digital signature

Re: PixelPlex listing inquiry (Debian consultants list)

[Holger Wansing]

Hello,

the following mail came to my notice, which showed there is an (old) copy of
the Debian website mirror'd at http://ftp2.pl.vim.org/pub/mirrors/debian-www/
(from 2008 as it seems).
Is there anything that needs to be done (and can be done) about this?
(and maybe more/other mirrors like this?)
On a first glance, visitors may be unable to detect, that it's not the
original site...

(Dejavu: 'uncensored' copy of debian planet comes to mind)


Holger




Date: Mon, 20 Apr 2020 12:16:05 +0300
From: "PixelPlex Inc." 
To: consulta...@debian.org
Subject: PixelPlex listing inquiry


Hello there,

I am writing to introduce our company — PixelPlex — and establish a
relationship with your platform. We would like to be listed on your Debian
consultants page
. Here is all
the required information about PixelPlex:

*Name*: Alex Dulub

*Company*: PixelPlex

*Address*: 520 West 28th St., Suite 31, New York, NY 10001, United States

*Phone*: + 1-646-490-0772

*Email*: i...@pixelplex.io

*URL*: https://pixelplex.io

*Rates*: Please contact for rates.

Thank you for your time and consideration. Hope to hear from you soon.



Best regards,
PixelPlex Team


email: i...@pixelplex.io
website: pixelplex.io


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Recommendations around Git Packaging in Debian

[Thomas Goirand]

On 4/20/20 4:19 PM, Paulo Henrique de Lima Santana wrote:
> Hi Sam,
> 
> Em 18/04/2020 15:38, Sam Hartman escreveu:
>>
>>
>> Tl;DR: This is a summary of discussion held during the summer and fall
>> of 2019 surrounding Git packaging in Debian. 
> I would like to remember we are not a north hemisphere community, so,
> please, don't say "summer and fall" because here on the south, it's not
> the same from you :-)
> 
> best regards,

When talking about the south hemisphere, I always found it confusing to
talk about summer and winter... What your recommendation? Only use month
names?

Cheers,

Thomas Goirand (zigo)

Re: Recommendations around Git Packaging in Debian

[Paulo Henrique de Lima Santana]

Hi,

Em 20/04/2020 16:45, Thomas Goirand escreveu:
> 
> When talking about the south hemisphere, I always found it confusing to
> talk about summer and winter... What your recommendation? Only use month
> names?

yes.

Best regards,

-- 
Paulo Henrique de Lima Santana (phls)
Curitiba - Brasil
Debian Developer
Diretor do Instituto para Conservação de Tecnologias Livres
Site: http://www.phls.com.br
GNU/Linux user: 228719  GPG ID: 0443C450



signature.asc
Description: OpenPGP digital signature

Re: Recommendations around Git Packaging in Debian

[Jeremy Stanley]

On 2020-04-20 21:45:27 +0200 (+0200), Thomas Goirand wrote:
> On 4/20/20 4:19 PM, Paulo Henrique de Lima Santana wrote:
> > Em 18/04/2020 15:38, Sam Hartman escreveu:
> > > Tl;DR: This is a summary of discussion held during the summer and fall
> > > of 2019 surrounding Git packaging in Debian.
> > 
> > I would like to remember we are not a north hemisphere community, so,
> > please, don't say "summer and fall" because here on the south, it's not
> > the same from you :-)
> 
> When talking about the south hemisphere, I always found it confusing to
> talk about summer and winter... What your recommendation? Only use month
> names?

He could also have phrased it "latter half of 2019," or "2019 third
and fourth quarters," or even simply "last year" (the topic at hand
didn't *really* warrant any more specific time frame than that to
begin with). This is a which habit of I've needed to cure myself in
recent decades too, so I totally empathize. It's hard to remember to
avoid referring to global events relative to the seasons in which I
experienced them, and that for others on the planet it was not the
same seasons they were experiencing. These days, I have my editor
treat names of seasons as a red flag when I'm reviewing what I've
written, so that I hopefully don't forget.
-- 
Jeremy Stanley


signature.asc
Description: PGP signature

Re: Recommendations around Git Packaging in Debian

[Jonathan Carter]

On 2020/04/20 21:45, Thomas Goirand wrote:
> When talking about the south hemisphere, I always found it confusing to
> talk about summer and winter... What your recommendation? Only use month
> names?

Well, I live in the Southern hemisphere. It's winter here from June
until the end of August. Don't you think it would be confusing to many
people in the world if I used terms like "during this winter" in reports?

In a global community, it's better to avoid regional terms to describe a
period of time, even if that covers a very large region or percentage of
contributors. Otherwise it's possible to cause some confusion or to make
some percentage of people feel less included. And I 100% understand that
it wouldn't be intentional because that's just how people tend to talk
(especially in the US and in Europe), but I do tend to think that months
is just better all round. Some people like to talk about quarters (where
Q1 could be Jan-March etc), but again some people count quarters based
on when financial years start in their country (some companies I work
for start Q1 in March) so I'd even avoid that and stick with months
since that's the same everywhere.

-Jonathan

-- 
  ⢀⣴⠾⠻⢶⣦⠀  Jonathan Carter (highvoltage) 
  ⣾⠁⢠⠒⠀⣿⡁  https://wiki.debian.org/highvoltage
  ⢿⡄⠘⠷⠚⠋   https://debian.org | https://jonathancarter.org
  ⠈⠳⣄  Be Bold. Be brave. Debian has got your back.

Re: Is there any way to refuse Janitor changes in team git?

[Jelmer Vernooij]

Hi Andreas,

On Mon, Apr 20, 2020 at 08:05:06AM +0200, Andreas Tille wrote:
> On Sun, Apr 19, 2020 at 06:35:13PM +, Jelmer Vernooij wrote:
> > On Sun, Apr 19, 2020 at 07:05:28PM +0200, Andreas Tille wrote:
> > > from time to time purely random packages (recently ctdconverter) recive
> > > changes by janitor in Git.  I consider this totally useless in the case
> > > of Debian Med team maintained packages.  We are usually calling
> > > routine-update before uploading which also calls the same scripts like
> > > Janitor.  Its just an extra effort to check merge requests.  Real merge
> > > requests might get lost in automatic janitor changes.  So I would love
> > > to stop those janitor changes in our team repository since these are not
> > > really helpful.
> > 
> > Sorry about that - they're meant to be helpful, rather than a source
> > of annoyance.
> 
> To be clear about this:  The command line tools used by the janitor are
> considered extremely helpful.  Lintian-brush became a fixed part of our
> workflow.  But since we do it anyway automatically any extra merging or
> checking for merge requests is just an extra step we would love to avoid.
Makes sense - either way, improvements to packages end up being made,
and that's the bit that ultimately matters. :-)

> > I've added the debian-med-packaging alioth list maintainer address
> > (as used by ctdconverter) to the opt-out list, which means that no new
> > merge proposals will be created. Please follow up privately if you'd
> > like me to add more addresses.
> 
> Please also add r-pkg-t...@alioth-lists.debian.net to the opt-out list.
Done.

Cheers,

Jelmer

-- 
Jelmer Vernooij 
PGP Key: https://www.jelmer.uk/D729A457.asc


signature.asc
Description: PGP signature

Bug#958366: ITP: python3-cleo -- Create beautiful and testable command-line interfaces.

[Emmanuel Arias]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias 

* Package name: python3-cleo
  Version : 0.8.1
  Upstream Author : Sébastien Eustace 
* URL : https://github.com/sdispater/cleo
* License : MIT
  Programming Lang: Python
  Description : Cleo allows you to create beautiful and testable 
command-line interfaces.
 
Create beautiful and testable command-line interfaces.
.
Cleo is mostly a higher level wrapper for CliKit, so a lot of the components and
utilities comes from it. Refer to its documentation for more information.
.
This package is need by poetry. This package can be under DPMT
umbrella.