Re: for the future of Debian Live

[Paul Wise]

On Sun, Sep 17, 2017 at 6:25 AM, Washington Feitosa wrote:

> please do not stop the production of Debian Live in the next distributions.

I would encourage you to get involved in the Debian Live testing and
development. Join the mailing list and IRC channel and introduce
yourself and state your willingness to help the project and what you
are able to do. There is some info about the team here:

https://wiki.debian.org/DebianLive

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Alioth: the future of mailing lists

[peter green]

On 17/09/17 10:38, Alexander Wirt wrote:


If you currently manage a user-support or discussion list, or run one
of the big teams


Just because a team isn't big or established doesn't mean they don't need a 
place to discuss issues relating to their activities, some of which do not 
relate to any one particular package. Contributers should be able to 
self-organise within the project and for many dds email is their primary means 
of communication. Sure you can just cc everyone involved but then there is no 
archive and no way for new contributers to jump in.

I find the current proposal to drop alioth mailing lists without a real 
replacement to be a major step backwards.

Is bash-completion orphaned?

[Hakan Peker]

Last non-NMU upload happened 3 years ago and version in sid is 2.1.

Development seems to be moved over to Github 
(https://github.com/scop/bash-completion/). Latest release there is 2.7 
from last July.


Why does Alioth site for bash-completion still exists and why doesn't it 
mention the Github repo? Why did Debian packaging activity stop?

Re: Summary of the 2038 BoF at DC17

[peter green]

Firstly: developers trying to be *too* clever are likely to only make
things worse - don't do it! Whatever you do in your code, don't bodge
around the 32-bit time_t problem. *Don't* store time values in weird
formats, and don't assume things about it to "avoid" porting
problems. These are all going to cause pain in the future as we try to
fix problems.

For the time being in your code, *use* time_t and expect an ABI break
down the road. This is the best plan *for now*.


I find this argument unconvincing.

If a library is new or is going to have an ABI break anyway then by moving to 
64-bit time in it's interfaces now it can avoid another ABI break down the road.

Similarly if someone is introducing a new version of a file format anyway 
moving to 64-bit time at the same time as making other changes avoids breaking 
things twice.

Bug#876059: ITP: libvd -- Volume Development library

[D Haley]

Package: wnpp
Severity: wishlist
Owner: D Haley 

* Package name: libvd
  Version : 1.1.0+svn7
  Upstream Author : Herve Lombaert
* URL : http://cim.mcgill.ca/~lombaert/libvd-doc/
* License : GPL
  Programming Lang: C++
  Description : Volume Development library

 A small opengl C++ library for 3D and 4D volume rendering. This is
 implemented using 3D textures and fragment shaders. The library is
 relatively simple compared to major frameworks, and is aimed at both
 learners, and those who wish to integrate this functionality into their
 own projects.

 This will be an optional dependence for the upcoming 3Depict 0.0.21 release. 
This is being maintained as a member of the debian-science team

Re: Re: source-only uploads

[peter green]

Andrey Rahmatullin writes ("Re: source-only uploads"):
> On Fri, Sep 01, 2017 at 12:47:41PM +0200, Emmanuel Bourg wrote:
> > Just yesterday I completely broke a key package used to build
> > many Java packages, and I couldn't even rebuild it to fix the issue.
>
> Why? Does it B-D on itself?

And, if it does, can it not be built using stretch ?

Ian.

I don't know about Java but I had an issue with freepascal not so long ago 
(back when Jessie was stable and stretch was testing).

A change in glibc broke freepascal on powerpc stretch/sid to the point it 
wouldn't install. Freepascal needs itself to build. Sids freepascal would not 
build in jessie due to using newer debhelper features.

To fix this I had to take sid's freepascal, apply the upstream patch for the 
glibc issue, hack it up so it would build in a jessie environment, build it in 
a jessie environment on the porterbox, install the binaries from that build 
into a sid environmentin qemu (because self-built packages can't be installed 
on porterboxes).

This kind of stuff does happen and we need to be able to deal with it.

Having said that I believe the default should be to throw away maintainer-built 
binaries, they should only be accepted if the developer explicitly asks for it.

Re: Summary of the Arm ports BoF at DC17

[Ben Hutchings]

On Sun, 2017-09-17 at 21:30 +0100, Colin Watson wrote:
> On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote:
> > On 2017-09-15, Ben Hutchings wrote:
> > > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > > [...]
> > > > There is optional kernel support to trap the exceptions here
> > > > and emulate the instructions, but it's really not recommended for
> > > > serious use (e.g. on a build machine!).
> > > 
> > > [...]
> > > 
> > > Why is it not recommended?  Terrible performance, or known bugs?
> > 
> > On arm64 kernels building armhf packages for the reproducible builds
> > builders,
> 
> Steve was mostly talking about armel, I thought?
[...]
> I can't really speak for how it would be on armel, but I rather suspect
> that decent ARMv8 hardware would be sufficiently much faster than
> ARMv7-or-earlier kit to more than cancel out performance losses from
> instruction emulation.

For armel, we can't assume there *are* any memory barrier instructions.
 Instead, atomic operations libraries or code generators should use the
kuser helper memory_barrier(), which will do the right thing on an SMP
system and nothing on a UP system.  (kuser helpers are user-mode
functions exposed by the kernel.)

So far as I can see, there are three sets of deprecated and emulated
instructions and I think they should be replaced as follows:

 min. arch   armelarmhf
 -   --
swp/swpb ARMv4?  kuser cmpxchg()  ldrex+strex
cp15 memory barrier  ARMv6   N/A  dmb/dsb/isb
setend   ARMv6   N/A  rev/rev16

(I think swp/swpb were originally specified to bypass the data cache,
which meant they was never useful in user mode armel code.)

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



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

Re: Summary of the Arm ports BoF at DC17

[Steve McIntyre]

On Fri, Sep 15, 2017 at 07:11:38PM +0100, Ben Hutchings wrote:
>On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
>[...]
>> There is optional kernel support to trap the exceptions here
>> and emulate the instructions, but it's really not recommended for
>> serious use (e.g. on a build machine!).
>[...]
>
>Why is it not recommended?  Terrible performance, or known bugs?

I've heard estimates for performance slowdown of a factor of 20 or
more, maybe worse. It's very dependent on the hardware and the code in
question obviously. Sorry, I don't have any references, I'm
afraid. :-/ Of course, the massive log overheard that Vagrant reports
won't help much either!

I'm not aware of any bugs OTTOMH.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

Re: Summary of the Arm ports BoF at DC17

[Ben Hutchings]

On Sun, 2017-09-17 at 12:59 -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> > > There is optional kernel support to trap the exceptions here
> > > and emulate the instructions, but it's really not recommended for
> > > serious use (e.g. on a build machine!).
> > 
> > [...]
> > 
> > Why is it not recommended?  Terrible performance, or known bugs?
> 
> On arm64 kernels building armhf packages for the reproducible builds
> builders, I'm seeing hundreds or even thousands of kernel log warnings
> per second when building anything that makes use of
> CP15_BARRIER_EMULATION (e.g. anything using ghc):
> 
>   [85740.553537] cp15barrier_handler: 115316 callbacks suppressed
>   [85740.559358] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction 
> at 0xf5beaa7c
>   [85740.567344] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction 
> at 0xf5beaa9c
>
> That *might* be sufficient to actually impact performance; it certainly
> makes it hard to read other kernel log messages on those machines...

The log rate-limiting is done in the kernel, so the log daemon doesn't
have to process all those messages.  However, the rate-limiting state
is protected with a mutex (actually a spin-lock) so even when the log
message is suppressed it involves an additional two memory barriers.

And I agree that this kind of rate-limiting isn't really sufficient. 
Warning once per process might be more reasonable, but there's
currently no mechanism for that in the kernel.

Ben.

> There was a bug reported on ghc related to this:
> 
>   https://bugs.debian.org/864847
> 
> 
> live well,
>   vagrant
-- 
Ben Hutchings
friends: People who know you well, but like you anyway.



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

Re: Sign up to mentor for Outreachy Round 15

[Molly de Blanc]

Our completely arbitrary internal deadline for signing up to mentor is
upon us! Please finish submitting project ideas and mentorship proposals.

https://wiki.debian.org/Outreachy/Round15/Projects

Interested in participating, but not sure what to do? Feel free to mail
outre...@debian.org or message tmarble or me (mollydb) on IRC to talk
about your ideas.

If you want to help, but aren't sure you can put in the time you want
to, consider asking someone if they need a co-mentor for their project.

Thanks everyone!

Cheers,
mdb

Re: Summary of the Arm ports BoF at DC17

[Colin Watson]

On Sun, Sep 17, 2017 at 12:59:04PM -0700, Vagrant Cascadian wrote:
> On 2017-09-15, Ben Hutchings wrote:
> > On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> > [...]
> >> There is optional kernel support to trap the exceptions here
> >> and emulate the instructions, but it's really not recommended for
> >> serious use (e.g. on a build machine!).
> > [...]
> >
> > Why is it not recommended?  Terrible performance, or known bugs?
> 
> On arm64 kernels building armhf packages for the reproducible builds
> builders,

Steve was mostly talking about armel, I thought?

> I'm seeing hundreds or even thousands of kernel log warnings
> per second when building anything that makes use of
> CP15_BARRIER_EMULATION (e.g. anything using ghc):
> 
>   [85740.553537] cp15barrier_handler: 115316 callbacks suppressed
>   [85740.559358] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction 
> at 0xf5beaa7c
>   [85740.567344] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction 
> at 0xf5beaa9c
> 
> 
> That *might* be sufficient to actually impact performance; it certainly
> makes it hard to read other kernel log messages on those machines...

We've been building armhf packages in arm64 VMs for some time in Ubuntu
and it generally seems to work fine; I haven't looked *very* closely but
I haven't noticed any particularly significant performance difference
between armhf and arm64 builds in that environment, including builds
that use GHC.  (I would have to go to some effort to look at kernel
logs, so I haven't.)

We're using HP ProLiant m400 cartridges running as OpenStack compute
nodes, and I gather that hardware supports a few more ARMv7 instructions
than some ARMv8 hardware does.  We also run with a small kernel tweak
[1] to set "uname -m" output to "armv7l" when running under linux32(1),
which makes some dodgy configure scripts behave themselves a bit better.
But apart from that, it's been a pretty good experience on armhf and
definitely much faster than what we had before.

[1] 
https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/kernel/sys.c?id=fff84367fa2a19f20c2b9094b47bc3db51fed183

I can't really speak for how it would be on armel, but I rather suspect
that decent ARMv8 hardware would be sufficiently much faster than
ARMv7-or-earlier kit to more than cancel out performance losses from
instruction emulation.

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

Re: Summary of the Arm ports BoF at DC17

[Vagrant Cascadian]

On 2017-09-15, Ben Hutchings wrote:
> On Thu, 2017-09-14 at 03:40 +0100, Steve McIntyre wrote:
> [...]
>> There is optional kernel support to trap the exceptions here
>> and emulate the instructions, but it's really not recommended for
>> serious use (e.g. on a build machine!).
> [...]
>
> Why is it not recommended?  Terrible performance, or known bugs?

On arm64 kernels building armhf packages for the reproducible builds
builders, I'm seeing hundreds or even thousands of kernel log warnings
per second when building anything that makes use of
CP15_BARRIER_EMULATION (e.g. anything using ghc):

  [85740.553537] cp15barrier_handler: 115316 callbacks suppressed
  [85740.559358] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction at 
0xf5beaa7c
  [85740.567344] "ghc-pkg" (29572) uses deprecated CP15 Barrier instruction at 
0xf5beaa9c


That *might* be sufficient to actually impact performance; it certainly
makes it hard to read other kernel log messages on those machines...


There was a bug reported on ghc related to this:

  https://bugs.debian.org/864847


live well,
  vagrant


signature.asc
Description: PGP signature

Re: Alioth: the future of mailing lists

[Jeremy Bicha]

On Sun, Sep 17, 2017 at 5:38 AM, Alexander Wirt  wrote:
>   - Distribution lists for use in the Maintainer: field.  We suggest
> that, with maybe some extra code, this use-case could be well served
> by the tracker.debian.org service for almost all purposes.  For
> larger teams, such as the Debian Perl Group, a list on lists.debian.org
> might be another option.

I think tracker.debian.org's email subscription feature is great. For
instance, it was really easy to create a team based on the email
address used for the pkg-gnome maintainers team.

https://tracker.debian.org/teams/debian-gnome-team/

It automatically adds new packages that have that email address in
Maintainers or Uploaders. Anyone can join the team and pick which
kinds of emails they want to get for the whole set of packages at
once.

So I'd like to be able to use the Debian tracker as the maintainer
email address for some packages I maintain. The downside is that my
understanding is taht tracker.debian.org doesn't provide a normal
email service. Personally, that's a positive for me since I get less
spam than if I subscribed to the mailing list. But it would be
unexpected that you can't just email the Maintainer directly using
what looks like an email address in the package metadata.

On the other hand, it sounds like many Maintainer email addresses (as
seen in Debian 9 "stable") will stop working next year any way. Which
is technically an RC-bug but I assume we won't be doing thousands of
stretch updates just to fix that.

Thanks,
Jeremy Bicha

Re: Alioth: the future of mailing lists

[Andreas Metzler]

On 2017-09-17 Alexander Wirt  wrote:
[...]
>   - Distribution lists for use in the Maintainer: field.  We suggest
> that, with maybe some extra code, this use-case could be well served
> by the tracker.debian.org service for almost all purposes.  For
> larger teams, such as the Debian Perl Group, a list on lists.debian.org
> might be another option.
[...]
> Proposed Timeline:
>  * 2018-02-01: mailing lists on Alioth are disabled; incoming mail is
>no longer accepted.

Hello,

thanks for the heads-up.

The maintainer e-mail address is listed not only on packages.debian.org
but also on "dpkg -s ..." et. al. Users send support e-mail there. Imho
either the mailing lists need to run a lot longer (possibly until
stretch EOL) or (prefered) the old list-address should redirect to the
new one.

>  * May 2018 (with the wheezy EOL): alioth is shut down; mailing list
>archives are unavailable.  (A static export/dump will be provided
>in some convenient location.)

Would it be possible to keep the list-archives online, indexed by
search-engines? These are static pages, aren't they? There is some
interesting information there and removal from the web makes it hard
to find.

cu Andreas

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

Re: Alioth: the future of mailing lists

[Thomas Hochstein]

Alexander Wirt wrote:

> As the Alioth system is not something that we as a project have the will
> and manpower to maintain in its current form, we held a sprint [sprint]
> last month in Hamburg, Germany,  and discussed options and the future of
> the several services currently provided by Alioth.

Thanks for thje update!

> [minutes] 
> https://wiki.debian.org/Sprints/2017/Alioth/MeetingMinutes/Mailinglist

It's

(plural form).

-thh

for the future of Debian Live

[Washington Feitosa]

Good evening! I spent last week seeking for some good Linux distro and 
after I have installed Ubuntu Gnome (bugged), Mint (wifi didn't work) 
and Debian 9.1.0 pure and that didn't work for me either I have issues 
because the firmware for my network card, but fortunately I have succeed 
in found your instructions about Debian Live with non free firmware and 
now I'm a happy new member of Debian comunity with my Debian 9.1.0 
stretch Live work properly, so please do not stop the production of 
Debian Live in the next distributions.


Yours

Washington Feitosa

Bug#876011: ITP: gtk+4.0 -- GTK+ graphical user interface library

[Jeremy Bicha]

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

Package Name: gtk+4.0
Version: 3.91.2
Upstream Authors : Many. See debian/copyright
License : LGPL-2+
Programming Lang: C

Description: GTK+ graphical user interface library
 GTK+ is a multi-platform toolkit for creating graphical user
 interfaces. Offering a complete set of widgets, GTK+ is suitable
 for projects ranging from small one-off tools to complete application
 suites.

Other Info
--
The Debian GNOME team intends to maintain this package.

Since gtk4 is still in beta development and we aren't aware of any
apps that require gtk4 yet, we will be uploading this to experimental.

Packaging is currently in svn at
svn://anonscm.debian.org/pkg-gnome/desktop/unstable/gtk+4.0/
You can browse at
https://anonscm.debian.org/viewvc/pkg-gnome/desktop/experimental/gtk%2B4.0/

Thanks,
Jeremy Bicha

Follow-up: Alioth: the future of mailing lists

[Alex Muntada]

Alexander Wirt:

> - Distribution lists for use in the Maintainer: field.  We suggest
>   that, with maybe some extra code, this use-case could be well served
>   by the tracker.debian.org service for almost all purposes.  For
>   larger teams, such as the Debian Perl Group, a list on lists.debian.org
>   might be another option.

These are a few numbers regarding affected source packages using
an alioth mail address (find script attached):

$ schroot -c sid perl count-alioth-packages.pl
 88 alioth addresses have   0 < packages <=   1
140 alioth addresses have   1 < packages <=  10
 66 alioth addresses have  10 < packages <= 100
 16 alioth addresses have 100 < packages <=1000
  6 alioth addresses have1000 < packages <=   1
  0 alioth addresses have   1 < packages <=  10

Cheers,
Alex

#!/usr/bin/perl

use strict;
use warnings;
use autodie;

# Grab first main sid source available
my $source = (glob '/var/lib/apt/lists/*_debian_dists_{sid,unstable}_main_source_Sources')[0];

# How to partition the counters
my @ranges = (0, 1, 10, 100, 1_000, 10_000, 100_000);

sub partition {
my ($min, $max, @values) = @_;

return scalar grep { $min < $_ && $_ <= $max } @values;
}

my %maintainers;
open my $fd, '<', $source;
while (<$fd>) {
$maintainers{$1}++ if /^Maintainer: .*<(.*\@.*)\.alioth\.debian\.org/;
}

my @counters = values %maintainers;
while (@ranges > 1) {
my $min = shift @ranges;
my $max = $ranges[0];
print sprintf("% 7d", partition($min, $max, @counters)),
  " alioth addresses have ",
  sprintf("% 7d", $min),
  " < packages <= ",
  sprintf("% 7d", $max),
  "\n";
}


signature.asc
Description: PGP signature

Re: s/python3-sphinx-intl/sphinx-intl

[Hideki Yamane]

On Wed, 13 Sep 2017 11:54:15 -0300
Antonio Terceiro  wrote:
> > > if sphinx-intl is primary application (cli tool, etc.), than binary pkg
> > > sphinx-intl is better. If it's library/module, than python3-sphinx-intl
> > > is better.
> > 
> > Based on the description of the project [1], it looks like it is the former.
> > 
> > [1] https://pypi.python.org/pypi/sphinx-intl
> 
> however sphinx itself is python*-sphinx, so maybe having those be
> consistent with each other is a good idea.

 Hmm. We don't have python-sphinx-intl for python2.x, so maybe just
 sphinx-intl is okay for users.


-- 
Regards,

 Hideki Yamane henrich @ debian.or.jp/org
 http://wiki.debian.org/HidekiYamane