Bug#980039: More information, again....

[Christian Perrier]

OK. Looks like the former issue was due to a weird behaviour of the
javascript-common package. The package wasn't properly configured and
extracted (missing /etc/apache2/conf-available/javascript-common.conf). I
probably should try debugging this and report against javascript-common if
it happens to be a real bug in the package.


Meanwhile, I hacked the problem by manually extracting the offending file
and moving it in the right place (BD thing to do, right? ;-) )

Then it seems that the setup phase goes a little further :

janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running first setup.
janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running setup for modules,
essential - True, selected modules - None
janv. 15 14:19:41 kheops /usr/bin/plinth[4789]: Running module setup -
storage
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Running step for module -
storage, step - post
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: # storage setup
janv. 15 14:19:42 kheops sudo[5863]:   plinth : TTY=unknown ; PWD=/ ;
USER=root ; COMMAND=/usr/share/plinth/actions/storage setup
janv. 15 14:19:42 kheops sudo[5863]: pam_unix(sudo:session): session opened
for user root by (uid=0)
janv. 15 14:19:42 kheops sudo[5863]: pam_unix(sudo:session): session closed
for user root
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Running step for module -
storage, step - post
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: # storage usage-info
janv. 15 14:19:42 kheops sudo[5866]:   plinth : TTY=unknown ; PWD=/ ;
USER=root ; COMMAND=/usr/share/plinth/actions/storage usage-info
janv. 15 14:19:42 kheops sudo[5866]: pam_unix(sudo:session): session opened
for user root by (uid=0)
janv. 15 14:19:42 kheops sudo[5866]: pam_unix(sudo:session): session closed
for user root
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Error running setup -
invalid literal for int() with base 10: 'cifs'
Traceback (most recent call
last):
  File
"/usr/lib/python3/dist-packages/plinth/setup.py", line 78, in run
self.module.setup(self,
old_version=current_version)
  File
"/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line
273, in setup
disks = get_disks()
  File
"/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line
77, in get_disks
disks_from_df =
_get_disks_from_df()
  File
"/usr/lib/python3/dist-packages/plinth/modules/storage/__init__.py", line
130, in _get_disks_from_df
disk['size'] =
int(disk['size'])
ValueError: invalid literal
for int() with base 10: 'cifs'
janv. 15 14:19:42 kheops /usr/bin/plinth[4789]: Error running setup -
invalid literal for int() with base 10: 'cifs'

Given that the problem now seems to lie with analyzing the output of "df",
here is the output of "df" on my system :

root@kheops:/etc/apache2# df -k
Sys. de fichiers blocs de 1K   Utilisé Disponible Uti% Monté sur
/dev/root   61110996  17934484   40658316  31% /
devtmpfs 1827800 01827800   0% /dev
tmpfs1959896 01959896   0% /dev/shm
tmpfs19598961164841843412   6% /run
tmpfs   5120 4   5116   1% /run/lock
tmpfs1959896 01959896   0% /sys/fs/cgroup
/dev/loop1 43136 43136  0 100% /snap/certbot/795
/dev/loop0 45056 45056  0 100% /snap/certbot/891
/dev/loop2 52608 52608  0 100% /snap/core20/876
/dev/loop3 52608 52608  0 100% /snap/core20/906
/dev/loop4 85248 85248  0 100% /snap/core/10579
/dev/loop5 85248 85248  0 100% /snap/core/10584
/dev/mmcblk0p1258095 46274 211822  18% /boot
/dev/sda1  672734512 608501768   30036728  96% /var/archives
/dev/sda3 1057232008  72666704  930837984   8% /var/backups/srv
/dev/sda2  288238944 192235056   81339084  71% /home
/dev/sdb1  960379920  72671624  838853872   8% /srv
//freebox/Disque dur   239216096 134956128   92085384  60% /music
tmpfs 391976 0 391976   0% /run/user/1000

The "cifs" keyword rang a bell in my head..as you can see, I DO have a
CIFS file system mount ( //freebox/Disque dur on /music) and, even
worse..the CIFS UNC name has a space in it:-)

So, just to check it hat helps, I unmounted the share and.freedombox
setup could continue.

And complete:-)

Bug#980039: freedombox: Setup Wizard stuck on the welcome screen

[Christian Perrier]

>Can you please check the logs of plinth service?
>E.g. run "journalctl -u plinth" as root, and look for any repeating error 
>messages.

>> -- System Information:
>> Distributor ID:  Raspbian
>> Description: Raspbian GNU/Linux 10 (buster)

>Could you please share how you installed freedombox package?

Hello James,

(may I suggest CC'ing -submitter@b.d.o to answers if input is
needed by the person who submitted the bug report? I actually noticed
your request while looking at the BTS but others might miss it)

Anyway, I installed freedombox by installing the backports packages on
my home server which is running buster (no other backports as far as I
remember).

journalctl -u plinth gives a hint :

janv. 13 19:04:26 kheops /usr/bin/plinth[928]: Running first setup.
janv. 13 19:04:26 kheops /usr/bin/plinth[928]: Running setup for
modules, essential - True, selected modules - None
janv. 13 19:04:26 kheops /usr/bin/plinth[928]: Running module setup - apache
janv. 13 19:04:27 kheops /usr/bin/plinth[928]: Error running setup - php-fpm
   Traceback (most recent
call last):
 File
"/usr/lib/python3/dist-packages/plinth/setup.py", line 78, in run

self.module.setup(self, old_version=current_version)
 File
"/usr/lib/python3/dist-packages/plinth/modules/apache/__init__.py",
line 65, in setup

helper.install(managed_packages)
 File
"/usr/lib/python3/dist-packages/plinth/setup.py", line 102, in install
   raise
PackageNotInstalledError(package_name)

plinth.errors.PackageNotInstalledError: php-fpm
janv. 13 19:04:27 kheops /usr/bin/plinth[928]: Error running setup - php-fpm

So I actually assumed that a dependency might be missing somewhere.
So, I just "apt-installed" php-fpm and then :

janv. 15 11:12:02 kheops /usr/bin/plinth[928]: Running first setup.
janv. 15 11:12:02 kheops /usr/bin/plinth[928]: Running setup for
modules, essential - True, selected modules - None
janv. 15 11:12:02 kheops /usr/bin/plinth[928]: Running module setup - apache
janv. 15 11:12:03 kheops /usr/bin/plinth[928]: # apache setup --old-version 0
janv. 15 11:12:03 kheops sudo[28790]:   plinth : TTY=unknown ; PWD=/ ;
USER=root ; COMMAND=/usr/share/plinth/actions/apache setup
--old-version 0
janv. 15 11:12:03 kheops sudo[28790]: pam_unix(sudo:session): session
opened for user root by (uid=0)
janv. 15 11:12:08 kheops /usr/bin/plinth[928]: Error executing command
- ['sudo', '-n', '/usr/share/plinth/actions/apache', 'setup',
'--old-version', '0'], , ERROR: Conf javascript-common does not exist!
   Traceback (most recent
call last):
 File
"/usr/share/plinth/actions/apache", line 202, in 
   main()
 File
"/usr/share/plinth/actions/apache", line 198, in main
   subcommand_method(arguments)
 File
"/usr/share/plinth/actions/apache", line 160, in subcommand_setup

webserver.enable('javascript-common', kind='config')
 File
"/usr/lib/python3/dist-packages/plinth/action_utils.py", line 227, in
enable
   action_required =
webserver_enable(name, kind, apply_changes=False)
 File
"/usr/lib/python3/dist-packages/plinth/action_utils.py", line 157, in
webserver_enable

subprocess.check_output([command_map[kind], name])
 File
"/usr/lib/python3.7/subprocess.py", line 395, in check_output
   **kwargs).stdout
 File
"/usr/lib/python3.7/subprocess.py", line 487, in run
   output=stdout, stderr=stderr)

subprocess.CalledProcessError: Command '['a2enconf',
'javascript-common']' returned non-zero exit status 1.
janv. 15 11:12:08 kheops /usr/bin/plinth[928]: Error running setup -
('apache', '', 'ERROR: Conf javascript-common does not
exist!\nTraceback (most recent call last):\n  File
"/usr/share/plinth/actions/apache", line 202, in \n
main()\n  File "/usr/share/plinth/actions/apache"
   Traceback (most recent
call last):
 File
"/usr/lib/python3/dist-packages/plinth/setup.py", line 78, in run

self.module.setup(self, old_version=current_version)
 File
"/usr/lib/python3/dist-packages/plinth/modules/apache/__init__.py",
line 68, in setup
   ['setup',

Bug#980039: freedombox: Setup Wizard stuck on the welcome screen

[Christian Perrier]

Package: freedombox
Version: 20.21~bpo10+1
Severity: normal

Hello fellow maintainers of freedombox,

My first Debian bug report for ages, it seems (one more to reach bug
#100!!!). Now, I'm a simple (and happy) user of Debian systems at
home, and as everything works so well, I don't make bug reports
anymorebut it seems that things didn't change that much.

Anyway.I'm trying to setup a FreedomBox at home and I'm stupidely
stuck with a simple problem. Probably easy to debug if only I could
figure out where to look. But I'm afraid that all these very modern
things are a bit new for me.

Anyway, the problem is simple : when launching the initial setup wizard,
the screen doesn't for further than the welcome screen. The page reload
every 5 seconds or so, I left it doint this for hours, filling up my
Apache logsbut nothing more happens.

The setup wizard is launched from another machine on my local network by
accessing the https URL of my freedombox server (not https://freedombox
as foudn in many online docs, as I have my own DNS server already
running).

This is probably not a bug per se but probably a usability issue so the
bug maybe lies in the documentation at least to know where to look in
order to solve the problem...:-)

Hope this helps and you guys will be able to give the needed clue to
figure out the problem.

For the record, just to be sure that my problem is not an l10n problem,
I switched my browser languege to en_US instead of fr_FR. But no lucK.

Thanks for your great work on all this. I still remind first hearing
about FreedomBox at DebConf 10 in NYC. Long Time ago.


-- System Information:
Distributor ID: Raspbian
Description:Raspbian GNU/Linux 10 (buster)
Release:10
Codename:   buster
Architecture: armv7l

Kernel: Linux 5.4.83-v7l+ (SMP w/4 CPU cores)
Kernel taint flags: TAINT_CRAP
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages freedombox depends on:
ii  adduser 3.118
ii  apache2 2.4.38-3+deb10u4
ii  augeas-tools1.11.0-3
ii  avahi-daemon0.7-4+b1
ii  avahi-utils 0.7-4+b1
ii  batctl  2020.4-1~bpo10+1
ii  borgbackup  1.1.15-1~bpo10+1
ii  certbot 0.31.0-1
ii  cockpit 235-1~bpo10+1
ii  curl7.64.0-4+deb10u1
ii  debconf [debconf-2.0]   1.5.71
ii  debsecan0.4.19
ii  dnsutils1:9.11.5.P4+dfsg-5.1+deb10u2
ii  e2fsprogs   1.44.5-1+deb10u3
ii  ez-ipupdate 3.0.11b8-13.4.1
ii  fail2ban0.10.2-2.1
ii  firewalld   0.8.2-1~bpo10+1
ii  flite   2.1-release-3
ii  fonts-fork-awesome  1.1.5+ds1-2
ii  fonts-lato  2.0-2
ii  gdisk   1.0.3-1.1
ii  gettext 0.19.8.1-9
ii  gir1.2-glib-2.0 1.58.3-2
ii  gir1.2-nm-1.0   1.14.6-2+deb10u1
ii  gir1.2-udisks-2.0   2.8.1-4
ii  javascript-common   11
ii  ldap-utils  2.4.56+dfsg-1~bpo10+1
ii  ldapscripts 2.0.8-1
ii  libapache2-mod-auth-pubtkt  0.13-1
ii  libglib2.0-bin  2.58.3-2+deb10u2
ii  libjs-bootstrap44.3.1+dfsg2-1
ii  libjs-jquery3.3.1~dfsg-3
ii  libjs-modernizr 2.6.2+ds1-3
ii  libnss-ldapd0.9.10-2
ii  libpam-ldapd0.9.10-2
ii  lsof4.91+dfsg-1
ii  needrestart 3.4-5
ii  netcat-openbsd  1.195-2
ii  network-manager 1.14.6-2+deb10u1
ii  nftables0.9.6-1~bpo10+1
ii  nscd2.28-10+rpi1
ii  nslcd   0.9.10-2
ii  openssh-server  1:7.9p1-10+deb10u2
ii  openssl 1.1.1d-0+deb10u4+rpt1
ii  parted  3.2-25
ii  php7.3-fpm [php-fpm]7.3.19-1~deb10u1
ii  ppp 2.4.7-2+4.1+deb10u1
ii  pppoe   3.12-1.2
ii  python3 3.7.3-1
ii  python3-apt 1.8.4.3
ii  python3-argon2  18.3.0-1
ii  python3-augeas  0.5.0-1
ii  python3-bootstrapform   3.4-2
ii  python3-cherrypy3   8.9.1-2
ii  python3-configobj   5.0.6-3
ii  python3-dbus1.2.8-3
ii  python3-django  2:2.2.17-2~bpo10+1
ii  python3-django-axes 4.4.0-1
ii  python3-django-captcha  0.5.6-1
ii  python3-django-stronghold   0.3.0+debian-1
ii  python3-gi  3.30.4-1
ii  python3-markupsafe  1.1.0-1
ii  python3-openssl 19.0.0-1
ii  python3-pampy   1.8.4-1
ii  python3-paramiko2.6.0-1~bpo10+1
ii  python3-psutil  5.7.2-1~bpo10+2
ii  python3-requests   

Bug#913493: RFS: geneweb/6.08+git20181019+dfsg-1

[Christian Perrier]

Le 27/12/2018 à 21:00, Guillaume Brochu a écrit :


https://github.com/geneweb/geneweb/issues/642
    Fixes ocaml warnings and correct English errors
  * New maintainer (Guillaume Brochu), Christian Perrier now in uploaders



You can even remove me from Uploaders. I anyway need to ask this for the 
gazillion package where I'm listed, as part of a future resignation from 
Debian



Merci encore pour ton travail !

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):

> The use of “you” seems to be one of the common errors I mentioned above.
> We tend to avoid pointing fingers at users.
> 
> Hrm. Grepping across our packages' templates, I see a lot of “you”s so I
> might just be misremembering. Or maybe we've tried hard not to introduce
> new occurrences while not actively fixing pre-existing entries.


The use of "you" is, I would say, tolerated. What we tried to avoid
(at least when I was a PITA for people wanting to introduce new
templates) was what I called "personnalization" of the computer :
"your machine", for instance. Everything that seems to impply that the
machine being installed belongs to the person who is installing it.

Addressing the user has been accepted : "you should do this", "you
need to do thaat".

In this case, I would try avoiding to imply that the person
installingn the machine will be the person who has to review security
chnges when they happen, so I'd probably use the passive form
"Security updates should be reviewed before they are applied"..os
something like this.

But you're right : we used debian-l10n-english for reviewing
templates. If someone is still alive there, (s)he may help.




signature.asc
Description: PGP signature

Bug#900640: garmin-forerunner-tools: Lots of URLs/addresses are incorrect

[Christian PERRIER]

Quoting Diederik de Haas (didi.deb...@cknow.org):
> Package: garmin-forerunner-tools
> Version: 0.10repacked-10+b1
> Severity: normal
> 
> As the maintainer address is no longer functional (see #899519), I'm
> sending it (also) directly to the listed maintainers.
> Hopefully that's not (too) inappropriate.
> 
> I recently bought a Garmin Forerunner 645 Music and found this package,
> but noticed several issues on its package tracker page,
> https://tracker.debian.org/pkg/garmin-forerunner-tools.
> 
> - As listed above and in #899519, the maintainer address no longer
>   works.
> - The upstream web homepage is listed as
>   http://garmintools.googlecode.com/ but that gives a 404. There is one
>   that works (https://code.google.com/archive/p/garmintools/) but that's
>   purely an archived version, so not very useful either.
>   Through some detours I found that https://github.com/jorgesca/garmintools
>   is now listed as the new upstream. But other then an import of that same 
>   code, there isn't much/any difference. It does contain the original 
>   issues though, which does seem useful.
>   Searching on GitHub (https://github.com/search?q=garmintools) I found
>   several others and looking through various of them, it looks like
>   https://github.com/phako/garmintools is the one with various new
>   commits added to them, most recently on 2018-02-23.
>   OTOH it also contains a commit removing HURD ifdefs.
>   I could of course create yet another repo and cherrypick various
>   commits from various repos, but that'll create https://xkcd.com/927/.
> - The VCS Browse URL points to
>   https://git.debian.org/?p=pkg-running/garmin-forerunner-tools.git;a=summary
>   but when opening that page you get a message that alioth is
>   discontinued. I tried searching on https://salsa.debian.org/ but
>   couldn't find garmin-forerunner-tools or pkg-running.
> - I did find https://alioth-archive.debian.org/git/pkg-running/ which
>   contains an archived copy of pkg-running and its sub-repos, including
>   the repo for this package.
> 
> Looking through 
> https://qa.debian.org/developer.php?email=pkg-running-devel%40lists.alioth.debian.org
> it looks like the other pkg-running packages are in a similar, not so 
> great, state but I hope there's still interest in improving things :).


Good question

As for me, I'm in the process of stepping out from Debian, as my
priorities have progressively switched from Debian work to other
activities over the years.

I tried to prepare this properly, but the shutdown of Alioth didn't
help: I never took time to invest my time in Salsa before Alioth's
complete stop.and I will probably never.

I can't speak for other pkg-running team members, but Ralf and Noèl
have low activity toowhich, of course, brings concerns about
packages we maintained over the years.

In anycase, NMU with patches even to fix "trivial" stuff are highly
welcomed.

Thansk for your interest in these packages



signature.asc
Description: PGP signature

Bug#890083: [PATCH] dl10n-check script: dpkg: warning: --compare-versions used with obsolete relation operator '>'

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Please ignore the former patch.
> 
> The correct patch is this one:

As we say in French : MDR:-)

There hasn't been as much activity on i18n infrastructure than today
during last months (if not years) and both of us report the same bug
with the same patch...:-)

I "git pulled" again





signature.asc
Description: PGP signature

Bug#895689: dl10n-check uses an obsolete version comparison ooperator with "dpkg --compare-versions"

[Christian Perrier]

Package: dl10n
Severity: normal
Tags: patch

dl10n-check spits out many warning messages when used (for instance on
i18n.debian.org) :

dpkg: warning: --compare-versions used with obsolete relation operator
'>'

This is indeed quite easy to fix with the attached patch.


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-6-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dl10n depends on:
ii  gettext   0.19.8.1-2
ii  liblocale-gettext-perl1.07-3+b1
ii  libmailtools-perl 2.18-1
ii  libtimedate-perl  2.3000-2
ii  libwww-perl   6.15-1
ii  perl  5.24.1-3+deb9u2
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u2

dl10n recommends no packages.

dl10n suggests no packages.
diff --git a/dl10n-check b/dl10n-check
index 4bad7a1..7b6b0cf 100755
--- a/dl10n-check
+++ b/dl10n-check
@@ -281,7 +281,7 @@ PKG: while ($dsc = shift @pkg_list) {
 $data->maintainer($pkg, $maint);
 my $newer = ($data->version($pkg) ne $ver);
 if ($newer) {
-$newer = system ("dpkg","--compare-versions", 
$data->version($pkg), "\>", $ver);
+$newer = system ("dpkg","--compare-versions", 
$data->version($pkg), "gt", $ver);
 }
 if ((!$force) && $newer==0 && $data->version($pkg) ne ""
 && !( $force_material &&

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hello
> The material data has not been updated, there are more packages
> producing errors.
> I've added them as exceptions to the config file, to workaround the
> issue (as with my previous patch).
> Christian, do you mind to update again the repo in tye, to see if
> tomorrow the material data is produced?
> I wouldn't mind to join the debian-i18n unix group so I can do it
> myself, if that's ok with you too, but I'm not sure about the procedure.
> Thanks!

I just "git pulled" again.

And I launched thte
/srv/i18n.debian.org/etc/cron.d/10gen-material-unstable script
manually, just to see what happens. Indeed, we get a daily cron
message which I (sadly) ignored for ages.that's quite probably the
problem.

debian-i18n crontab on tye has:
MAILTO="brot...@debian.org,bubu...@debian.org,f...@debian.org,nek...@debian.org,taf...@debian.org"

but it seems that all of us are ignoring these mails nowadays.

I don't remember how one can be added to the right group on Debian
machines and be allowed to "sudo" to debian-i18n. I suspect this
should be done with a ticket to the Debian admin team.

At minimum, I can add your mail address to this crontab, Laura, tthat
may help



signature.asc
Description: PGP signature

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hi again
> 
> El 12/04/18 a las 07:12, Christian PERRIER escribió:
> 
> > Doh, I'm now in the salsa mess:
> > debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
> > fatal: unable to access 'https://salsa.debian.org/l10n-team/dl10n.git/': 
> > server certificate verification failed. CAfile: 
> > /etc/ssl/certs/ca-certificates.crt CRLfile: none
> Sorry, my fault, I gave incomplete directions.
> There is also needed to do the following (in tye.debian.org):
> 
> dir=/etc/ssl/ca-debian
> test -d $dir && git config --local --add http.sslCAInfo 
> $dir/ca-certificates.crt
> 
> (This is documented in https://wiki.debian.org/ServicesSSL#git )


Gracias!

It just worked now and the local copy on tye is now synced again with
the git repo on salsa.




signature.asc
Description: PGP signature

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> 
> 
> El 12 de abril de 2018 6:52:28 CEST, Christian PERRIER <bubu...@debian.org> 
> escribió:
> >Quoting Laura Arjona Reina (larj...@debian.org):
> >> Hello all
> >> I applied a patch to the dl10n repo in salsa, with a workaround for
> >this
> >> bug (adding the problematic packages to an exclusion list).
> >> However, the material is not being updated, I think because the repo
> >in
> >> tye still uses alioth as origin.
> >> 
> >> Can somebody in the debian-i18n group update the config in
> >> /srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?
> >> 
> >> (I'm not sure if manual git pull is needed too, or if there is some
> >cron
> >> script that auto-updates the repo at some time. I'm not in the
> >> debian-i18n group so I think I cannot check...
> >
> >
> >Hi Laura,
> >
> >Thanks for your work.
> >
> >I logged in to i18n.d.o, then sudo'ed to debian-i18n, then moved to
> >/srv/i18n.debian.org/dl10n/git
> >
> >"git pull" mentions that the local copy is up-to-date and "git log"
> >says :
> >
> >commit d17144ddc047f48bc4609202bb6e48d04fe92f33
> >Author: David Prévot <da...@tilapin.org>
> >Date:   Wed Jan 7 12:12:43 2015 -0400
> >
> >Workaround recent SSL breakage from DSA
> >
> ><1420638006.22794.18.ca...@debian.org>.
> >
> >
> >So, it looks like I can't have your patch make its way to the
> >server:-(
> >
> 
> Please modify the .git/config file to change the origin to salsa instead of 
> alioth:
> 
> https://salsa.debian.org/l10n-team/dl10n.git
> 
> Then save and git pull.

Doh, I'm now in the salsa mess:

debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git pull
fatal: unable to access 'https://salsa.debian.org/l10n-team/dl10n.git/': server 
certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt 
CRLfile: none

(for the record, I didn't move anything of what I personnally
maintain, to salsa: I decided that It's no longer time for me to learn
how to make things work with new stuff..call that lazyness, it's
prrobably more a lack of motivation)

So, well, help is welcomed again, here, sorry for being a n00b.




signature.asc
Description: PGP signature

Bug#887107: https://i18n.debian.org/material/data/unstable.gz not updated since 2017-11-23

[Christian PERRIER]

Quoting Laura Arjona Reina (larj...@debian.org):
> Hello all
> I applied a patch to the dl10n repo in salsa, with a workaround for this
> bug (adding the problematic packages to an exclusion list).
> However, the material is not being updated, I think because the repo in
> tye still uses alioth as origin.
> 
> Can somebody in the debian-i18n group update the config in
> /srv/i18n.debian.org/dl10n/git/ so it uses the salsa repo?
> 
> (I'm not sure if manual git pull is needed too, or if there is some cron
> script that auto-updates the repo at some time. I'm not in the
> debian-i18n group so I think I cannot check...


Hi Laura,

Thanks for your work.

I logged in to i18n.d.o, then sudo'ed to debian-i18n, then moved to
/srv/i18n.debian.org/dl10n/git

"git pull" mentions that the local copy is up-to-date and "git log"
says :

commit d17144ddc047f48bc4609202bb6e48d04fe92f33
Author: David Prévot 
Date:   Wed Jan 7 12:12:43 2015 -0400

Workaround recent SSL breakage from DSA

<1420638006.22794.18.ca...@debian.org>.


So, it looks like I can't have your patch make its way to the
server:-(

From what I remember, there is no auto update of the local git
repository copy, it has to be pulled manually.

debian-i18n@tye:/srv/i18n.debian.org/dl10n/git$ git remote -v
origin  git://anonscm.debian.org/debian-l10n/dl10n.git (fetch)
origin  git://anonscm.debian.org/debian-l10n/dl10n.git (push)

I think that, indeed, it would be good if someone more active than me
would apply to be included in the debian-i18n group





signature.asc
Description: PGP signature

Bug#895396: fonts-anonymous-pro: Please drop myself from Uploaders

[Christian Perrier]

Source: fonts-anonymous-pro
Severity: minor

I'm no longer active in maintaining fonts in Debian, so I suggest that
my name iis removed from the Uploaders field in debian/control.

Many thanks in advance.


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#895172: fonts-freefont: Please remove me from Uploaders

[Christian Perrier]

Source: fonts-freefont
Severity: minor

As part of my work in a aligning the many packages I have worked on in
the past.and the few which I am still working on, please remove me
from Uploaderes in this package (and, indeed, all other fonts-*
packages where it currently appears..I'll report bugs for each of
them, but that will take time as I'm doing so manually).


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#895105: fontforge-extras: Please remove myself from Uploaders

[Christian Perrier]

Package: fontforge-extras
Severity: minor

I'm not sure that this package is still useful.however, it it
still in unstable, as far as I can see though it hasn't got uploads
for years.

In any case, if it's not removed from unstable, please remove my name
from Uploaders as part of my "prepare to resign some day" work (sorry
for this).


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#895003: fontforge-doc: Please remove myself from Uploaders

[Christian Perrier]

Package: fontforge-doc
Severity: minor

Same rationale than fontforge: I'm no longer active in these packages'
maintenance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#894873: fontforge: Please remove myself from Uploaders

[Christian Perrier]

Package: fontforge
Version: 1:20170731~dfsg-1
Severity: minor

I'm no longer active in font packages maintenance, so I'm in the
process of requesting to be removed from Uploaders in packages where
I'm listed as such.

So, for next uploads, may I suggest that my name is removed from
Uploaders?

Thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages fontforge depends on:
ii  fontforge-common  1:20170731~dfsg-1
ii  libc6 2.27-2
ii  libfontforge2 1:20170731~dfsg-1
ii  libgdraw5 1:20170731~dfsg-1
ii  libltdl7  2.4.6-2
ii  libx11-6  2:1.6.4-3

fontforge recommends no packages.

Versions of packages fontforge suggests:
pn  autotrace 
pn  fontforge-doc 
pn  fontforge-extras  
pn  potrace   
pn  python-fontforge  

-- no debconf information

Bug#894599: dl10n: Please remove me from Uploaders

[Christian Perrier]

Package: dl10n
Severity: minor

I'm much less active in Debian nowadays and I'm currently cleaning out
areas where I'm not active anymore.

It has been years since this package got uploaded (it is used indeed
in the l10n infrastructure only).

I think it's better to remove my name and address from Uploaders
(which indeed mostly orphans the package, I'm afraid).


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages dl10n depends on:
ii  gettext   0.19.8.1-2
ii  liblocale-gettext-perl1.07-3+b1
ii  libmailtools-perl 2.18-1
ii  libtimedate-perl  2.3000-2
ii  libwww-perl   6.15-1
ii  perl  5.24.1-3+deb9u2
ii  perl-modules-5.24 [perl-modules]  5.24.1-3+deb9u2

dl10n recommends no packages.

dl10n suggests no packages.

Bug#894485: console-data: Please remove myself from Uploaders

[Christian Perrier]

Package: console-data
Version: 2:1.12-5
Severity: minor

Just like console-common, I haven't done an upload for a very long
time and Am currently reducingn my activity in Debian.

Therefore, I think I should be removed from the Uploaders field in
console-data.

Thanks in advance.

-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages console-data depends on:
ii  debconf [debconf-2.0]  1.5.61

Versions of packages console-data recommends:
ii  console-common  0.7.89
ii  kbd 2.0.3-2+b1

Versions of packages console-data suggests:
ii  unicode-data  9.0-1

-- debconf information excluded

Bug#894420: console-common: Please remove myself from Uploaders

[Christian Perrier]

Package: console-common
Version: 0.7.89
Severity: minor

I am no longer active in the maintenance of console-common. As I'm
cleaning out areas in Debian where I've been active, in preparation
for a possible future resignation, I suggest removing my name and
address from console-common's Uploaders field.

Thanks in advance.


-- System Information:
Debian Release: 9.4
  APT prefers oldoldstable
  APT policy: (500, 'oldoldstable'), (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 4.9.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Versions of packages console-common depends on:
ii  console-data   2:1.12-5
ii  debconf [debconf-2.0]  1.5.61
ii  debianutils4.8.1.1
ii  kbd2.0.3-2+b1
ii  lsb-base   9.20161125

console-common recommends no packages.

console-common suggests no packages.

-- debconf information excluded

Bug#894322: cifs-utils: Please remove myself from Uploaders

[Christian Perrier]

Package: cifs-utils
Version: 2:6.7-1
Severity: minor

I am no longer active in the Samba Packaging team for quite a while
now. Please remove me from the Uploaders field from the cifs-utils
package.

Thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages cifs-utils depends on:
ii  libc6 2.27-2
ii  libcap-ng00.7.7-3.1+b1
ii  libkeyutils1  1.5.9-9.2
ii  libkrb5-3 1.16-2
ii  libpam0g  1.1.8-3.7
ii  libtalloc22.1.10-2
ii  libwbclient0  2:4.7.4+dfsg-2
ii  samba-common  2:4.7.4+dfsg-2

cifs-utils recommends no packages.

Versions of packages cifs-utils suggests:
ii  keyutils   1.5.9-9.2
ii  smbclient  2:4.7.4+dfsg-2
ii  winbind2:4.7.4+dfsg-2

-- no debconf information

Bug#894182: O: calife

[Christian Perrier]

Package: wnpp
Severity: normal

I just orphaned this package, in preparation of /me slowly decreasing
my activity in Debian.

Bug#894070: ca-certificates: Please remove myself from Uploaders

[Christian Perrier]

Package: ca-certificates
Version: 20170717
Severity: minor

Hello,

It's been a very long time since I uploaded ca-certificates, mostly
acting as a sponsor rather than real maintainer.

I'm currently trying to clean out my developer page, so that it
includes only packages I really feel responsiible for.

As a consequence, I suggest that I'm removed from Uploaders for this
package.

Many thanks in advance.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages ca-certificates depends on:
ii  cdebconf [debconf-2.0]  0.241+b1
ii  debconf [debconf-2.0]   1.5.66
ii  openssl 1.1.0g-2

ca-certificates recommends no packages.

ca-certificates suggests no packages.

-- debconf information excluded

Bug#893944: shadow: Please remove myself from Uploaders

[Christian Perrier]

Package: shadow
Version: 4.5-1
Severity: normal

I'm no longer active in the maintenance of the shadow package. As a
consequence, I Isuggest that my name and Debian address are removed
from Uploaders.

Maintaining shadow over the years has been a great pleasure. Thanks to
people who took the maintenance over.


-- System Information:
Debian Release: buster/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.15.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#893917: O: antpm -- ANT+ information retrieval client for Garmin GPS products

[Christian Perrier]

Package: wnpp
Severity: normal

I intend to orphan the antpm package. I am the only uploader, the
pkg-running group is anything but active and I intend to reduce my
involvment in packaging (probably as I intend to resign from Debian in
one year or so)

The package description is:
 This software uses the Garmin ANT+ proprietary USB keys and
 communication protocol to retrieve information (such as GPS traces)
 from some Garmin Forerunner watches such as Forerunner 405 and 310XT.
 .
 The underlying ANT+minus implements the ANT/ANT+/ANT-FS protocols to
 provide these tools: garmin-ant-downloader, antpm-downloader,
 antpm-fit2gpx, and antpm-usbmon2ant.
 .
 ANT+minus is a userspace implementation of a wire protocol similar
 to the ANT/ANT+/ANT-FS protocols. The goal is to be able to communicate
 with any ANT capable device in order to e.g. retrieve sports tracks. The
 c++ implementation is currently available under both linux and win.
 Communication with watches other than the 310XT might work, but are
 untested. Please report your experience to help improving the software.
 .
 The software was originally named "gant" but renamed when packaged
 to avoid confusion with existing Java software.

Bug#893916: O: antpm -- ANT+ information retrieval client for Garmin GPS products

[Christian Perrier]

Package: wnpp
Severity: normal

I intend to orphan the antpm package.

The package description is:
 This software uses the Garmin ANT+ proprietary USB keys and
 communication protocol to retrieve information (such as GPS traces)
 from some Garmin Forerunner watches such as Forerunner 405 and 310XT.
 .
 The underlying ANT+minus implements the ANT/ANT+/ANT-FS protocols to
 provide these tools: garmin-ant-downloader, antpm-downloader,
 antpm-fit2gpx, and antpm-usbmon2ant.
 .
 ANT+minus is a userspace implementation of a wire protocol similar
 to the ANT/ANT+/ANT-FS protocols. The goal is to be able to communicate
 with any ANT capable device in order to e.g. retrieve sports tracks. The
 c++ implementation is currently available under both linux and win.
 Communication with watches other than the 310XT might work, but are
 untested. Please report your experience to help improving the software.
 .
 The software was originally named "gant" but renamed when packaged
 to avoid confusion with existing Java software.

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Christian PERRIER]

Quoting Jürgen Göricke (bugrep...@mag-keinen-spam.de):
> Hello everyone,
> 
> because this bug report is still not closed, I would like to check the status 
> of this bug report after more than a year and after the release of Debian 
> Stretch.
> When is it planned to replace the VLC Media Player with Xfce's own Media 
> Player Parole?
> And no, the VLC player is not a good alternative, as mentioned above due to 
> the Qt dependencies and of course because this player often has security 
> vulnerabilities.
> It is therefore advisable to replace the VLC Media Player with the Media 
> Player Parole.

Once again, I have strictly no advice about this. Formerly in the bug
report, Yves-Alexis didn't really object but argued about VLC being
kind of the reference player which "everybody" expects. On the ther
hand he gave no advice *against* having Parole specifically in the
Xfce task.

Finally, as we were late in the release process, the change didn't
seem a good thing to do at that momentbut now is maybe a better
moment.

Xfce developers in Debian (if some are left), do you have objections ?


-- 





signature.asc
Description: PGP signature

Bug#884375: flash-kernel wandboard patches, NMU?

[Christian PERRIER]

Quoting Andreas Henriksson (andr...@fatal.se):

> Btw, seems like except from Christian Perrier none of the Uploaders
> are active. Should I wipe out their names while at it? Maybe some
> others would accept being added instead, like Karsten Merker and
> possibly also Vagrant Cascadian?


It would probably be a good idea, sure. I'm only active because of
l10n-targeted uploads. Admitedly, I could also incorporate trivial
patches such as "Patch to support the foobar boards" because it seems
they're usually quite straightforward, but I have no clue when it
comes at these ARM things, so I usually tend to leave it up to someone
else (Karsten or Vagrant) to commit what they think is correct.

Most of the time, when something is committed to GIT, I upload the
package immediately after this, as this is a policy we apply in
debian-boot for quite a while and has proven mostly successful.

As I understand, Vagrant committed your patch so it's quite likely
that I upload a new flash-kernel quite soon.



signature.asc
Description: PGP signature

Bug#885475: pytrainer: Depends on unmaintained pygtk

[Christian PERRIER]

forwarded 885475 https://github.com/pytrainer/pytrainer/issues/106
tags 885475 upstream
thanks

Quoting Jeremy Bicha (jbi...@debian.org):
> Source: pytrainer
> Version: 1.11.0-1
> Severity: important
> User: pkg-gnome-maintain...@lists.alioth.debian.org
> Usertags: oldlibs pygtk
> Tags: sid buster
> 
> pygtk is unmaintained upstream. It has not had a release since GNOME 3
> was released in 2011.
> 
> The way forward is to port your app to use GObject Introspection
> bindings (and gtk3).
> 
> For more information on GObject Introspection see [1] and [2].
> 
> Please try to do this before the Buster release as we're going to
> try to remove pygtk this cycle.
> 
> If you have any question don't hesitate to ask.
> 
> [1] https://wiki.gnome.org/Projects/GObjectIntrospection
> [2] https://wiki.gnome.org/Projects/PyGObject
> 
> On behalf of the Debian GNOME team,
> Jeremy Bicha


Sigh. 

It's likely that, as with the recent issue with pytrainer depending on
obsolete python-wekbit, this issue stays unfixed for quite a while.

Nothing that I can really fix myself, unfortunately. I'm much more
running than hacking nowadays.




signature.asc
Description: PGP signature

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Raymond Burkholder (r...@oneunified.net):
> > > So, as an accommodation,  a flag in the preseed mechanism to
> > enable/disable would be helpful.  
> > 
> > You mean something like:
> > 
> > Template: pkgsel/update-policy
> > Type: select
> > Default: unattended-upgrades
> > 
> > pkgsel/update-policy=none thus seem the perfect preseed choice for your
> > use case.
> > 
> 
> Yes, thank you, that works for me.
> 
> Is there a dictionary somewhere where I can look these things up?  From
> where did you get your Template extract?

No, there is no such dictionary. Sadly, documenting all possible
presseding options really lacks a dedicated effort. There was one, in
the past, when the D-I team was much bigger, and, still the
Installation Guiide does document the most important options, but
those that have been "recently" added ("recentlly" means "last years")
shoudl be added there.

I got the template extractfrom the package source itself (pkgsel
package, here).




signature.asc
Description: PGP signature

Bug#875068: [Pkg-running-devel] Bug#875068: [openambit] Future Qt4 removal from Buster

[Christian Perrier]

Le 09/09/2017 à 22:13, Lisandro Damián Nicanor Pérez Meyer a écrit :

Source: openambit
Version: 0.3-1
Severity: wishlist
User: debian-qt-...@lists.debian.org
Usertags: qt4-removal


Hi! As you might know we the Qt/KDE team are preparing to remove Qt4
as [announced] in:

[announced] 
<https://lists.debian.org/debian-devel-announce/2017/08/msg6.html>

Currently Qt4 has been dead upstream and we are starting to have problems
maintaining it, like for example in the [OpenSSL 1.1 support] case.

[OpenSSL 1.1 support] <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=828522>

In order to make this move, all packages directly or indirectly depending on
the Qt4 libraries have to either get ported to Qt5 or eventually get
removed from the Debian repositories.

Therefore, please take the time and:
- contact your upstream (if existing) and ask about the state of a Qt5
port of your application
- if there are no activities regarding porting, investigate whether there are
suitable alternatives for your users
- if there is a Qt5 port that is not yet packaged, consider packaging it
- if both the Qt4 and the Qt5 versions already coexist in the Debian
archives, consider removing the Qt4 version

= Porting =

Some of us where involved in various Qt4 to Qt5 migrations [migration] and we
know for sure that porting stuff from Qt4 to Qt5 is much much easier and less
painful than it was from Qt3 to Qt4.

We also understand that there is still a lot of software still using Qt4.

Don't forget to take a look at the C++ API changes page [apichanges] whenever
you start porting your application.

[migration] http://pkg-kde.alioth.debian.org/packagingqtbasedstuff.html
[apichanges] http://doc.qt.io/qt-5/sourcebreaks.html

For any questions and issues, do not hesitate to contact the Debian Qt/KDE
team at debian-qt-...@lists.debian.org

The removal is being tracked in <https://wiki.debian.org/Qt4Removal>

Lisandro,
on behalf of the Qt4 maintainers

___
Pkg-running-devel mailing list
pkg-running-de...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-running-devel

Upstream now has a proposed patch to allow QT5 build (finally!). 
Therefore, I hope it will be applied soon and then a new version released.



If it isn't applied, I may apply it on the Debian package only.


--
*Christian Perrier*
Chef de service IID
Direction des systèmes d’information
Tél: +33 1 46 73 44 38


ONERA - The French Aerospace Lab - Centre de Châtillon
29, avenue de la Division Leclerc - BP 72 - 92322 CHATILLON CEDEX

Nous suivre sur : www.onera.fr <http://www.onera.fr> | Twitter 
<http://www.twitter.com/@onera_fr> | LinkedIn 
<http://www.linkedin.com/company/onera> | Facebook 
<http://www.facebook.fr/thefrenchaerospacelab>



Avertissement/disclaimer http://www.onera.fr/onera-en/emails-terms

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Christian PERRIER]

Quoting Raymond Burkholder (r...@oneunified.net):
> > 
> > I think its totally adequate to assume people want automatic security
> > updates, on all kinds of systems, unless they opt out.
> 
> Security updates, yes.  Automated, no.  Desktops, maybe.  Servers, no.
> 
> For my infrastructure, updates, of what ever kind, need to be incorporated 
> into the test/build/roll-out cycle.
> 
> Unless I misunderstand the intent of this thread.
> 
> So, as an accommodation,  a flag in the preseed mechanism to enable/disable 
> would be helpful.  But would need to be exposed in maybe the expert mode 
> menus, which I think was already mentioned.


You mean something like:

emplate: pkgsel/update-policy
Type: select
Default: unattended-upgrades
Choices-C: none, unattended-upgrades
__Choices: No automatic updates, Install security updates automatically
_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are automatically installed by the
 unattended-upgrades package. Alternatively, you can opt-out from
 this system and apply updates manually using standard package management
 tools.


pkgsel/update-policy=none thus seem the perfect preseed choice for
your use case.




signature.asc
Description: PGP signature

Bug#881578: [PKG-Openstack-devel] Bug#881578: watcher: Wrong encoding in Portuguese debconf translation

[Christian PERRIER]

Quoting Thomas Goirand (z...@debian.org):
> On 11/13/2017 07:11 AM, Christian Perrier wrote:
> > Source: watcher
> > Severity: normal
> > Tags: l10n
> > 
> > The Portuguese translaiton of debconf messages sent in #876177 claims
> > to be UTF-8 encoded while it is indeed ISO-8859-1.
> > 
> > Please find attached to the report a fixed version of this file.
> 
> 
> Hi Christian,
> 
> It's nice to see doing stuff for Debian again.

I'm still doing things...;-). Mostly D-I Irelated, though much much
less active nowadays. Also, maintaining a few sports-related
packagesand still monitoring some of the l10n infrastructure
tools. The latter is what made me discover this encoding problem.

> 
> I'll fix this ASAP, however, it looks like there's a few other pt.po
> that were recently sent to the BTS that had the same issue. If you could
> identify them, it'd be great, and then just tell me the list, and I can
> convert them myself (using whatever you will suggest). IMO, no need for
> a bug report for it, I can simply push it to Git and to Debian.


Well, indeed, I haven't spotted any other such problem. For the
record, the problem ehre was spotted by one of the l10n scripts : the
one that builds a giant "compendium" of debconf translations for  each
language. Theoretically, any other such problem should be spotted by
this script and I haven't seen anything as of now.




signature.asc
Description: PGP signature

Bug#881578: watcher: Wrong encoding in Portuguese debconf translation

[Christian Perrier]

Source: watcher
Severity: normal
Tags: l10n

The Portuguese translaiton of debconf messages sent in #876177 claims
to be UTF-8 encoded while it is indeed ISO-8859-1.

Please find attached to the report a fixed version of this file.


-- System Information:
Debian Release: buster/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.13.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE= 
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# watcher debconf portuguese messages
# Copyright (C) 2013 THE Watcher COPYRIGHT HOLDER
# This file is distributed under the same license as the watcher package.
# Pedro Ribeiro , 2013-2014, 2017
#
msgid ""
msgstr ""
"Project-Id-Version: watcher_0.30.0-5\n"
"Report-Msgid-Bugs-To: watc...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-29 12:24+\n"
"PO-Revision-Date: 2017-09-11 10:27+0100\n"
"Last-Translator: Pedro Ribeiro \n"
"Language-Team: Portuguese \n"
"Language: pt\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid "Set up a database for Watcher?"
msgstr "Configurar uma base de dados para o Watcher?"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"No database has been set up for Watcher to use. Before continuing, you "
"should make sure you have the following information:"
msgstr ""
"Não foi definida nenhuma base de dados para uso do Watcher. Antes de "
"continuar, deve certificar-se que tem a seguinte informação:"

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
" * the type of database that you want to use;\n"
" * the database server hostname (that server must allow TCP connections from "
"this\n"
"   machine);\n"
" * a username and password to access the database."
msgstr ""
" * o tipo de base de dados que deseja usar;\n"
" * o nome da máquina do servidor da base de dados (que tem que permitir\n"
"ligações TCP a partir desta máquina);\n"
" * um nome de utilizador e palavra-passe para aceder à base de dados."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"If some of these requirements are missing, do not choose this option and run "
"with regular SQLite support."
msgstr ""
"Se não tem alguns destes requisitos, não escolha esta opção e corra com "
"suporte SQLite normal."

#. Type: boolean
#. Description
#: ../watcher-common.templates:2001
msgid ""
"You can change this setting later on by running \"dpkg-reconfigure -plow "
"watcher\"."
msgstr ""
"Pode mudar esta definição mais tarde executando \"dpkg-reconfigure -plow "
"watcher\"."

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid "Authentication server hostname:"
msgstr "Nome do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:3001
msgid ""
"Please specify the hostname of the authentication server. Typically this is "
"also the hostname of the OpenStack Identity Service (Keystone)."
msgstr ""
"Por favor especifique o nome de máquina do servidor de autenticação. "
"Tipicamente este é também o nome de máquina do Serviço de Identidade "
"OpenStack (Keystone)."

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Authentication server tenant name:"
msgstr "Nome do inquilino ('tenant') do servidor de autenticação:"

#. Type: string
#. Description
#. Translators: a "tenant" in OpenStack world is
#. an entity that contains one or more username/password couples.
#. It's typically the tenant that will be used for billing. Having more than one
#. username/password is very helpful in larger organization.
#. You're advised to either keep "tenant" without translating it
#. or keep it aside with your translation. Example for French:
#. proprietaire ("tenant")
#: ../watcher-common.templates:4001
msgid "Please specify the authentication server tenant name."
msgstr "Indique por favor o nome 'tenant' do servidor de autenticação."

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Authentication server username:"
msgstr "Nome de utilizador do servidor de autenticação:"

#. Type: string
#. Description
#: ../watcher-common.templates:5001
msgid "Please specify the username to use with the authentication server."
msgstr ""
"Indique por favor o nome de 

Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):

> It seems there were no functional changes between both versions, only
> translation updates plus an extra CHANGES file (which looks like the
> last changelog entry). BTW, Christian, a git push seems to be missing.

I confirm: this last upload was just a rebuild to include a few
updated translations, at least theoretically.

I just made the git push which I apparently forgot to do (still
happens from time to time, grrr).




signature.asc
Description: PGP signature

Bug#875909: user-setup: Please drop set_special_users hack added for "the convenience of heavy testers"

[Christian PERRIER]

Quoting Chris Lamb (la...@debian.org):
> Source: user-setup
> Version: 1.69
> Severity: normal
> Tags: patch
> 
> Hey!
> 
> Please drop the set_special_users hack added for "the convenience
> of heavy testers".

Doh. Some history is vanishing out. Admitedly, I could have tried
some negotiation and propose to add "kibi" and "lamby" to this list
but let's face it: I'm no longer a heavy tester of D-I and I also
think that tbm will not whine either. I didn't even remember about
this hack...:-)

IIRC, there are a few other Eater Eggs here or there in D-I, but I
won't help finding them (mostly because I don't remember about them).

Patch applied. I'm rebuilding user-setup (it had to be done for i18n
pruposes anyway) and will upload it ASAP.




signature.asc
Description: PGP signature

Bug#874597: debian-installer: switch to debhelper 10

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Source: debian-installer
> Severity: normal
> 
> We're still using debhelper 7, and we're seeing such lines during the build:
> | dh_clean: Compatibility levels before 9 are deprecated (level 7 in use)
> | dh_installdirs: Compatibility levels before 9 are deprecated (level 7 in 
> use)
> 
> … so I guess it's time we update debhelper compat and check Standards-Version.
> Any takers?

I'd be happy to do that when rebuilding for translation (I have a
bunch of pending builds to do, because of recent updates for two
languages).

I can probably start doing so as soon as my next race is over and I'm
back to work (it is suppsoed to start in.6h30...and end on next Sunday).

Of course, it won't cover all D-I packages, but once done for those
with translated material, I can continue with others.




signature.asc
Description: PGP signature

Bug#872867: is ISO-3166 really the optimal list for our users?

[Christian PERRIER]

Fun to see this discussion going round with people having no idea of
what we went through back in 2004 and later and the real circumstances
around the choice of ISO-3166 and the very few minor concessions we
made back then (mostly Taiwan and Macedonia), to accomodate at best
what would be good for our users.

So my only and last words about this topic will be:

- drop support for countries in the installer? Probably the stupidest
idea I've ever heard. If you do so, then please first ask for dropping
support for locales in the glibc

- use an alternate list than ISO-3166. Come on. Who will maintain that
in the long term?

- do something for Kosovo? Yeah, I think it's worth it. The best being
to ask it to be exceptionnally added to the iso-codes package (which I
would support, even though I'm no longr its maintainer)

In short, reassign this bug to iso-codes and rename it. This is what I
would do.





signature.asc
Description: PGP signature

Bug#865319: [Pkg-shadow-devel] Bug#865319: passwd: Partial man French l10n: 1 untranslated sentence

[Christian PERRIER]

Quoting David Guyot (david.gu...@web-eci.com):
> Package: passwd
> Version: 1:4.4-4.1
> Severity: minor
> Tags: l10n
> 
> Dear Maintainer,
> 
> Reading the French passwd(1) man, I noticed that there was a remaining English
> sentence: "You can find advice on how to choose a strong password on
> http://en.wikipedia.org/wiki/Password_strength;. In French, that would
> translate to: "Vous trouverez des conseils concernant la robustesse d’un mot 
> de
> passe à l’adresse https://en.wikipedia.org/wiki/Password_strength (en)".
> 
> I did not pick the page from the French Wikipedia, as it is currently way too
> concise and useless, and I didn't know which other source I could use there.
> Regarding the translation, French being my first language, I'm rather 
> confident
> that it is good, but feel free to not take my word for it ;)


This is common practice in gettext-based translation work. Doing so
allows to keep the part that have been translated *and* avoid dropping
additional English parts.

I do not consider this a bug but a feature that helps in keeping alive
translation work even when nobody works on updating it.



Would I still be the package maintainer, I would consider closing the
bug report.




signature.asc
Description: PGP signature

Bug#864751: Need common names for Iran, North Korea, South Korea, Palestine, Russia, and Syria

[Christian PERRIER]

Quoting Alex Henrie (alexhenri...@gmail.com):
> Package: iso-codes
> Version: 3.75-1
> Tags: patch
> 
> I have to convert a list of country names to ISO codes, but my script
> is failing on Iran, North Korea, South Korea, Palestine, Russia, and
> Syria. I submitted patches on the mailing list, but haven't gotten any
> response: 
> http://lists.alioth.debian.org/pipermail/pkg-isocodes-devel/2017-May/006860.html
> 
> The patches that I sent to the mailing list are attached.


As *former* maintainer of iso-codes, and the one who introduced the
concept of "common name", I am *not* in favor of such patch.

The idea behind the entire iso-codes package is to implement the
standard, the entire sttandard, but only the standard.

Such "common names" are NOT part of the standard. The country names as
they are in the standard are the way these countries want to be
named. As a consequence, I think this is how they should be called.

Personal preferences or even so-called "common" ways to call these
countries should not some in the game.

I introduced "common names" in order to solve TWO specific cases that
had very strong political implications, *including in the said
countries themselves : Taiwan and Macedonia. These names are the way
these countries and their respective governing bodies want them to be
called. However, international bodies (namely the UNO and the ISO-3166
standard agency), have chosen to follow advices and influences from
*outside* the said countries, to include names ("Taiwan, Republic of
China" and "Former Yougoslavian Republic of Macedonia") that are NOT
ACCEPTED inside the countries.

So, after a heated debate with Debian users from these countries, this
concept was introduced.

However, I think that diverting the idea behind "common names" to
implement so-called "commonly used" names, goes too far. If these
countries want to be named this way, their national standard body can
change that by following standard ISO-3166 procedures (in such cases
that implies changing the "short name" in the UNO). We, as package
maintainers, should not interfere with that.

However, I leave such decision to Tobias, the current package maintainer.



signature.asc
Description: PGP signature

Bug#862787: debconf: Passwords do not match.

[Christian PERRIER]

reassign 862787 ddclient
severity 862787 normal
thanks

Quoting luciano (fran...@modula.net):
> Package: debconf
> Version: 1.5.56
> Severity: grave
> Tags: security
> Justification: user security hole
> 
> Dear Maintainer,
> 
> *** Reporter, please consider answering these questions, where appropriate ***
> During the installation of ddclient, Debconf display the error "Passwords do 
> not match. The two passwords you entered where not the same. Please try 
> again". If I try again then the password is accepted. Always the same 
> message, after more than 10 install/uninstall attemps using two different 
> computers.


If this happens during the installation of ddclient, then this bug
belongs to that package, not debconf. And is indeed of normal severity
(or "important" but certainly not grave).




signature.asc
Description: PGP signature

Bug#854653: encourage users to generate strong passwords

[Christian PERRIER]

reassign 854653 user-setup
thanks

Quoting Antoine Beaupre (anar...@debian.org):
> Package: debian-installer
> Severity: wishlist
> 
> After reflecting for a few days about password generation and writing
> an [article][1] about it, I was told the debian-installer may be a good
> place to encourage people to set strong passwords. In the d-i, we set
> one or three critically important passwords: the main user account
> and, optionnally, the root account and crypto passphrase. The latter
> password seems especially important to be cryptographically secure.


This is more or less #364526

I don't merge the bugs as they're phrased differently but I think the
spirit is the same.but in 11 years, it seems that nobody stepped
up to implement something..:-)



signature.asc
Description: PGP signature

Bug#854291: debian-installer: Installer does not map English / Denmark to en_DK.xxx locale.

[Christian PERRIER]

reassign 854291 localechooser
tags 854291 wontfix
thanks

Quoting Thomas Rosted Jensen (tho...@rosted.net):
> Package: debian-installer
> Version: 20170127_amd64
> 
> I have installed Debian test image from 1. Feb 2017:
> http://cdimage.debian.org/cdimage/stretch_di_rc2/amd64/iso-cd/debian-stretch-DI-rc2-amd64-netinst.iso
> 
> 
> During installation i select English for Language, and Denmark for the
> locale.
> 
> However the install fails to map English language / Denmark locale to the
> "en_DK.UTP-8" locale definition.
> 
> The expert install allows me to select "en_DK.UTP-8" definition manually, so
> that installed system works fine.
> 
> Attached files.
> - /etc/default/locale
> - /etc/locale.gen
> - /var/log/installer/syslog
> 
> Screenshots with descriptions in file "Debian9_select_en_DK_locale.pdf"
> 
> /Thomas

This is frequently reported.and, as usual, plain wrong. en_DK is a
longstanding locale in glibc that is indeed a tweak and that shouldn't
exist.

By design, locales are meant to represent real use cases, which is why
they're nearly always limited to language/country combinations that
indeed *really* exist.

English has no specific status in Denmark (except by being spoken by
many peoplebut that's also the case in most countries) and the
fact that a en_DK locale existts is only historical.

For that reason, d-i does not directly support tthe en_DK locale and
does it only exactly as you did, through the expert install. Whichis
logical as nobody would choose such combination in normal installs

This is commonly argued by a few people, from time to time.and
none of them managed to convince the D-I team to do something
else..:-)

So, well, reassigning and tagging accordingly




signature.asc
Description: PGP signature

Bug#824391: [Pkg-shadow-devel] Bug#824391: Pending fixes for bugs in the shadow package

[Christian PERRIER]

Quoting Bálint Réczey (bal...@balintreczey.hu):
> 2017-01-25 17:14 GMT+01:00 Steinar H. Gunderson :
> > On Wed, Jan 25, 2017 at 04:00:18PM +, 
> > pkg-shadow-de...@lists.alioth.debian.org wrote:
> >> The full diff can be seen at
> >> http://anonscm.debian.org/gitweb/?p=pkg-fonts/shadow.git;a=commitdiff;h=d779e83
> >
> > FWIW; this 404-s. pkg-fonts/shadow?
> 
> No, this is a bug in the scripts. :-)
> 
> Christian, could you please fix it in the following file?:
> /home/groups/pkg-shadow/scripts/git-tag-pending-bugs
> 
> I have no write access.

Done:
bubulle@moszumanska:/home/groups/pkg-shadow/scripts$ chmod g+w 
git-tag-pending-bugs
bubulle@moszumanska:/home/groups/pkg-shadow/scripts$ chmod g+w .




signature.asc
Description: PGP signature

Bug#852646: task-xfce-desktop: please recommend atril not evince

[Christian PERRIER]

Quoting Adam Borowski (kilob...@angband.pl):
> Package: task-xfce-desktop
> Version: 3.39
> Severity: wishlist
> 
> Hi!
> Currently, the XFCE task pulls in evince, whose interface is really out of
> place outside of Gnome.  It'd be far better to install atril instead (from
> Mate) -- it blends in with XFCE seamlessly.  It also doesn't suffer from a
> number of weird decisions taken by the Gnome project that make the user
> interface really inconsistent with XFCE components.
> 
> Atril is a fork of Evince, so base functionality is the same.

As usual: what's the stance of Xfce packages maintainers about this?




signature.asc
Description: PGP signature

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Christian PERRIER]

Quoting Jürgen Göricke (juergengoeri...@smart-mail.de):
> Dear Maintainer,
> 
> see all the dependencies from package vlc in Debian Sid.
> 
> https://packages.debian.org/sid/vlc
> 
> http://paste.debian.net/905778
> 
> Vlc needs Qt dependencies by default.
> 
> What is the problem with parole to add the task-xfce-desktop respectively
> tasksel meta packages?
> 
> Why you wan't change the packages? I can't understand it.
> 
> Parole is the default media player from xfce project and not so bloated
> as the vlc player.

The more impatient you appear, the less likely is that the change will
happen.

Corsac gave a good answer, which, somehow, may trigger discussion
about the fact that doing such change so late in the release process
may not be a good idea.

Let other people give some advice.




signature.asc
Description: PGP signature

Bug#849578: task-xfce-desktop: Why you use the vlc player in the task-xfce-desktop meta package?

[Christian PERRIER]

Quoting Jürgen Göricke (bugrep...@smart-mail.de):
> Package: task-xfce-desktop
> Version: 3.39
> Severity: wishlist
> 
> Dear Maintainer,
> 
> why you use the vlc player in the task-xfce-desktop meta package instead
> the parole player from xfce project directly?
> 
> The advantages from parole player are, you don't need Qt dependencies from
> vlc player. The parole player is written in Gtk+, runnig fine and need
> the gstreamer framework only.
> 
> Please do set the parole player as default player in the
> task-xfce-desktop meta package.
> Many thanks!

Hello,

Thank you for your suggestion.

It should be discussed with people who package Xfce in Debian
(CC'ed). For most desktop tasks, the content of the tack is determined
by the relevant team. The tasksel maintainers (or what's left of them)
only apply their recommendations.

Please keep all addresses but me when answering this mail (I'll
receive anwswers through the bug tracking system anyway).




signature.asc
Description: PGP signature

Bug#846002: blends-tasks must not be priority:important (was Re: Bug#846002: Lowering severity)

[Christian PERRIER]

Quoting Raphael Hertzog (hert...@debian.org):

> Christian and Cyril, what are your thoughts on this? Do you think that if
> we come up with a patch implementing the above, we could get it in
> stretch? What would be the last delay to come up with such a patch?


From my own POV, I'm too far from core D-I development (except l10n)
nowadays to get a usefuul advice. When it comes at tasksel, I work in
low maintenance mode. When obvious things pop up, and if I notice
them, I usually apply fixes. The same stands when an upload is needed.

However, when it comes at design issues, I consider that my own advice
would be quite pointless and maybe even confusing.

Sorry for not being very helpful here.



signature.asc
Description: PGP signature

Bug#847056: debian-installer: Installer can't find "en_DK.utf-8" locale

[Christian PERRIER]

reassign 847056
forcemerge 847056 842630
thanks

Quoting Christian Iversen (ci+debb...@iversenit.dk):
> Package: debian-installer
> Severity: normal
> Tags: l10n d-i
> 
> Hello d-i, et al
> 
> I live in Denmark, but almost always set up servers in english, to make
> collaboration easier.
> 
> This means the en_DK.utf-8 locale is my preferred choice.
> 
> However, I can no longer (I believe it broke in jessie, perhaps before) select
> it in the installer.
> 
> I select "English", then "Europe" then "Copenhagen", and I am told that there
> is no locale available for my combination of choices. This is, of course,
> wrong.
> 
> I then have to either fix up the system later, go through expert install, or
> increase debconf priority (a trick I just learned today).
> 
> Why the bug happens, I'm not quite sure, but I have a suspicion. Denmark is 
> one
> of the few countries in the world, where the language and country codes do not
> align (language: "da", country: "dk"). Perhaps the installer is checking the
> wrong one of these?
> 
> Let me know how I can help!


This is indeed bug #842630 (sort of). Please also notice that, last
time I checked, the en_DK locale is only meant to be a kind of proof of
concept and historical stuff by locales' upstream and not something
that should be in production (otherwise we would have as many en_*
locales as there are countries in the world.).





signature.asc
Description: PGP signature

Bug#768914: Bug#847038: Bug#768914: Bug#847038: Wireless password displayed in clear

[Christian PERRIER]

Quoting Baptiste Jammet (bapti...@mailoo.org):
> Hi all,
> 
> Le 05/12/2016 07:32, Christian PERRIER a écrit :
> > Quoting wi...@infradead.org (wi...@infradead.org):
> > > Second, it prompted me to enter the WPA2 passphrase, but it displays
> > > the
> > > password as I typed it instead of masking it with dots the way that it
> > > does for user & root passwords.
> > > 
> > 
> > This is #768914 and FWIW, I personnaly do not agree with changing the
> > password phrase prompt to hide the text as typed.
> > 
> > The only idea that comes to my mind is a (low priority) debconf
> > question before the passphrase prompt, asking users whether they want
> > the passphrase to be shown as typed or not.
> 
> Since d-i Stretch Alpha x (verified with daily images), there is a checkbox
> "Show password" during the {root,user}-password questions.
> As a non-tech user, I wonder if this can be used for the wifi passphrase
> too ?

Indeed. This is from cdebconf's changelog:

  * Allow one to show/hide characters typed in password field with the GTK+ and
Newt frontends. Closes: #700924.

Fixed in cdebconf 0.197


-- 




signature.asc
Description: PGP signature

Bug#768914: Bug#847038: Wireless password displayed in clear

[Christian PERRIER]

Quoting wi...@infradead.org (wi...@infradead.org):
> Package: installation-reports
> 
> Image version: 
> http://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/weekly-builds/amd64/jigdo-cd/firmware-testing-amd64-netinst.jigdo
>  timestamped 2016-11-28 06:24
> 
> I was installing over wifi, and encountered two problems.
> 
> First, it said it needed non-free firmware for the iwlwifi that it
> couldn't find ... but I'd used the non-free jigdo above, so I thought they
> probably were on the USB stick.  I asked it to look and it found them.
> Why didn't it find them the first time?
> 
> Second, it prompted me to enter the WPA2 passphrase, but it displays the
> password as I typed it instead of masking it with dots the way that it
> does for user & root passwords.
> 

This is #768914 and FWIW, I personnaly do not agree with changing the
password phrase prompt to hide the text as typed.

The only idea that comes to my mind is a (low priority) debconf
question before the passphrase prompt, asking users whether they want
the passphrase to be shown as typed or not.

-- 




signature.asc
Description: PGP signature

Bug#845757: geneweb FTBFS on mipsel: dpkg-deb (subprocess): compressing tar member: lzma error: Cannot allocate memory

[Christian PERRIER]

Quoting Guillaume Brochu (guillaume.bro...@gmail.com):

> This modification was introduced in June 2012:
> 
> https://anonscm.debian.org/cgit/collab-maint/geneweb.git/commit/?id=16cddde963e4169c09bfe49cb6949fe0dc484f0c
> 
> At first sight, I don't see any reason to use compression level 9, so I will
> apply your patch on the git repository.

Indeed no good reason. This change was done when exchanging with
Hideki Yamane who was preparing a talk about switching to xz, for
DebConf 12. As much as I remember, I proposed Yamane-san to swith "my"
geneweb package to xz and even enforce the highest compression level,
as an illustration of "yes we can".

Later on, several discussions showed that this compression level puts
too much load on autobuilders and then the default was setto use
xz's own default.

But, geneweb was never changed later on, which explains this. So, in
short, there was no special reason except experimentation.

I'm building the package modified by Guillaume and will upload
soon. Thank you for your work.




signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Christian PERRIER <bubu...@debian.org> (2016-11-19):
> > I now need to figure out where to make other changes.
> > 
> > One is in the installer build files (in the debian-installer package
> > itself) and is committed to git.
> 
> Maybe you forgot to push that part? I've mentioned it earlier when I
> noticed the rootskel-gtk upload (and only saw this thread afterwards):
>   https://lists.debian.org/debian-boot/2016/11/msg00178.html


That's right. I forgot pushing the commitwhich I found, today, was
done in an outdated copy of installer/ directory anyway (I keep my
copy of packages/ up-to-date, but not installer/)

I redid it cleanly today and just pushed.



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):

> > http://sources.debian.net/src/debian-installer/20161031/build/pkg-lists/gtk-common/?hl=22#L22
> > 
> > I found above at https://codesearch.debian.org/ with this expression:
> > 
> >   (?i:sinhal) package:debian-installer
> > 
> > (to cover upper/lower case, and both Sinhala and Sinhalese)
> 
> 
> Indeed, this is in rootskel-gtk, in src/usr/bin/gtk-set-font. It
> allows choosing the "main" font depending on the locale and even
> picking a bigger size than the default.
> 

rootskel-gtk just uploaded.

If everything goes well, the next daily builds of D-I (netboot images)
should soon use the Noto fonts to display Sinhala.

-- 




signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Jonas Smedegaard (d...@jones.dk):
> Quoting Christian PERRIER (2016-11-19 12:17:00)
> > Quoting Jonas Smedegaard (d...@jones.dk):
> > 
> > > > Another is in one of the D-I packages : changing the file that
> > > > mentions what fonts are used depending on the locale. This is not yet
> > > > committed as I now have to remember what package we're talking 
> > > > about..:-)
> > > 
> > > Old: fonts-lklug-sinhala-udeb
> > > 
> > > New: fonts-noto-hinted-udeb package
> > 
> > *that* I found. The place I'm looking for is a file that says "if
> > you're using a Sinhala locale, then load this font". From memory that
> > might be rootskel-gtk
> 
> Ah, ok.
> 
> gtk-common, perhaps?
> 
> http://sources.debian.net/src/debian-installer/20161031/build/pkg-lists/gtk-common/?hl=22#L22
> 
> I found above at https://codesearch.debian.org/ with this expression:
> 
>   (?i:sinhal) package:debian-installer
> 
> (to cover upper/lower case, and both Sinhala and Sinhalese)


Indeed, this is in rootskel-gtk, in src/usr/bin/gtk-set-font. It
allows choosing the "main" font depending on the locale and even
picking a bigger size than the default.



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Jonas Smedegaard (d...@jones.dk):

> > Another is in one of the D-I packages : changing the file that
> > mentions what fonts are used depending on the locale. This is not yet
> > committed as I now have to remember what package we're talking about..:-)
> 
> Old: fonts-lklug-sinhala-udeb
> 
> New: fonts-noto-hinted-udeb package

*that* I found. The place I'm looking for is a file that says "if
you're using a Sinhala locale, then load this font". From memory that
might be rootskel-gtk



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Harshula (harsh...@debian.org):
> On 18/11/16 22:12, Jonas Smedegaard wrote:
> > Quoting Christian Perrier (2016-11-18 09:11:00)
> 
> >> Chagning the D-I font to Noto for all languages hasn't been 
> >> validated...and the current font is well tested and accepted.
> >>
> >> So, as a consequence, I'd prefer a udeb that would be suited for 
> >> Sinhala.
> > 
> > Makes sense.
> > 
> > udeb package fonts-noto-hinted-udeb now, since 20161116-1, contains only 
> > fonts relevant for debian-installer - i.e. for now only Sinhala fonts.
> 
> Thanks!! That was very quick.


I now need to figure out where to make other changes.

One is in the installer build files (in the debian-installer package
itself) and is committed to git.

Another is in one of the D-I packages : changing the file that
mentions what fonts are used depending on the locale. This is not yet
committed as I now have to remember what package we're talking about..:-)



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian Perrier]

Le 17/11/2016 à 15:32, Jonas Smedegaard a écrit :

Quoting Harshula (2016-11-17 14:58:33)

On 19/09/16 02:07, Christian PERRIER wrote:

I'd be happy to do this, however the fonts-noto-hinted-udeb package
is 5 megabytes in size while the former fonts-lklug-sinhala-udeb
package is only 67kilobytes.

Size is somehow constrained in Debian Installer, so I'd prefer
getting more input and advice before replacing
fonts-lklug-sinhala-udeb byt fonts-notohinted-udeb in D-I


Perhaps the Noto maintainers might consider splitting Noto into script
based debs. IIRC, that's what was done in Fedora.


I'd be happy to improve the usefulnes of the Noto package(s), but will
need more guidance.

I suspect easiest approach would be for debian-installer to use Noto
generally - i.e. replace not only the font for Sinhala but (I guess) a
larger range of region-specific fonts.

If debian-installer installs locale-specific fonts only when needed, or
there are reasons to not shift generally to Noto, then indeed there is a
benefit in creating udeb packages for smaller regions.

I can create a udeb specifically for Sinhala.  Or I can create a udeb
for each single font part of the Noto deb.  What do the debian-installer
team consider useful?

 - Jonas



Chagning the D-I font to Noto for all languages hasn't been 
validated...and the current font is well tested and accepted.


So, as a consequence, I'd prefer a udeb that would be suited for Sinhala.

Bug#842331: task-chinese-s-desktop: please replace Rec: ttf-wqy-zenhei with Rec: fonts-wqy-zenhei

[Christian PERRIER]

Quoting Boyuan Yang (073p...@gmail.com):
> Package: task-chinese-s-desktop
> Severity: wishlist
> Tags: l10n
> 
> The package `ttf-wqy-zenhei' is now a dummy transitional package. Please
> directly depend on the real package `fonts-wqy-zenhei'.

Thanks for pointing this. I'll also change ttf-wqy-microhei to its
fonts- equivalent.



signature.asc
Description: PGP signature

Bug#814923: tasksel: Please add task-lxqt-desktop to tasksel

[Christian PERRIER]

Quoting Roger Shimizu (rogershim...@gmail.com):
> Dear Changzhuo,
> 
> On Tue, Oct 25, 2016 at 7:46 PM, ChangZhuo Chen  wrote:
> > On Sun, Mar 20, 2016 at 01:24:16AM +0800, ChangZhuo Chen (陳昌倬) wrote:
> >> Any progress for this patch?
> >
> > Could you help to review the patch in tasksel for LXQt desktop? We, the
> > LXQt packaging team, needs this to make LXQt available in Stretch.
> 
> AFAIK. The D-I team is preparing a release [0], I'm not sure whether
> your patch can be merged before that release.


But we waited for much too long time, sorry for this. Tasksel sadly
needs a lot of love and more active maintenance.

I don't think this chance is too invasive, so I'll include it
ASAP. Sorry again for the delay.



signature.asc
Description: PGP signature

Bug#837926: debian-installer: please use fonts-noto-hinted to display the Sinhala script

[Christian PERRIER]

Quoting Harshula (harsh...@debian.org):
> Package: debian-installer
> Version: 20160630
> Severity: important
> 
> Please use fonts-noto-hinted to display the Sinhala script
> 
> The LKLUG font is viewed as deprecated and we've been trying to
> encourage other fonts that can succeed as the default Sinhala font on
> GNU/Linux.
> 
> At this stage the Noto Sinhala range, in fonts-noto-hinted, is a more
> appropriate default font than LKLUG.
> 
> See the discussion here:
> http://sourceforge.net/p/sinhala/mailman/message/34481529/

I'd be happy to do this, however the fonts-noto-hinted-udeb package is
5 megabytes in size while the former fonts-lklug-sinhala-udeb package
is only 67kilobytes.

Size is somehow constrained in Debian Installer, so I'd prefer getting
more input and advice before replacing fonts-lklug-sinhala-udeb byt
fonts-notohinted-udeb in D-I

-- 




signature.asc
Description: PGP signature

Bug#762311: task-laptop: drop acpi package recommendation?

[Christian PERRIER]

Quoting Bob Bib (bob...@ukr.net):
> Any opinion from the maintainers?..
> 
> -- 
> Best wishes,
> Bob
> 

I just committed the fix in git.


-- 




signature.asc
Description: PGP signature

Bug#836715: samba: Please drop my name from Uploaders of the samba package

[Christian Perrier]

Package: samba
Version: 2:4.4.5+dfsg-2
Severity: minor

Hello folks,

It's really time for me to admit that I'm not longer really involved
in the maintenance of the samba package in Debian. As a consequence, I
'think it would be better for my name to be removed from the Uploaders
field in debian/control.

The same question may rise for Steve but I leave it up to him to
confirm.

The project admins on Alioth were Steve Langasek, Ivo de Decker and me. 

I just added admin privileges to Andrew, Jelmer and Mathieu. I know
that some of you certainly don't define themselves as "lead" for this
work but you guys are way more active than I am, anyway...:-)


-- System Information:
Debian Release: stretch/sid
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages samba depends on:
ii  adduser  3.115
ii  dpkg 1.18.10
ii  init-system-helpers  1.42
ii  libbsd0  0.8.3-1
ii  libc62.23-4
ii  libldb1  2:1.1.26-1
ii  libpam-modules   1.1.8-3.3
ii  libpam-runtime   1.1.8-3.3
ii  libpopt0 1.16-10
ii  libpython2.7 2.7.12-2
ii  libtalloc2   2.1.7-1
ii  libtdb1  1.3.9-1
ii  libtevent0   0.9.28-1
ii  libwbclient0 2:4.4.5+dfsg-2
ii  lsb-base 9.20160629
ii  procps   2:3.3.12-2
ii  python   2.7.11-2
ii  python-dnspython 1.14.0-3
ii  python-samba 2:4.4.5+dfsg-2
pn  python2.7:any
ii  samba-common 2:4.4.5+dfsg-2
ii  samba-common-bin 2:4.4.5+dfsg-2
ii  samba-libs   2:4.4.5+dfsg-2
ii  tdb-tools1.3.9-1
ii  update-inetd 4.43

Versions of packages samba recommends:
ii  attr1:2.4.47-2
ii  logrotate   3.8.7-2
ii  samba-dsdb-modules  2:4.4.5+dfsg-2
ii  samba-vfs-modules   2:4.4.5+dfsg-2

Versions of packages samba suggests:
pn  bind9  
pn  bind9utils 
ii  ctdb   2:4.4.5+dfsg-2
pn  ldb-tools  
ii  ntp1:4.2.8p8+dfsg-1
ii  smbldap-tools  0.9.9-1
pn  ufw
ii  winbind2:4.4.5+dfsg-2

-- no debconf information

Bug#827228: [Pkg-running-devel] Bug#827228: pytrainer: Add firefox-esr to the browser dependency list

[Christian PERRIER]

Quoting Cesare Leonardi (celeo...@gmail.com):
> On 14/06/2016 08:07, Christian PERRIER wrote:
> > Upload is on its way. However, is there indeed a reason to *keep*
> > iceweasel in the dependency list?
> 
> Hello Christian, any news on that?
> 
> Currently i'm unable to remove the iceweasel package, because it's a
> dependency only of pytrainer.
> 
> I think you could leave iceweasel in the dependency list just for backport
> reasons. But feel free to remove it entirely.
> 
> Cesare.
> 

Doh.

The upload is prepared since June 14th and..waiting for me to
upload.

Sincere apologies. You did well by reminding this to me.

*now* it should be uploaded (and, doh, I'll have to manually close
#827228 as I forgot to add the needed "Closes" line in the upload.

-- 




signature.asc
Description: PGP signature

Bug#717298: debian-installer: After installing xfce environment, don't see xfce

[Christian PERRIER]

Quoting Thorsten Glaser (t...@mirbsd.de):
> Package: debian-installer
> Followup-For: Bug #717298
> 
> This is probably because of this…
> 
> Choices-C: kde, gnome, lxde, xfcd, sugar  
>
> 
> … in 
> debian-installer/packages/desktop-chooser/debian/desktop-chooser.templates.
> 
> Quick fix attached.

Well, desktop-chooser is a package that has never been released, so I
doubt the problem comes from it.

Anyway, your patch is still valid (so, thank you) and I'll apply it to
desktop-chooser's git in case someone does something with it in the
future...




signature.asc
Description: PGP signature

Bug#833737: tasksel: s390x should be a server architecture

[Christian PERRIER]

Quoting Philipp Kern (pk...@debian.org):
> On Mon, Aug 08, 2016 at 12:09:06PM +0100, Dimitri John Ledkov wrote:
> > Please mark s390x as an unlikely desktop architecture, and thus a server
> > one. s390 port is already marked as such.
> 
> LGTM. But it seems that tasksel is not part of debian-installer's git
> repositories. |-:

I suggest that people who want to commit stuff in tasksel's git repo
just apply for commit there. At least Kibi and I can grant commit
access.






signature.asc
Description: PGP signature

Bug#801707: ITA: shadow -- system login tools

[Christian PERRIER]

Quoting Andreas Henriksson (andr...@fatal.se):
> Hello!
> 
> Would just like to add here that http://bugs.debian.org/833256
> has been filed and another option than seeking someone to
> maintain src:shadow would be to migrate over to the tools
> provided by src:util-linux (which other distributions use
> and is well maintained upstream) and thus possibly getting
> rid of src:shadow.
> 
> Anyone thinking of adopting shadow might want to investigate
> this alternative. Feel free to comment on #833256.
> 
> Regards,
> Andreas Henriksson
> 

Juste answering to your mail so that' it's CC'ed to the shadow
development list. 

I agree that having something different from other distros is,
nowadays, probably not the best thing. If we look how loosely shadow
was maintained during several years (no offense intended to those
involved, of course, which includes myself), I'm sure there's
something better to do.

-- 




signature.asc
Description: PGP signature

Bug#832318: [Pkg-samba-maint] Bug#832318: samba: valid users = +group can't work with open LDAP

[Christian PERRIER]

Quoting Tomoo Nomura (nom...@tmo.co.jp):
> Package: samba
> Version: 2:4.1.17+dfsg-2
> Severity: normal
> 
> Dear Maintainer,
> 
> Access control, valid user = +group, can't work when using with open LDAP, 
> while it works fine with /etc/group.
> For examples, user=nomura is a member of group named manager and mount 
> [testmanager] from another debian jessie machine. It shows "mount error(13): 
> Permission denied ".


Shouldn't this be "valid users = @group"?



signature.asc
Description: PGP signature

Bug#830308: d-i.debian.org: l10n-sync script breaks headers in individual package files in some situations

[Christian PERRIER]

Quoting Steve McIntyre (st...@einval.com):

> Arg, sorry. :-( It's very easy to make mistakes when editing large
> numbers of files like this by hand. I double-checked the diffs,
> even. Could we add some commit-time checking to run msgfmt etc. and
> warn on errors?

Yes, this is exactly what I did in l10n-sync before reverting the
changes. It has been tested locally with the "broken" files in place
and the script stopped as expected before committing.

Indeed, the breakage happened when the 5 "sublevels" PO files for
Banish and Belarusian are temporarily concatenated into one single PO
file, which "msgcat". The single PO file is then used for synchronize
the PO files in individual packages.

The "msgcat" command (line 585 in l10n-sync) was indeed not protected
by error handling in our scripts, while most gettext commands are.

The fix I committed added a prior test of merged PO files with "msgfmt
-c" (and exiting if that fails) and I just added one more error
handling in the "msgcat" command itself.




signature.asc
Description: PGP signature

Bug#830308: d-i.debian.org: l10n-sync script breaks headers in individual package files in some situations

[Christian PERRIER]

Quoting Cyril Brulebois (k...@debian.org):
> Christian PERRIER <bubu...@debian.org> (2016-07-11):
> > […]
> > (notice the line after "../rescue-mode.templates:21001")
> > 
> > In short, Steve's attempt to fix the translation broke the PO file.
> > 
> > And, later on, l10n-sync choke on this.
> > 
> > And thus, the fix is to make l10n-sync more resilient to this and for
> > instance have it to test the validity of "master" PO files before
> > working with them.
> 
> Many thanks for this. I'll try and join the fun later on today, once I'm
> done with other urgent matters. As I mentioned, l10n-sync needs some
> patching, and I'll be happy to deal with it once time allows.


I started working on a patch that will at least run "msgcat -c" on PO
files at some critical steps.

The first place where this is needed is the place in l10n-sync where
we merge all sublevel PO files for a given language into one big
"master" file, that is, later on, used to update individual packages'
files.

I found at least one place where a broken PO file is happily merged
with other file without error being thrown out. This is what explains
the current breakage on da.po and be.po

I'm currently testing a patch to fix this and have l10n-sync abort its
operations when this happens.




signature.asc
Description: PGP signature

Bug#830308: d-i.debian.org: l10n-sync script breaks headers in individual package files in some situations

[Christian PERRIER]

Quoting Christian Perrier (bubu...@debian.org):
> Package: d-i.debian.org
> Severity: normal
> Tags: l10n
> 
> It turns out that, as things are right now, the l10n-sync scripts
> appears to break PO files headers in Danish and Belarusian
> translations of many packages, if not all of them.


OK, I have a few more clues about this:

If I revert packages/po/sublevel2/da.po to r70261:

bubulle@kheops:~/src/debian/debian-installer/trunk.test/packages/po/sublevel2 $ 
svn diff -r HEAD:70261 da.po | patch 
patching file da.po
bubulle@kheops:~/src/debian/debian-installer/trunk.test/packages/po/sublevel2 $ 
LC_ALL=C msgfmt -c -v -o /dev/null --statistics da.po
da.po:5047:78: syntax error
msgfmt: found 1 fatal error

The offending part:
#. Type: boolean
#. Description
#. :sl2:
#: ../rescue-mode.templates:21001
#| "It is normally a good idea to mount it as it will allow operations such "
#| "as reinstalling the boot loader. However, if the file system on 
${FILESYSTEM} is "
#| "corrupt then you may want to avoid mounting it."
msgid ""
"It is normally a good idea to mount it as it will allow operations such as "
"reinstalling the boot loader. However, if the file system on ${FILESYSTEM} "
"is corrupt then you may want to avoid mounting it."
msgstr ""
"Det er normalt en god ide at montere den, da det vil tillade handlinger "
"såsom geninstallation af opstartsindlæseren. Hvis filsystemet på ${FILESYSTEM} 
er "
"korrept så vil du dog nok ønske at undgå montering af denne."

It should be

#. Type: boolean
#. Description
#. :sl2:
#: ../rescue-mode.templates:21001
#| msgid "It is normally a good idea to mount it as it will allow operations 
such "
#| "as reinstalling the boot loader. However, if the file system on 
${FILESYSTEM} is "
#| "corrupt then you may want to avoid mounting it."
msgid ""
"It is normally a good idea to mount it as it will allow operations such as "
"reinstalling the boot loader. However, if the file system on ${FILESYSTEM} "
"is corrupt then you may want to avoid mounting it."
msgstr ""
"Det er normalt en god ide at montere den, da det vil tillade handlinger "
"såsom geninstallation af opstartsindlæseren. Hvis filsystemet på ${FILESYSTEM} 
er "
"korrept så vil du dog nok ønske at undgå montering af denne."

(notice the line after "../rescue-mode.templates:21001")

In short, Steve's attempt to fix the translation broke the PO file.

And, later on, l10n-sync choke on this.

And thus, the fix is to make l10n-sync more resilient to this and for
instance have it to test the validity of "master" PO files before
working with them.

More later



signature.asc
Description: PGP signature

Bug#830308: d-i.debian.org: l10n-sync script breaks headers in individual package files in some situations

[Christian Perrier]

Package: d-i.debian.org
Severity: normal
Tags: l10n

It turns out that, as things are right now, the l10n-sync scripts
appears to break PO files headers in Danish and Belarusian
translations of many packages, if not all of them.

That can be seen for instance in arcboot-installer. See the following
"git log" output:

commit 6e8d75e50bc237758c3c112a23c83f02d949c019
Author: D-I role <debian-b...@lists.debian.org>
Date:   Thu Jul 7 22:24:03 2016 +

[l10n]  Commit changed/added files

commit cf342c5cbdbb395903bcbcf52a5b5603cd48b5a2
Author: Christian Perrier <bubu...@debian.org>
Date:   Thu Jul 7 06:52:04 2016 +0200

Revert "[l10n]  Commit changed/added files"

This reverts commit d723909ca66e3438f92c478d2097d1caf5b28673.

commit ce0fc132232d436288438e778ef051fddff9478d
Author: Christian Perrier <bubu...@debian.org>
Date:   Thu Jul 7 06:51:41 2016 +0200

Revert "[l10n]  Commit changed/added files"

This reverts commit 2fd6349f7ea98ac1885b3b2263b85352e9e93ce9.

commit 2fd6349f7ea98ac1885b3b2263b85352e9e93ce9
Author: D-I role <debian-b...@lists.debian.org>
Date:   Mon Jul 4 22:24:33 2016 +

[l10n]  Commit changed/added files

commit d723909ca66e3438f92c478d2097d1caf5b28673
Author: D-I role <debian-b...@lists.debian.org>
Date:   Sun Jul 3 22:25:20 2016 +

[l10n]  Commit changed/added files

Before d723909ca66e3438f92c478d2097d1caf5b28673, the da.po headers are like 
this:
"PO-Revision-Date: 2010-08-05 10:48+0200\n"
"Last-Translator: Jacob Sparre Andersen <ja...@jacob-sparre.dk>\n"
"Language-Team: Danish <debian-l10n-dan...@lists.debian.org>\n"
"Language: da\n"

After d723909ca66e3438f92c478d2097d1caf5b28673, headers vanish:
# THIS FILE IS GENERATED AUTOMATICALLY FROM THE D-I PO MASTER FILES
# The master files can be found under packages/po/
#
# DO NOT MODIFY THIS FILE DIRECTLY: SUCH CHANGES WILL BE LOST
#
#. Type: text
#. Description
#. :sl4:
#: ../arcboot-installer.templates:1001
msgid "Install the Arcboot boot loader on a hard disk"
msgstr ""

After 2fd6349f7ea98ac1885b3b2263b85352e9e93ce9, headers re-appear, but
with:
"PO-Revision-Date: \n"
"Last-Translator: \n"
"Language-Team: <da...@dansk-gruppen.dk>\n"
"Language: da\n"


If thos two commits are reverted, which I did in
cf342c5cbdbb395903bcbcf52a5b5603cd48b5a2, they are sadly re-broken in
the next l10n-sync run.

I have not yet investigated whether changes to
packages/po/sublevel*/da.po (and be.po) triggerred this in some way.

As suggested by KiBi, I first report this as an attempt to make l10n
scripts more resilient.




-- System Information:
Debian Release: 8.5
  APT prefers stable
  APT policy: (500, 'stable'), (500, 'oldstable')
Architecture: i386 (i686)

Kernel: Linux 3.16.0-4-686-pae (SMP w/1 CPU core)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Bug#828624: [Pkg-samba-maint] Bug#828624: samba: Service fails to install and start

[Christian PERRIER]

Quoting Marc J. Driftmeyer (m...@reanimality.com):

> Gotta love when testing isn't thorough.


What exactly was your intention when adding this information to this
already reported bug?




signature.asc
Description: PGP signature

Bug#827562: [Pkg-xfce-devel] Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Christian PERRIER]

tags 827562 wontfix
thanks

Quoting Yves-Alexis Perez (cor...@debian.org):

> > >   I suggest that task-xfce-desktop reduce the dependency on
> > > light-locker from Depends to Recommends.
> 
> task-xfce-desktop is for installation time, so here Depends is correct. We
> want light-locker by default, but people are free to remove it afterwards if
> they know what they do.


...which means we should mark this bug as "wontfix" (or close it,
whatever solution is preferred). Thanks for your
input. That makes things clear.




signature.asc
Description: PGP signature

Bug#827562: task-xfce-desktop: Depends on light-locker Should Be Recommends

[Christian PERRIER]

Xfce people, could you please bring some input on that issue?

TIA

Quoting Leo L. Schwab (ew...@ewhac.org):
> Package: task-xfce-desktop
> Version: 3.35
> Severity: normal
> 
> Dear Maintainer,
> 
>   task-xfce-desktop has grown a dependency on the package
> light-locker, which is billed as a lightweight alternative to xscreensaver.
> I suspect this is to track a similar change in xfce4-session, which recently
> also added a dependency for light-locker.
> 
>   However, xfce4-session only Recommends light-locker; it does not
> Depends on it.  light-locker at the moment doesn't seem to play well with
> xscreensaver, and is something of a nuisance.  For those of us who prefer
> xscreensaver, light-locker gets in the way.
> 
>   I suggest that task-xfce-desktop reduce the dependency on
> light-locker from Depends to Recommends.
> 
>   Schwab
> 
> 
> -- System Information:
> Debian Release: stretch/sid
>   APT prefers unstable
>   APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable')
> Architecture: amd64 (x86_64)
> 
> Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores)
> Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
> 
> Versions of packages task-xfce-desktop depends on:
> ii  lightdm   1.18.1-1
> ii  task-desktop  3.35
> ii  tasksel   3.35
> ii  xfce4 4.12.3
> 
> Versions of packages task-xfce-desktop recommends:
> ii  dbus-x111.10.8-1
> ii  evince  3.20.0-4
> ii  evince-gtk  3.20.0-4
> ii  gnome-orca  3.20.2-1
> ii  hunspell-en-us  20070829-6
> ii  hyphen-en-us2.8.8-3
> pn  iceweasel   
> ii  libreoffice 1:5.1.3-2
> ii  libreoffice-gtk 1:5.1.3-2
> ii  libreoffice-help-en-us  1:5.1.3-2
> ii  mousepad0.4.0-4
> ii  mythes-en-us1:5.1.3-2
> ii  network-manager-gnome   1.2.2-2
> ii  orage   4.12.1-2
> ii  quodlibet   3.6.1-2
> ii  synaptic0.83+b1
> ii  system-config-printer   1.5.7-2
> ii  tango-icon-theme0.8.90-6
> ii  vlc 1:2.2.4-dmo1
> ii  xfce4-goodies   4.12.2
> pn  xfce4-mixer 
> ii  xfce4-power-manager 1.4.4-4
> ii  xfce4-terminal  0.6.3-2
> ii  xsane   0.999-3+b1
> 
> task-xfce-desktop suggests no packages.
> 
> -- no debconf information
> 

-- 




signature.asc
Description: PGP signature

Bug#827254: task-french-desktop: Please switch from iceweasel-l10n-fr to firefox-esr-l10n-fr | firefox-l10n-fr

[Christian PERRIER]

Quoting Laurent Bigonville (bi...@debian.org):

> What about this?

\o/ tells me you're way more clevr in regexps than I am..:-)

Patch committed. Rolling out a new upload.

Thanks a lot for both reporting (which triggerred me to see that we
had pending changes in git and no upload since last November) and
providing a good patch.






signature.asc
Description: PGP signature

Bug#827254: task-french-desktop: Please switch from iceweasel-l10n-fr to firefox-esr-l10n-fr | firefox-l10n-fr

[Christian PERRIER]

Quoting Laurent Bigonville (bi...@debian.org):
> reassign 827254 src:tasksel
> retitle 827254 tasksel: Please switch from iceweasel-l10n-* to
> firefox-esr-l10n-* | firefox-l10n-*
> thanks
> 
> On Tue, 14 Jun 2016 10:46:22 +0200 Laurent Bigonville 
> wrote:
> 
> > Could you please change the dependencies from iceweasel-l10n-fr to
> > firefox-esr-l10n-fr | firefox-l10n-fr ?
> 
> Actually this needs to be done for all the desktop language packages.

This is partly pending in git: iceweasel has been replaced by
firefox-esr, there.

I'm not entirely convinced that it makes sense to  mention the
alternative, though (which makes a quite tedious change to 68
different tasks).




signature.asc
Description: PGP signature

Bug#827228: [Pkg-running-devel] Bug#827228: pytrainer: Add firefox-esr to the browser dependency list

[Christian PERRIER]

Quoting Cesare Leonardi (celeo...@gmail.com):
> Package: pytrainer
> Version: 1.10.2~git20160107-3
> Severity: normal
> 
> Currently firefox-esr has replaced iceweasel, that became a transitional
> package. But pytrainer depends on iceweasel or firefox or abrowser,
> preventing the iceweasel transitional package to be removed.
> 
> Please, add firefox-esr to the browser dependency list.

Upload is on its way. However, is there indeed a reason to *keep*
iceweasel in the dependency list?




signature.asc
Description: PGP signature

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Christian PERRIER]

Quoting Ole Streicher (oleb...@debian.org):

> The "standard" task is IMO one of the concepts in this step that
> actually *nobody* understands: I myself don't know what it means, and
> all the people I asked (when I presented the current scheme of
> installing the blends) have no idea what happens if they (de)select this.

Longstanding "issue". It installs packages of priority "standard", so
that brings us to the definition of these "standard" packages. IIRC
(but I even don't remember where it lies) I spent hours thinking about
the "right" way to translate the "standard" task name into French.

Anyway, the "standard" tasks I was talking about are the other tasks
in tasksel, not "standard" itself.


> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environmentsbecause, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment. So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> So, if the average user doesn't have a glue about a Desktop environment,
> why is it offered in the installation by default? You seem to contradict
> to your own arguments here.

Because there has always been a contradiction..:-)

In the past, precisely for these reasons, the D.E. tasks were not
presented to users. However, over time, we had more and more and more
requests to allow this and it finally got enabled, but nnot really
with great enthusiasm...:-). This is kinda acknowledging that, indeed,
Debian installations from scratch with user's manual interaction is
now more something that skilled users are doing (let's face reality :
is Debian really used and installed by unskilled users
nowadays...certainly not).

So, more or less, we currently already are in a kind of compromise
which will never satisfy everybody

About the name of the "Debian Blends" menu entry : I have no intent to
rename the project, but more to present users with a meaningful
choice. Holger's suggestion in this thread seems to be the way to go
--> keep "Debian Blends" but explain in a few words what it is.



signature.asc
Description: PGP signature

Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Christian Perrier]

(thanks for prodding me...you never know, indeed, though I still read 
-boot...;-) )



I have no idea whether the following is practical, and/or makes sense
regarding d-i's logic, etc., but I'm wondering whether it would be
possible to have checking "Debian Pure Blends" activate a follow-up
screen which would list all Blends. This way, we would get the previous
tasksel screen back, and only present the Blends to users who're
actually asking for it. And that, without changing anything in debconf,
its (non-)support for structure prompts, etc. Merging two tasks lists
obtained in two stages shouldn't be too hard, I suppose. But does that
make sense?

Again, Christian is more knowledgeable in this area, and might have more
insight.


I tried to read the whole thread and then I'll summarize my thoughts.

At first, I'm not happy with the idea of Pure Blends tasks mixing up 
with standard tasks. I fully respect the work done by the variou sblends 
teams, but having our usual longstanding "standard" tasks kinda lost in 
the middle of "strange" and obscure tasks which the average user has no 
idea about what they're about...is a no-no for me.


I still remember Joey's objections about *not* having users forced to 
choose between desktop environmentsbecause, contrary to what the 
average geek thinks, most people have no idea about what is a desktop 
environment. So, just imagine if we present them with "Hamradio", 
"NeuroDebian", "Debian Med" and such a list of unsorted strange things.


Not to mention that most of these tasks titles wouldn't be translated, 
while other tasks are.


So, yes, I'd object strongly to mixing up Blends tasks with other tasks.

I think that the idea of blends choice in the boot menu has already 
ruled out for several reasons, so I won't develop here, but just add one 
more reason : this is untranslatable.


That leaves us with the idea of a "Debian Blends" choice in the standard 
task menu, which would lead to a dedicated "blends" menu. I think this 
is the best compromise to do, provided we find a good name for the menu 
entry : "Debian Blends" or "Debian pure Blends" is a great name for the 
project in its entirety...but probably not for the menu entry. Again, 
because it means nothing to Joe User.


So, with something like "Special-purpose packages" or "Specialized 
installations" or whatever along those lines, *then* a menu with the 
Blends list (unsorted) and the possibility of going back just in case 
people see the list and think "heck, I have no idea about what this 
stuff is about"then I'd say this is the way to go.

Bug#823996: partconf: hang when formatting a partition containing 'dos extended' partition table

[Christian PERRIER]

reassign 823996 partman-ext3
fixed 823996 86
thanks

Quoting Daniel R. Warner (drwar...@lakeheadu.ca):
> Package: partconf
> Version: 1.47
> Severity: normal
> 
> Dear Maintainer,
> 
> When installing into a partition previously containing a 'dos extended' 
> partition table, even if the partition was deleted and recreated, mkfs.ext4 
> (and likely other mkfs.[filesystem] utilities do not proceed, instead d-i 
> effectively freezes.
> This is because mkfs is asking for confirmation to create a new FS over top 
> of partition structure.
> 
> Can be solved by manually creating fs and rerunning d-i.
> Could also be solved by partconf 0'ing out the first few sectors of an 
> extended partition when it is deleted.
> 
> This was tested and reproduced using the jessie 8.4 netinst image.


This is solved by mkfs -F in partman-ext3. See #767682



signature.asc
Description: PGP signature

Bug#823599: task-polish-desktop: Please add firefox-l10n-pl to package recommendations

[Christian PERRIER]

Quoting Christian PERRIER (bubu...@debian.org):

> Isn't this a more general issue with iceweasel|firefox in desktop
> tasks ?
> 
> To Mozilla package maintainers, since the change from iceweasel to
> firefox, isn't there something we should change in tasksel tasks?
> 
> (please keep all addresses CC'ed when answering, except /me as I'm
> subscribed to tasksel bugs)
> 

OK...#823605, which I didn't originally noticed;..:-)




-- 




signature.asc
Description: PGP signature

Bug#823599: task-polish-desktop: Please add firefox-l10n-pl to package recommendations

[Christian PERRIER]

Quoting Gsc (gscs...@gmail.com):
> Package: task-polish-desktop
> Version: 3.34
> Severity: wishlist
> Tags: l10n
> 
> Dear Maintainer,
> 
> task-polish-desktop recommends iceweasel-l10n-pl, which depends on
> firefox-esr-l10n-pl. So if one wanted to install non-esr firefox (and
> firefox-l10n-pl), while installing also task-polish-desktop, he may end up
> having both firefox and firefox-esr installed.
> 
> Is it possible to modify task-polish-desktop dependencies so that it will
> recommend either firefox-l10n-pl or firefox-esr-l10n-pl?


Isn't this a more general issue with iceweasel|firefox in desktop
tasks ?

To Mozilla package maintainers, since the change from iceweasel to
firefox, isn't there something we should change in tasksel tasks?

(please keep all addresses CC'ed when answering, except /me as I'm
subscribed to tasksel bugs)



signature.asc
Description: PGP signature

Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138)

[Christian PERRIER]

Quoting Felipe Sateler (fsate...@debian.org):
> I have uploaded a new version. I have not yet, however, secured commit
> rights to d-i git repository. If you want to pull the changes before I
> get the access, you can pull the signed tag from my fork:
> 
> git pull https://anonscm.debian.org/git/users/fsateler/console-setup.git
> debian/1.141


I just added you to committers : I didn't notice this discussion when
it happened and went on a problem when trying to upload a new version
of the package --> my new version was 1.141 as it was built from git,
and of course it was REJECTed as it conclicted with your upload.

Would you mind pushing your changes to the D-I git? I'm more confident
in you doing so than me merging from your git repo as my git skills
are.let's say incomplete..:-)




signature.asc
Description: PGP signature

Bug#816314: [Pkg-running-devel] Bug#816314: Fix patch v2 for libusb1.0 update.

[Christian PERRIER]

Quoting Fenix (fenix...@gmail.com):
> 
> Hi.
> 
> I attach the previous patch cleaned of unfunctional cosmetic changes.
> 
> As I said in my previous message, I maintain the complex anidation of
> the original conditional structure. It is ugly, but it works. Anyway, if you
> think it should be refactor, we can make it a bit more readable.
> 
>So, I'm keeping from previuos patch (libusb1.0_fix.patch):
> 
>1) The elimination of a duplicate mark of block {} in the main for (this
> is cosmetic but is really ugly keep it. :))
> 
>2) The changes for the else block in the conditional blocks (Functional
> change).
> 
>3) The changes that pass the new (for libusb1.0) endpoints directions of
> the device (functional change). In this, I change too the printed messages
> for a better understanding for verbose purpose (cosmetic but I think it's
> neccesary for good verbosity).
> 
> 
> 
>If you have any question or suggestion, please, feel free to ask.
> 
>As I said in my last message, could be a good idea that the original
> patcher of the port to libusb1.0 checks this patch. I suppose he is
> experience with libusb, and I could overlook something related with.


I just uploaded -10 yesterday.

Please let me know if it works OK now.




signature.asc
Description: PGP signature

Bug#821424: pulseaudio: Do not put normal users on group audio

[Christian PERRIER]

Quoting Ben Hutchings (b...@decadent.org.uk):

> I don't know where you get this 'all possible use cases of the
> installer' from.  Adding the first user to device access groups only

.../...

Something like "not default installs" or "non default desktop
environments". Indeed, I have no precise idea, just somerthing along
"what would be the consequences of dropping these 'default groups' in
non default installs".

I'm all in for simplifying things and it"s very likely possible that
these things are just remains of the past, just as you own tests seem
to show.

> I've done a quick test of removing myself from the device access groups
> on a current GNOME desktop, with these results:
> 
> - audio:      redundant, I'm on the ACL for /dev/snd/*
> - cdrom:      redundant, I'm on the ACL for /dev/sr0
> - floppy:     unknown, but expect this to work like cdrom
> - video:      redundant, I'm on the ACL for /dev/video0
> - plugdev:    redundant, I'm on the ACL for /dev/bus/usb/002/006
> - netdev:     redundant, I'm on the ACL for /dev/rfkill
> - scanner:    redundant, I'm on the ACL for /dev/sg2
> - bluetooth:  unknown, seems broken whether or not I'm a member of the group
> 
> The other groups (dip, debian-tor, lpadmin, sudo) make more sense,
> though CUPS should probably be changed to treat sudo like lpadmin.


So, well, are there any objections to us dropping all the above
groups from the list of groups the first created user is added to?



signature.asc
Description: PGP signature

Bug#821424: pulseaudio: Do not put normal users on group audio

[Christian PERRIER]

Quoting asu (a...@marian1000.go.ro):
> Just simple scenario i add asterisk user on group audio and asu user on
> group audio result is bad
>  here is result of lsoff:
> root@marian1000:/home/asu# lsof /dev/snd/*
> COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
> pulseaudi 961 asterisk  memCHR  116,4  9689 /dev/snd/pcmC0D0c
> pulseaudi 961 asterisk  memCHR  116,3  9688 /dev/snd/pcmC0D0p
> pulseaudi 961 asterisk   15u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   20u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   21u   CHR  116,3  0t0 9688 /dev/snd/pcmC0D0p
> pulseaudi 961 asterisk   22u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   27u   CHR  116,2  0t0 9684 /dev/snd/controlC0
> pulseaudi 961 asterisk   32u   CHR  116,4  0t0 9689 /dev/snd/pcmC0D0c
> 
> On my user asu pulseaudio have acces only on Dummy card .
> Second on my audio application audacious  set to use  output to alsa
> (assumed that pulseaudio is down)
> same issue audacious take control of audio device and is no room for
> pulseaudio.
> 

So, what I understand is that this "audacious" thing shoulnd't take
control of the audio device, which it does because your user is member
of the audio group.

But, then, why launching audocious, then? That may sound like a silly
question, but, to my understanding, this is where the problem lies, am
I wrong?

-- 




signature.asc
Description: PGP signature

Bug#821424: pulseaudio: Do not put normal users on group audio

[Christian PERRIER]

Control: reassign -1 user-setup

Quoting Felipe Sateler (fsate...@debian.org):
> Control: reassign -1 debian-installer
> 
> On 18 April 2016 at 13:06, Corcodel Marian  wrote:
> 
> > Any way pulseaudio is default sound server on debian and suggest to do not 
> > put
> > users on audio group because cross interference with alsa programs, now 
> > alsa is
> > for power users and pulseaudio is on default.
> 
> Pulseaudio does not add the user to the audio group. I'm guessing the
> installer does, so I reassign there.


Adding the *first created* user to so-called "useful" groups is done
by user-setup.

We'll need a detaailed explanantion abou twhy this shouldn't be done
anymore, including all possible use cases of the installer.




signature.asc
Description: PGP signature

Bug#821173: s390-zfcp: [INTL:de] Initial German debconf translation

[Christian PERRIER]

Quoting Holger Wansing (li...@wansing-online.de):
> Hi,
> 
> Chris Leick  wrote:
> > Package: s390-zfcp
> > version: 1.0.1
> > Tags: l10n, patch
> > Severity: wishlist
> > 
> > 
> > Hi,
> > 
> > please find attached the german debconf translation of s390-zfcp.
> 
> Hmm, there was a decision to mark that strings in s390-zfcp as 
> not-translatable, right? 
> See https://lists.debian.org/debian-boot/2016/02/msg00259.html
> and follow-ups.
> So, why is there a corresponding pot-file listed at
> https://www.debian.org/international/l10n/po-debconf/pot#s390-zfcp ?
> 
> There are already 2 bugreports with translations for that package strings:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=817206
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=821173
> Wasted time of translators...

Because the debian/po directory hasn't been removed.

I just committed the needed changes to git and I'll try to reupload
the package with them, closing the translation bugs.




signature.asc
Description: PGP signature

Bug#816314: [Pkg-running-devel] Bug#816314: Fix patch for libusb1.0 update.

[Christian PERRIER]

Quoting Fenix (fenix...@gmail.com):
> 
> Hi.
> 
> 
> I have fixed this. There were two problems in usb_comm.c when the update
> to libusb1.0:
> 
> 
>   1) It seems libusb1.0 changes the addres of the endpoint to talk to. The
> code made a bit operation that makes the device unachievable.
> 
>   2) There were core code of libusb that only was execute with the -v
> (verbose) option, because an incorrect conditional anidation.
> 
> 
>The patch I attach fix the two problems and works for me (now with
> libusb1.0 :P). I have tested garmin_get_info, garmin_save_runs and
> garmin_gpx. If you need more information about this fix, please, feel free
> to ask.

It builds fine.

Still, there are a few chunks in the patch that look like noise to me.

For instance:

> diff --git a/src/usb_comm.c b/src/usb_comm.c
> index f00f6d9..9c5afa3 100644
> --- a/src/usb_comm.c
> +++ b/src/usb_comm.c
> @@ -72,9 +72,8 @@ garmin_open ( garmin_unit * garmin )
>}
>  }
>  cnt = libusb_get_device_list(ctx,);
> -
> +
.../...


> @@ -97,22 +96,28 @@ garmin_open ( garmin_unit * garmin )
> if ( err ) {
>   printf("libusb_open failed: %s\n",libusb_error_name(err));
>  garmin->usb.handle = NULL;
> -   } else if ( garmin->verbose != 0 ) {
> - printf("[garmin] libusb_open = %p\n",garmin->usb.handle);
> +   } else {
> +   if ( garmin->verbose != 0 ) {
> +printf("[garmin] libusb_open = %p\n",garmin->usb.handle);
> +   }

I'm not really skilled in C, but isn't that just cosmetic?

>  
> -err = libusb_set_configuration(garmin->usb.handle,1);
> +  err = libusb_set_configuration(garmin->usb.handle,1);

Ditto

>  if ( err ) {
> -  printf("libusb_set_configuration failed: %s\n",
> +printf("libusb_set_configuration failed: %s\n",

Ditto

And so on

I'd be happy to apply the patch, of course, but do you think that it
can be "cleaned"?

I can try to do it myself but..I'm a bit afraid to break things
doing so.




signature.asc
Description: PGP signature

Bug#816314: [Pkg-running-devel] Bug#816314: Bug#816314: fixed in garmin-forerunner-tools 0.10repacked-9

[Christian PERRIER]

Quoting Fenix (fenix...@gmail.com):
> Oooops.
> 
> I think that I know what happens. I just did clone [
> git://git.debian.org/git/pkg-running/garmin-forerunner-tools.git ] thinking
> that the master branch was updated until the last repackage.
> 
> I just see that the patches is inside de Debian/patches and not applied to
> the source code.
> 
> 
> So, was me who was seeing a non updated code. I'm sorry. I didn't know the
> Debian workflow.
> 
> 
> I'm going to update the code with the patches, and try to say something.

Well, the "816314_fix.patch" *is* in master.

The patch is in debian/patches *and* listed in debian/patches/series,
so as far as I can tell, it is applied at build time and thus is
ending in the built binaries.

Still the debian/0.10repacked-9 tag didn't end up on Alioth because of
an omission of mine on my local copy. This is now fixed.



signature.asc
Description: PGP signature

Bug#820598: [Pkg-fonts-devel] Bug#820598: fontforge: undefined symbol: png_longjmp

[Christian PERRIER]

Quoting James Cowgill (jcowg...@debian.org):
> Control: reassign 820800 fontforge
> Control: forcemerge -1 820800
> Control: retitle -1 fontforge: undefined symbol: png_longjmp
> Control: tags -1 patch pending
> 
> Hi,
> 
> This bug seems to be caused by incorrect detection of libpng16 in the
> configure script. There is special handling for version 16 in the
> detection code, but not in the part which adds the linker flags.
> Removing the special code for libpng16 fixes the issue (and falls back
> to -lpng which should work anyway).
> 
> I think that the crashes due to this bug are no longer happening due to
> transitive dependencies on libpng16, but I have prepared an NMU with
> the patch anyway since relying on these is horrible (and violates
> policy).
> 
> I've uploaded the attached NMU to DELAYED/5. Please tell me if you want
> me to cancel it.


Thanks for this. Don't cancel your NMU, thanks *a lot* for it. Sadly,
the fonts team is still stuck in licensing problems (as far as I can
follow) to upload a new version of fontforge in the archive and I
suspect that dealing with this issue would not have been a big
priority. So, your NMU is very much welcomed and appreciated.

Thanks also, for the proper bug handling and merging. I tried to do
this, but failed because I did things too hastily.




signature.asc
Description: PGP signature

Bug#816314: [Pkg-running-devel] Bug#816314: fixed in garmin-forerunner-tools 0.10repacked-9

[Christian PERRIER]

Quoting Chris AtLee (ch...@atlee.ca):
> I'm still getting a segfault in the latest version. Here's the traceback:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x77bba378 in garmin_open (garmin=garmin@entry=0x7fffe350) at
> usb_comm.c:137
> 137 usb_comm.c: No such file or directory.
> (gdb) where
> #0  0x77bba378 in garmin_open (garmin=garmin@entry=0x7fffe350)
> at usb_comm.c:137
> #1  0x77bc3180 in garmin_init (garmin=garmin@entry=0x7fffe350,
> verbose=) at protocol.c:1186
> #2  0x00400725 in main (argc=, argv=)
> at garmin_save_runs.c:36


We may need to check this with Fenix, who provided the patch I
used. Sadly, I'm not in position to test myself



signature.asc
Description: PGP signature

Bug#820483: accommodate rename of btrfs-tools to btrfs-progs

[Christian PERRIER]

Quoting Nicholas D Steeves (nstee...@gmail.com):
> Package: partman-btrfs
> Version: 20
> 
> I am working on problems associated with bug #780081, where it was
> planned to have a fix staged in experimental after Jessie was
> released.


Changes seem to be OK, but I guess that we can't upload before the
btrfs-tools package hasn't been renamed, isn't it?

From what I see, we need both btrfs-progs and the udeb in the archive
before partman-btrfs is uploaded, or it will:
- FTBFS
- fail when running

I'm not sure if an upload to experimental is really useful, as the
installer and its components doesn't make good use of experimental.

I'd say "go ahead for the package rename and we'll apply the changes
to partman-btrfs as soon as btrfs-progs is in unstable". Other
advices?




signature.asc
Description: PGP signature

Bug#820399: [Pkg-samba-maint] Bug#820399: How will Jessie get the important upstream security fix for Samba (smb/cifs) badlock (details embargod until April 12, 2016)?

[Christian PERRIER]

Quoting Michael Evans (michael.ev...@nor-consult.com):

> The severity and impact of not releasing an updated upstream version is
> unknown, and I am quite worried that there isn't a backports version of the
> Samba packages to use a version that should (easily) have the security patch
> included.

Work is in progress for this, thanks for your concern.




signature.asc
Description: PGP signature

Bug#816314: [Pkg-running-devel] Bug#816314: Fix patch for 816314.

[Christian PERRIER]

Quoting Fenix (fenix...@gmail.com):
> 
> Dear maintainer:
> 
> As the new version didn't fix this bug, I looked to the code and I find the
> problem (at least for me, but I really don't know how this error has been
> hidden just now. Maybe the old libusb masked the error in the code?).
> 
> The problem is in protocol.c

.../...

Thanks a lot. Not owning a Forerunner anymore, I'm indeed in the blind
to test the package, so I couldn't do much for this bug.

So, your help is highly appreciated. I'm in the process of
test-building the package and will upload it ASAP (from what I
understand, it won't be worse than the current version of the package
anyway.

BTW, the bug was indeed release critical, I should have raised its
severity to serious



signature.asc
Description: PGP signature

Bug#819998: [Pkg-running-devel] Bug#819998: garmin-forerunner-tools: FTBFS on !linux after switch to libusb 1.0

[Christian PERRIER]

Quoting Andreas Beckmann (a...@debian.org):
> Source: garmin-forerunner-tools
> Version: 0.10repacked-8
> Severity: important
> 
> Hi,
> 
> the non-linux architectures have a different implementation for libusb,
> available from different packages. The recent switch to libusb 1.0
> caused a FTBFS since there is no libusb-1.0-0-dev.


Doh. I blindly followed instructions from the bug reporter for this
change.

I suppose that this probably affects several packages and not this
one, only. If so, are there guidelines somewhere about Doing The Right
Thing?




signature.asc
Description: PGP signature

Bug#819949: tzdata: [INTL:fr] French debconf templates translation update

[Christian Perrier]

Package: tzdata
Version: N/A
Severity: wishlist
Tags: patch l10n

Please find attached the french debconf templates update, proofread by the
debian-l10n-french mailing list contributors.



-- System Information:
Debian Release: stretch/sid
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.4.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
# Translation of tzdata debconf templates to French
# Copyright (C) 2008 Christian Perrier <bubu...@debian.org>
# This file is distributed under the same license as the tzdata package.
#
# Several translations merged with translations from debian-installer's tzsetup package
#
# Christian Perrier <bubu...@debian.org>, 2002-2004.
# Pierre Machard <pmach...@debian.org>, 2002-2004.
# Denis Barbier <barb...@debian.org>, 2002-2004.
# Philippe Batailler <philippe.batail...@free.fr>, 2002-2004.
# Michel Grentzinger <mic.gre...@online.fr>, 2003-2004.
# Christian Perrier <bubu...@debian.org>, 2005, 2006, 2007, 2008, 2011, 2013, 2016.
msgid ""
msgstr ""
"Project-Id-Version: \n"
"Report-Msgid-Bugs-To: tzd...@packages.debian.org\n"
"POT-Creation-Date: 2016-03-14 20:43+\n"
"PO-Revision-Date: 2016-04-04 09:30+0100\n"
"Last-Translator: Christian Perrier <bubu...@debian.org>\n"
"Language-Team: French <debian-l10n-fre...@lists.debian.org>\n"
"Language: fr\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Plural-Forms: nplurals=2; plural=n>1;\n"
"X-Generator: Lokalize 2.0\n"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Africa"
msgstr "Afrique"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "America"
msgstr "Amérique"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Antarctica"
msgstr "Antarctique"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Australia"
msgstr "Australie"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Arctic"
msgstr "Arctique"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Asia"
msgstr "Asie"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Atlantic"
msgstr "Atlantique"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Europe"
msgstr "Europe"

#. Type: select
#. Choices
#. Note to translators:
#. - "Etc" will present users with a list
#. of "GMT+xx" or "GMT-xx" timezones
#. - SystemV will give the choice between zone named as per SystemV conventions:
#. EST5, MST7, etc.
#: ../tzdata.templates:1001
msgid "Indian"
msgstr "Océan Indien"

#. Type: select
#. Choices
#

Bug#819271: [geneweb] Hard links to jquery_1_9_1_min.js and jquery_placeholder_min.js in templates should be modified

[Christian PERRIER]

Quoting Guillaume Brochu (guillaume.bro...@gmail.com):

> So, depending if geneweb is used as a genealogy web server or as a genealogy
> personal software (on the local machine), the solution to replace hard links
> is not the same.
> 
> If there is a way to fix this for both kind of users, it would be great,
> otherwise we will have to choose one of the two possible methods.

I have no idea about fixing this for both uses, but if we have to
choose, I'd go for the "web server" choice. I always designed the
package for usability as a web server service, including for the
localhost, indeed.




signature.asc
Description: PGP signature

Bug#814829: eviacam: General update after the debconf review process

[Christian PERRIER]

Dear Debian maintainer,

On Wednesday, February 17, 2016, I sent you a notification about the beginning 
of a review
action on debconf templates for eviacam.

Then, I sent you a bug report with rewritten templates and announcing
the beginning of the second phase of this action: call for translation
updates.

Translators have been working hard and here is now the result of their efforts.

Please consider using it EVEN if you committed files to your
development tree as long as they were reported.

The attached tarball contains:

- debian/changelog with the list of changes
- debian/control with rewrites of packages' descriptions
- debian/ with all the rewritten templates file(s)
- debian/po/*.po with all PO files (existing ones and new ones)

As said, please use *at least* the PO files as provided here,
preferrably over those sent by translators in their bug reports. All
of them have been checked and reformatted. In some cases, formatting
errors have been corrected.

The patch.rfr file contains a patch for the templates and control
file(s) alone.

Please note that this patch applies to the templates and control
file(s) of your package as of Wednesday, February 17, 2016. If your package was 
updated
in the meantime, I may have updated my reference copybut I also
may have missed that. This is indeed why I suggested you do not
modified such files while the review process was running,
remember..:-)

It is now safe to upload a new package version with these changes.

Please notify me of your intents with regards to this. 

There is of course no hurry to update your package but feel free to
contact me in case you would need sponsoring or any other action to
fix this.



-- 




patch.tar.gz
Description: application/gzip
--- eviacam.old/debian/templates2016-02-15 19:53:17.828347882 +0100
+++ eviacam/debian/templates2016-03-03 08:01:33.875381936 +0100
@@ -1,12 +1,20 @@
+# These templates have been reviewed by the debian-l10n-english
+# team
+#
+# If modifications/additions/rewording are needed, please ask
+# debian-l10n-engl...@lists.debian.org for advice.
+#
+# Even minor modifications require translation updates and such
+# changes should be coordinated with translators and reviewers.
+
 Template: eviacamloader/eviacamloader_setuid
 Type: boolean
 Default: false
-_Description: Should eviacamloader be installed 'setuid root'?
- In order to enable users of the group 'eviacam' to run eviacam in 
- high priority (which improves responsiveness), the eviacamloader 
- program can be installed with the set-user-ID bit set, so that it 
- will run with the permissions of the superuser.
+_Description: Should eviacamloader be installed "setuid root"?
+ Installing eviacamloader with the set-user-ID bit set enables all
+ users who have been added to the group "eviacam" to launch eviacam
+ with a modified scheduling priority for better responsiveness.
  .
- Such a setting requires that the sysadmin adds authorized users to the 
- 'eviacam' group and may have security implications in the case of 
+ Since this setting allows eviacamloader to be run with superuser
+ privileges, it may have security implications in the case of
  vulnerabilities in eviacamloader's code.
--- eviacam.old/debian/control  2016-02-15 19:53:17.828347882 +0100
+++ eviacam/debian/control  2016-03-01 19:20:15.480690879 +0100
@@ -19,8 +19,8 @@
 Architecture: any
 Depends: ${misc:Depends}, ${shlibs:Depends}, opencv-data
 Recommends: wx3.0-i18n
-Description: webcam based mouse emulator
+Description: camera based mouse emulator
  Enable Viacam (aka eViacam) is a mouse replacement program that moves
- the pointer as you move your head. It works on a standard computer
- equipped with a web camera. No additional hardware is required. Based
- on the award winning Facial Mouse software.
+ the pointer tracking the user's head movements. It works on a standard
+ computer equipped with a "webcam". No additional hardware is required.
+ Based on the award winning Facial Mouse.
--- eviacam.old/debian/changelog2016-02-15 19:53:17.828347882 +0100
+++ eviacam/debian/changelog2016-03-20 11:24:32.947383383 +0100
@@ -1,3 +1,21 @@
+eviacam (2.0.3-2) UNRELEASED; urgency=low
+
+  * Debconf templates and debian/control reviewed by the debian-l10n-
+english team as part of the Smith review project. Closes: #814829
+  * [Debconf translation updates]
+  * Russian (Yuri Kozlov).  Closes: #817013
+  * Japanese (Takuma Yamada).  Closes: #817861
+  * German (Chris Leick).  Closes: #818028
+  * Czech (Michal Simunek).  Closes: #818348
+  * Catalan; (Cesar Mauri).  Closes: #818613
+  * Spanish; (Cesar Mauri).  Closes: #818614
+  * Brazilian Portuguese (Adriano Rafael Gomes).  Closes: #818682
+  * Dutch; (Frans Spiesschaert).  Closes: #818690
+  * Portuguese (Américo Monteiro).  Closes: #818720
+  * French (Julien Patriarca).  Closes: #818283
+
+ -- Christian Perrier <bubu...@debian.org>  Tue, 16 Feb 2016 05:52:01 +0100
+