Bug#829151: RFS: setcolortemperature/1.1-1 ITP

[Jacob Adams]

Package: sponsorship-requests
Severity: wishlist

  Dear mentors,

  I am looking for a sponsor for my package "setcolortemperature"

 * Package name: setcolortemperature
   Version : 1.1-1
   Upstream Author : Ted Unangst  (I am upstream
maintainer though)
 * URL : https://github.com/Tookmund/setcolortemperature
 * License : public domain
   Section : x11

  It builds those binary packages:

setcolortemperature - Set screen color temperature

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/setcolortemperature


  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/s/setcolortemperature/setcolortemperature_1.1-1.dsc

  Changes since the last upload:

setcolortemperature (1.1-1) unstable; urgency=medium

  * Initial release (Closes: #828028)

 -- Jacob Adams   Sat, 04 Jun 2016 22:00:43 -0400


  Regards,
-- 
Jacob Adams
GPG Key: AF6B 1C26 E2D0 A988 432B  94F4 24C0 2B85 B59F E5A9



signature.asc
Description: OpenPGP digital signature

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Sean Whitton]

On Thu, Jun 30, 2016 at 04:26:02PM +0300, Dmitry Bogatov wrote:
> 
> > Thanks for your response.  I think this package is almost ready.  Please
> > add Forwarded: headers to the patches based on our discussion.
> 
> Is it any wat to get best of 'gbp pq' and dep3?

I generally resort to using quilt :(

-- 
Sean Whitton

Bug#827623: RFS: luakit/2012.09.13-r1-9 ITA -- fast and small web browser extensible by Lua

[Herminio Hernandez Jr]

On 06/18, James Cowgill wrote:
> Control: tags -1 moreinfo
> 
> Hi,
> 
> On Sat, 2016-06-18 at 13:28 -0700, Herminio Hernandez, Jr. wrote:
> > Package: sponsorship-requests
> > Severity: normal
> > 
> >  Dear mentors,
> > 
> >  I am looking for a sponsor for my package "luakit"
> 
> It seems the only change you've made to the package is to set the
> Maintainer field to yourself. I doubt you will get sponsorship for this
> because you haven't actually improved anything.
> 
> There are bug reports here you could look at:
> https://bugs.debian.org/luakit
> 
> This bug might be an issue for the stretch release:
> https://bugs.debian.org/790207
> 
I am working on bug 790207 for the past few days. Moving from webkit-1.0 to 
wenkit2gtk requires that I build against gtk3. These past few days I have been 
wokring resolving all the errors I am getting during compile. I think I have 
them all resovled (I still get warnings which I may got back and try to fix).

Right now I am dealing with the errors that are coming from the change to 
webkit2gtk. There was a lot of changes that require updating the code. Just 
wanted to give an update.

Thanks!
Herminio 
> Also the lintian errors here:
> https://lintian.debian.org/maintainer/packa...@qa.debian.org.html#luakit
> 
> I see from this bug that luakit has been recently revived using the
> contents of a fork:
> https://github.com/luakit/luakit/issues/299
> 
> You should try and get them to make an official release which you could
> then package.
> 
> Thanks,
> James




signature.asc
Description: PGP signature

Re: Becoming a Debian Maintainer - and behavior of DDs

[Richard B Winters]

Hi Paul,

June 30 2016 4:07 PM, "Paul Tagliamonte"  wrote:
> I started replying to this mail, but I found that I really don't want
> to. I'm guessing you don't want me to, either. After all, I'm just a
> person. A person totally unrelated to this, who knows nothing of facts,
> and will never know the facts.
> 
> So, let me treat this mailing list like my blog, once again, and talk a
> bit about something I do know a bit about - ways in which teams fail.
> 
> So, Richard, here's what I have to say and/or think on this -
> 
> My current job is being thrown into a large amount of dysfunction, with
> a small bit of air-cover, and to work to stabilize things which are
> unstable, and help to foster a culture of engineering in a place which
> doesn't take well to that.
> 
> I see a lot of things. I see a lot of good things, and I see a lot of
> bad things. Often times it's not clear who's right, and frankly, it
> doesn't matter, because it's not important.
> 
> It doesn't matter if doing something way X is better or worse than way
> Y when half the team is refusing to cooperate. Turns out that's a bigger
> issue.
> 
> Technical failures in 1-50 Million USD/year projects are *rarely*
> technical in nature, rather, they're Social. I don't see why Debian is
> any different.
> 
> Sometimes this takes the form of experts being ignored, sometimes it
> takes the form of antibodies being sent to kill good work, and sometimes
> it takes the form of rules designed for one situation being
> misinterpreted and applied to cases that don't sit in-line with the
> principal of the rule.
> 
> Good work often dies. People get angry. Defenses go up, and everyone
> loses. People start to fight about who's violating what rules, and
> suddenly everyone's at fault for all the failures everywhere.
> 
> What's lacking in teams, generally speaking, is usually empathy.
> 
> It's pretty easy to get that frustrated and annoyed pit of your stomach
> where all you want to do is fight with someone. I get it often. I'm part
> of the problem. I'm cocky, and sometimes I don't listen at all. I'm
> pretty quick to blame other people, and I have a long list of
> personality faults. But that's not really the point of this email.
> 
> I'm aware of these things, and it's something I try to monitor, because
> the fact is, I'm helping to shape the culture and team around me. People
> will read the things I write and change their behavior. Sometimes in a
> good way, sometimes in a bad way. I'm an imperfect person, so I'm going
> to have an imperfect effect on things around me.
> 
> This entire spat in this team is frustrating, and it looks very murkey.
> I don't want to weigh in because I have no buisness doing so. All I know
> is I get the feeling no one is *listening* to eachother.
> 
> People don't contribute to F/OSS or Debian because they are
> mean-spirited evildo-ers who want to rule the world, because frankly,
> there are quicker ways to do that. People contribute because they care.
> Myon cares, and you care. These are facts.
> 
> Both of you want to make the world a better place and make Debian a
> better place. This is a fact I've accepted.
> 
> The failure here appears to be based on communication, and feelings of
> hurt. This is normal. This is basically the same as every other Thursday
> I've seen for the last year.
> 
> Fealings matter, and ensuring we have a space where people don't feel
> like there is a team of people undermining them is important. Even if
> it's true, the *perception* is enough to cause, well, this email thread.
> 
> I've never talked with you before, Richard, but I see you litigating and
> going on the offensive. I'm guessing this is because you feel wronged by
> Myon, and the larger population needs to understand this, and ensure new
> contributors don't feel this way. I agree. I want to make sure no new
> contributor feels this -- true or false, perception or reality. I don't
> know how, but I know it's not good. I'm *with you* on that. I'm sure
> Myon is *with you* on that.
> 
> All I ask is that you empathize with eachother, and think about what the
> situation looks like from their point of view.
> 
> As a general rule, I feel that I can learn a lot about a person after
> they answer the following questions:
> 
> 1. What's your least favorite programming language, and why?
> 2. Explain why people like that programming language.
> 
> If 2. is answered with "because their dumb dumbs", I know where the
> problem is.
> 
> So, I guess my gentle invitation is for folks in Debian generally to stop and
> think about the motiviations and reasoning for the things that people do
> in Debian, and to not assume the problem is with other people.
> 
> For the most part, *we* are the problem. *I* am the problem. *we* have
> failed countless people, and we will continue to. Let's start there and
> find common ground.

I know I said I wasn't going to reply on this chain again - but I couldn't let 
you give all 

Re: Becoming a Debian Maintainer - and behavior of DDs

[Paul Tagliamonte]

I started replying to this mail, but I found that I really don't want
to. I'm guessing you don't want me to, either. After all, I'm just a
person. A person totally unrelated to this, who knows nothing of facts,
and will never know the facts.

So, let me treat this mailing list like my blog, once again, and talk a
bit about something I do know a bit about - ways in which teams fail.


So, Richard, here's what I have to say and/or think on this -

My current job is being thrown into a large amount of dysfunction, with
a small bit of air-cover, and to work to stabilize things which are
unstable, and help to foster a culture of engineering in a place which
doesn't take well to that.

I see a lot of things. I see a lot of good things, and I see a lot of
bad things. Often times it's not clear who's right, and frankly, it
doesn't matter, because it's not important.

It doesn't matter if doing something way X is better or worse than way
Y when half the team is refusing to cooperate. Turns out that's a bigger
issue.

Technical failures in 1-50 Million USD/year projects are *rarely*
technical in nature, rather, they're Social. I don't see why Debian is
any different.

Sometimes this takes the form of experts being ignored, sometimes it
takes the form of antibodies being sent to kill good work, and sometimes
it takes the form of rules designed for one situation being
misinterpreted and applied to cases that don't sit in-line with the
principal of the rule.

Good work often dies. People get angry. Defenses go up, and everyone
loses. People start to fight about who's violating what rules, and
suddenly everyone's at fault for all the failures everywhere.

What's lacking in teams, generally speaking, is usually empathy.

It's pretty easy to get that frustrated and annoyed pit of your stomach
where all you want to do is fight with someone. I get it often. I'm part
of the problem. I'm cocky, and sometimes I don't listen at all. I'm
pretty quick to blame other people, and I have a long list of
personality faults. But that's not really the point of this email.

I'm aware of these things, and it's something I try to monitor, because
the fact is, I'm helping to shape the culture and team around me. People
will read the things I write and change their behavior. Sometimes in a
good way, sometimes in a bad way. I'm an imperfect person, so I'm going
to have an imperfect effect on things around me.

This entire spat in this team is frustrating, and it looks very murkey.
I don't want to weigh in because I have no buisness doing so. All I know
is I get the feeling no one is *listening* to eachother.

People don't contribute to F/OSS or Debian because they are
mean-spirited evildo-ers who want to rule the world, because frankly,
there are quicker ways to do that. People contribute because they care.
Myon cares, and you care. These are facts.

Both of you want to make the world a better place and make Debian a
better place. This is a fact I've accepted.

The failure here appears to be based on communication, and feelings of
hurt. This is normal. This is basically the same as every other Thursday
I've seen for the last year.

Fealings matter, and ensuring we have a space where people don't feel
like there is a team of people undermining them is important. Even if
it's true, the *perception* is enough to cause, well, this email thread.

I've never talked with you before, Richard, but I see you litigating and
going on the offensive. I'm guessing this is because you feel wronged by
Myon, and the larger population needs to understand this, and ensure new
contributors don't feel this way. I agree. I want to make sure no new
contributor feels this -- true or false, perception or reality. I don't
know how, but I know it's not good. I'm *with you* on that. I'm sure
Myon is *with you* on that.

All I ask is that you empathize with eachother, and think about what the
situation looks like from their point of view.

As a general rule, I feel that I can learn a lot about a person after
they answer the following questions:

  1. What's your least favorite programming language, and why?
  2. Explain why people like that programming language.

If 2. is answered with "because their dumb dumbs", I know where the
problem is.

So, I guess my gentle invitation is for folks in Debian generally to stop and
think about the motiviations and reasoning for the things that people do
in Debian, and to not assume the problem is with other people.

For the most part, *we* are the problem. *I* am the problem. *we* have
failed countless people, and we will continue to. Let's start there and
find common ground.


signature.asc
Description: PGP signature

Bug#827907: RFS: evil/1.2.12-1 ITP

[Dmitry Bogatov]

> It would be great if you could make the evil test suite run by using
> dtach.  You won't be able to use dh_elpa_test directly -- maybe you
> could use
> 
> override_dh_elpa_test:
> dtach --foo --bar -- dh_elpa_test
> 
> or just drop to compat level 9 and use override_dh_auto_test.

I elaborated this solution and pushed to master. Following is true:

 * `make test < /dev/null' fails
 * `dpkg-buildpackage -us -uc < /dev/null' is success now. (see 16d89)
 * 'dtach' uses pty(7)
 * default configuration of pbuilder do not provide possibility to allocate
   pty

So, question is whether it is possible to allocate pty on Debian build farm.

> > > Nice work.  Have you forwarded the fix upstream?
> > Too much trouble. To fix it upstream, they have to deal with either:
> >  * evil mode is autoloaded, interactive and with sane description. Ugliness
> >in code.

> Do you know whether the problem if Debian-specific, or if it also arises
> when installing evil from MELPA?

On MELPA everything is smooth.

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Re: Becoming a Debian Maintainer - and behavior of DDs

[Richard B Winters]

Hello Raphael,


June 30 2016 3:02 PM, "Raphael Hertzog"  wrote:
> Hello Richard,
> 
> On Thu, 30 Jun 2016, Richard B Winters wrote:
> 
>> Again, you are just talking out of your  I care not about the
>> uploaders field, I've said this to you numerous times (and repeated it
>> yet again for you above). I do not know any other way to make you
>> understand that I am not an idiot, I know what you are doing and I can
>> see through your BS.
>> 
>> Instead of excuses, why not simply apologize and promise it wont happen
>> again, just like you did in IRC after I sent the original email -
>> instead of making excuses that contradict your actions?
>> 
>> Again, I wasn't expecting anything of this email chain. I simply want
>> this information shared someplace more permanently than IRC chat.
> 
> I'm not sure that having this conversation stored permanently on mailing
> list archive is going to help you or Debian in any way.
> 
> I understand you feel somewhat betrayed because Ferenc is going
> forward quicker than you but that's life in Debian. This is a
> meritocracy and a social project. Some learn faster or have more
> prior knowledge, some interact in a way that fits better the
> existing developers, etc.
> 
> Even if you had the technical skills, you just proved that you
> are prompt to insult other Debian contributors and that makes
> it a no-go for many of us. We had too many problems in the past
> by focusing only on the technical aspect and so we are much
> more attentive to the ability to work collaboratively in a friendly
> way. That doesn't mean that we can't complain and argue, but there are
> ways to do it and you haven't found the correct way, yet.
> 
> Cheers,
> --
> Raphaël Hertzog ◈ Debian Developer
> 
> Support Debian LTS: http://www.freexian.com/services/debian-lts.html
> Learn to master Debian: http://debian-handbook.info/get

From what I've seen go back and forth through Debian lists matter-of-fact 
phrases and insults are not uncommon.  Though I do appreciate the reply and 
your advice. I am not saying those things out of spite or malice, it is 
matter-of-fact and I am simply being blunt. I'll change my phrasing in the 
future.

I do want to point out that my intelligence - and contribution - is being 
insulted by a DD - I think my aggravation should be quite understood. Yet, you 
- and many of you - aren't the one(s) making that contradiction - I admit.

I will end this on that note, and not say or reply anymore on this chain.


Best regards,



Richard B Winters

Re: Becoming a Debian Maintainer - and behavior of DDs

[Richard B Winters]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi Christoph,

June 22 2016 5:26 PM, "Christoph Berg"  wrote:
> [tl;dr: Richard is disappointed that I didn't advocate him for DM,
> while I did advocate other team members shortly after.]
>
> Hi Richard,
>
> Re: Richard B Winters 2016-06-22 
> <204e2c0e01254a766699d615036d2...@mail.mmogp.com>
>
>> During that time I worked with Christoph Berg, he advised not to play with 
>> repository structure too
>> much - and asked that I didn't do more than I had to to get the stack 
>> working again.
>
> I didn't recommend any particular repository structure. What I did
> recommend was not to bikeshed about that, stop discussing the layout,
> and start the real work.
>

In essence, exactly what I said. Ferenc wanted to change the repository layout, 
I wasn't opposed, you hadn't wanted to focus on that.  I don't see what you are 
disagreeing with here?


>> Ferenc disregards all my work and makes his own repository on github 
>> (instead of contributing to
>> the team repository) so that he can structure branches how he wants and move 
>> to DEP-14 (I was never
>> opposed to that, but its exactly what Christoph asked me not to do when I 
>> suggested it based off of
>> conversations I had with Ferenc) - and after Christoph states that he 
>> doesn't care for
>> bike-shedding and had been working with me already on some of the packages 
>> along with Adrian; he
>> reneged with regard to Ferenc's new repository (which was now missing all of 
>> my changelog entries
>> which cataloged my contributions to the package, the very thing I didn't do 
>> - but which Ferenc
>> complained about himself).
>
> It was suboptimal that Feri's changes were often staged elsewhere, but
> this was communicated, and I think now everything relevant is on
> git.debian.org.

You blatantly refused me when I offered to host some code on Github.  Refused 
to even look at it.  Yet when Ferenc did it you were more than willing to work 
with him solely on his account until such time as you were ready to replace the 
work I had done on the team repository.  It's not just sub-optimal my man, its 
manipulative and deceptive.


>> Yes, after Debconf Christoph's whole demeanor towards me changed; He 
>> blatantly started uploading
>> each and every one of Ferenc's packages, 'mindfully' attempting to accept 
>> the ruby packages I
>> worked on - I'm guessing to try to make me feel better and shut me up. And 
>> all he had to offer was
>
> Sorry if uploading your packages was wrong. Would it have been better
> to not do anything?

Probably, it was a Ruby package I brought to the Ruby team, and one of the 
members was reviewing my work - albeit a while back but still. If I recall you 
did not even review my package, and after your first upload the ftp team 
emailed back having denied the upload for what I'm recalling as a minor mistake 
that you would have picked up had you actually reviewed my work.

Is that your routine? Whoever's package you can upload without having to review 
or fix - that is who you will sponsor,  and mentor?  You offered to sponsor the 
team when you first came to usnot just Ferenc.


> At that point, corosync and pacemaker were the next packages in the
> stack that needed to be done. "Your" pcs and crmsh packages were due
> after that. That was the reason for the ordering.
>
>> a 'Sorry if your changelog entries got removed'. Sure I was still in the 
>> uploaders field or
>> whatever, but the changes I made to code were no longer noted.

> I don't fancy changelog bikeshedding. All your changes made it into
> the next package, though possibly after re-re-rebasing them through
> whatnot git operations, the changelogs were a mess. I'd care more
> about getting the problems fixed.

Again, you are avoiding the real issue.  Let me explain for you in very clear 
terms.  Putting me in the uploaders field doesn't mean crap to anybody, 
especially when I can't upload.  My name was there solely so I could upload to 
mentors.

The real issue is that I did massive amounts of work to the package, as well as 
others.  When you do something in a package you add the change to the change 
log.  When multiple people do something, you format the changelog a certain 
way.  What is ironic about this is that you and Ferenc made a point to 'teach' 
this to me and show me how to format such a changelog.

Why is it that my changes were removed?  For instance:

[Richard B. Winters]
* change
* change

[Christoph Berg]

* change
* change

When I review the package, the whole section for me is gone (not just the 
signature at the end...proving what you actually care about).  Thanks for that. 
The change log wasn't a mess by the way, it was quite understandable.  If you 
guys hadn't been rebasing and rebasing and bikeshedding you wouldn't have 
created such a mess.  You don't care for bikeshedding though right?


>> I had also asked Christoph to advocate me as a maintainer 6-8 months prior 

Bug#829117: RFS: groonga/6.0.5-1

[Kentaro Hayashi]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "groonga"

* Package name: groonga
   Version : 6.0.5-1
   Upstream Author : Groonga Project 
* URL : http://groonga.org/
* License : LGPL-2.1
   Section : database

It builds those binary packages:

groonga- Fulltext search engine (metapackage for library use)
groonga-bin - Commands for Groonga
groonga-doc - Documentation of Groonga
groonga-examples - Examples of Groonga
groonga-httpd - Groonga HTTP server
groonga-munin-plugins - munin-node plugins for Groonga
groonga-plugin-suggest - Suggest plugin for Groonga
groonga-server-common - Fulltext search engine (metapackage for server use)
groonga-server-gqtp - Fulltext search engine (metapackage for GQTP server use)
groonga-token-filter-stem - Stemming token filter for Groonga
groonga-tokenizer-mecab - MeCab tokenizer for Groonga
libgroonga-dev - Development files to use Groonga as a library
libgroonga0 - Library files for Groonga

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/groonga


Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/g/groonga/groonga_6.0.5-1.dsc

More information about groonga can be obtained from http://groonga.org.

Changes since the last upload:

  * New upstream release.

Regards,


pgpV4P0xqWesy.pgp
Description: PGP signature

Bug#823140: RFS: caffe/1.0.0~rc3-1 -- a deep learning framework [ITP]

[lumin]

Hi guys,

Some updates to the caffe package:
(can be seen in git repo but no mentors upload)

  1. added octave-caffe-cpu package, but there remains some
 lintian errors to be solved.
  2. changed package caffe-cpu into metapackage, move tools
 to package caffe-tools-cpu. the metapackage pulls
 libcaffe-cpu, caffe-tools-cpu and python-caffe-cpu,
 and it suggests the octave interface, libdevel pkg and
 the doxygen doc package.

Concerning protobuf3 and opencv3:

  opencv3 is not a must, but python3-protobuf is needed.
  Some weeks ago I had a quick study on them and I found that
  they are not as easy to be dealt with as I hoped.
  * even failed to build the unchanged opencv3 package from
experimental ...
  * protobuf3 compilation needs gmock but it's missing.
need to inspect the packaging on how the missing gmock
source was resolved by protobuf maintainers.

Without python3-protobuf the python3-caffe-cpu still builds,
although it doesn't runs correctly...  Can we first get it into
experimental to see on which Architecture does it FTBFS? [1]
Besides in this way we can let it pass the first-time-new-queue
when waiting for the required runtime-dep.
Is experimental available for this purpose?

Thanks. :-)

[1] amd64 and ppc64el won't FTBFS, both tested by myself,
and that's all I know.

Bug#829012: RFS: udftools/1.2-0.1 [NMU] [RC]

[Tobias Frost]

Hi Pali,

The udftools package has (now) been orphaned by the MIA Team (#829016).
if you want you can just adopt it. 

-- 
tobi

Bug#827907: RFS: evil/1.2.12-1 ITP

[Jakub Wilk]

* Sean Whitton , 2016-06-30, 13:32:

   override_dh_elpa_test:
   dtach --foo --bar -- dh_elpa_test


It's probably not _that_ simple. dtach, understandably, ignores exit 
status of the program it runs.


I think you'll need something like this:

override_dh_elpa_test:
rm -f test_exit_status
dtach -c tmpsocket sh -c 'dh_elpa_test; echo $$? > test_exit_status'
rc=$$(cat test_exit_status) && exit $rc

--
Jakub Wilk

Re: a few questions on ITP shadowsocks-libev before formal RFS

[Gianfranco Costamagna]

Hi,

>> you already are a DM, you need the guest account, but it isn't requested

>> for collab-maint access
>
>You mean guest account of porterbox, right?
>I already applied, and got approved. It's for debug FTBFS of libcork
>on s390x/ppc64/sparc64.
>
>For access collab-maint, guest account of alioth is enough.
>Two co-maintainers already have it. So it's cleared here.


wonderful.

>Thanks for your help!
>I'll push the commits when the upload is done.


ack ok!
>I get it.
>I'll ask them later.


wonderful!
in the meanwhile they can git commit, git format-patch -1 and git-send-email 
patches to you :)
(not the best workflow, I know)


git send-email --to youem...@domain.com 0001-whatever.patch
>You're so kind!

>I'll let you know when I need more. Thank you!

wonderful!

Gianfranco

Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

[Gianfranco Costamagna]

Hi,

>However, ftp-master rejected the upload, I reopen this ticket.
>I'm sorry that I miss-checked the license under man/ folder.
>
>I search GFDL, and find [0][1]
>
>[0] https://www.debian.org/vote/2006/vote_001
>[1] https://wiki.debian.org/DFSGLicenses
>
>So if my understanding is correct, I think there're 2 ways to solve
>this license issue.
>
>Way 0:
>Put manpages to a new created -doc package, which we can put in non-free


:(

>Way 1:
>Since all manpages is created by Max (co-maintainer of this package,
>and in CC list), we can ask him to relicense, according to [2]
>
>[2] https://wiki.debian.org/qa.debian.org/gfdlinvariant
>
>I think Way 1 is better.
>What do you think?


+1 for way 1!

Gianfranco

Bug#829081: RFS: python3-adns/1.2.3-1 [ITP, NMU] -- A Python-3 port of the python-adns package

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo

Hi,

>I am looking for a sponsor for my package "python3-adns". This package is a 
>Debian packaging of the Python 3 port of python-adns, found at 
>>https://mentors.debian.net/sponsors/rfs-howto/python3-adns, with minor fixes. 
>My sources are at https://github.com/dreibh/python3-adns/ . I needed a Python 
>3 port >of python-adns, so I packaged this port. It is probably useful for 
>other Debian users as well.


https://packages.qa.debian.org/p/python-adns.html
there is already a python-adns, why can't you patch/update the source to work 
and provide both python
bindings?
I admit I have strong feelings about having two different sources, specially 
because
the Python3 code can easily work with Python2 too.
(at least in my knowledge experience)


so, please try to update python-adns to the new release, and add the python3- 
package on top of it
(if possible of course)


>More information about hello can be obtained from https://www.example.com.


nice website! ^^


Gianfranco

Bug#829012: RFS: udftools/1.2-0.1 [NMU] [RC]

[Gianfranco Costamagna]

control: owner -1 !
control: tags -1 moreinfo



Hi,

* Pali Rohár , 2016-06-29, 21:01:
>  * New upstream release:
>Closes: #672839, #272648, #606664, #715720, #716102, #716287, #727634
>Closes: #727636, #775273, #539530, #680272


1) indeed, please list them separately, with a brief explanation

2) please call it 1.2-1 and do a QA upload (dch --qa)

3) undocumented stuff:
add misc:Depends not in changelog
fix description
dep5 copyright (yeah)
patch drop (list them and explain why you dropped them)

4) do you want to maintain it? you can! #817705

thanks a lot for the very nice work!

Just some changelog rewording and we should be fine to go :)

Gianfranco

Bug#829087: marked as done (RFS: nfft/3.3.2~rc2-1)

[Debian Bug Tracking System]

Your message dated Thu, 30 Jun 2016 13:44:06 + (UTC)
with message-id <1697743202.6949062.1467294246967.javamail.ya...@mail.yahoo.com>
and subject line Re: Bug#829087: RFS: nfft/3.3.2~rc2-1
has caused the Debian Bug report #829087,
regarding RFS: nfft/3.3.2~rc2-1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
829087: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=829087
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nfft"

* Package name: nfft
  Version : 3.3.2~rc2-1
  Upstream Author : Prof. Dr. Daniel Potts 
* URL :http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL-2+
  Section : science

It builds those binary packages:

  libnfft3-2 - library for computing non-uniform Fourier transforms
  libnfft3-dbg - debugging symbols for the NFFT library
  libnfft3-dev - development files for the NFFT library
  libnfft3-doc - documentation for the NFFT library
  libnfft3-double2 - library for computing non-uniform Fourier 
transforms (double prec
  libnfft3-long2 - library for computing non-uniform Fourier transforms 
(long-double
  libnfft3-single2 - library for computing non-uniform Fourier 
transforms (single prec


To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/nfft

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc1-1.dsc


Successful build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/nfft/3.3.2~rc1-1/buildlog

http://debomatic-i386.debian.net/distribution#unstable/nfft/3.3.2~rc1-1/buildlog

Changes since the last upload:

  * New upstream release.
  * Drop -dbg packages in favor of autogenerated -dbgsym.

Regards,
Ghislain Vaillant
--- End Message ---
--- Begin Message ---
Hi,

>I am looking for a sponsor for my package "nfft"


here we are
>https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc1-1.dsc

404


this is the rc2!

anyway, signed and uploaded

BTW please make the package go in Stretch!

Gianfranco--- End Message ---

Bug#827907: RFS: evil/1.2.12-1 ITP

[Sean Whitton]

Hello,

On Thu, Jun 30, 2016 at 01:28:00PM +0300, Dmitry Bogatov wrote:
> > > Here is script, that does same as dh_elpa_test:
> > > [...]
> > > It reports 22 failures. If I replace -batch with -nw, all tests
> > > passes. So seems tty is really needed, but I do not understand why.
> >
> > This is not what dh_elpa_test is actually running ;)
> 
> Well, I was not explicit enough.
> 
> > In the worst case, if we can confirm that some of tests really do
> > require a tty (it would be good to figure out why -- maybe ask
> > upstream?), you can add a patch disabling those tests in particular.
> 
> Simple. Replace in upstream Makefile -nw with -batch and get 22 failures.
> So I think we should accept it -- no tests for us.

I just talked to David Bremner about this.  He suggested looking at the
notmuch-emacs source package.  Although its test suite does not use
dh_elpa_test (because it does not use ERT or Buttercup), it too requires
emacs -nw and fails with emacs -batch.  To deal with this, the d/rules
file wraps emacs in dtach.

It would be great if you could make the evil test suite run by using
dtach.  You won't be able to use dh_elpa_test directly -- maybe you
could use

override_dh_elpa_test:
dtach --foo --bar -- dh_elpa_test

or just drop to compat level 9 and use override_dh_auto_test.

If you can make it work, I could add this as a dh_elpa_test feature.
Let me know if I can help you.  David also suggested asking him in
#debian-emacs on OFTC, or in #notmuch on freenode.  Since evil is likely
to be a popular package, we should definitely get its test suite running.

> > Nice work.  Have you forwarded the fix upstream?
> 
> Too much trouble. To fix it upstream, they have to deal with either:
>  [...]
>  * evil mode is autoloaded, interactive and with sane description. Ugliness
>in code.

Do you know whether the problem if Debian-specific, or if it also arises
when installing evil from MELPA?

-- 
Sean Whitton

Bug#828889: RFS: elisp-slime-nav-el/0.9-1 ITP

[Dmitry Bogatov]

> Thanks for your response.  I think this package is almost ready.  Please
> add Forwarded: headers to the patches based on our discussion.

Is it any wat to get best of 'gbp pq' and dep3?

-- 
Accept: text/plain, text/x-diff
Accept-Language: eo,en,ru
X-Web-Site: sinsekvu.github.io

Bug#829087: RFS: nfft/3.3.2~rc2-1

[Ghislain Vaillant]

Package: sponsorship-requests
Severity: normal

Dear mentors,

I am looking for a sponsor for my package "nfft"

* Package name: nfft
  Version : 3.3.2~rc2-1
  Upstream Author : Prof. Dr. Daniel Potts 
* URL :http://www-user.tu-chemnitz.de/~potts/nfft/
* License : GPL-2+
  Section : science

It builds those binary packages:

  libnfft3-2 - library for computing non-uniform Fourier transforms
  libnfft3-dbg - debugging symbols for the NFFT library
  libnfft3-dev - development files for the NFFT library
  libnfft3-doc - documentation for the NFFT library
  libnfft3-double2 - library for computing non-uniform Fourier 
transforms (double prec
  libnfft3-long2 - library for computing non-uniform Fourier transforms 
(long-double
  libnfft3-single2 - library for computing non-uniform Fourier 
transforms (single prec


To access further information about this package, please visit the 
following URL:


  https://mentors.debian.net/package/nfft

Alternatively, one can download the package with dget using this command:

  dget -x 
https://mentors.debian.net/debian/pool/main/n/nfft/nfft_3.3.2~rc1-1.dsc


Successful build on debomatic:


http://debomatic-amd64.debian.net/distribution#unstable/nfft/3.3.2~rc1-1/buildlog

http://debomatic-i386.debian.net/distribution#unstable/nfft/3.3.2~rc1-1/buildlog

Changes since the last upload:

  * New upstream release.
  * Drop -dbg packages in favor of autogenerated -dbgsym.

Regards,
Ghislain Vaillant

Bug#825532: RFS: shadowsocks-libev/2.4.6+20160526+ds-1 [ITP]

[Roger Shimizu]

Control: reopen -1

Dear G,

Thanks for your upload!

However, ftp-master rejected the upload, I reopen this ticket.
I'm sorry that I miss-checked the license under man/ folder.

I search GFDL, and find [0][1]

[0] https://www.debian.org/vote/2006/vote_001
[1] https://wiki.debian.org/DFSGLicenses

So if my understanding is correct, I think there're 2 ways to solve
this license issue.

Way 0:
Put manpages to a new created -doc package, which we can put in non-free

Way 1:
Since all manpages is created by Max (co-maintainer of this package,
and in CC list), we can ask him to relicense, according to [2]

[2] https://wiki.debian.org/qa.debian.org/gfdlinvariant

I think Way 1 is better.
What do you think?

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Re: ITA for an abandoned package: evolver case

[Jerome BENOIT]

Hi,

On 08/06/16 09:51, Gianfranco Costamagna wrote:
> Hi,
> 
> 
> 
>> i am maintaining many packages, which were maintained by Adam 
>> originally. But all of them are team-maintained (Debian Science),
>> and this one is not.
>> 
>> AFAIK Adam is not active in Debian last several years. From my
>> point of view, it will not be too offensive, if evolver will be
>> moved under the roof of Debian Science and you can be added as an
>> uploader of this package. But we need a confirmation from Adam or
>> MIA-team, I think.
> 
> 
> last activity is around 2012 according to db.d.o
>> Another option for the time being is that you are preparing a new
>> upload, file a bug against evolver ("new version...") and the
>> package will be NMUed after some time.
> 
> 
> I second this option, together with the move on debian-science of the
> package.
> 
> in the meanwhile, according to quantz, the MIA process started some
> time ago (on 2016-05-24),


How can we get the current status of the process ? 


Thanks,
Jerome


 so I guess you can start proposing patches
> and open bugs, and then somebody will sponsor the work (after some
> reasonable time), together with a move to science team.
> 
> 
> thanks!
> 
> Gianfranco
> 
> 
> 2016-06-07 23:42 GMT+02:00 Jerome BENOIT
> :
>> Hello All,
>> 
>> since a while I [0] have wanted to update the [surface] evolver
>> package [1,2] because I used it a few years ego [and because I may
>> use it a gain sooner or later]: I try to contact several times the
>> current maintainer in view to get the package officially orphaned
>> before any ITA submission. So far, I got no feed back. The package
>> is clearly abandoned. Is there any Debian authority that have the
>> permission to orphan it ? If not, what can be done ?
>> 
>> Thanks, Jerome
>> 
>> [0]
>> https://qa.debian.org/developer.php?login=calculus%40rezozer.net=1
>>
>> 
[1] https://packages.qa.debian.org/e/evolver.html
>> [2] http://facstaff.susqu.edu/brakke/evolver/evolver.html
>> 
>> -- debian-science-maintainers mailing list 
>> debian-science-maintain...@lists.alioth.debian.org 
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers

Bug#827333: RFS: newlisp/10.7.0-1 [ITP]

[Andrey Rahmatullin]

On Tue, Jun 28, 2016 at 02:42:47PM -0400, Sergio Durigan Junior wrote:
> >> > I've uploaded the package, thanks for your contribution to Debian :)
> >> Thank you!  I guess I will ping you again when the package has been
> >> accepted, so that you can allow me to make further uploads as a DM,
> >> right?
> > OK.
> 
> Hi Andrey,
> 
> The package has been accepted into the archives yesterday, so if you
> could please give me DM access to it I'd appreciate!
Sorry for misunderstanding :) Usually DM rights are granted after
sponsoring several good-looking uploads of a package, so I won't do this
now but if you will continue preparing good uploads I will be glad to
grant the rights :)

-- 
WBR, wRAR


signature.asc
Description: PGP signature