Bug#853140: ITP: node-ieee754 -- Read/write IEEE754 floating point numbers from/to a Buffer or array-like object

[Siddhesh Rane]

Package: wnpp
Severity: wishlist
Owner: Siddhesh Rane 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-ieee754
  Version : 1.1.8
  Upstream Author : Feross Aboukhadijeh  (http://feross.org)
* URL : https://github.com/feross/ieee754#readme
* License : BSD-3-Clause
  Programming Lang: JavaScript
  Description : Read/write IEEE754 floating point numbers from/to
a Buffer or array-like object

 Node.js is an event-based server-side JavaScript engine.

Re: manpages.debian.org has been modernized!

[Bernd Zeimetz]

On 01/30/2017 12:44 AM, Sean Whitton wrote:
>> Same here. Also since I've moved my major packages to github, a constant
>> stream of pull requests for even simple bugs like typos is coming in.
>> People are used to github and how to create a pull request on the web
>> interface, and I can just merge these changes with a few clicks.
> 
> Please don't forget about git-request-pull(1), or it's simpler cousin,
> "to fix this bug please merge branch foo from repo bar".

That still involves cloning re pository, pushing stuff...
Using a web interface is much more easy - and works well even on a
tablet. And even people who don't know how to use the cosole are able to
handle it.

-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Yves-Alexis Perez]

On Sun, 2017-01-29 at 17:54 +, Debian Bug Tracking System wrote:
> Processing commands for cont...@bugs.debian.org:
> 
> > reassign 853084 xfce4-pulseaudio-plugin
> 
> Bug #853084 [general] general: Not connected to PulseAudio server
> Bug reassigned from package 'general' to 'xfce4-pulseaudio-plugin'.
> Ignoring request to alter found versions of bug #853084 to the same values
> previously set
> Ignoring request to alter fixed versions of bug #853084 to the same values
> previously set
> > thanks
> 
Michael, it's always appreciated when you add a bit of context when
reassigning bug.

Fredrik, the plugin already recommends pavucontrol (which recommends
pulseaudio) so it should already have been installed unless you manually asked
 not. But right, it might be a good idea to have a direct pulseaudio
recommends .

Regards,
-- 
Yves-Alexis

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

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Michael Biebl]

Am 30.01.2017 um 11:15 schrieb Yves-Alexis Perez:

> Fredrik, the plugin already recommends pavucontrol (which recommends
> pulseaudio) so it should already have been installed unless you manually asked
>  not. But right, it might be a good idea to have a direct pulseaudio
> recommends .

A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless


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



signature.asc
Description: OpenPGP digital signature

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Guus Sliepen]

On Mon, Jan 30, 2017 at 11:19:32AM +0100, Michael Biebl wrote:

> > Fredrik, the plugin already recommends pavucontrol (which recommends
> > pulseaudio) so it should already have been installed unless you manually 
> > asked
> >  not. But right, it might be a good idea to have a direct pulseaudio
> > recommends .
> 
> A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless

But xfce4 Depends on xfce4-pulseaudio-plugin. Maybe it is better if that
became a Recommends then?

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Jonas Smedegaard]

Hi Guus,

Quoting Guus Sliepen (2017-01-30 11:29:17)
> On Mon, Jan 30, 2017 at 11:19:32AM +0100, Michael Biebl wrote:
> 
> > > Fredrik, the plugin already recommends pavucontrol (which recommends
> > > pulseaudio) so it should already have been installed unless you manually 
> > > asked
> > >  not. But right, it might be a good idea to have a direct pulseaudio
> > > recommends .
> > 
> > A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless
> 
> But xfce4 Depends on xfce4-pulseaudio-plugin. Maybe it is better if that
> became a Recommends then?

I'd say yes, but that would be a _different bug, and depends on how that 
metapackage is intended to behave.

For each _direct_ package relation, question is if related packages a 
needed for _all_ uses of the package (depend), there is a rare use 
without it (recommend) or it is only uncommonly needed (suggest).

If it _never_ makes sense to install xfce4 metapackage without also 
installing xfce4-pulseaudio-plugin (i.e. if xfwm4 crashes without that 
plugin existing), then it makes sense to declare strict as a dependency.

Argument above by Michael is that it sounds like it _never_ makes sense 
to install xfce4-pulseaudio-plugin without also installing pulseaudio.

Example: If xfce4-pulseaudio-plugin can somehow communicate (by itself, 
without help from pulseaudio package!) with a remote pulseaudio install 
on a separate host, then it makes sense for the package relation to be a 
recommendation.  If you cannot describe a single use case for this 
package without its related package, then depend on that other package 
(no matter needs of _reverse_ related packages further up the stack!).


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: manpages.debian.org has been modernized!

[The Wanderer]

On 2017-01-30 at 03:54, Bernd Zeimetz wrote:

> On 01/30/2017 12:44 AM, Sean Whitton wrote:

>>> Same here. Also since I've moved my major packages to github, a
>>> constant stream of pull requests for even simple bugs like typos
>>> is coming in. People are used to github and how to create a pull
>>> request on the web interface, and I can just merge these changes
>>> with a few clicks.
>> 
>> Please don't forget about git-request-pull(1), or it's simpler
>> cousin, "to fix this bug please merge branch foo from repo bar".
> 
> That still involves cloning re pository, pushing stuff... Using a web
> interface is much more easy - and works well even on a tablet. And
> even people who don't know how to use the cosole are able to handle
> it.

If someone isn't cloning the repository locally, how is that someone
creating the patch which is in the git repo which is requested to be
pulled?

And if someone isn't pushing that locally-cloned repo back to github,
how is that someone getting the local changes into github to be pulled?
(AFAIK, the official way of getting your local changes into github is
with 'git push'; at least that's what I had to use the one time I tried
to work with github other than to clone a repo hosted there, although
admittedly my network situation is a bit unusual.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: manpages.debian.org has been modernized!

[Bernd Zeimetz]

On 01/30/2017 01:32 PM, The Wanderer wrote:
> If someone isn't cloning the repository locally, how is that someone
> creating the patch which is in the git repo which is requested to be
> pulled?

Choose a random file in a random repository you are not allowed to
commit to. Click on the edit button. Ack that github will create a fork
to edit the file. Make your changes. Click on save and on create a pull
request... just a few clicks...



-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

github and its workflows (was Re: manpages.debian.org has been modernized!)

[The Wanderer]

On 2017-01-30 at 07:38, Bernd Zeimetz wrote:

> On 01/30/2017 01:32 PM, The Wanderer wrote:
> 
>> If someone isn't cloning the repository locally, how is that
>> someone creating the patch which is in the git repo which is
>> requested to be pulled?
> 
> Choose a random file in a random repository you are not allowed to 
> commit to. Click on the edit button. Ack that github will create a
> fork to edit the file. Make your changes. Click on save and on create
> a pull request... just a few clicks...

...bwah?

I deleted my "unless github has incorporated an _editor interface_ now"
comment, because I thought that was too tangential and off-the-wall to
bring up even as a hypothetical.

Are you saying that people are writing and submitting patches via a
Web-based editor interface, and that you're recommending that people
consider _accepting_ those patches, when they haven't even been
_build-tested_ before submission (because you can't build-test - much
less actually _test_ - without the full source tree, which you'd obtain
by pulling the repo)?

Maybe I'm missing something, or maybe I'm just backwards, but that
sounds _insane_ to me.

(I imagine it would be _possible_ to have a workflow of something like
"clone the repo, edit and test locally, copy-and-paste the full contents
of the edited source files one-by-one into the editor interface", just
to avoid 'git push' - but that seems like overkill, and would still
involve cloning the repo.)

If github really is encouraging that sort of thing (by including such an
editor interface) - as well as the "keep the only copy of your fork in
the same centralized location as the original code" mindset implied by a
don't-bother-to-clone-a-local-copy workflow - that leaves me
considerably less comfortable with the idea of people using github than
I used to be.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: manpages.debian.org has been modernized!

[Alec Leamas]

On 30/01/17 13:32, The Wanderer wrote:

On 2017-01-30 at 03:54, Bernd Zeimetz wrote:


On 01/30/2017 12:44 AM, Sean Whitton wrote:



Same here. Also since I've moved my major packages to github, a
constant stream of pull requests for even simple bugs like typos
is coming in. People are used to github and how to create a pull
request on the web interface, and I can just merge these changes
with a few clicks.


Please don't forget about git-request-pull(1), or it's simpler
cousin, "to fix this bug please merge branch foo from repo bar".


Easy enough for me. But Sean and Bernd has a point,  the github workflow 
*is* easier. It's also used by so many that it's well established.


That said, the very idea with debian is about free software; free as in 
Open Source. And github is certainly not free. So, we should try hard to 
push for the free alternatives. If we had applied the github thinking 
"use what works, free or not" we shouldn't be where we are.


But, we cannot just say "our tools are as good as github". Because they 
are not.  We need to understand it, and see what can be done. It's an 
uphill battle, but also uphill battles can be won.



Cheers!

--alec

Re: manpages.debian.org has been modernized!

[Paul Wise]

On Mon, Jan 30, 2017 at 8:54 PM, Alec Leamas wrote:

> But, we cannot just say "our tools are as good as github".
> Because they are not.

That is a very subjective statement. I for one really really dislike
github and much prefer other workflows.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

[Dimitri John Ledkov]

On 30 January 2017 at 12:53, The Wanderer  wrote:
> On 2017-01-30 at 07:38, Bernd Zeimetz wrote:
>
>> On 01/30/2017 01:32 PM, The Wanderer wrote:
>>
>>> If someone isn't cloning the repository locally, how is that
>>> someone creating the patch which is in the git repo which is
>>> requested to be pulled?
>>
>> Choose a random file in a random repository you are not allowed to
>> commit to. Click on the edit button. Ack that github will create a
>> fork to edit the file. Make your changes. Click on save and on create
>> a pull request... just a few clicks...
>
> ...bwah?
>
> I deleted my "unless github has incorporated an _editor interface_ now"
> comment, because I thought that was too tangential and off-the-wall to
> bring up even as a hypothetical.
>
> Are you saying that people are writing and submitting patches via a
> Web-based editor interface, and that you're recommending that people
> consider _accepting_ those patches, when they haven't even been
> _build-tested_ before submission (because you can't build-test - much
> less actually _test_ - without the full source tree, which you'd obtain
> by pulling the repo)?
>
> Maybe I'm missing something, or maybe I'm just backwards, but that
> sounds _insane_ to me.
>

Well, clearly, one should have CI hooked up to run the tests against
merge proposals and master branch. And pretend that is good enough.

In practice, works fine for small edits, e.g. typos and grammar corrections.

> (I imagine it would be _possible_ to have a workflow of something like
> "clone the repo, edit and test locally, copy-and-paste the full contents
> of the edited source files one-by-one into the editor interface", just
> to avoid 'git push' - but that seems like overkill, and would still
> involve cloning the repo.)
>
> If github really is encouraging that sort of thing (by including such an
> editor interface) - as well as the "keep the only copy of your fork in
> the same centralized location as the original code" mindset implied by a
> don't-bother-to-clone-a-local-copy workflow - that leaves me
> considerably less comfortable with the idea of people using github than
> I used to be.
>
> --
>The Wanderer
>
> The reasonable man adapts himself to the world; the unreasonable one
> persists in trying to adapt the world to himself. Therefore all
> progress depends on the unreasonable man. -- George Bernard Shaw
>

-- 
Regards,

Dimitri.

Re: Bug#853026: ITP: pointback -- restore window points when returning to buffers

[Simon Richter]

Hi,

On 29.01.2017 02:32, Sean Whitton wrote:

> * Package name: pointback

Should that be "emacs-pointback"?

   Simon



signature.asc
Description: OpenPGP digital signature

Re: manpages.debian.org has been modernized!

[Alec Leamas]

On 30/01/17 13:59, Paul Wise wrote:

On Mon, Jan 30, 2017 at 8:54 PM, Alec Leamas wrote:


But, we cannot just say "our tools are as good as github".
Because they are not.


That is a very subjective statement. I for one really really dislike
github and much prefer other workflows.


Agreed, sloppy wording from my side. Personally, I also side with you in 
the workflow discussion. That said, github *is* easier for a whole lot 
of people, more used to GUI tools and less comfortable with the  console 
than you. And me.


Which also is a subjective view. I have no data,  just my gut feeling.


--alec

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

[Holger Levsen]

On Mon, Jan 30, 2017 at 07:53:58AM -0500, The Wanderer wrote:
> Are you saying that people are writing and submitting patches via a
> Web-based editor interface, and that you're recommending that people
> consider _accepting_ those patches, when they haven't even been
> _build-tested_ before submission (because you can't build-test - much
> less actually _test_ - without the full source tree, which you'd obtain
> by pulling the repo)?
 
besides that github supports automated testing too, I think that you're
too much thinking of (big|bigger) patches while I imagine that most of
the patches created via this web editor are rather simple typo fixes and
small correcttions and such.

> […] as well as the "keep the only copy of your fork in
> the same centralized location as the original code" mindset implied by a
> don't-bother-to-clone-a-local-copy workflow - that leaves me
> considerably less comfortable with the idea of people using github than
> I used to be.

which also becomes less troublesome if such changes are merged soon…


To be clear, I do believe in owning ones infrastructures, but I also see
how this encourages small contributions and makes them easy and I do see
this as a good thing too.

I think this is really great to lower the barrier for newcomers, to make
them feel accepted and I too dive deeper eventually.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Git hosting for code that provides Debian services

[Pirate Praveen]

On വെള്ളി 20 ജനുവരി 2017 04:59 രാവിലെ, Ben Finney wrote:
> Ian Jackson  writes:
> 
>> For a debian.org service, I would like to be able to check out the
>> running version without interacting with a proprietary online service.
> 
> I have been looking at the GitLab instance hosted at FOSS Community
> India's servers, https://git.fosscommunity.in/>. It's been working
> fine for a few months.
> 
> Do the FOSS Community India people want us to make larger use of that
> GitLab instance for general Debian code bases?

We'd be happy to have more people use it.

There is also gitlab.debian.net alias for this instance, though it will
need a local account to work. There is a feature request for supporting
multiple domains https://gitlab.com/gitlab-org/gitlab-ce/issues/19449

>> Using github as well is up to you. I won't try to talk you out of it.
>> But I think for a service in the .debian.org namespace, bugs should be
>> reportable without interacting with a proprietary web service.
> 
> I believe the GitLab running at the above URL is entirely free software.

The entire idea of that instance is to make a 100% Free Software public
git hosting service available to the Free Software community.

Yes, it is running gitlab debian package backported for jessie
(https://people.debian.org/~praveen/gitlab). All code is in debian main.
We'll switch to stretch once its released so it will be a fully official
package (though I plan to provide updates via stretch-backports, which
is still official debian).



signature.asc
Description: OpenPGP digital signature

Bug#853177: ITP: parent-mode-el -- get major mode's parent modes

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: parent-mode-el
  Version : 2.3
  Upstream Author : Fanael Linithien 
* URL : https://github.com/Fanael/parent-mode
* License : BSD-2-clause
  Programming Lang: Emacs Lisp
  Description : get major mode's parent modes

This package provides `parent-mode', Emacs mode to get major mode's
parent modes.

Bug#853178: ITP: ruby-signet -- Signet is an OAuth 1.0 / OAuth 2.0 implementation

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ruby-signet
  Version : 0.5.1
  Upstream Author : "Bob Aman", "Steven Bazyl"
* URL :  https://rubygems.org/gems/signet
* License : Apache-2.0
  Programming Lang: ruby
  Description : Signet is an OAuth 1.0 / OAuth 2.0 implementation




signature.asc
Description: OpenPGP digital signature

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 06:57:46PM +0530, Pirate Praveen wrote:
> The entire idea of that instance is to make a 100% Free Software public
> git hosting service available to the Free Software community.

Is the Gitlab software still an "open core" product of Gitlab the
company?

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug Squashing Party in MiniDebConf Curitiba 2017

[Lucas Kanashiro]

Hi,

I am pleased to announce a BSP (Bug Squashing Party) hosted at UTFPR [1] 
in Curitiba, Brazil.
The BSP will occur during the MiniDebConf Curitiba 2017 [2], we intend 
to spend a weekend having

fun and trying to fix many bugs as we can.

Date: March, 18th/19th 2017
Start: 10 am on the 18th and 19th
End: 6 pm on the 18th and 19th
Location: UTFPR - Campus Curitiba
  Av. Sete de Setembro, 3165
  Curitiba, Brazil.

We created a wiki page with some information about the BSP [3], but you 
can probably find more

info in MiniDebConf Curitiba 2017 website [2].

We are looking forward to the presence of anyone who is interested in 
having fun with us and

contribute with Debian. See you there :)

Thanks for your attention!

[1] https://www.openstreetmap.org/way/427929017
[2] http://br2017.mini.debconf.org/
[3] https://wiki.debian.org/BSP/2017/03/br/Curitiba

--
Lucas Kanashiro

Re: Git hosting for code that provides Debian services

[Pirate Praveen]

On തിങ്കള്‍ 30 ജനുവരി 2017 07:05 വൈകു, Lars Wirzenius wrote:
> On Mon, Jan 30, 2017 at 06:57:46PM +0530, Pirate Praveen wrote:
>> The entire idea of that instance is to make a 100% Free Software public
>> git hosting service available to the Free Software community.
> 
> Is the Gitlab software still an "open core" product of Gitlab the
> company?
> 

git.fosscommunity.in is running Gitlab Community Edition, code that is
DFSG compliant and accepted in debian main
https://tracker.debian.org/pkg/gitlab

gitlab.com runs Gitlab Enterprise Edition. See
https://about.gitlab.com/products/ for different products of Gitlab Inc



signature.asc
Description: OpenPGP digital signature

Bug#853182: ITP: highlight-numbers-el -- highlight numbers in source code

[Lev Lamberov]

Package: wnpp
Severity: wishlist
Owner: Lev Lamberov 

* Package name: highlight-numbers-el
  Version : 0.2.3
  Upstream Author : Fanael Linithien 
* URL : https://github.com/Fanael/highlight-numbers
* License : BSD-2-clause
  Programming Lang: Emacs Lisp
  Description : highlight numbers in source code

This minor mode provides syntax highlighting of numeric literals in
source code, like what many editors provide by default.

It's easy to add or redefine what exactly consitutes a "number" in
given major mode. See `highlight-numbers-modelist'.

Bug#783975: ITP: giac -- computer algebra system

[Ximin Luo]

Package: wnpp
Followup-For: Bug #783975
Owner: Ximin Luo 

Control: retitle -1 RFP: giac -- computer algebra system

Bug#853190: ITP: libpod-elemental-transformer-list-perl -- Pod transformer to convert :lists sections to standard Pod lists

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-elemental-transformer-list-perl
  Version : 0.102000
  Upstream Author : Ricardo SIGNES 
* URL : https://metacpan.org/release/Pod-Elemental-Transformer-List
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod transformer to convert :lists sections to standard Pod 
lists

Pod::Elemental::Transformer::List is a transformer for a
Pod::Elemental::Document which produces traditional Pod5 lists
(=over / =item / =item / =back) from an alternative more compact
syntax.

Bug#853191: ITP: libpod-weaver-section-generatesection-perl -- Pod::Weaver plugin

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-section-generatesection-perl
  Version : 1.02
  Upstream Author : Carnë Draug 
* URL : 
https://metacpan.org/release/Pod-Weaver-Section-GenerateSection
* License : GPL-3+
  Programming Lang: Perl
  Description : Pod::Weaver plugin to add Pod sections from a template text.

Pod::Weaver::Section::GenerateSection provides a Pod::Weaver plugin
to introduce a Pod section in the distribution modules.  This section
is generated from a template text where multiple variables can be
expanded to the values in the distribution metadata.

Re: Looking for maintainer(s) of the sigrok packages

[Jonathan McDowell]

Aaron, if you're still interested in getting involved in looking after
these I can help with giving things a look over and sponsoring their
uploads (with the aim that you'd eventually go for at least DM status
and be able to do the uploads yourself).

On Fri, Jan 27, 2017 at 06:44:54PM +0100, Uwe Hermann wrote:
> Hi, I'm looking for a maintainer (or a team of maintainers) for all
> sigrok packages in Debian (see www.sigrok.org for details).
> 
> I've already officially RFA'd the packages a few minutes ago.
> 
> Lack of spare time doesn't currently allow me to keep the packages
> up-to-date in a timely manner, plus I'm part of upstream and I'd like
> to spend more time with upstream development rather than distro stuff.
> 
> Hence, I'm looking for active DDs to take over the following packages:
> 
> libsigrok-dev - sigrok hardware driver library - development files
> libsigrok0-dev - sigrok hardware driver library (transitional dummy package)
> libsigrok2 - sigrok hardware driver library - shared library
> libsigrokdecode-dev - sigrok protocol decoding library - development files
> libsigrokdecode0-dev - sigrok protocol decoding library (transitional dummy 
> package)
> libsigrokdecode2 - sigrok protocol decoding library - shared library
> libserialport-dev - Crossplatform serial port handling library - development 
> files
> libserialport0 - Crossplatform serial port handling library - shared library
> pulseview - sigrok logic analyzer, oscilloscope, and MSO GUI
> sigrok - Logic analyzer and protocol decoder software suite (metapackage)
> sigrok-cli - command-line frontend for the sigrok software
> sigrok-firmware-fx2lafw - Firmware for Cypress FX2(LP) based logic analyzers
> 
> Optionally, there are also still old open RFPs for these additional (less
> important) sigrok-related packages:
> 
>  #669073 RFP: sigrok-dumps -- example logic analyzer protocol data for sigrok
>  #669074 RFP: sigrok-firmware -- firmware files for various logic analyzers
>  #681881 RFP: sigrok-util -- sigrok related utilities
>
> If any active DD is interested in taking over these packages, please
> go ahead, no need to ask for permission. It probably makes sense to
> have at least the packages that directly depend on each other be
> maintained by the same DD(s).
> 
> I'll be happy to answer any questions regarding upstream releases,
> shared libs, versioning, etc. etc. However, I'll not be able to do any
> sponsoring or mentoring of non-DDs (lack of spare time, see above).

J.

-- 
/-\ |   "I've checked, but I can't find
|@/  Debian GNU/Linux Developer | anything in the bible which
\-  |supports C++." -- Malcolm Ray


signature.asc
Description: Digital signature

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

[Bernd Zeimetz]

On 01/30/2017 01:53 PM, The Wanderer wrote:
> Are you saying that people are writing and submitting patches via a
> Web-based editor interface,

yes, nothing wrong with that.

> and that you're recommending that people
> consider _accepting_ those patches, when they haven't even been
> _build-tested_ before submission (because you can't build-test - much
> less actually _test_ - without the full source tree, which you'd obtain
> by pulling the repo)?

nobody stops you from build-testing pull requests. But people using the
web interface usually don't change lots of things because coding in the
web editor is no fun. Such changes are small and easy to review usually.
And you can always fetch the pull request and use your command line tools.


> Maybe I'm missing something, or maybe I'm just backwards, but that
> sounds _insane_ to me.

its not more or less insane then what you do in your daily git usage.
either you review things properly or not.


> (I imagine it would be _possible_ to have a workflow of something like
> "clone the repo, edit and test locally, copy-and-paste the full contents
> of the edited source files one-by-one into the editor interface", just
> to avoid 'git push' - but that seems like overkill, and would still
> involve cloning the repo.)

why should one do that?

> If github really is encouraging that sort of thing (by including such an
> editor interface) - as well as the "keep the only copy of your fork in
> the same centralized location as the original code" mindset implied by a
> don't-bother-to-clone-a-local-copy workflow - that leaves me
> considerably less comfortable with the idea of people using github than
> I used to be.

You start to sound like a troll.

So far I think I've created like a dozen of pull requests to fix typos
using the web interface, and I think I've accepted an even bigger amount
of changes without rebuilding everything before accepting the pull
request. A lot of changes don't even need a rebuild to know that they
won't break things.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

[Bernd Zeimetz]

On 01/30/2017 02:14 PM, Holger Levsen wrote:
> On Mon, Jan 30, 2017 at 07:53:58AM -0500, The Wanderer wrote:
>> Are you saying that people are writing and submitting patches via a
>> Web-based editor interface, and that you're recommending that people
>> consider _accepting_ those patches, when they haven't even been
>> _build-tested_ before submission (because you can't build-test - much
>> less actually _test_ - without the full source tree, which you'd obtain
>> by pulling the repo)?
>  
> besides that github supports automated testing too, I think that you're
> too much thinking of (big|bigger) patches while I imagine that most of
> the patches created via this web editor are rather simple typo fixes and
> small correcttions and such.

Indeed, if done right, pull requests are built in travis and the result
is being displayed on the pull requests' page.


> To be clear, I do believe in owning ones infrastructures, but I also see
> how this encourages small contributions and makes them easy and I do see
> this as a good thing too.

Exactly - it is easy to make and receive contributions and much faster
to send and handle them than using the BTS

> I think this is really great to lower the barrier for newcomers, to make
> them feel accepted and I too dive deeper eventually.

+1
Not only newcomers, but also the typical sysadmin with no spare time.


-- 
 Bernd ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F



signature.asc
Description: OpenPGP digital signature

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 07:16:59PM +0530, Pirate Praveen wrote:
> On തിങ്കള്‍ 30 ജനുവരി 2017 07:05 വൈകു, Lars Wirzenius wrote:
> > Is the Gitlab software still an "open core" product of Gitlab the
> > company?
> > 
> 
> git.fosscommunity.in is running Gitlab Community Edition, code that is
> DFSG compliant and accepted in debian main
> https://tracker.debian.org/pkg/gitlab
> 
> gitlab.com runs Gitlab Enterprise Edition. See
> https://about.gitlab.com/products/ for different products of Gitlab Inc

Right, so the answer is that Gitlab is still an "open core" project. I
therefore repeat that I find it sad that it's being pushed as a
service for Debian to use.

I personally don't find "open core" projects to be fully free
software, even if they follow current DFSG, OSI, and FSF criteria. I
may be in a minority with that view, of course.

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Re: Bug#853026: ITP: pointback -- restore window points when returning to buffers

[Sean Whitton]

Dear Simon,

On Mon, Jan 30, 2017 at 02:05:03PM +0100, Simon Richter wrote:
> Hi,
> 
> On 29.01.2017 02:32, Sean Whitton wrote:
> 
> > * Package name: pointback
> 
> Should that be "emacs-pointback"?

Thank you for your feedback.

Do you know of another prominent project called 'pointback' that might
someday be packaged for Debian?

In the pkg-emacsen team, we use the upstream project name for source
packages unless it is very generic (e.g. we have 'evil-el' instead of
'evil', and 'emacs-buttercup' instead of 'buttercup').

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#853212: ITP: libpod-weaver-plugin-ensureuniquesections-perl -- Pod::Weaver plugin to check for duplicate Pod section headers

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-plugin-ensureuniquesections-perl
  Version : 0.163250
  Upstream Author : Ryan C. Thompson 
* URL : 
https://metacpan.org/release/Pod-Weaver-Plugin-EnsureUniqueSections
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod::Weaver plugin to check for duplicate Pod section 
headers

Pod::Weaver::Plugin::EnsureUniqueSections is a Pod::Weaver plugin to
ensure that the Pod after weaving has no duplicate top-level section
headers.  This can help you if you are converting from writing all
your own POD to generating it with Pod::Weaver.  If you begin
generating a section with Pod::Weaver but you forget to delete the
manually written section of the same name, this plugin will warn you.

Re: Git hosting for code that provides Debian services

[Alexander Wirt]

On Mon, 30 Jan 2017, Lars Wirzenius wrote:

> On Mon, Jan 30, 2017 at 07:16:59PM +0530, Pirate Praveen wrote:
> > On തിങ്കള്‍ 30 ജനുവരി 2017 07:05 വൈകു, Lars Wirzenius wrote:
> > > Is the Gitlab software still an "open core" product of Gitlab the
> > > company?
> > > 
> > 
> > git.fosscommunity.in is running Gitlab Community Edition, code that is
> > DFSG compliant and accepted in debian main
> > https://tracker.debian.org/pkg/gitlab
> > 
> > gitlab.com runs Gitlab Enterprise Edition. See
> > https://about.gitlab.com/products/ for different products of Gitlab Inc
> 
> Right, so the answer is that Gitlab is still an "open core" project. I
> therefore repeat that I find it sad that it's being pushed as a
> service for Debian to use.
> 
> I personally don't find "open core" projects to be fully free
> software, even if they follow current DFSG, OSI, and FSF criteria. I
> may be in a minority with that view, of course.
I am not sure what you mean with "debian", but we (git.d.o) doesn't plan to
use gitlab (for exact that reasoning).

Alex



signature.asc
Description: PGP signature

Re: manpages.debian.org has been modernized!

[Sean Whitton]

Dear Alec,

On Mon, Jan 30, 2017 at 01:54:28PM +0100, Alec Leamas wrote:
> Easy enough for me. But Sean and Bernd has a point,  the github workflow
> *is* easier.

Just to be clear, I wasn't one of those arguing that it's easier.

> But, we cannot just say "our tools are as good as github". Because they are
> not.  We need to understand it, and see what can be done. It's an uphill
> battle, but also uphill battles can be won.

I agree, they aren't as good.  However, they're very nearly as good, and
it's too common to overstate how good GitHub's workflow is.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: github and its workflows (was Re: manpages.debian.org has been modernized!)

[Sean Whitton]

Hello Bernd,

On Mon, Jan 30, 2017 at 04:10:38PM +0100, Bernd Zeimetz wrote:
> On 01/30/2017 02:14 PM, Holger Levsen wrote:
> > To be clear, I do believe in owning ones infrastructures, but I also see
> > how this encourages small contributions and makes them easy and I do see
> > this as a good thing too.
> 
> Exactly - it is easy to make and receive contributions and much faster
> to send and handle them than using the BTS
> 
> > I think this is really great to lower the barrier for newcomers, to make
> > them feel accepted and I too dive deeper eventually.
> 
> +1
> Not only newcomers, but also the typical sysadmin with no spare time.

I think we might be overstating the value of the kind of improvements
that can be submitted with GitHub's web-based text editor.

Firstly, it is not clear to me how the barrier to getting involved with
more substantial bugs is affected by the fact that I can trivially
submit typo fixes.  What did you have in mind?

Secondly, I suspect that the feeling of being accepted might be
illusory.  Submitting typo fixes that don't require any review does not
help build any relationships.

I don't mean that these fixes have *no* value, of course.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Git hosting for code that provides Debian services

[Ian Campbell]

On Mon, 2017-01-30 at 09:53 -0700, Sean Whitton wrote:
> Dear Lars,
> 
> On Mon, Jan 30, 2017 at 05:18:38PM +0200, Lars Wirzenius wrote:
> > I personally don't find "open core" projects to be fully free
> > software, even if they follow current DFSG, OSI, and FSF criteria. I
> > may be in a minority with that view, of course.
> 
> Possibly we should change mailing list, but could you explain more?
> 
> I agree that there can be good reasons to avoid open core projects: the
> open core part might not be adequately maintained, it might be
> prohibitively hard to reimplement non-open core features, etc.  But none
> of these are reasons why open core projects are not DFSG-free.

Lars said that even though they are DFSG-free they do not satisfy his
own personal Freeness criteria. He didn't suggest they weren't DFSG-
free which is what you seem to have read (judging from the final
sentence).

Ian.

Bug#853215: ITP: libpod-weaver-section-contributors-perl -- Pod::Weaver plugin for a section listing contributors

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-section-contributors-perl
  Version : 0.009
  Upstream Author : Keedi Kim 
* URL : https://metacpan.org/release/Pod-Weaver-Section-Contributors
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Pod::Weaver plugin for a section listing contributors

Pod::Weaver::Section::Contributors provides a Pod::Weaver plugin to
generate a section listing modules contributors.  These can be named
on the source of individual modules as well as on the pod weaver and
dist zilla configuration files.

Re: Git hosting for code that provides Debian services

[Sean Whitton]

Dear Lars,

On Mon, Jan 30, 2017 at 05:18:38PM +0200, Lars Wirzenius wrote:
> I personally don't find "open core" projects to be fully free
> software, even if they follow current DFSG, OSI, and FSF criteria. I
> may be in a minority with that view, of course.

Possibly we should change mailing list, but could you explain more?

I agree that there can be good reasons to avoid open core projects: the
open core part might not be adequately maintained, it might be
prohibitively hard to reimplement non-open core features, etc.  But none
of these are reasons why open core projects are not DFSG-free.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#853217: ITP: libpod-weaver-section-legal-complicated-perl -- Pod::Weaver plugin for Pod sections of authors, copyright holders, and licenses

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libpod-weaver-section-legal-complicated-perl
  Version : 1.21
  Upstream Author : Carnë Draug 
* URL : 
https://metacpan.org/release/Pod-Weaver-Section-Legal-Complicated
* License : GPL-3+
  Programming Lang: Perl
  Description : Pod::Weaver plugin for Pod sections of authors, copyright 
holders, and licenses

Pod::Weaver::Section::Legal::Complicated is a Pod::Weaver plugin to
create Pod sections listing authors, copyright owners, and licenses
of each module in the distribution.  It is targeted at distributions
with a large number of modules and where different module may have
different authos, copyright holders, and licenses.  It does so by
parsing individual modules and looking for specific comments.

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Guus Sliepen]

On Mon, Jan 30, 2017 at 09:13:00AM -0800, Octavio Alvarez wrote:

> >> A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless
> > 
> > But xfce4 Depends on xfce4-pulseaudio-plugin. Maybe it is better if that
> > became a Recommends then?
> 
> What's the problem with two packages depending on the same package? What am I 
> missing?

That if xfce4 Depends: xfce4-pulseaudio-plugin, which in turn Depends:
pulseaudio, then suddenly xfce4 always pulls in pulseaudio, even though
it doesn't actually depend on pulseaudio.

I agree that the xfce4-pulseaudio-plugin is useless without pulseaudio,
so there you want a Depends. But XFCE doesn't depend on the
xfce4-pulseaudio-plugin. In fact, with a clean install, the default
panel configuration doesn't even include that plugin.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: Digital signature

Re: [Pkg-xfce-devel] Processed: reassign 853084 to xfce4-pulseaudio-plugin

[Octavio Alvarez]

On 01/30/2017 02:29 AM, Guus Sliepen wrote:
> On Mon, Jan 30, 2017 at 11:19:32AM +0100, Michael Biebl wrote:
> 
>>> Fredrik, the plugin already recommends pavucontrol (which recommends
>>> pulseaudio) so it should already have been installed unless you manually 
>>> asked
>>>  not. But right, it might be a good idea to have a direct pulseaudio
>>> recommends .
>>
>> A pulseaudio plugin without a pulseaudio "Depends" seems rather pointless
> 
> But xfce4 Depends on xfce4-pulseaudio-plugin. Maybe it is better if that
> became a Recommends then?

What's the problem with two packages depending on the same package?

What am I missing?

-- 
Octavio.

Re: Git hosting for code that provides Debian services

[Sean Whitton]

On Mon, Jan 30, 2017 at 04:59:00PM +, Ian Campbell wrote:
> Lars said that even though they are DFSG-free they do not satisfy his
> own personal Freeness criteria. He didn't suggest they weren't DFSG-
> free which is what you seem to have read (judging from the final
> sentence).

Sorry, my e-mail was poorly worded.  I'd like to know why Lars thinks
that they are not sufficiently free.  The reasons I listed might count
for him as reasons the software isn't free, or he might have other
reasons.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Running Debian in the Web browser (JS VM)?

[Olivier Berger]

Olivier Berger  writes:

> Note that the OpenRISC isn't my main interest here, even if I mentioned
> jor1k.
>
> Simulating any other architecture may fit, as my purpose, so far would
> be to try and run a Debian system inside the browser... and the
> underlying CPU / simulator wouldn't matter much.
>
> Jor1k is simulating an OpenRISC, but I don't mind trying with x86 ala
> http://bellard.org/jslinux/.
>

Btw, I've had a look at copy/v86 [0] which looks interesting. There's a
bootable arch system in the demos.

I haven't yet figured out how to boot an installed system as I haven't
understood the way the disks/FS are handled, but the installer works
(slowly).

See [1] for my report / request for more details.

Hope this helps,

[0] https://github.com/copy/v86
[1] https://github.com/copy/v86/issues/128
-- 
Olivier BERGER 
http://www-public.telecom-sudparis.eu/~berger_o/ - OpenPGP-Id: 2048R/5819D7E8
Ingenieur Recherche - Dept INF
Institut Mines-Telecom, Telecom SudParis, Evry (France)

Bug#853229: ITP: libdist-zilla-plugin-readmefrompod-perl -- Dist::Zilla plugin to generate a README from Pod

[Carnë Draug]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?Carn=C3=AB_Draug?= 

* Package name: libdist-zilla-plugin-readmefrompod-perl
  Version : 0.35
  Upstream Author : Fayland Lam 
* URL : https://metacpan.org/release/Dist-Zilla-Plugin-ReadmeFromPod
* License : Artistic or GPL-1+
  Programming Lang: Perl
  Description : Dist::Zilla plugin to generate a README from Pod

Dist::Zilla::Plugin::ReadmeFromPod is a Dist::Zilla plugin that
generates a README from a specific module using Pod::Readme.  It
supports the conversion to "html", "pod", "markdown" and "rtf"
formats.

Re: Git hosting for code that provides Debian services

[Adam Borowski]

On Mon, Jan 30, 2017 at 09:53:49AM -0700, Sean Whitton wrote:
> On Mon, Jan 30, 2017 at 05:18:38PM +0200, Lars Wirzenius wrote:
> > I personally don't find "open core" projects to be fully free
> > software, even if they follow current DFSG, OSI, and FSF criteria. I
> > may be in a minority with that view, of course.
> 
> I agree that there can be good reasons to avoid open core projects: the
> open core part might not be adequately maintained, it might be
> prohibitively hard to reimplement non-open core features, etc.

The problem doesn't lie in lack of maintenance nor in lack in features --
many fully free projects have these issues.  What's bad is that the upstream
has a strong motivation to not accept patches that compete with their
commercial offering.

The project is still DFSG-free and can be forked, but it's not like a team
capable of maintaining something that size will pop up from nothing.  And if
we get too uppity, upstream will become hostile.


Meow!
-- 
Autotools hint: to do a zx-spectrum build on a pdp11 host, type:
  ./configure --host=zx-spectrum --build=pdp11

Re: Git hosting for code that provides Debian services

[Lars Wirzenius]

On Mon, Jan 30, 2017 at 10:31:41AM -0700, Sean Whitton wrote:
> Sorry, my e-mail was poorly worded.  I'd like to know why Lars thinks
> that they are not sufficiently free.

I don't want to spend much time on this (there are backups to make and
test) so I'll just link to the infinitely wise Bradley Kuhn:
http://ebb.org/bkuhn/blog/2009/10/16/open-core-shareware.html

-- 
I want to build worthwhile things that might last. --joeyh


signature.asc
Description: PGP signature

Bug#853259: ITP: ruby-googleauth -- Google Auth Library for Ruby

[Pirate Praveen]

Package: wnpp
Severity: wishlist
Owner: Pirate Praveen 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: ruby-googleauth
  Version : 0.5.1
  Upstream Author : Tim Emiola
* URL :  https://rubygems.org/gems/googleauth
* License : Apache-2.0
  Programming Lang: ruby
  Description : Google Auth Library for Ruby
  Allows simple authorization for accessing Google APIs.
   Provide support for Application Default Credentials, as described at

https://developers.google.com/accounts/docs/application-default-credentials

A dependency for gitlab 8.16




signature.asc
Description: OpenPGP digital signature

Re: manpages.debian.org has been modernized!

[Cyril Brulebois]

Hi,

Michael Stapelberg  (2017-01-18):
> https://manpages.debian.org has been modernized! We have just launched
> a major update to our manpage repository. What used to be served via a
> CGI script is now a statically generated website, and therefore
> blazingly fast.

Many thanks, this looks like a very useful entry point for everyday
work, which would usually depend on having documentation for packages
that are not necessarily installed, sometimes having to switch between
several versions, etc.

Whatever is said in some subthreads: great work, thanks!


KiBi.


signature.asc
Description: Digital signature

Bug#853279: ITP: node-irregular-plurals -- Map of nouns to their irregular plural form

[Abhishek Lolage]

Package: wnpp
Severity: wishlist
Owner: Abhishek Lolage 
X-Debbugs-CC: debian-devel@lists.debian.org

* Package name: node-irregular-plurals
  Version : 1.2.0
  Upstream Author : Sindre Sorhus  (sindresorhus.com

)
* URL : https://github.com/sindresorhus/irregular-plurals#readme
* License : Expat
  Programming Lang: JavaScript
  Description : Map of nouns to their irregular plural form

 This package can be used to find the plural form of some
 nouns who have irregular plural form.
 If the noun ends in an "s", "x", "z", "ch" or "sh", add "es"
 If the noun ends in a "y" and is preceded by a consonant, drop the
 "y" and add "ies"
 If the noun ends in a "y" and is preceded by a vowel, add "s"
 .
 Node.js is an event-based server-side JavaScript engine.