Re: popularity-contest reachs 200000 submitters!

[Gunnar Wolf]

Zlatan Todoric dijo [Sat, Jun 24, 2017 at 01:05:10AM +0200]:
> > Reports by versions of popcon:
> >
> > 1.46 (lenny)   : 2925  
> > 1.49 (squeeze) : 9600
> > 1.56 (wheezy)  : 33450
> > 1.61 (jessie)  : 114427
> > 1.64 (stretch/stable/testing/unstable) : 36640
> > 1.65 (unstable): 785
> > others: 3131
> >
> > (Yes there still more submitters running wheezy or squeeze than stretch).
> 
> Actually if I read it correctly - stretch already surpassed wheezy and
> take into account it is just released so give it a time.

Yes, but do consider that 1.64 is run also by all machines that track
Unstable (and have not updated popcon during the past week) or
Testing. The number of machines tracking Stable / Stretch are just a
fraction of it.

Re: popularity-contest reachs 200000 submitters!

[Zlatan Todoric]

On 06/24/2017 12:11 AM, Bill Allombert wrote:
> Dear developpers,
>
> With the release of stretch, popularity-contest has reached 20
> submitters, see .
>
> Some stats:
>
> Reports by architectures:
>
> amd64 submissions: 160428 
> i386  submissions: 37979 
> others   : 1766
>
> Reports by versions of popcon:
>
> 1.46 (lenny)   : 2925  
> 1.49 (squeeze) : 9600
> 1.56 (wheezy)  : 33450
> 1.61 (jessie)  : 114427
> 1.64 (stretch/stable/testing/unstable) : 36640
> 1.65 (unstable): 785
> others: 3131
>
> (Yes there still more submitters running wheezy or squeeze than stretch).

Actually if I read it correctly - stretch already surpassed wheezy and
take into account it is just released so give it a time.

>
> A lot of credit for that go to Peter Palfrader which optimised the
> popcon CGI to be able to process that volume of submissions without
> choking.
>
> Thanks Peter!
>
> Cheers,

popularity-contest reachs 200000 submitters!

[Bill Allombert]

Dear developpers,

With the release of stretch, popularity-contest has reached 20
submitters, see .

Some stats:

Reports by architectures:

amd64 submissions: 160428 
i386  submissions: 37979 
others   : 1766

Reports by versions of popcon:

1.46 (lenny)   : 2925  
1.49 (squeeze) : 9600
1.56 (wheezy)  : 33450
1.61 (jessie)  : 114427
1.64 (stretch/stable/testing/unstable) : 36640
1.65 (unstable): 785
others: 3131

(Yes there still more submitters running wheezy or squeeze than stretch).

A lot of credit for that go to Peter Palfrader which optimised the
popcon CGI to be able to process that volume of submissions without
choking.

Thanks Peter!

Cheers,
-- 
Bill. 

Imagine a large red swirl here. 

Re: Bug#865642: ITP: libgtk3-webkit-perl -- WebKit bindings for Perl

[Mike Gabriel]

Control: tags -1 wontfix
Control: close -1

Hi,

On  Fr 23 Jun 2017 14:28:49 CEST, Mike Gabriel wrote:


Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: libgtk3-webkit-perl
  Version : 0.06
  Upstream Author : Emmanuel Rodriguez 
* URL : https://metacpan.org/release/Gtk3-WebKit
* License : LGPL-2.1
  Programming Lang: Perl
  Description : WebKit bindings for Perl

 Gtk3::WebKit provides the Perl bindings for the Gtk3 port of WebKit.

 This package will soon be required by the Arctica Web Browser, a  
remote session

 aware web browser with client side rendering overlay.

 The package will be maintained under the umbrella of the pkg-perl group and
 the co-maintained by Debian Remote Maintainers team.


as just discussed with pochu on IRC, packaging the above is not such a  
good idea, as libwebkit-3.0-dev and co. are gonna be removed in the  
buster release cycle.


Thus, closing this ITP...

Mike
--

DAS-NETZWERKTEAM
mike gabriel, herweg 7, 24357 fleckeby
mobile: +49 (1520) 1976 148
landline: +49 (4354) 8390 139

GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22  0782 9AF4 6B30 2577 1B31
mail: mike.gabr...@das-netzwerkteam.de, http://das-netzwerkteam.de



pgpyvvcTD_qRr.pgp
Description: Digitale PGP-Signatur

Bug#865643: ITP: libgstreamer1-perl -- Bindings for GStreamer 1.0, the open source multimedia framework

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: libgstreamer1-perl
  Version : 0.003
  Upstream Author : Timm Murray 
* URL : https://metacpan.org/release/GStreamer1
* License : BSD-2-clause
  Programming Lang: Perl
  Description : Bindings for GStreamer 1.0, the open source multimedia 
framework

 GStreamer1 implements a framework that allows for processing and encoding of
 multimedia sources in a manner similar to a shell pipeline.
 .
 Because it's introspection-based, most of the classes follow directly from
 the C API. Therefore, most of the documentation is by example rather than a
 full breakdown of the class structure.
 .
 This package will soon be required by the Arctica Streaming Server, a
 remote toolset to launch a Pulseaudio daemon inside a remote desktop session
 and have its sink/source streamed to and from a client via GStreamer.
 .
 The package will be maintained under the umbrella of the pkg-perl group and
 the co-maintained by Debian Remote Maintainers team.

Bug#865642: ITP: libgtk3-webkit-perl -- WebKit bindings for Perl

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: libgtk3-webkit-perl
  Version : 0.06
  Upstream Author : Emmanuel Rodriguez 
* URL : https://metacpan.org/release/Gtk3-WebKit
* License : LGPL-2.1
  Programming Lang: Perl
  Description : WebKit bindings for Perl

 Gtk3::WebKit provides the Perl bindings for the Gtk3 port of WebKit.

 This package will soon be required by the Arctica Web Browser, a remote session
 aware web browser with client side rendering overlay.

 The package will be maintained under the umbrella of the pkg-perl group and
 the co-maintained by Debian Remote Maintainers team.

Bug#865639: ITP: fonts-lohit-deva-nepali -- Lohit TrueType font for Nepali

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: fonts-lohit-deva-nepali
  Version : 2.94.2
  Upstream Author : Pravin Satpure and others
* URL : https://pagure.io/lohit
* License : OFL-1.1
  Programming Lang:
  Description : Lohit TrueType font for Nepali

 This package provides Lohit TrueType font for Nepali language.

 This is upstream split from fonts-lohit-deva package.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Bug#865638: ITP: fonts-lohit-deva-marathi -- Lohit TrueType font for Marathi

[Kartik Mistry]

Package: wnpp
Severity: wishlist
Owner: Kartik Mistry 

* Package name: fonts-lohit-deva-marathi
  Version : 2.94.2
  Upstream Author : Pravin Satpure and others
* URL : https://pagure.io/lohit/
* License : OFL-1.1
  Programming Lang: 
  Description : Lohit TrueType font for Marathi

This package provides Lohit TrueType font for Marathi language. It is upstream
split from fonts-lohit-deva package.

-- 
Kartik Mistry | IRC: kart_
{0x1f1f, kartikm}.wordpress.com


signature.asc
Description: PGP signature

Re: Bug#863801: grub-coreboot: fails to upgrade from jessie to stretch if init-select was installed

[Colin Watson]

On Wed, May 31, 2017 at 01:42:34PM +0200, Andreas Beckmann wrote:
> during a test with piuparts I noticed your package fails to upgrade from
> 'jessie'.
> It installed fine in 'jessie', then the upgrade to 'stretch' fails.
> 
> >From the attached log (scroll to the bottom...):
> 
>   Setting up grub-coreboot (2.02~beta3-5) ...
>   Installing new version of config file /etc/kernel/postinst.d/zz-update-grub 
> ...
>   Installing new version of config file /etc/kernel/postrm.d/zz-update-grub 
> ...
>   /var/lib/dpkg/info/grub-coreboot.config: 1: 
> /etc/default/grub.d/init-select.cfg: /usr/lib/init-select/get-init: not found
>   dpkg: error processing package grub-coreboot (--configure):
>subprocess installed post-installation script returned error exit status 
> 127
> 
> 
> This is most likely a bug in init-select, but since that package
> does not exist in stretch any more (and it will be removed during the
> upgrade from jessie to stretch due to dependencies/conflicts),
> grub-coreboot will have to work around the bug.

This is a tricky bug, so CCing debian-devel for comments.  (Note that
this applies to all grub- binary packages, not just
grub-coreboot.)

The basic problem in init-select is of course the good old favourite of
a conffile not behaving correctly when the package has been removed but
not purged.  This is probably worth fixing in unstable as follows, since
init-select is still there:

--- a/init-select.cfg
+++ b/init-select.cfg
@@ -1,1 +1,1 @@
-GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT 
$(/usr/lib/init-select/get-init)"
+GRUB_CMDLINE_LINUX_DEFAULT="$GRUB_CMDLINE_LINUX_DEFAULT $([ ! -x 
/usr/lib/init-select/get-init ] || /usr/lib/init-select/get-init)"

I propose to NMU init-select with this change after a bit of testing and
the usual delay, since it would generally make life easier if there were
a non-broken version around somewhere.  We might also want to think
about putting that into jessie-proposed-updates.

However, I take Andreas's point that we need to work around this
somehow, probably in a stretch point release now, and that's where I
need feedback.  One possible approach would be to change grub-mkconfig
to do something like this:

  for x in ${sysconfdir}/default/grub.d/*.cfg ; do
if [ "$(basename "$x")" = init-select.cfg ] && [ ! -x 
/usr/lib/init-select/get-init ]; then
  # work around #863801
  continue
fi
if [ -e "${x}" ]; then
  . "${x}"
fi
  done

But that lumbers me with having to maintain a workaround patch forever,
since there's no guarantee that init-select would ever be purged from
affected systems.  I appreciate that it's only a few lines, but these
things pile up over time.  I also don't think that ignoring errors from
/etc/default/grub.d/*.cfg scripts is a good idea: they might actually be
important to booting the system, even though they aren't in this case.

I'd rather do something like checking in the postinst whether these
conditions hold:

 * init-select is removed but not purged
 * /etc/default/grub.d/init-select.cfg contents match the buggy contents
   shown above

... and if so, replace /etc/default/grub.d/init-select.cfg with the
corrected version, coordinated with the NMU above.  This ought to mean
that if a fixed version of init-select is installed in the future, then
there'll be no conffile prompt because the new version is already in
place.  It would open the possibility of a potential conffile prompt in
future if the conffile in question is changed further, but it doesn't
seem to me that init-select has a sufficiently long likely future
lifespan for this to be very probable.  Replacing the file with a
corrected version is better than removing it, moving it aside, or
commenting out the offending line, since none of those would have the
desired behaviour in the event that a fixed version of init-select is
installed.

The benefit of this approach, even though it's a bit more complicated,
is that I could eventually drop it once users can be expected to have
upgraded through a grub-* package containing this workaround.  That
means that I don't have to carry a permanent patch just because some
other package made use of my package's extension facilities and got it
wrong.

I fully appreciate that this is skating along the edge of policy's
requirements regarding conffiles, and arguably violates at least 10.7.4
"The maintainer scripts must not alter a conffile of any package,
including the one the scripts belong to".  However, I think that this is
a reasonable case of self-defence, and could be tolerable with
sufficient commentary and care.  I doubt I would be contemplating it if
init-select hadn't been removed from stretch.

Thoughts?  Can anyone think of a better solution than either of the two
I've outlined here?

Thanks,

-- 
Colin Watson   [cjwat...@debian.org]

Bug#865627: ITP: gmavenplus -- Maven plugin to build Groovy source files

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: gmavenplus
  Version : 1.5
  Upstream Author : Keegan Witt
* URL : http://groovy.github.io/GMavenPlus/
* License : Apache-2.0
  Programming Lang: Java, Groovy
  Description : Maven plugin to build Groovy source files

GMavenPlus Plugin is a rewrite of GMaven, a Maven plugin that allows
one to integrate Groovy into Maven projects.

This package will be maintained by the Java team.

Re: Bug#782654: ITP: bazel, but it builds against its earlier version.

[PaulLiu]

Hi Damien,

That's great. I didn't know that because I'm using git and just checkout
the version tags.
So the thing left is to clean-up the binary jar files inside that zip and
replaced by the Debian and modify the classpath.

I'll start working on this. :)

Thanks,
Paul



On Fri, Jun 23, 2017 at 4:26 PM, Damien Martin-Guillerez <
dmart...@google.com> wrote:

> Hi Ying-Chun,
>
> AFAICT this is incorrect, we maintain distribution artifact that can be
> built without bazel. See https://github.com/bazelbuild/bazel/releases/
> download/0.5.1/bazel-0.5.1-dist.zip for 0.5.1 distribution artifact. This
> is a source zip that does not need bazel to be built.
>
> On Fri, Jun 23, 2017 at 4:21 PM Ying-Chun Liu (PaulLiu) <
> paul...@debian.org> wrote:
>
>> Dear Debian devel,
>>
>> I'm looking into how to package bazel these days. But found it is a bit
>> hard and I need some suggestions.
>>
>> Bazel is a build system. Means it is something like cmake, autotools, ant.
>>
>> First, bazel definitely needs some cleaning. It has some built-in libs
>> which should be package to Debian first. But that's fine because I'll do
>> it.
>>
>> The problem is, bazel 4.0.1 is the last version that can be built
>> directly inside Debian because it can be built from scratch by its own
>> shell script.
>> Later bazel version build depends on ealier version. That means, 4.0.2
>> depends on 4.0.1. And 4.0.3 depends on 4.0.2.
>>
>> So my question is does that mean I need to package (and clean-up
>> built-in libs) for 4.0.1 first. And uploading 4.0.1 to Debian. And then
>> start to package 4.0.2 .. until to the latest? It is similar to gcc
>> compiles itself by earlier version. Just want to know how to solve this
>> and the best practice.
>>
>> Yours,
>> Paul
>>
>>
>>
>>
>> --
>> PaulLiu (劉穎駿)
>> E-mail: Ying-Chun Liu (PaulLiu) 
>>
>>

Re: Bug#782654: ITP: bazel, but it builds against its earlier version.

[Damien Martin-Guillerez]

Hi Ying-Chun,

AFAICT this is incorrect, we maintain distribution artifact that can be
built without bazel. See
https://github.com/bazelbuild/bazel/releases/download/0.5.1/bazel-0.5.1-dist.zip
for
0.5.1 distribution artifact. This is a source zip that does not need bazel
to be built.

On Fri, Jun 23, 2017 at 4:21 PM Ying-Chun Liu (PaulLiu) 
wrote:

> Dear Debian devel,
>
> I'm looking into how to package bazel these days. But found it is a bit
> hard and I need some suggestions.
>
> Bazel is a build system. Means it is something like cmake, autotools, ant.
>
> First, bazel definitely needs some cleaning. It has some built-in libs
> which should be package to Debian first. But that's fine because I'll do
> it.
>
> The problem is, bazel 4.0.1 is the last version that can be built
> directly inside Debian because it can be built from scratch by its own
> shell script.
> Later bazel version build depends on ealier version. That means, 4.0.2
> depends on 4.0.1. And 4.0.3 depends on 4.0.2.
>
> So my question is does that mean I need to package (and clean-up
> built-in libs) for 4.0.1 first. And uploading 4.0.1 to Debian. And then
> start to package 4.0.2 .. until to the latest? It is similar to gcc
> compiles itself by earlier version. Just want to know how to solve this
> and the best practice.
>
> Yours,
> Paul
>
>
>
>
> --
> PaulLiu (劉穎駿)
> E-mail: Ying-Chun Liu (PaulLiu) 
>
>

Bug#865621: ITP: oomox -- Graphical application for generating different

[Alex ARNAUD]

Package: wnpp
Owner: Alex ARNAUD 
Severity: wishlist

* Package name: oomox
  Version : 1.2.6
  Upstream Author : Yauhen Kirylau 
* URL : https://github.com/actionless/oomox
* License : GPL V3
  Programming Lang: Python, Bash (S)CSS
  Description : Graphical application for generating different 
color variations of Numix theme (GTK2, GTK3) and gnome-colors icon theme.


Dear all,

This package allows people to customize the GTK+ theme, and is based on 
the Numix theme. It is a substitute of gnome-color-chooser that is 
deprecated (only for GTK+2).


This program is useful for people that want to create a new GTK+ theme 
and is useful for low-vision people that needs to change the contrast of 
the default theme.


Best regards.
--
Alex ARNAUD
Visual-Impairment Project Manager
Hypra - "Humanizing technology"

ITP: bazel, but it builds against its earlier version.

[Ying-Chun Liu (PaulLiu)]

Dear Debian devel,

I'm looking into how to package bazel these days. But found it is a bit
hard and I need some suggestions.

Bazel is a build system. Means it is something like cmake, autotools, ant.

First, bazel definitely needs some cleaning. It has some built-in libs
which should be package to Debian first. But that's fine because I'll do it.

The problem is, bazel 4.0.1 is the last version that can be built
directly inside Debian because it can be built from scratch by its own
shell script.
Later bazel version build depends on ealier version. That means, 4.0.2
depends on 4.0.1. And 4.0.3 depends on 4.0.2.

So my question is does that mean I need to package (and clean-up
built-in libs) for 4.0.1 first. And uploading 4.0.1 to Debian. And then
start to package 4.0.2 .. until to the latest? It is similar to gcc
compiles itself by earlier version. Just want to know how to solve this
and the best practice.

Yours,
Paul




-- 
PaulLiu (劉穎駿)
E-mail: Ying-Chun Liu (PaulLiu) 



signature.asc
Description: OpenPGP digital signature