Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Ansgar Burchardt]

Scott Kitterman writes:
> Personally, I think people should be more annoyed at the people doing
> the hijacking than the one they did it to.

I thought this is called "salvage" now?

There might have been some miscommunications, but given an acceptable
alternative is just requesting the removal of a package with open RC
bugs that hasn't been uploaded for a time, isn't just salvaging the
package by adding oneself as a maintainer better?

And if this is the preferred outcome, shouldn't the salvaging be
"easier" than just requesting removal (which is just one bug report
away)?

Ansgar

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Scott Kitterman]

On April 16, 2018 7:10:34 AM UTC, Ansgar Burchardt  wrote:
>Scott Kitterman writes:
>> Personally, I think people should be more annoyed at the people doing
>> the hijacking than the one they did it to.
>
>I thought this is called "salvage" now?
>
>There might have been some miscommunications, but given an acceptable
>alternative is just requesting the removal of a package with open RC
>bugs that hasn't been uploaded for a time, isn't just salvaging the
>package by adding oneself as a maintainer better?
>
>And if this is the preferred outcome, shouldn't the salvaging be
>"easier" than just requesting removal (which is just one bug report
>away)?

I'd think an attempt to contact the maintainer first would be a prerequisite to 
it potentially being salvage and not a hijack.

Perhaps they attempted and failed and it was only miscommunication, but neither 
of them have spoken up yet, so we don't know.

Scott K

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Rolf Leggewie]

On 16.04.2018 14:28, Tobias Frost wrote:

> On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
>> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git
> You know that collab-maint stands for "Collaborative Maintaince"?
>
> IMHO by placing it into collab-maint, everyone is allowed / suggested
> to work on those packages. If you don't want that, don't go there.

Tobi, I never knew I could simply self-appoint myself to maintainer with
a simple (sponsored) upload of libpng16 (a package you co-maintain) or
tokyocabinet (a package you maintain), drop you to uploader or nothing
and you'd be cool with that.  Hey, it's in collab-maint after all, isn't
it?  Awesome!

Joking aside, I think you are the one who misunderstands
co-maintainership and collab-maint, not me.  I welcome patches,
pull-requests for git branches, co-maintainership, etc.  It's sad if you
can't see the difference to what happened here.




signature.asc
Description: OpenPGP digital signature

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Andreas Tille]

Hi,

On Mon, Apr 16, 2018 at 09:10:34AM +0200, Ansgar Burchardt wrote:
> Scott Kitterman writes:
> > Personally, I think people should be more annoyed at the people doing
> > the hijacking than the one they did it to.
> 
> I thought this is called "salvage" now?

I remember that this discussion comes up quite regularly (no statistic
but to my feeling once a year).  I'd love if we could give fix rules to
the process of salvaging a package (or am I missing that this was just
done).  I think the preconditions should contain something like: 

  (
   * RC buggy (mandatory feature for salvaging a package)
  or
   * No uploads for > 365 days *and* lagging behind upstream
  )
  and
   * Public attempt to contact the former maintainer (be it as
 response to the RC bug or for instance CCed to debian-devel
 list)

It should be also mandatory that the salvaged package gets Vcs-fields
pointing to salsa.debian.org to enable any interested person to
contribute.  The former Maintainer may not be removed from d/control.
If the salvage is done by a team that should be used as maintainer and
the old maintainer moved to Uploaders.  The changelog owner of the
salvage upload should be added to Uploaders in any case to take over
responsibility for the work.

Opinions?

Kind regards

   Andreas.

-- 
http://fam-tille.de

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Geert Stappers]

On Mon, Apr 16, 2018 at 07:34:34AM +, Scott Kitterman wrote:
> On April 16, 2018 7:10:34 AM UTC, Ansgar Burchardt wrote:
> >Scott Kitterman writes:
> >> Personally, I think people should be more annoyed at the people doing
> >> the hijacking than the one they did it to.
> >
> >I thought this is called "salvage" now?
> >
> >There might have been some miscommunications, but given an acceptable
> >alternative is just requesting the removal of a package with open RC
> >bugs that hasn't been uploaded for a time, isn't just salvaging the
> >package by adding oneself as a maintainer better?
> >
> >And if this is the preferred outcome, shouldn't the salvaging be
> >"easier" than just requesting removal (which is just one bug report
> >away)?
> 
> I'd think an attempt to contact the maintainer first would be a
> prerequisite to it potentially being salvage and not a hijack.
> 
> Perhaps they attempted and failed and it was only miscommunication,
> but neither of them have spoken up yet, so we don't know.
 
Indeed we don't know about communication attempts on upload the package.

I do hope that this escalation learns us to file bugs like

 Subject: re-enter testing
 
 Package: gjots2
 Version: 2.4.1-2

 Hi,

 Previous upload of gjots2 was done 4 years ago.
 And removed from testing 5 months ago.
 
 This bugreport is to announce (and document)
 my intention doing an upload.




Groeten
Geert Stappers
-- 
Leven en laten leven

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Boyuan Yang]

在 2018年4月16日星期一 CST 下午3:43:10，Andreas Tille 写道：
> I remember that this discussion comes up quite regularly (no statistic
> but to my feeling once a year).  I'd love if we could give fix rules to
> the process of salvaging a package (or am I missing that this was just
> done).  I think the preconditions should contain something like:
> 
>   (
>* RC buggy (mandatory feature for salvaging a package)
>   or
>* No uploads for > 365 days *and* lagging behind upstream
>   )
>   and
>* Public attempt to contact the former maintainer (be it as
>  response to the RC bug or for instance CCed to debian-devel
>  list)
> 
> It should be also mandatory that the salvaged package gets Vcs-fields
> pointing to salsa.debian.org to enable any interested person to
> contribute.  The former Maintainer may not be removed from d/control.
> If the salvage is done by a team that should be used as maintainer and
> the old maintainer moved to Uploaders.  The changelog owner of the
> salvage upload should be added to Uploaders in any case to take over
> responsibility for the work.
> 
> Opinions?

I would suggest we exclude NMUs from "No uploads for > 365 days" requirement.

The person who want to salvage the package probably should also wait for two 
weeks after initial public contact, then send another public email, wait for 
another two weeks, send another public notification email before doing actual 
salvaging efforts (moving packaging repo, uploading packages, etc). Idea 
copied from QA/MIA process (https://wiki.debian.org/qa.debian.org/MIATeam).

--
Regards,
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Tobias Frost]

Am 16. April 2018 09:43:10 MESZ schrieb Andreas Tille :
>Hi,
>
>On Mon, Apr 16, 2018 at 09:10:34AM +0200, Ansgar Burchardt wrote:
>> Scott Kitterman writes:
>> > Personally, I think people should be more annoyed at the people
>doing
>> > the hijacking than the one they did it to.
>> 
>> I thought this is called "salvage" now?
>
>I remember that this discussion comes up quite regularly (no statistic
>but to my feeling once a year).  I'd love if we could give fix rules to
>the process of salvaging a package (or am I missing that this was just
>done).  I think the preconditions should contain something like: 
>
>  (
>   * RC buggy (mandatory feature for salvaging a package)
>  or
>   * No uploads for > 365 days *and* lagging behind upstream
>  )
>  and
>   * Public attempt to contact the former maintainer (be it as
> response to the RC bug or for instance CCed to debian-devel
> list)
>
>It should be also mandatory that the salvaged package gets Vcs-fields
>pointing to salsa.debian.org to enable any interested person to
>contribute.  The former Maintainer may not be removed from d/control.
>If the salvage is done by a team that should be used as maintainer and
>the old maintainer moved to Uploaders.  The changelog owner of the
>salvage upload should be added to Uploaders in any case to take over
>responsibility for the work.
>
>Opinions?
>
>Kind regards
>
>   Andreas.

Was mentioned on the salvaging packages BoF at Montreal:  
https://lists.debian.org/debian-devel/2012/09/msg00654.html

Re: Hi, I am blind

[Samuel Thibault]

Hello,

Paul Wise, le lun. 16 avril 2018 10:05:52 +0800, a ecrit:
> On Mon, Apr 16, 2018 at 6:20 AM, MENGUAL Jean-Philippe wrote:
> > For example, adding a tag to mention if some package is or not
> > accessible would be a good idea.
> 
> There is already an accessibility facet, but it covers tools:
> 
> https://debtags.debian.org/reports/facets/accessibility
> 
> I guess the way to go would be to create a new accessible-to:: facet
> indicating which groups of abilities that each package is accessible
> to. A bug against debtags with some initial set of tags would be the
> way to start on this.

Well, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855446 already
got uploaded, but it seems 
https://debtags.debian.org/
hasn't gotten updated yet.

Samuel

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Philipp Kern]

On 2018-04-16 10:11, Boyuan Yang wrote:
I would suggest we exclude NMUs from "No uploads for > 365 days" 
requirement.


The person who want to salvage the package probably should also wait 
for two
weeks after initial public contact, then send another public email, 
wait for
another two weeks, send another public notification email before doing 
actual
salvaging efforts (moving packaging repo, uploading packages, etc). 
Idea
copied from QA/MIA process 
(https://wiki.debian.org/qa.debian.org/MIATeam).


I know that I am someone who also lacks time quite often. But still, 
this kills a lot of velocity and I wonder how many people will be 
motivated enough to follow up through a whole month of waiting. On the 
other hand if that gives you a blanket "it's now yours, do with it as 
you see fit, including taking over ownership", maybe that's not so bad.


(There's of course also the question of VAC notices to crawl, though. If 
someone went away for a longer period of time with an intent to come 
back, it should be fair game to fix the package and own related breakage 
but obviously not to just hijack it away from the original maintainer.)


Kind regards
Philipp Kern

Re: MBF proposal: python modules that fail to import

[Andreas Tille]

Hi Helmut,

On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote:
> > For more information: https://wiki.debian.org/Python/LibraryStyleGuide
> 
> Note that autopkgtest-pkg-python is only applicable when the module name
> matches the package name. That's true for the majority of packages, but
> not for all (e.g. capitalization). Nevertheless, a lot of packages are
> missing the flag. Since I have the data at hand, I figured it would be
> easy to generate a dd-list of packages named after their module that
> lack the tag. You find that list attached.

Thanks for assembling this list.

> ... 
> Andreas Tille 
> ...
>python-csb (U)

I'd consider this a false positive since the package has a dedicated
test suite.  When adding "Testsuite: autopkgtest-pkg-python" you get
a lintian warning:

W: python-csb source: unnecessary-testsuite-autopkgtest-field
N: 
N:You do not need to specify a Testsuite: autopkgtest field if a
N:debian/tests/control file exists. It is automatically added by
N:dpkg-source(1) since dpkg 1.17.1.
N:
N:Please remove this line from your debian/control file.
N:
N:Severity: normal, Certainty: certain
N:
N:Check: testsuite, Type: source
N: 

So before doing a MBF "Missing Testsuite: autopkgtest-pkg-python"
this should be checked as well.

Kind regards

   Andreas (just updated five other packages accordingly)

-- 
http://fam-tille.de

Re: MBF proposal: python modules that fail to import

[Ondrej Novy]

Hi,

2018-04-16 11:47 GMT+02:00 Andreas Tille :
>
> W: python-csb source: unnecessary-testsuite-autopkgtest-field
> ...
> So before doing a MBF "Missing Testsuite: autopkgtest-pkg-python"
> this should be checked as well.
>

already done in git.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: MBF proposal: python modules that fail to import

[Ondrej Novy]

Hi,

2018-04-16 11:56 GMT+02:00 Ondrej Novy :

> already done in git.
>

sry. I only removed useless Testsuite: autopkgtest-pkg in git.

Checking if d/tests already exists before adding autopkgtest-pkg-python is
really important. You can add autopkgtest-pkg-python even if there is
d/tests, but you should rename d/tests/control to d/tests/control.autodep8

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: MBF proposal: python modules that fail to import

[Ondrej Novy]

Hi,

2018-04-15 21:32 GMT+02:00 Mattia Rizzolo :

> On Sun, Apr 15, 2018 at 09:27:30PM +0200, Helmut Grohne wrote:
> > Note that autopkgtest-pkg-python is only applicable when the module name
> > matches the package name. That's true for the majority of packages, but
> > not for all (e.g. capitalization).
>
> This could be fixed in autodep8.
> File a bug maybe?
>

I tried to do my best :)

https://sources.debian.org/src/autodep8/0.11.1/support/python/generate/

Feel free to add more "magic" for module name detection.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: MBF proposal: python modules that fail to import

[Ondrej Novy]

Hi,

2018-04-15 21:27 GMT+02:00 Helmut Grohne :

> Note that autopkgtest-pkg-python is only applicable when the module name
> matches the package name. That's true for the majority of packages, but
> not for all (e.g. capitalization). Nevertheless, a lot of packages are
> missing the flag. Since I have the data at hand, I figured it would be
> easy to generate a dd-list of packages named after their module that
> lack the tag. You find that list attached.
>

I think it's good idea to mass commit this (adding Testsuite:
autopkgtest-pkg-python) into Git repos. We should probably merge this list
with Debian CI whitelist one.

-- 
Best regards
 Ondřej Nový

Email: n...@ondrej.org
PGP: 3D98 3C52 EB85 980C 46A5  6090 3573 1255 9D1E 064B

Re: MBF proposal: python modules that fail to import

[Andreas Tille]

Hi Ondrej,

On Mon, Apr 16, 2018 at 11:58:17AM +0200, Ondrej Novy wrote:
> 
> sry. I only removed useless Testsuite: autopkgtest-pkg in git.
> 
> Checking if d/tests already exists before adding autopkgtest-pkg-python is
> really important. You can add autopkgtest-pkg-python even if there is
> d/tests, but you should rename d/tests/control to d/tests/control.autodep8

OK, this was new to me.  I added autopkgtest-pkg-python to python-csb and
renamed d/tests/control to d/tests/control.autodep8.

Thanks for the hint

  Andreas.

-- 
http://fam-tille.de

Re: Completed: lists.alioth.debian.org migration

[Mathias Behrle]

* Dominic Hargreaves: " Completed: lists.alioth.debian.org migration" (Sat, 14
  Apr 2018 13:11:56 +0100):

> On Fri, Apr 13, 2018 at 06:02:37PM +0100, Dominic Hargreaves wrote[1]:
...
> Thanks
> --
> 
> Thanks to the following for their help and support with this process!
> 
> * Alexander Wirt for his assistance as current alioth admin
> * Julien Cristau and Tollef Fog Heen for the DNS/redirection changes
> * Alex Muntada and Bernhard Schmidt, co-admins of the new service
> 
> Dominic.

Big thanks to all involved also from my side, it is great to have the mailing
lists seamlessly running!

Mathias


-- 

Mathias Behrle
PGP/GnuPG key availabable from any keyserver, ID: 0xD6D09BE48405BBF6
AC29 7E5C 46B9 D0B6 1C71  7681 D6D0 9BE4 8405 BBF6


pgpEqwcE59LOG.pgp
Description: Digitale Signatur von OpenPGP

Re: MBF proposal: python modules that fail to import

[Piotr Ożarowski]

[Helmut Grohne, 2018-04-15]
> Piotr Ożarowski 
>python-changelog (U)
>python-sphinx-paramlinks (U)
>python3-changelog (U)
>python3-sphinx-paramlinks (U)

These packages provide sphinx plugins and have Enhances: python{,3}-sphinx
Missing module is available after installing python{,3}-sphinx

same situation most probably also in: python3-sphinxcontrib.autoprogram,
python3-sphinxcontrib.plantuml, python3-sphinxcontrib.rubydomain,
python3-sphinxcontrib.youtube
-- 
GPG: 1D2F A898 58DA AF62 1786 2DF7 AEF6 F1A2 A745 7645

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Gert Wollny]

Am Montag, den 16.04.2018, 09:58 +0200 schrieb Tobias Frost:
> 
> Was mentioned on the salvaging packages BoF at Montreal:  
> https://lists.debian.org/debian-devel/2012/09/msg00654.html
> 
Indeed, and I think one of the key points in that proposalo is that the
last upload was an NMU - and as far as I can see there was none.

So IMO, the right appoach for Lucas Kanashiro and Athos Ribeiro would
have been to do a NMU with the usual delay, and offer co-
maintainership. 

Best, 
Gert

Re: my package was fixed by someone else and i dont like that

[Holger Levsen]

Rolf,

first of all, you immediatly lost your argument by putting peoples name
in the subject of a mail to debian-devel. This is really bad style
(called fingerpointing) and I wish you hadn't done this. Based on this
behaviour alone, I wouldnt recommend *you* becoming a DD or DM, at least
not now.

2nd, Athos' upload didnt remove you from uploaders, so "hijacked" is the
wrong word as well.

3rd, why oh why did you reintroduce fixed bugs like 876571? (I'd
understand if you just reverted everything the next day but 3 weeks
after their upload the urgency is gone...) 
(and btw, I also don't think that bug is serious...)

so, in summary: as often when one points fingers to others, 4 finger
point back to oneself.


-- 
cheers,
Holger


signature.asc
Description: PGP signature

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Michael Stone]

On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:

They might want to argue that gjots2 was poorly maintained and hasn't
seen an upload to unstable for years.  That still would not give them
reason to do what they did.  In fact, I have always taken my
responsibilities seriously.  There are good reasons there was no
upload.  If they had bothered to check the upstream bug tracker or the
upstream branch at
https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git they would
have surely realized I followed upstream closely.  It was simply that I
was never satisfied with any of the upstream releases.  I have been in
contact with upstream about this via bug tracker and e-mail (many of
which bounced, so progress has been slow).  Even the latest upstream
release 3.0.2 does not work for me and thus I would not upload it to
unstable.  Agreed, gjots2 is not in good shape but it's not because of a
lack of effort from the Debian Maintainer.


They didn't upload a new upstream version, so I don't understand what 
your point is here. 


Lucas and Atheros hijacked my package and then failed to clean up after
the mess they made despite being asked to do so.


What is "the mess"?

Mike Stone

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Jeremy Bicha]

On Mon, Apr 16, 2018 at 7:56 AM, Gert Wollny  wrote:
> So IMO, the right appoach for Lucas Kanashiro and Athos Ribeiro would
> have been to do a NMU with the usual delay

The Debian Developer's Reference says that a 0-day NMU is appropriate
for an RC bug older than 7 days with no developer response:

https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu

https://bugs.debian.org/876571

Thanks,
Jeremy Bicha

Bug#895829: ITP: snore -- sleep with feedback

[Paride Legovini]

Package: wnpp
Severity: wishlist
Owner: Paride Legovini 

* Package name: snore
  Version : 0.1
  Upstream Author : Claudio Alessi 
* URL : https://github.com/clamiax/snore/
* License : Expat
  Programming Lang: C
  Description : sleep with feedback

This tool is similar to sleep(1), but visual feedback is given by
printing the flowing of time in both ascending and descending order.

This is useful as a generic countdown timer, or when sleep(1) is used in
an interactive script.

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Russ Allbery]

Jeremy Bicha  writes:
> On Mon, Apr 16, 2018 at 7:56 AM, Gert Wollny  wrote:

>> So IMO, the right appoach for Lucas Kanashiro and Athos Ribeiro would
>> have been to do a NMU with the usual delay

> The Debian Developer's Reference says that a 0-day NMU is appropriate
> for an RC bug older than 7 days with no developer response:

> https://www.debian.org/doc/manuals/developers-reference/ch05.html#nmu

> https://bugs.debian.org/876571

Yes.

Fixing the package when it was removed from testing with RC bugs seems
entirely reasonable.  What bothers me is just adding onself as
comaintainer without any discussion, and thus making that upload not an
NMU.

By all means NMU to fix the RC bugs.  By all means reach out to the
maintainer and ask, if you want to be comaintainer.  But even if you have
the absolute best of intentions, a lot of people are going to react poorly
to having someone just upload their package while adding themselves as a
comaintainer, and it seems very avoidable.  (Maybe there was more
discussion behind the scenes than has so far materialized in this thread,
of course.)

I suspect this was just a miscommunication, but the NMU process is spelled
out to try to avoid exactly this miscommunication, and also because it
provides a lot of signal for figuring out what packages do need a change
of maintainers.

-- 
Russ Allbery (r...@debian.org)   

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Ian Campbell]

On Mon, 2018-04-16 at 09:00 -0700, Russ Allbery wrote:
> Fixing the package when it was removed from testing with RC bugs seems
> entirely reasonable.  What bothers me is just adding onself as
> comaintainer without any discussion, and thus making that upload not an
> NMU.
> 
> By all means NMU to fix the RC bugs.  By all means reach out to the
> maintainer and ask, if you want to be comaintainer.  But even if you have
> the absolute best of intentions, a lot of people are going to react poorly
> to having someone just upload their package while adding themselves as a
> comaintainer,

Not just as a comaintainer according to https://salsa.debian.org/debian
/gjots2/commit/202ae3f586cbe3a7867b881389382d3ee75b39a9 which relegated
the previous maintainer to Uploaders.

There were half a dozen commits before that, starting as NMUs, then
adding the comaintainer, then another handful of changes culminating in
the above but all on the same day 

https://salsa.debian.org/debian/gjots2/commits/master

Ian.

Bug#895834: ITP: python-dataclasses -- Python dataclasses backport from 3.7

[Joel Cross]

Package: wnpp
Severity: wishlist
Owner: Joel Cross 

* Package name: python-dataclasses
  Version : 0.5
  Upstream Author : Eric V. Smith 
* URL : https://github.com/ericvsmith/dataclasses
* License : MIT
  Programming Lang: Python
  Description : Python dataclasses backport from 3.7

This is a backport of the dataclasses feature that will be made available in
Python 3.7 (see https://www.python.org/dev/peps/pep-0557).
Many libraries are already being built that depend upon this feature - with
this packaged, these libraries will be able to have support in Python 3.6 as
well as the upcoming Python 3.7.

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Tobias Frost]

On Mon, Apr 16, 2018 at 03:29:32PM +0800, Rolf Leggewie wrote:
> On 16.04.2018 14:28, Tobias Frost wrote:
> 
> > On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
> >> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git
> > You know that collab-maint stands for "Collaborative Maintaince"?
> >
> > IMHO by placing it into collab-maint, everyone is allowed / suggested
> > to work on those packages. If you don't want that, don't go there.
> 
> Tobi, I never knew I could simply self-appoint myself to maintainer with
> a simple (sponsored) upload of libpng16 (a package you co-maintain) or
> tokyocabinet (a package you maintain), drop you to uploader or nothing
> and you'd be cool with that.  Hey, it's in collab-maint after all, isn't
> it?  Awesome!

Read carefully.
I wrote "everyone is allowed / suggested to work on those packages", not
this is a blanco cheque to do anything you can think of. Collab-maint is
like a big team (with everyone being member) and such what is acceptable
or not should be like what's acceptable or not in our (bigger) teams.
Especially I did not endorse hijacking.

(And yes, I'd be ok if someone adds himeself as Co-Maintainer to my packages,
and brush them up and fixes this nasty bugs, fine with me;) I agree with you
that at minimum out of courtesy someone should get in touch before doing so.

> Joking aside, I think you are the one who misunderstands
> co-maintainership and collab-maint, not me.  I welcome patches,
> pull-requests for git branches, co-maintainership, etc.  It's sad if you
> can't see the difference to what happened here.

If you were right, what exactly would be the difference between collab-maint
and the other personal repos, then? Because you have all those features you
describe in every repo.

As said, this is not an endorsment of any hi-jacking but this thread sheds also
some not so nice light on you... But Holger wrote that already.

--
tobi

Re: ITP: ell -- Embedded Linux library

[Andreas Henriksson]

Hello Nobuhiro Iwamatsu,

On Fri, Apr 13, 2018 at 12:57:46PM +0900, Nobuhiro Iwamatsu wrote:
[...]
> * Package name: ell
>   Version : 0.4
[...]

Out of interest (and since I'm not aware of any other users of ell than
iwd), may I ask what your motivation is for packaging ell?

FYI I've recently uploaded iwd which is currently in NEW (see also
ITP #894537) which currently comes with a bundled version of ell.
Any chance you're interested in iwd and would like to help out looking
into building it against the system ell once your package is available
in the archive?

Regards,
Andreas Henriksson

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Scott Kitterman]

On Monday, April 16, 2018 06:47:04 PM Tobias Frost wrote:
> On Mon, Apr 16, 2018 at 03:29:32PM +0800, Rolf Leggewie wrote:
> > On 16.04.2018 14:28, Tobias Frost wrote:
> > > On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
> > >> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git
> > > 
> > > You know that collab-maint stands for "Collaborative Maintaince"?
> > > 
> > > IMHO by placing it into collab-maint, everyone is allowed / suggested
> > > to work on those packages. If you don't want that, don't go there.
> > 
> > Tobi, I never knew I could simply self-appoint myself to maintainer with
> > a simple (sponsored) upload of libpng16 (a package you co-maintain) or
> > tokyocabinet (a package you maintain), drop you to uploader or nothing
> > and you'd be cool with that.  Hey, it's in collab-maint after all, isn't
> > it?  Awesome!
> 
> Read carefully.
> I wrote "everyone is allowed / suggested to work on those packages", not
> this is a blanco cheque to do anything you can think of. Collab-maint is
> like a big team (with everyone being member) and such what is acceptable
> or not should be like what's acceptable or not in our (bigger) teams.
> Especially I did not endorse hijacking.
> 
> (And yes, I'd be ok if someone adds himeself as Co-Maintainer to my
> packages, and brush them up and fixes this nasty bugs, fine with me;) I
> agree with you that at minimum out of courtesy someone should get in touch
> before doing so.
> > Joking aside, I think you are the one who misunderstands
> > co-maintainership and collab-maint, not me.  I welcome patches,
> > pull-requests for git branches, co-maintainership, etc.  It's sad if you
> > can't see the difference to what happened here.
> 
> If you were right, what exactly would be the difference between collab-maint
> and the other personal repos, then? Because you have all those features you
> describe in every repo.

You're making an argument against a strawman.  You don't think there's 
anything different from making a change in git and making an upload to the 
archive where you demote the previous maintainer from maintainer to uploader 
and set yourself as maintainer of the package with no prior communication?  
That's what happened here.  I'd be upset too.  

> As said, this is not an endorsment of any hi-jacking but this thread sheds
> also some not so nice light on you... But Holger wrote that already.

Yes, because blaming the victim is so much easier.

Scott K

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Andrey Rahmatullin]

On Mon, Apr 16, 2018 at 06:47:04PM +0200, Tobias Frost wrote:
> Collab-maint is
> like a big team (with everyone being member) 
Citation needed.
There is no such thing as collab-maint anywhere except the alioth
namespace.

> If you were right, what exactly would be the difference between collab-maint
> and the other personal repos, then? 
This is a good, but obsolete, question.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: MBF proposal: python modules that fail to import

[Johannes Schauer]

Hi,

Quoting Adam Borowski (2018-04-15 22:30:47)
> On Sun, Apr 15, 2018 at 09:45:45PM +0200, Helmut Grohne wrote:
> > On Sun, Apr 15, 2018 at 09:38:27PM +0200, Christoph Biedl wrote:
> > > The src:file package doesn't ship python{,3}-magic any longer, the change
> > > was two months ago. Mind to check how file got on this list?
> > I used "apt-cache showsrc python-magic" to get the source package and
> > Testsuite header. It seems that this is not the best approximation as it
> > includes non-recent versions. The list thus needs to be treated as an
> > overapproximation. I don't have a good idea how to fix that part atm.
> You can write a script to read apt-avail, parse it as 822, drop all entries
> that have an entry with same Package but higher Version.
> 
> Not exactly brain surgery, but tedious enough that it should be providen
> _somewhere_.  And at least one moron has written exactly that but misplaced
> the script somewhere -- one more reason to have the wheel around so no one
> needs to reinvent it.

Alternatively, use "apt-cache showsrc --no-all-versions" which will print the
candidate version. The candidate version is usually the highest version
available to apt. If you combine this approach with chdist, then you should not
run into false positives anymore.

Or, if you want to follow Adam's approach reading apt-avail, and only retain
the highest version of each package you can use botch-latest-version to do the
filtering.

Thanks!

cheers, josch


signature.asc
Description: signature

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Andreas Metzler]

Tobias Frost  wrote:
> On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
>> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git

> You know that collab-maint stands for "Collaborative Maintaince"?

> IMHO by placing it into collab-maint, everyone is allowed / suggested
> to work on those packages. If you don't want that, don't go there.

That is not my understanding. alioth/collab-maint and its successor
salsa/debian simply provide a public GIT repository without the need
to set up a separate salsa project.

See https://wiki.debian.org/Alioth/PackagingProject

The fact that *technically* every DM has write permission on the repo
does not make committing permitted. There is just no technical barrier,
only the social one.

cu Andreas
-- 
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Oliver Meißner]

On Mon, 16 Apr 2018 20:06:21 +0200
Andreas Metzler  wrote:

>The fact that *technically* every DM has write permission on the repo
>does not make committing permitted. There is just no technical barrier,
>only the social one.

IMHO nearly every party involved into this conflict is right and wrong
the same way.

Maybe every project-owner should be able to set permissions to commit
like nearly any unix fs does (owner, group and rest-of-the-world)

By this way (nearly) anyone should be satisfied.

Regards,
O. Meißner 

Re: MBF proposal: python modules that fail to import

[Herbert Fortes]

Hi,

Em 15-04-2018 15:56, Helmut Grohne escreveu:
> Hi,
> 
> I was surprised to find a python module that failed to import thinking
> that our qa would catch this. So I wondered how many other python
> modules would fail to import and started a little yak shaving journey.
> 
> It turns that this happens for 251 python modules. Since failure to
> import the main module of a python library indicates that the modules
> doesn't work at all, I propose to file this at severity serious.
> 
> Actually, there is autodep8 at ci.debian.net testing this already. It
> has a whitelist
> (https://salsa.debian.org/ci-team/debian-ci-config/blob/master/cookbooks/debci/files/default/whitelist-python.txt)
> of around 800 packages opting in to import testing. Unfortunately, the
> results do not seem to be synced into tracker.d.o. The main difficulty
> is determining the name of the python module. Sometimes capitalization
> differs from the package name. Other times a completely different name
> is used. Thus I am attaching a genlist.py that tries to compute the
> module name and it succeeds in about 4300 packages.
> 
> Thus I tried installing and importing all of these and figured that 251
> packages would fail. The process of installing and importing is rather
> simple and implemented in autodep8 already, so I'm not attaching my
> crude hacks here. Nonetheless I am attaching a draft of the proposed bug
> reports since each of them includes a specific error. I also include a
> dd-list of affected packages.
> 
> The most common issues is missing dependencies. Very often,
> pkg_resources is missing. Also six, numpy, tkinter and distutils are
> missing several times. A fair number of strange exceptions is included
> as well. When dealing with C extensions, we are faced with two
> segmentation faults, one assertion failure and three missing symbols.
>

Package python3-dj-static is on the dd-list. But I can import it.

# on a bananapi

$ python3
Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
[GCC 6.3.0 20170124] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import static # dependency
>>> import dj_static  # module
>>> 

If I understood correct (about the test), please note the diff:

python3-dj-static  # Debian package
dj_static  # module

The package name uses '-' and the module '_'.

Re: MBF proposal: python modules that fail to import

[Simon McVittie]

On Mon, 16 Apr 2018 at 16:14:21 -0300, Herbert Fortes wrote:
> Package python3-dj-static is on the dd-list. But I can import it.
...
> The package name uses '-' and the module '_'.

I think this is a false positive in the preparation of the dd-list.
/usr/share/autodep8/support/python/generate correctly applies
s/-/_/g to the module name before trying to import it.

smcv

Re: MBF proposal: python modules that fail to import

[Helmut Grohne]

On Mon, Apr 16, 2018 at 01:44:48PM +0200, Piotr Ożarowski wrote:
> [Helmut Grohne, 2018-04-15]
> > Piotr Ożarowski 
> >python-changelog (U)
> >python-sphinx-paramlinks (U)
> >python3-changelog (U)
> >python3-sphinx-paramlinks (U)
> 
> These packages provide sphinx plugins and have Enhances: python{,3}-sphinx
> Missing module is available after installing python{,3}-sphinx

I understand that sphinx plugins are meant to extend sphinx. What I
don't understand is why they shouldn't simply depend on sphinx.

Please elaborate how you can use sphinx plugins without installing
sphinx.

To me it looks like this simply is a missing dependency and adding it
the right course of action. Thus the bug reports against these packages
seem warranted to me.

Helmut

Re: MBF proposal: python modules that fail to import

[Helmut Grohne]

On Mon, Apr 16, 2018 at 04:14:21PM -0300, Herbert Fortes wrote:
> Package python3-dj-static is on the dd-list. But I can import it.
> 
> # on a bananapi
> 
> $ python3
> Python 3.5.3 (default, Jan 19 2017, 14:11:04) 
> [GCC 6.3.0 20170124] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import static # dependency
> >>> import dj_static  # module
> >>> 

For most of these bug reports there exists a setting in which the
modules can be imported. E.g. a significant chunk of them becomes
importable after installing python3-pkg-resources.

> If I understood correct (about the test), please note the diff:
> 
> python3-dj-static  # Debian package
> dj_static  # module
> 
> The package name uses '-' and the module '_'.

In my initial mail there is a draft.gz that contains the proposed bug
reports. Searching for python3-dj-static yields:

| After installing python3-dj-static importing the module dj_static
| into a python interpreter fails with the following error:
| 
| Traceback (most recent call last):
|   File "", line 1, in 
|   File "/usr/lib/python3/dist-packages/dj_static.py", line 5, in 
| from django.conf import settings
| ModuleNotFoundError: No module named 'django'

So my heuristic did select the right module and it failed to import,
because no dependency on python3-django was declared. Thus the bug
report seems legitimate to me.

Helmut

Re: MBF proposal: python modules that fail to import

[Paul Gevers]

Hi

On 16-04-18 12:03, Ondrej Novy wrote:
> I think it's good idea to mass commit this (adding Testsuite:
> autopkgtest-pkg-python) into Git repos. We should probably merge this
> list with Debian CI whitelist one.

I assume you mean you want to mass commit the packages that are
currently on the whitelist. We (the CI team) want to reduce (or get rid
of) the whitelists as much as possible as it is not well maintainable in
the team and they have other issues like Scott pointed out. They
are/should be used to bootstrap an autodep8 language, but shouldn't be
considered long term solutions.

Paul



signature.asc
Description: OpenPGP digital signature

salvage != hijacking

[Steve Langasek]

On Mon, Apr 16, 2018 at 09:10:34AM +0200, Ansgar Burchardt wrote:
> Scott Kitterman writes:
> > Personally, I think people should be more annoyed at the people doing
> > the hijacking than the one they did it to.

> I thought this is called "salvage" now?

I believe I was the one who originated the term "salvage", so I want to
make clear why I thought it was important to change our terminology.

A few years ago, it was common practice to refer in QA circles to taking
over abandoned packages as "hijacking".  Hijacking is a hostile act; it is
forcibly taking something that is not yours from someone else.  The problem
with referring to QA work as "hijacking" is that it *signals that forcibly
taking over packages from other maintainers without coordination is ok*.

My goal in introducing the term "salvage" was to distinguish the QA activity
of identifying abandoned packages which we collectively agree should be
given to a new maintainer, from the antisocial act of a developer claiming
maintainership of a package without going through a community process.

If we have now come full circle and are calling the second act "salvage",
then we have reintroduced the original problem of implicitly blessing
package hijacking by an individual uploading developer.

> There might have been some miscommunications, but given an acceptable
> alternative is just requesting the removal of a package with open RC
> bugs that hasn't been uploaded for a time, isn't just salvaging the
> package by adding oneself as a maintainer better?

> And if this is the preferred outcome, shouldn't the salvaging be
> "easier" than just requesting removal (which is just one bug report
> away)?

First, by not following best practices of reaching out to the existing
maintainer beforehand, you are dishonoring any in-progress work the
maintainer has on this package (since they are a sole maintainer, there is
no reasonable expectation that their in-progress work will be globally
visible; the onus is on the non-maintainer to inquire).

Second, in this case the maintainer noted concerns that the new upstream
releases have not been of sufficient quality to fix the RC-bugginess of the
package.  Making it "easier" for a no-maintainer, who doesn't have the same
context of the package's maintenance history, to take the package over in
order to get it into testing without addressing the maintainer's concerns,
is not obviously a win for our users.


Further, in this case it appears someone added themselves as a comaintainer
on the package.  This seems to be something people do when they want to
signal that they are only trying to help and are open to collaborating,
rather than trying to take the package away from the original maintainer.
But I don't think anyone who has thought about this for more than two
seconds from the perspective of the existing maintainer can believe that
someone adding themselves as a comaintainer /without ever communicating with
the current maintainer/ is anything other than a hostile act, because you
have deprived the maintainer of the opportunity to refuse that particular
form of "help".

I think the particular structure of, and ambiguous messaging around,
collab-maint on alioth has definitely contributed to this.  People are
wrongly left with the impression that hosting a project under collab-maint
means that all uploading developers are free to consider themselves
comaintainers, when the original presentation of collab-maint was that any
developer can commit to the repo, /not/ that any developer should feel free
to upload the result without coordination.  I am hopeful that the move to
salsa means we will have less of this sort of thing going forward, since
creating a separate project under salsa is now not so heavy-weight that it
steers maintainers towards collab-maint with its unintended consequences.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Lucas Kanashiro and Athos Ribeiro salvaged my package

[Steve Langasek]

Hi Andreas,

On Mon, Apr 16, 2018 at 09:43:10AM +0200, Andreas Tille wrote:
> I remember that this discussion comes up quite regularly (no statistic
> but to my feeling once a year).  I'd love if we could give fix rules to
> the process of salvaging a package (or am I missing that this was just
> done).  I think the preconditions should contain something like: 

>   (
>* RC buggy (mandatory feature for salvaging a package)
>   or
>* No uploads for > 365 days *and* lagging behind upstream
>   )

No opinion on the specific numbers here.

>   and
>* Public attempt to contact the former maintainer (be it as
>  response to the RC bug or for instance CCed to debian-devel
>  list)

+1, absolutely a requirement that the salvage process includes cc:ing the
existing maintainer on a public post, making clear the poster's intent to
take over the package and the rationale (debian-qa@lists exists for this).

> It should be also mandatory that the salvaged package gets Vcs-fields
> pointing to salsa.debian.org to enable any interested person to
> contribute.

No, it should not be mandatory.

>  The former Maintainer may not be removed from d/control.

Absolutely, emphatically, NO.

One of the few benefits package maintainers receive from their package
maintenance work is their reputation.  While a package in line for salvaging
is probably not doing anything to benefit the maintainer's reputation, any
impact on the maintainer's reputation is still under their control.  By
leaving the previous maintainer in debian/control, you are causing that
maintainer to be associated, without their consent, with whatever packaging
changes the "salvager" is making.  It may be good, it may be bad, it doesn't
matter - what matters is that they have not given their consent, and it is
wrong to list them as a "maintainer" in an arrangement they have not
consented to.

If you want them to remain listed as the maintainer, there's a process for
that already - non-maintainer uploads.  People can do as many of those as
they want.  Or, they can go through a salvage process which is honest about
the reality - the previous maintainer is no longer doing the work, and the
community has handed the package over to someone else who is willing to do
the work.  But it's just wrong to pretend that a package is "team"
maintained without the consent of one of the members of the "team".

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Lucas Kanashiro]

Hi,


On 04/15/2018 09:28 PM, Rolf Leggewie wrote:
> Dear fellow maintainers, dear Lucas and Atheros,
>
> I'd like to use this opportunity to relay my experiences with Lucas
> Kanashiro (kanash...@debian.org) and Athos Ribeiro
> (athoscribe...@gmail.com). TL;DR Going purely by my "interaction" or
> rather the lack of it with them in the maintenance of gjots2, I have
> some doubts they are fit to be DD or DM.
>
> Let me be clear, I am not calling for Lucas Kanashiro to be stripped of
> DD privileges, but I would certainly like to raise my objections if
> Athos ever attempted to become DM or DD.  And I want to make sure that
> Lucas' behaviour is documented and known in case of a repeat.

Athos and I already apologized ourselves in your private email that you
sent us April 11th and we said that we could do a better approach and we
would revert that as you requested (even reintroducing a bug with it).
In short, we had a communication issue. Although, from April 11th to
April 15th (yesterday) I was helping in the organization of MiniDebConf
Curitiba and I did not have enough time to figure this out. Sorry for
the delay.

However, I am really upset since you are selling us as the "bad guys"
here, for instance adding our names in the subject was not a good
decision IMO. Moreover, Athos is a newcomer and he is feeling really sad
because of this attack in a public mailing list. He is a very skilled
developer and he was working on the migration of gjots2 to use gtk3
(related to the RC bug), I do not know if he will keep it up after your
email. So blame on me, not him.

> For many years, I have maintained gjots2 and a number of other packages
> in Debian, I am DM.  Towards the end of March, totally out of the blue
> Lucas and Atheros usurped maintenance of gjots2 from me without NMU, MIA
> or any form of communication with me whatsoever.  I am very active, both
> in Debian and Ubuntu, anything but MIA.  I have a working e-mail
> account.  About a week ago I asked them to reverse their changes which
> until today hasn't happened so I went ahead and did it myself now, doing
> their clean-up work.
>
> They might want to argue that gjots2 was poorly maintained and hasn't
> seen an upload to unstable for years.  That still would not give them
> reason to do what they did.  In fact, I have always taken my
> responsibilities seriously.  There are good reasons there was no
> upload.  If they had bothered to check the upstream bug tracker or the
> upstream branch at
> https://anonscm.debian.org/gitweb/?p=collab-maint/gjots2.git they would
> have surely realized I followed upstream closely.  It was simply that I
> was never satisfied with any of the upstream releases.  I have been in
> contact with upstream about this via bug tracker and e-mail (many of
> which bounced, so progress has been slow).  Even the latest upstream
> release 3.0.2 does not work for me and thus I would not upload it to
> unstable.  Agreed, gjots2 is not in good shape but it's not because of a
> lack of effort from the Debian Maintainer.
>
> Lucas and Atheros hijacked my package and then failed to clean up after
> the mess they made despite being asked to do so.

Anyway,  Athos was writing some patches and he wanted to send them to
you for review. We will leave your package as it is and I wish you can
keep working on it.

Sorry for the miscommunication and this noise in debian-devel.

Regards.



signature.asc
Description: OpenPGP digital signature

Re: MBF proposal: python modules that fail to import

[Helmut Grohne]

On Mon, Apr 16, 2018 at 12:00:24PM +0200, Ondrej Novy wrote:
> I tried to do my best :)
> 
> https://sources.debian.org/src/autodep8/0.11.1/support/python/generate/
> 
> Feel free to add more "magic" for module name detection.

There is an easy improvement and a difficult one I can propose.

The easy one is adding -examples to the list of ignored package
suffixes.

The difficult one is deriving the module name from the list of files. My
initial mail contains a genlist.py that shows my technique for computing
the module name. Essentially it looks for all *.py files, trims .py,
then trims /__init__ and then looks for a common prefix of all .py
files. If there is a single prefix, then we found the module name.

This finds things such as:

 * python-azure-storage -> azure.storage (likely the binary package
   should be renamed to python-azure.storage)
 * python-ball -> BALL
 * python-bd2k -> bd2k.util
 * python-bpfcc -> bcc
 * python-distutils-extra -> DistUtilsExtra
 * python-djangorestframework-gis -> rest_framework_gis
 * python-dogpile.cache -> dogpile
 * python-fftw -> fftw3
 * python-pastewebkit -> paste.webkit (again rename to
   python-paste.webkit?)
 * python-pyscss -> scss
 * python-pysnmp4 -> pysnmp
 * python-tcpwrap -> pytcpwrap

I'm not sure how I'd add this to the generate script, but there clearly
is room for improvement over s/-/_/. There also is room for improving
our package naming.

Would it help to get a list of binary packages that could be covered by
the current autodep8 if they were named correctly (according to the
Python Policy)? Actually renaming them might make ftp masters a bit
grumpy though.

Helmut

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Thomas Goirand]

On 04/16/2018 08:00 AM, Geert Stappers wrote:
> Facts from 
> https://tracker.debian.org/news/949699/accepted-gjots2-241-4-source-all-into-unstable/
>  gjots2 (2.4.1-4) unstable; urgency=medium
>  .
>* revert the package hijack in 2.4.1-3 by
>  Athos Ribeiro 
>  Lucas Kanashiro 
>  who couldn't even be bothered to clean up after their mess
>* move VCS URIs to point to github

For what reason exactly did you move the VCS to Github?

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Clint Adams]

On Mon, Apr 16, 2018 at 08:28:08AM +0800, Rolf Leggewie wrote:
> They might want to argue that gjots2 was poorly maintained and hasn't
> seen an upload to unstable for years.  That still would not give them
> reason to do what they did.  In fact, I have always taken my
> responsibilities seriously.  There are good reasons there was no
> upload.  If they had bothered to check the upstream bug tracker or the

Were there also good reasons why you don't respond to bug reports except
to yell at someone requesting a new version?

Results for Debian Project Leader 2018 Election

[devotee]

Greetings,

This message is an automated, unofficial publication of vote results.
 Official results shall follow, sent in by the vote taker, namely
Debian Project Secretary

This email is just a convenience for the impatient.
 I remain, gentle folks,

Your humble servant,
Devotee (on behalf of Debian Project Secretary)

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Starting results calculation at Tue Apr 17 00:00:17 2018

Option 1 "Chris Lamb"
Option 2 "None Of The Above"

In the following table, tally[row x][col y] represents the votes that
option x received over option y.

  Option
  1 2 
===   === 
Option 1  315 
Option 2 14   



Looking at row 2, column 1, None Of The Above
received 14 votes over Chris Lamb

Looking at row 1, column 2, Chris Lamb
received 315 votes over None Of The Above.

Option 1 Reached quorum: 315 > 44.5477272147525


Option 1 passes Majority.  22.500 (315/14) >= 1


  Option 1 defeats Option 2 by ( 315 -   14) =  301 votes.


The Schwartz Set contains:
 Option 1 "Chris Lamb"



-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The winners are:
 Option 1 "Chris Lamb"

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

The total numbers of votes tallied = 333
-- 
The voters have spoken, the bastards... --unknown
DEbian VOTe EnginE
digraph Results {
  ranksep=0.25;
 "Chris Lamb\n22.50" [ style="filled" , color="powderblue", shape=egg, 
fontcolor="NavyBlue", fontname="Helvetica", fontsize=10  ];
 "Chris Lamb\n22.50" -> "None Of The Above" [ label="301" ];
 "None Of The Above" [ style="filled" , shape=diamond, fontcolor="Red", 
fontname="Helvetica", fontsize=10  ];
}


pgp25oTYL7oUB.pgp
Description: PGP signature

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Ian Jackson]

Lucas Kanashiro writes ("Re: Lucas Kanashiro and Athos Ribeiro hijack my 
package"):
> [stuff]

Thank you for this grown-up email.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: MBF proposal: python modules that fail to import

[Paul Wise]

On Tue, Apr 17, 2018 at 5:00 AM, Helmut Grohne wrote:

> The difficult one is deriving the module name from the list of files.

It should be just reading top_level.txt from the egg-info directory?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Hi, I am blind

[Paul Wise]

On Mon, 2018-04-16 at 10:15 +0200, Samuel Thibault wrote:

> Well, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=855446

accessible-via seems different to what I propose.

accessible-via references software that makes each package accessible.

The proposed accessible-to would reference classes of abilities that
are required to use the package. For example accessible-to::sighted.
I've no idea if this sort of thing would be useful though.

> but it seems https://debtags.debian.org/ hasn't gotten updated yet.

I'd suggest filing another bug about that.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


signature.asc
Description: This is a digitally signed message part

Re: MBF proposal: python modules that fail to import

[Scott Kitterman]

On Tuesday, April 17, 2018 10:45:29 AM Paul Wise wrote:
> On Tue, Apr 17, 2018 at 5:00 AM, Helmut Grohne wrote:
> > The difficult one is deriving the module name from the list of files.
> 
> It should be just reading top_level.txt from the egg-info directory?

For packages that use setuptools, which isn't all of them.  Possibly not even 
a majority.

Scott K

Re: hijack of gjots2 package

[Rolf Leggewie]

Dear Lucas,

thank you for your mail to the list and thank you very much for your
efforts at MiniDebConf as well as maintaining and sponsoring packages as
a DD, and all the other things I am not aware of.  We share a common
goal and vision.

I am happy you and Athos want to contribute to Debian.  My beef is that
you need to do it the proper way (failure #1).  And that you need to own
up to and correct in a reasonable time frame mistakes you make (failure
#2).  I would not have made this public if you hadn't failed me the
second time around as well, leaving me little time to push "RC bug"
#876571 to bionic (yes, I do want that Recommends in there for that LTS).

I cannot help but notice how much space you devote in your mail to
"owning up to your mistakes" vs. going on the offense (saying my mail
was noise (when it wasn't), reintroducing "bugs" (that are arguable even
though they are technically RC), etc.).  You complain that I put Athos'
and your name in the subject of my mail to the list and that this made
you very upset.  I am truly sorry about hurting your feelings, this was
certainly not my intention.  I will own up to this mistake of mine, I
was simply unaware of this interpretation.  If that really makes me
instantly lose my argument as Holger put it then I would have to say
what a sorry discussion culture that is, though.  Etiquette is important
but so is intention and in the end, the substance still matters most in
my opinion.  You complain that I make you look like the "bad guys", you
blame me for scaring off a newcomer.  I am not attacking your character,
I am clear and bluntly complaining about *your actions* and since they
were your actions I certainly felt that after the second failure those
actions needed to made publicly known, not least to prevent a repeat.  I
very much hope you and Athos continue to contribute to Debian and gjots2
if you so chose.  My request is simply that you do it the right way and
respect other people's work.

You try to brush this off as a problem of "miscommunication".  As if you
had been trying to but failing to reach me, as if there had been a
misunderstanding, a potential language barrier or some such prior to
your upload.  Let me be crystal clear, that is absolutely not the case. 
This was a case of NON-communication on your and Athos part.  It's sad
to see you try to cover it up that way even now.  I really can't agree
with Ian that yours was a "grown-up" response.  For you being the
self-admitted main agressor, I feel there's an awful lot of blame coming
from your corner.  Now, let me ponder on what I can do better...

Regards

Rolf




signature.asc
Description: OpenPGP digital signature

Re: gjots2 package

[Geert Stappers]

On Tue, Apr 17, 2018 at 01:02:37PM +0800, Rolf Leggewie wrote:
>[ more fighting ]
> Now, let me ponder on what I can do better...

Work on the package
Work together on the package


Groeten
Geert Stappers
-- 
Leven en laten leven