Bug#980039: More information, again....
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
>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
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
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
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
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 '>'
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"
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
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
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
Quoting Laura Arjona Reina (larj...@debian.org): > > > El 12 de abril de 2018 6:52:28 CEST, Christian PERRIER > 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 > >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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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?
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?
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
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
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
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
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
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
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 utilizador a usar com o servidor de autenticação." #. Type: password #. Descrip
Bug#875989: console-setup: generated cached_setup_keyboard.sh references /tmp/ file
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"
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
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?
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
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
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.
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
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.
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
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
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?
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?
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)
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
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
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
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
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
Quoting Cyril Brulebois (k...@debian.org): > Christian PERRIER (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
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
Quoting Cyril Brulebois (k...@debian.org): > Christian PERRIER (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
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
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 Date: Thu Jul 7 22:24:03 2016 + [l10n] Commit changed/added files commit cf342c5cbdbb395903bcbcf52a5b5603cd48b5a2 Author: Christian Perrier Date: Thu Jul 7 06:52:04 2016 +0200 Revert "[l10n] Commit changed/added files" This reverts commit d723909ca66e3438f92c478d2097d1caf5b28673. commit ce0fc132232d436288438e778ef051fddff9478d Author: Christian Perrier 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 Date: Mon Jul 4 22:24:33 2016 + [l10n] Commit changed/added files commit d723909ca66e3438f92c478d2097d1caf5b28673 Author: D-I role 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 \n" "Language-Team: Danish \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: \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
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
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
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
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
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
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
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
(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
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
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
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 (Bug#796603: fixed in console-setup 1.138)
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.
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
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
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
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
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.
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,&dl); > - > + .../... > @@ -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
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
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
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
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)?
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.
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
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
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 # 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 , 2002-2004. # Pierre Machard , 2002-2004. # Denis Barbier , 2002-2004. # Philippe Batailler , 2002-2004. # Michel Grentzinger , 2003-2004. # Christian Perrier , 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 \n" "Language-Team: French \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 #. 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. #. Type: se
Bug#819271: [geneweb] Hard links to jquery_1_9_1_min.js and jquery_placeholder_min.js in templates should be modified
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
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 Tu