Bug#980144: mailutils: movemail does not remove start mailbox when moving

[Florent Rougon]

Hello,

This appears to be a duplicate of #980042:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=980042

Regards

-- 
Florent

Bug#965193: policykit-1: fails to install: chown error on /usr/lib/policykit-1/polkit-agent-helper-1

[Florent Rougon]

Hello,

Same problem here, please provide a fix. Thanks.

-- 
Florent

Bug#873439: [pkg-fgfs-crew] Bug#873439: flightgear: CVE-2017-13709: Incorrect access control

[Florent Rougon]

Hi,

For stretch, the last two commits of upstream branch release/2016.4:

  https://sourceforge.net/p/flightgear/flightgear/ci/release/2016.4/~/tree/

should do the job (as already said in other mails, and ditto for
unstable with the release/2017.2 branch).

For jessie (it's also affected), I successfully built FG in a
jessie-amd64 pbuilder chroot with the attached source debdiff. You'll
certainly want to make the patch headers DEP-3-compliant and arrange
debian/changelog (at least the version number), but the C++ side should
be fine with these changes. I only tested the build in this old version:
no runtime test, but I don't expect any particular problem. :)

Regards

-- 
Florent
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog	2017-07-02 14:39:08.0 +0200
+++ flightgear-3.0.0/debian/changelog	2017-08-28 18:07:28.0 +0200
@@ -1,3 +1,13 @@
+flightgear (3.0.0-5+deb8u3+frougon0) jessie; urgency=high
+
+  * Add two patches for CVE-2017-13709:
+  - call-fgInitAllowedPaths-earlier-c7a2ae.patch (required by the next
+patch)
+  - CVE-2017-13709-FGLogger-2a5e3d.patch
+  * The patch headers are not in the Debian DEP-3 format, this needs fixing.
+
+ -- Florent Rougon <f.rou...@free.fr>  Mon, 28 Aug 2017 18:07:28 +0200
+
 flightgear (3.0.0-5+deb8u2) jessie; urgency=high
 
   * Add patch restrict-save-flightplan-secu-fix-faf872.patch: prevent
diff -Nru flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch
--- flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch	1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/call-fgInitAllowedPaths-earlier-c7a2ae.patch	2017-08-28 18:07:28.0 +0200
@@ -0,0 +1,55 @@
+Author: Florent Rougon <f.rou...@free.fr>
+
+Call fgInitAllowedPaths() earlier: after Options::processOptions()
+
+Call fgInitAllowedPaths() right after Options::processOptions() (which,
+among other things, determines $FG_ROOT and processes
+--allow-nasal-read). This way, fgInitAllowedPaths() can be used in much
+more code, such as when initializing subsystems.
+
+(cherry picked from commit c7a2aef59979af3e9ff22daabb37bdaadb91cd75)
+
+--- a/src/Main/fg_init.cxx
 b/src/Main/fg_init.cxx
+@@ -1023,7 +1023,12 @@
+ fgGetNode("/sim")->removeChild("aircraft-dir");
+ fgInitAircraft(true);
+ flightgear::Options::sharedInstance()->processOptions();
+-
++
++// Rebuild the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ render = new FGRenderer;
+ render->setEventHandler(eventHandler);
+ globals->set_renderer(render);
+--- a/src/Main/main.cxx
 b/src/Main/main.cxx
+@@ -461,7 +461,12 @@
+ } else if (configResult == flightgear::FG_OPTIONS_EXIT) {
+ return EXIT_SUCCESS;
+ }
+-
++
++// Set the lists of allowed paths for cases where a path comes from an
++// untrusted source, such as the global property tree (this uses $FG_HOME
++// and other paths set by Options::processOptions()).
++fgInitAllowedPaths();
++
+ // Initialize the Window/Graphics environment.
+ fgOSInit(, argv);
+ _bootstrap_OSInit++;
+--- a/src/Scripting/NasalSys.cxx
 b/src/Scripting/NasalSys.cxx
+@@ -800,9 +800,6 @@
+   .member("singleShot", ::isSingleShot, ::setSingleShot)
+   .member("isRunning", ::isRunning);
+ 
+-// Set allowed paths for Nasal I/O
+-fgInitAllowedPaths();
+-
+ // Now load the various source files in the Nasal directory
+ simgear::Dir nasalDir(SGPath(globals->get_fg_root(), "Nasal"));
+ loadScriptDirectory(nasalDir);
diff -Nru flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch
--- flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch	1970-01-01 01:00:00.0 +0100
+++ flightgear-3.0.0/debian/patches/CVE-2017-13709-FGLogger-2a5e3d.patch	2017-08-28 18:07:28.0 +0200
@@ -0,0 +1,69 @@
+Author: Florent Rougon <f.rou...@free.fr>
+
+Security: don't allow FGLogger to overwrite arbitrary files
+
+Since the paths of files written by FGLogger come from the property
+tree[1], they must be validated before we decide to write to these
+files.
+
+[1] Except for the "empty" case, which uses the default name
+'fg_log.csv'.
+
+This fixes CVE-2017-13709.
+
+(cherry picked from commit 2a5e3d06b2c0d9f831063afe7e7260bca456d679)
+
+--- a/src/Main/logger.cxx
 b/src/Main/logger.cxx
+@@ -11,10 +11,14 @@
+ 
+ #include 
+ #include 
++#include 
+ 
+ #include 
++#in

Bug#848114: flightgear: Allows the route manager to overwrite arbitrary files

[Florent Rougon]

Markus Wanner  wrote:

> Hello Florent,
>
> thanks a lot for your notification and the patch(es). Uploads to stable
> (security) and unstable should follow, shortly.

Fine, thank you, Markus!

Regards

-- 
Florent

Bug#848114: flightgear: Allows the route manager to overwrite arbitrary files

[Florent Rougon]

Source: flightgear
Version: 3.0.0-5
Severity: grave
Tags: security upstream fixed-upstream patch
Justification: user security hole

Hello,

As already stated in several places:

  
https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/
  https://sourceforge.net/p/flightgear/mailman/message/35548661/
  
http://lists.alioth.debian.org/pipermail/pkg-fgfs-crew/2016-December/001795.html

and reported to people in charge of FlightGear both upstream (of which I am a
recent addition) and in several Linux distributions, the flightgear package
has a security bug allowing malicious Nasal code[1] to overwrite arbitrary
files the user running FlightGear has write access to, by using the property
tree to cause the route manager to save a flightplan.

This problem is, AFAICT, present in all FlightGear versions released after
October 5, 2009, which largely includes those shipped in Debian stable,
testing and unstable. It is however fixed in the upstream Git repository:

  
https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/

and I have backported this fix to FlightGear 3.0.0, i.e., the version shipped
in jessie: cf. two links given above
(<https://sourceforge.net/p/flightgear/mailman/message/35548661/> and
<http://lists.alioth.debian.org/pipermail/pkg-fgfs-crew/2016-December/001795.html>),
the second one being more ready-to-use for Debian since it contains a debdiff
including an additional fix for build failures I encountered while testing the
fix in the jessie package.

Since all parties have already been contacted, this bug report is mainly for
tracking purposes, as advised by
<https://www.debian.org/security/faq#discover>.

I'm attaching here the patch for FlightGear 3.0.0 as well as the mentioned
debdiff for completeness and “self-containedness” of this report. The upstream
fix
(<https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/>)
can certainly be used as is for the version in unstable.

Regards

[1] Which can be embedded in aircraft, which can in their turn be installed by
users from various third-party sources.
Description: Security fix: don't allow the route manager to overwrite arbitrary files
 Since the Save function of the route manager can be triggered from Nasal with
 an arbitrary path, we must check the path before overwriting the file.
 .
 (also add a missing include that is directly needed for this commit)
Author: Florent Rougon <f.rou...@free.fr>
Origin: upstream, https://sourceforge.net/p/flightgear/flightgear/ci/280cd523686fbdb175d50417266d2487a8ce67d2/

--- a/src/Autopilot/route_mgr.cxx
+++ b/src/Autopilot/route_mgr.cxx
@@ -47,6 +47,7 @@
 #include 
 #include 
 
+#include 
 #include "Main/fg_props.hxx"
 #include "Navaids/positioned.hxx"
 #include 
@@ -55,6 +56,8 @@
 #include "Airports/runways.hxx"
 #include 
 #include 
+#include // fgValidatePath()
+#include 
 
 #define RM "/autopilot/route-manager/"
 
@@ -707,7 +710,23 @@ void FGRouteMgr::InputListener::valueChanged(SGPropertyNode *prop)
   mgr->loadRoute(path);
 } else if (!strcmp(s, "@SAVE")) {
   SGPath path(mgr->_pathNode->getStringValue());
-  mgr->saveRoute(path);
+  const std::string authorizedPath = fgValidatePath(path.str(),
+true /* write */);
+
+  if (!authorizedPath.empty()) {
+mgr->saveRoute(authorizedPath);
+  } else {
+const SGPath proposedPath = SGPath(globals->get_fg_home()) / "Export";
+std::string msg =
+  "The route manager was asked to write the flightplan to '" +
+  path.str() + "', but this path is not authorized for writing. " +
+  "Please choose another location, for instance in the $FG_HOME/Export "
+  "folder (" + proposedPath.str() + ").";
+
+SG_LOG(SG_AUTOPILOT, SG_ALERT, msg);
+modalMessageBox("FlightGear", "Unable to write to the specified file",
+msg);
+  }
 } else if (!strcmp(s, "@NEXT")) {
   mgr->jumpToIndex(mgr->currentIndex() + 1);
 } else if (!strcmp(s, "@PREVIOUS")) {
diff -Nru flightgear-3.0.0/debian/changelog flightgear-3.0.0/debian/changelog
--- flightgear-3.0.0/debian/changelog	2015-03-18 11:19:39.0 +0100
+++ flightgear-3.0.0/debian/changelog	2016-12-13 12:40:51.0 +0100
@@ -1,3 +1,13 @@
+flightgear (3.0.0-5+deb8u1) jessie; urgency=medium
+
+  * Add patch route-manager-secu-fix-280cd5.patch (security fix preventing
+the route manager from being able to overwrite arbitrary files
+writable by the user running FlightGear).
+  * Add patch fix-missing-lX11-in-link-commands.patch to fix an FTBFS
+failure due to -lX11 missing in two link commands.
+
+ -- Florent Ro

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Simple workaround for this bug:

  1) Create the venv with --without-pip. For instance:

   /usr/bin/python3.5 -m venv --without-pip 

  2) Download https://bootstrap.pypa.io/get-pip.py as ~/tmp/get-pip.py.

  3) Bootstrap pip "manually" in your venv:

   /bin/python ~/tmp/get-pip.py

HTH

-- 
Florent

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Some more info:

Inserting a 'print(cmd)' at line 259 showed that the direct cause of
the error message is the command:

  ['/home/flo/python-venv/testdir/bin/python3.5',
   '-Im', 'ensurepip', '--upgrade', '--default-pip']

exiting with a non-zero exit status. Running this command by hand after
the venv creation failed yields:

~/python-venv % /home/flo/python-venv/testdir/bin/python3.5 -Im ensurepip 
--upgrade --default-pip; echo $?
Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.5/ensurepip/__main__.py", line 4, in 
ensurepip._main()
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 218, in _main
version="pip {}".format(version()),
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 74, in version
assert len(wheel_names) == 1, wheel_names
AssertionError: []
1
~/python-venv %

The assertion error comes from this in
/usr/lib/python3.5/ensurepip/__init__.py:

wheel_names = glob.glob('/usr/share/python-wheels/pip-*.whl')
assert len(wheel_names) == 1, wheel_names

and indeed:

~/python-venv % ls /usr/share/python-wheels/pip-*.whl
zsh: no matches found: /usr/share/python-wheels/pip-*.whl
~/python-venv % apt-file search /usr/share/python-wheels/pip-
virtualenv: /usr/share/python-wheels/pip-8.0.2-py2.py3-none-any.whl
~/python-venv %

I then installed the 'virtualenv' package, which does provide the
mentioned file, and tried to recreate the venv from scratch after adding
a 'print(os.getcwd())' right after the previously-added 'print(cmd)' in
/usr/lib/python3.5/venv/__init__.py (lines 259-260, before the 'try'
statement in EnvBuilder._setup_pip()):

~/python-venv % rm -rf testdir
~/python-venv % /usr/bin/python3.5 -m venv testdir
['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 'ensurepip', 
'--upgrade', '--default-pip']
/home/flo/python-venv
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

~/python-venv % /usr/bin/python3.5 -c "import subprocess; 
subprocess.check_output(['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 
'ensurepip', '--upgrade', '--default-pip'])"
Traceback (most recent call last):
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
33, in vendored
ImportError: No module named 'pip._vendor.cachecontrol'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/lib/python3.5/runpy.py", line 184, in _run_module_as_main
"__main__", mod_spec)
  File "/usr/lib/python3.5/runpy.py", line 85, in _run_code
exec(code, run_globals)
  File "/usr/lib/python3.5/ensurepip/__main__.py", line 4, in 
ensurepip._main()
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 269, in _main
default_pip=args.default_pip,
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 175, in bootstrap
_run_pip(args + _PROJECTS, additional_paths)
  File "/usr/lib/python3.5/ensurepip/__init__.py", line 65, in _run_pip
import pip
  File "/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/__init__.py", line 
12, in 
  File "/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/exceptions.py", 
line 6, in 
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
52, in 
  File 
"/tmp/tmpicb907db/pip-8.0.2-py2.py3-none-any.whl/pip/_vendor/__init__.py", line 
35, in vendored
ImportError: No module named 'cachecontrol'
Traceback (most recent call last):
  File "", line 1, in 
  File "/usr/lib/python3.5/subprocess.py", line 626, in check_output
**kwargs).stdout
  File "/usr/lib/python3.5/subprocess.py", line 708, in run
output=stdout, stderr=stderr)
subprocess.CalledProcessError: Command 
'['/home/flo/python-venv/testdir/bin/python3.5', '-Im', 'ensurepip', 
'--upgrade', '--default-pip']' returned non-zero exit status 1
~/python-venv %

-- 
Florent

Bug#815864: python3-venv: unable to create a virtual environment

[Florent Rougon]

Package: python3-venv
Version: 3.5.1-2
Severity: serious
Justification: renders the package unusable

Hello,

It seems current Python 3 packages in Debian unstable don't allow
creating a virtual environment anymore with pyvenv and friends:

~/python-venv % /usr/bin/python3.5 -m venv testdir
The virtual environment was not created successfully because ensurepip is not
available.  On Debian/Ubuntu systems, you need to install the python3-venv
package using the following command.

apt-get install python3-venv

You may need to use sudo with that command.  After installing the python3-venv
package, recreate your virtual environment.

~/python-venv % dpkg -l python3-venv
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name   Version  Architecture Description
+++-==---=
ii  python3-venv   3.5.1-2  amd64pyvenv-3 binary for python3 (defa
~/python-venv %

Thanks in advance for looking into this.

Regards

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

Kernel: Linux 4.4.0-1-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages python3-venv depends on:
ii  python3 3.5.1-2
ii  python3.5-venv  3.5.1-7

python3-venv recommends no packages.

python3-venv suggests no packages.

-- no debconf information

Bug#811479: boot fails in "run-init -n ..."

[Florent Rougon]

Hello,

Same problem here after yesterday's upgrade. The 0.122~a.test
initramfs-tools and initramfs-tools-core packages mentioned by Ben at
 allowed my
system to boot, thank you!

(along with the Debian jessie installation DVD in rescue mode, its
option to automatically assemble RAID arrays, followed by mounting the
/, /usr and /var filesystems of my normal system at temporary mount
points, chrooting into the temporarily-mounted root before running dpkg
-i the_deb_files [maybe simply booting with the previous kernel to
install the test packages would have worked, too?..])

Regards

-- 
Florent

Bug#789922: kio-dev: uninstallable on current unstable

[Florent Rougon]

Hi Lisandro,

Lisandro Damián Nicanor Pérez Meyer perezme...@gmail.com wrote:

 Qt5 is currently going trough a transition, so this is just OK. You just
 need to wait until it's sorted out.

 Actually you will need to wait until the package gets pushed to unstable or 
 rebuilt in experimental. It should happen soon though.

OK, thank you for your quick answer. I will wait, then. :)

Regards

-- 
Florent


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#789922: kio-dev: uninstallable on current unstable

[Florent Rougon]

Package: kio-dev
Version: 5.9.0-1
Severity: serious
Justification: Policy 7.2

Hello,

Since yesterday's upgrade, kio-dev is not installable anymore on sid:

# aptitude install kio-dev
The following NEW packages will be installed:
  kio{a} (for kio-dev)  kio-dev  libdbusmenu-qt5-2{a} (for kio-dev)
  libkf5attica5{a} (for kio-dev)  libkf5auth-data{a} (for kio-dev)
  libkf5auth-dev{a} (for kio-dev)  libkf5auth5{a} (for kio-dev)
  libkf5bookmarks-data{a} (for kio-dev)
  libkf5bookmarks-dev{a} (for kio-dev)  libkf5bookmarks5{a} (for kio-dev)
  libkf5codecs-data{a} (for kio-dev)  libkf5codecs-dev{a} (for kio-dev)
  libkf5codecs5{a} (for kio-dev)  libkf5completion-data{a} (for kio-dev)
  libkf5completion-dev{a} (for kio-dev)
  libkf5completion5{ab} (for kio-dev)  libkf5config-bin{a} (for kio-dev)
  libkf5config-data{a} (for kio-dev)  libkf5config-dev{a} (for kio-dev)
  libkf5configcore5{a} (for kio-dev)  libkf5configgui5{a} (for kio-dev)
  libkf5configwidgets-data{a} (for kio-dev)
  libkf5configwidgets-dev{a} (for kio-dev)
  libkf5configwidgets5{a} (for kio-dev)
  libkf5coreaddons-data{a} (for kio-dev)
  libkf5coreaddons-dev{a} (for kio-dev)
  libkf5coreaddons5{a} (for kio-dev)  libkf5crash5{a} (for kio-dev)
  libkf5dbusaddons-bin{a} (for kio-dev)
  libkf5dbusaddons-data{a} (for kio-dev)
  libkf5dbusaddons-dev{a} (for kio-dev)
  libkf5dbusaddons5{a} (for kio-dev)
  libkf5globalaccel-bin{a} (for kio-dev)
  libkf5globalaccel-data{a} (for kio-dev)
  libkf5globalaccel-dev{a} (for kio-dev)
  libkf5globalaccel5{a} (for kio-dev)
  libkf5guiaddons-dev{a} (for kio-dev)  libkf5guiaddons5{a} (for kio-dev)
  libkf5i18n-data{a} (for kio-dev)  libkf5i18n-dev{a} (for kio-dev)
  libkf5i18n5{a} (for kio-dev)  libkf5iconthemes-bin{a} (for kio-dev)
  libkf5iconthemes-data{a} (for kio-dev)
  libkf5iconthemes-dev{a} (for kio-dev)
  libkf5iconthemes5{a} (for kio-dev)
  libkf5itemviews-data{a} (for kio-dev)
  libkf5itemviews-dev{a} (for kio-dev)  libkf5itemviews5{ab} (for kio-dev)
  libkf5jobwidgets-data{a} (for kio-dev)
  libkf5jobwidgets-dev{a} (for kio-dev)
  libkf5jobwidgets5{a} (for kio-dev)  libkf5kiocore5{a} (for kio-dev)
  libkf5kiofilewidgets5{ab} (for kio-dev)  libkf5kiontlm5{a} (for kio-dev)
  libkf5kiowidgets5{a} (for kio-dev)
  libkf5notifications-data{a} (for kio-dev)
  libkf5notifications5{a} (for kio-dev)
  libkf5service-bin{a} (for kio-dev)  libkf5service-data{a} (for kio-dev)
  libkf5service-dev{a} (for kio-dev)  libkf5service5{a} (for kio-dev)
  libkf5solid-dev{a} (for kio-dev)  libkf5solid5{a} (for kio-dev)
  libkf5solid5-data{a} (for kio-dev)  libkf5sonnet-dev{a} (for kio-dev)
  libkf5sonnet5-data{a} (for kio-dev)  libkf5sonnetcore5{a} (for kio-dev)
  libkf5sonnetui5{a} (for kio-dev)
  libkf5textwidgets-data{a} (for kio-dev)
  libkf5textwidgets-dev{a} (for kio-dev)
  libkf5textwidgets5{a} (for kio-dev)  libkf5wallet-bin{a} (for kio-dev)
  libkf5wallet-data{a} (for kio-dev)  libkf5wallet5{a} (for kio-dev)
  libkf5widgetsaddons-data{a} (for kio-dev)
  libkf5widgetsaddons-dev{a} (for kio-dev)
  libkf5widgetsaddons5{a} (for kio-dev)
  libkf5windowsystem-data{a} (for kio-dev)
  libkf5windowsystem-dev{a} (for kio-dev)
  libkf5windowsystem5{a} (for kio-dev)  libkf5xmlgui-bin{a} (for kio-dev)
  libkf5xmlgui-data{a} (for kio-dev)  libkf5xmlgui-dev{ab} (for kio-dev)
  libkf5xmlgui5{ab} (for kio-dev)  libkwalletbackend5-5{a} (for kio-dev)
  libphonon4qt5-4{a} (for kio-dev)  libpolkit-qt5-1-1{a} (for kio-dev)
  libqt5svg5{a} (for kio-dev)  sonnet-plugins{a} (for kio-dev)
0 packages upgraded, 89 newly installed, 0 to remove and 0 not upgraded.
Need to get 275 kB/11.8 MB of archives. After unpacking 72.1 MB will be used.
The following packages have unmet dependencies:
 libkf5completion5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5xmlgui-dev : Depends: libkf5attica-dev (= 5.9.0~) but it is not going 
to be installed.
 libkf5xmlgui5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5itemviews5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
 libkf5kiofilewidgets5 : Depends: qtbase-abi-5-3-2 which is a virtual package.
The following actions will resolve these dependencies:

  Keep the following packages at their current version:
1)  kio [Not Installed]
2)  kio-dev [Not Installed]
3)  libkf5bookmarks-dev [Not Installed]
4)  libkf5bookmarks5 [Not Installed]
5)  libkf5completion-dev [Not Installed]
6)  libkf5completion5 [Not Installed]
7)  libkf5iconthemes-bin [Not Installed]
8)  libkf5iconthemes-dev [Not Installed]
9)  libkf5iconthemes5 [Not Installed]
10) libkf5itemviews-dev [Not Installed]
11) libkf5itemviews5 [Not Installed]
12) libkf5kiofilewidgets5 [Not Installed]
13) libkf5kiowidgets5 [Not Installed]
14) libkf5notifications5 [Not Installed]
15) libkf5textwidgets-dev [Not Installed]
16) libkf5textwidgets5 [Not Installed]
17) libkf5wallet-bin [Not Installed]
18) libkf5wallet5 [Not Installed]
19) 

Bug#780716: [pkg-fgfs-crew] Bug#780716: flightgear-data: nasal scripts can ready any file

[Florent Rougon]

Hi again,

As far as I know, this bug is still present in 3.4.0+dfsg-0~exp1 (from
experimental). The fix you applied to unstable (commit
d8603af7f98a6394442818d823a79b680b1f9e8b) can be cherry-picked to
experimental with minor conflicts (d/changelog and d/patches/series). It
seems to work fine here. What do you think?

Regards

-- 
Florent


-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#775903: systemd: 'service initscript start' starts initscript.dpkg-dist under systemd

[Florent Rougon]

Package: systemd
Version: 215-9
Severity: serious
Tags: security

Dear maintainer,

I tried systemd after a wheezy → sid upgrade and encountered an annoying
problem: after modifying a file related to my /etc/init.d/fetchmail script[1],
I decided to start the fetchmail service with 'service fetchmail start'[2]. To
my great surprise, this did not start my /etc/init.d/fetchmail script but
/etc/init.d/fetchmail.dpkg-dist, i.e., the script I had explicitely told dpkg
to disable when doing the wheezy to sid upgrade.

  [1] Apparently run with 'set -e' under systemd, but that is another issue.

  [2] Being new to systemd, I didn't know the systemd idiom for this, but my
  reading of /usr/sbin/service leads me to think that 'systemctl start
  fetchmail.service' would have done exactly the same, hence the report to
  systemd as opposed to sysvinit-utils.

Apparently, systemd somehow kept thinking that the fetchmail service
corresponded to that .dpkg-dist script until I ran 'systemctl daemon-reload'.
This behavior has the adverse effect of running a service the administrator
explicitely disabled, or of running it with completely different options from
those he configured, etc. This is why I set the security tag on this bug.
Maybe the severity should be raised too.

Here is a transcript of the commands I ran to trigger and work around the bug:

# service fetchmail start
# systemctl status -l fetchmail
● fetchmail.dpkg-dist.service - LSB: init-Script for system wide fetchmail 
daemon
   Loaded: loaded (/etc/init.d/fetchmail.dpkg-dist)
   Active: active (exited) since Mon 2015-01-19 10:26:35 CET; 51min ago

Jan 19 10:26:35 zita fetchmail.dpkg-dist[3090]: Not starting fetchmail daemon, 
disabled via /etc/default/fetchmail.
Jan 19 10:26:35 zita systemd[1]: Started LSB: init-Script for system wide 
fetchmail daemon.
# find /etc/rc*.d /etc/init.d |grep fetchmail
/etc/rc0.d/K01fetchmail
/etc/rc1.d/K01fetchmail
/etc/rc2.d/S01local-rotate-fetchmail-logfiles
/etc/rc2.d/S04fetchmail
/etc/rc3.d/S01local-rotate-fetchmail-logfiles
/etc/rc3.d/S04fetchmail
/etc/rc4.d/S01local-rotate-fetchmail-logfiles
/etc/rc4.d/S04fetchmail
/etc/rc5.d/S01local-rotate-fetchmail-logfiles
/etc/rc5.d/S04fetchmail
/etc/rc6.d/K01fetchmail
/etc/init.d/fetchmail.dpkg-dist
/etc/init.d/fetchmail
/etc/init.d/local-rotate-fetchmail-logfiles
# mv fetchmail.dpkg-dist /root/tmp
# service fetchmail start
Warning: Unit file of fetchmail.service changed on disk, 'systemctl 
daemon-reload' recommended.
Job for fetchmail.dpkg-dist.service failed. See 'systemctl status 
fetchmail.dpkg-dist.service' and 'journalctl -xn' for details.
# systemctl status -l fetchmail
● fetchmail.dpkg-dist.service - LSB: init-Script for system wide fetchmail 
daemon
   Loaded: loaded (/etc/init.d/fetchmail.dpkg-dist)
   Active: failed (Result: exit-code) since Mon 2015-01-19 11:25:15 CET; 36s ago
  Process: 13937 ExecStart=/etc/init.d/fetchmail.dpkg-dist start (code=exited, 
status=203/EXEC)

Jan 19 11:25:15 zita systemd[1]: fetchmail.dpkg-dist.service: control process 
exited, code=exited status=203
Jan 19 11:25:15 zita systemd[1]: Failed to start LSB: init-Script for system 
wide fetchmail daemon.
Jan 19 11:25:15 zita systemd[1]: Unit fetchmail.dpkg-dist.service entered 
failed state.

Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended.
# systemctl daemon-reload
# service fetchmail start
# systemctl status -l fetchmail
● fetchmail.service - LSB: init script for per-user fetchmail daemons
   Loaded: loaded (/etc/init.d/fetchmail)
   Active: active (exited) since Mon 2015-01-19 11:26:28 CET; 6s ago
  Process: 13983 ExecStart=/etc/init.d/fetchmail start (code=exited, 
status=0/SUCCESS)

Jan 19 11:26:27 zita fetchmail[13983]: Starting mail retrieval agent: fetchmail.
Jan 19 11:26:28 zita fetchmail[13983]: Waiting for a Mail Transport Agent 
lising on the SMTP port...done.
Jan 19 11:26:28 zita su[13992]: Successful su for flo by root
Jan 19 11:26:28 zita su[13992]: + ??? root:flo
Jan 19 11:26:28 zita su[13992]: pam_unix(su:session): session opened for usero 
by (uid=0)
Jan 19 11:26:28 zita fetchmail[13983]: Starting fetchmail for user flo...done
Jan 19 11:26:28 zita systemd[1]: Started LSB: init script for per-user fetchm 
daemons.
#

Thanks for considering, have a nice day. :-)

(the 'Init: sysvinit (via /sbin/init)' bit below is misleading, I am running
systemd via the 'init' kernel command line parameter)


-- Package-specific info:

-- System Information:
Debian Release: 8.0
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages systemd depends on:
ii  acl 2.2.52-2
ii  adduser 3.113+nmu3
ii  initscripts 2.88dsf-58
ii  libacl1 2.2.52-2
ii  libaudit1   1:2.4-1+b1
ii  libblkid1   2.25.2-4.1

Bug#441526: lmodern: updmap-sys failed.

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 I agree that we shouldn't change dh_installtex's default.  Florent, will
 you have time to fix this?

Sorry, I don't feel well these days. Please do what you think should be
done.

-- 
Florent

Bug#400494: lirc: Fix for the build failure caused by the inclusion of linux/config.h is incomplete

[Florent Rougon]

Hi,

Loïc's upload of lirc 0.8.0-10 commented out the inclusion of
linux/config.h in drivers/lirc_dev/lirc_dev.c, but that was not enough
for me.

lirc-modules-source still failed to build because
drivers/lirc_serial/lirc_serial.c also wants to include that file.
Commenting out the relevant line in lirc_serial.c solved the problem.
The build now succeeds and the resulting module package works fine.

This is on etch with Linux 2.6.21 from bpo and lirc 0.8.0-12 backported
from unstable.

HTH,

-- 
Florent

Bug#436235: texlive-lang-ukenglish: postinst and uninstall fail: Package color Error: No driver specified.

[Florent Rougon]

Hi,

Johannes Rohr [EMAIL PROTECTED] wrote:

 I was apparantly hit by bug #425803

Can we (or you) close the bug, then?

Thanks.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431672: Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Hi,

Nice to see you back!

Frank Küster [EMAIL PROTECTED] wrote:

 I suggest we remove the wontfix tag and add a block on the dpkg bug
 requesting the trigger, what do you think?

Fine, feel free to do so.

Regards,

-- 
Florent

Bug#431672: Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Norbert Preining [EMAIL PROTECTED] wrote:

 retitle 400742 dh_installtex should check the existence for tex file
 tags 400742 - wontfix
 thanks

[...]

 Ok, I retitled the bug and removed the wontfix stuff. If I find time I
 will implement it.

*WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*

  If you check for the existence of TeX files in the package being built
  and don't run mktexlsr in case there is no TeX file, this is in
  general short-sighted and incorrect.

*WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*  *WARNING*

Reason: if there were TeX files in any previous version of the package
(up to the previous Debian release), then mktexlsr *has* to be run.

People always complain about cheap stuff being run unnecessarily, but
then they will also complain when hell breaks because the cheap stuff
was so wisely not run...

If there is nothing TeX-related in your package, don't run
dh_installtex...

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#431671: Bug#400742: Bug#431671: Bug#400742: Bug#431671: piuparts test: fails to install: line 43: update-updmap: command not found

[Florent Rougon]

Rene Engelhard [EMAIL PROTECTED] wrote:

 Reason: if there were TeX files in any previous version of the package
 (up to the previous Debian release), then mktexlsr *has* to be run.

 Why weren't they in their own package then?

Huh? I don't know. I'm not the maintainer of texpower.

 Then if the package goes away you already have the postrm run mktexlsr
 because it's there in the old package and gets run when you remove it.

Hah! So you would want mktexlsr to be run on 'postrm upgrade' for every
package that ships .tex files and runs dh_installtex, right?

I'm not opposed to that, because this is clean. But do you realize that
if go that route, when a package containing .tex files is upgraded to a
version that also contains .tex files, then mktexlsr would be run *twice
in a row*? Once by old-postrm upgrade and once by
new-postinst configure.

I can very well imagine the gazillion bug reports we would get if we did
that.

Reminder:

  * Why does mktexlsr need to be run on upgrade?

Because the list of .tex file can change (new files, removals,
renamings).

  * Why does mktexlsr need to be run by postinst configure?

Because when you go from the removed state to the installed state,
the .tex files added by the installation have to be registered.

Since new-postinst configure is automatically run on upgrades anyway,
we thought it not useful to *additionally* run it on old-postrm upgrade,
but if that's what you want, we can enable that and let you deal with
the bug reports. :-P

If I follow your reasoning, you're embarrassed seeing mktexlsr being run
on postinst configure for a package that doesn't ship tex files.
Right. But at the same time, you would like that the previous version of
the package runs mktexlsr as old-postrm upgrade because you know, the
next version might not ship the exact same list of .tex files. Since
we don't have a time machine, there is no way to know when writing
old-postrm that the next version will have .tex files (in which case,
running mktexlsr in old-postrm upgrade is useless, since it will be
run by new-postinst configure anyway). Therefore, by your reasoning,
we would have to *always* run mktexlsr in old-postrm upgrade. Since,
with your proposal of looking whether the new version contains .tex
files, postinst configure would also cause a mktexlsr run whenever the
new version contains .tex files, you're proposing a system where
mktexlsr is run twice in a row in most cases. Doesn't look like an
improvement to the current system to me.

 I'd have split out the tex files (let alone because the dependencies on
 TeX stuff) and if you app really needs them make the app depend on
 *them*, not ship them in the normal packages.

Making a new binary package only in order to avoid a dependency on
tex-common in the main package is ridiculous. tex-common is quite
small.

 This is like comparable to programs/libs, where the (public) libs built from a
 programs' source package should also not be in package foo but in
 libfooX.

Gni? The reason we need libfooX is for other packages to depend on it,
and only on it. But programs that are the only users of their libraries
don't need to create libfooX binary packages.

 dh_installmenu does not add update-menus to everything because one
 package produced has a menu file and is therefore called. It just adds
 the needed stuff to the needed packages.

So?

 In contrast to that, dh_installtex when ran without -p adds its snippet
 to *every* binary package, may it have tex stuff in it or not.

And rightly so, because if the maintainer runs dh_installtex for a
package, he should have a reason to do so. For instance, because the
previous version had .tex files.

 Anyway, I just worked around it by using -p and will keep it mind.

It is not a workaround. It is simply using the tool where it is
needed.

 Do whatever you think, but you are behaving completely different than
 many normal dh_*'s.

dh_installtex is doing more complex stuff than many dh_*'s. It is normal
that it is not a clone of all of them.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#427562: forkbomb: Workaround and request for comment on documentation

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Comments?

Nice explanation, thank you.

-- 
Florent

Bug#427859: lmodern fails to configure on upgrade, dpkg error

[Florent Rougon]

Hi,

Frank Küster [EMAIL PROTECTED] wrote:

 Are you sure that lmodern doesn't need a higher version of tex-common?

I looked at both changelogs and couldn't see why it would. Do you have
anything specific in mind?

 It also seems strange that the submitter has the stable version of it,
 but testing has the highest pinning priority.

It seems the submitter is exercising some control over what to upgrade
and what not to upgrade, which could explain why tex-common wasn't
upgraded. BTW, I don't understand why both 1.0.1 and 1.7 are listed for
testing at:

http://packages.debian.org/cgi-bin/search_packages.pl?keywords=tex-commonsearchon=namessubword=1version=allrelease=all

Any idea?

-- 
Florent

Bug#356853: Relicensing the ae package under the LPPL

[Florent Rougon]

Lars Engebretsen [EMAIL PROTECTED] wrote:

 Thanks for doing all this work! I have now uploaded the updated
 package to CTAN.

That's great. Thank you very much, Lars.

I cannot see the new version on CTAN yet, but I suppose it's a matter of
days.

Regards,

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#421450: fiaif: FTBFS: File `fancyheadings.sty' not found.

[Florent Rougon]

Hi,

Kurt Roeckx [EMAIL PROTECTED] wrote:

 Hi,

 Your package is failing to build with the following error:
 ! LaTeX Error: File `fancyheadings.sty' not found.

fancyheadings.sty has long been obsolete. fancyhdr.sty should be used
instead.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Hi,

Frank Küster [EMAIL PROTECTED] wrote:

 Hi Florent,

[...]

 any chance that you find time for this?

This is now done. Sorry for taking so much time, but this is one of
those boring tasks with unclear non-technical choices[1] to make, so...

  [1] Who are the copyright holders for $file? Which years to put in the
  copyright notice? Is the file even copyrightable? etc.

-- 
Florent

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Great, merci beaucoup.  You've forwarded it to Lars, so that he'll do
 the upload?

Yes, it's the previous message in the bug log. But indeed, I don't
recall having seen it on -tex-maint. Maybe because it has an attachment
of approx. 230 Ko? Hmmm...

 No need to apologize.  I also didn't want to bug you, just ask: I looked
 through texlive's RC bugs and found these two, inherited from tetex...

But all the contributors responded positively several months ago, so
that *had* to be done...

-- 
Florent

Bug#419756: albatross: FTBFS: epstopdf: Command not found

[Florent Rougon]

Norbert Preining [EMAIL PROTECTED] wrote:

 Yes they do: texlive-extra-utils/2007 depends on 
   texlive-common/2007 conflicts with
   texlive-pdfetex

That is not enough. With these depends and conflicts, apt could unpack
texlive-extra-utils/2007 while texlive-pdfetex is unpacked (because they
don't conflict), which I suppose would fail (because I suppose that
epstopdf is shipped in the same path in both packages).

The dependency you cited only ensures that texlive-extra-utils/2007 will
be *configured* after texlive-common/2007 is configured. Nothing about
unpacking, which is where file conflicts usually happen.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#419756: albatross: FTBFS: epstopdf: Command not found

[Florent Rougon]

Norbert Preining [EMAIL PROTECTED] wrote:

 Hmm. What about asking removal of texlive-pdfetex? Would be the cleanest
 solution ;-)

You could still hit the file conflict when upgrading from etch.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#403641: tetex-base: postrm fails if just unpackaged.

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Why is --quiet only used for update-updmap?  It's the same script behind
 the three, and with -v it always says

IMHO, it's a bug that --quiet isn't used for all three calls. But this
--quiet here dates from before we introduced
dhit_check_run_without_errors(). With this function, the output of the
three update-* calls is redirected to a file, so whether using --quiet
or not is not that important.

I believe we should still call all of them with --quiet in this context,
because most of the info that comes in without this option is
user-oriented and misleading in case of a package installation:

echo $progname has updated '$output_file'. If you want to

if [ $progname = update-language ]; then
echo enable the new patterns, you should run fmtutil-sys or fmtutil
echo (with option --all, or with a particular format specified).
elif [ $progname = update-updmap ]; then
echo enable the map files with this new file, you should run \
 updmap-sys or updmap.
elif [ $progname = update-fmtutil ]; then
echo enable the new formats,  you should run fmtutil-sys or fmtutil
echo (with option --all or --missing).

This info is really intended for users running the update-* scripts
manually.

 ${progname}'s -v option is deprecated. The default mode of operation will
 be verbose as soon as enough packages use the --quiet option. Please update
 your scripts accordingly.\n\n 2; quiet=0; shift ;;

Yeah, we should really do the switch to verbose mode right after the
release of etch. Otherwise, we can still wait...
It's a pity we didn't do it for etch. :-|

-- 
Florent

Bug#403641: tetex-base: postrm fails if just unpackaged.

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 On the other hand, I'm not sure how to fix this.  There's a reason why
 the update-* scripts fail (with an understandable error message) when
 the basic file is missing - so this shouldn't be changed.  Should we
 really ignore all errors of update-* in postrm remove?

Tough question. It would certainly fix the error... apparently, but
such a fix may lead to later breakages, more difficult to analyze.

If you choose to ignore the errors, I'd suggest not to ignore them
altogether, but actually perform the update-* and updmap-sys/fmtutil-sys
calls in postrm scripts only when tex-common is configured (by checking
for the existence of 00tex.cnf, or by using dpkg-query?...).

If tex-common is not configured, the TeX system is in such a bad state
that we cannot do much to help the packages getting removed properly.
Granted, supposing the above is implemented: if the package to remove
was texlive-lang-french, it could be removed from dpkg's POV while my
formats would still have french hyphenation patterns. But I don't think
it's that bad, because the TeX system *is* broken at that time. Only
when tex-common is configured, may the TeX system be in a sane state.

Uuups. I wrote that under the assumption that tex-common tries to run
updmap-sys and fmtutil-sys after the update-* commands, but it doesn't.
Therefore, in my example, my formats would still have french hyphenation
patterns installed even after tex-commmon is configured again, with
texlive-lang-french removed. Baaad.

My conclusion: if these errors are avoided as described above, then
tex-common should also try to call create_tetex_formats() and
create_fontmaps() when configured (which, in case of errors, would
probably spit out more confusing messages...).

-- 
Florent

Bug#403641: tetex-base: postrm fails if just unpackaged.

[Florent Rougon]

In fact, this problem is taken care of by the dh_installtex snippets,
and the approach is closer to ignore errors but display a warning than
to run the commands iff tex-common is configured, not ignoring errors:

,[ From lmodern's current postrm ]
| case $1 in
| remove|disappear)
| dhit_check_run_without_errors -silent update-updmap --quiet
| dhit_check_run_without_errors -silent update-language
| dhit_check_run_without_errors -silent update-fmtutil
| if dhit_libkpathsea_configured; then
| dhit_check_run_without_errors mktexlsr
| fi
| for i in map ; do
| if [ $i = map ] ; then
| dhit_libkpathsea_configured  \
| dhit_check_run_without_errors updmap-sys
| fi
| if [ $i = format ] ; then
| for fmt in  ; do
| rm -f /var/lib/texmf/web2c/$fmt.*
| done
| fi
| if [ $i = language ] ; then
| if dhit_libkpathsea_configured  \
| which fmtutil-sys /dev/null; then
| dhit_build_hyphen_format_if_format_exists \
| latex $(kpsewhich language.dat)
| fi
| fi
| done
| ;;
`

Maybe tetex-base should do the same, or something similar.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Hi,

Rolf Niepraschk [EMAIL PROTECTED] wrote:

 My account has been changed: [EMAIL PROTECTED] It would be nice if
 you can change this also in ae.sty.

This address is the one I tried previously. So, you mean we should use
the @gmx.de one instead, right?

From a pratical point of view, I think I'll put your name and that of
Gilbert Ritschard in the Copyright line of ae.sty (as hinted by ae's
README), and will inlude the names along with the email addresses in an
AUTHORS file, so that there is only one place to update when an email
address changes.

 Of course you can change it. All my packages have LPPL license.

Great, thank you very much. We now have the permission from all
copyright holders I could identify for ae. :-)

When I have some time, I'll submit an updated package to Lars with the
LPPL license applied to all files, which he can review and upload to
CTAN.

Thanks to all who made this possible.

Regards,

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Dear Rolf,

I'm trying to reach you again using a different address, because my
previous attempt[1] with your @ptb.de address failed.

As part of a license audit in progress for the TeX distributions teTeX
and TeX Live, we Debian[2] TeX maintainers found that a number of files
in the ae package have no license statement, which unfortunately renders
them undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer, Lars Engebretsen, to
arrange for an update of the ae package using this license, provided
that the various copyright holders give us the permission to do so (all
of them already did, except you).

Looking at the ae package, it appears that you hold copyright on the
following file:

  tex/ae.sty

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in a digitally-signed mail)

Many thanks for your work, and in advance for considering this request.

  [1] http://lists.debian.org/debian-tex-maint/2006/10/msg00595.html

  [2] http://www.debian.org/

-- 
Florent


pgpVdAj68HrvK.pgp
Description: PGP signature

Bug#396002: tetex-bin: fails to install

[Florent Rougon]

Hello,

Peter Weiss [EMAIL PROTECTED] wrote:

 fmtutil-sys failed. Output has been stored in:
   /tmp/tetex.format_creation.PGl27246/fmtutil-sys.log
 Please include this file if you report a bug.

[...]

 fmtutil-sys failed. Output has been stored in:
   /tmp/tetex.format_creation.GeT27825/fmtutil-sys.log
 Please include this file if you report a bug.

As far as I can see, you didn't attach these files to the bug report.
Please do so (most probably, both will tell the same thing).

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396002: tetex-bin: fails to install

[Florent Rougon]

Peter Weiss [EMAIL PROTECTED] wrote:

 Looking at line 822 of

  /usr/share/texmf-tetex/tex/generic/hyphen/icehyph.tex:

 [...]
  d^^f35l^^ed
  1d^^f32m
  d^^f3m5an
  l.822 ---  d^^35ne
  3d^^f3r
  d^^f32s
  d^^f3s5e

It seems your file got corrupted for some reason, because:
  - the line is 'd^^f35ne' in tetex-base versions 3.0.dfsg.3-1 (testing,
unstable) as well as 3.0-21 from http://snapshot.debian.net/
  - I searched the tetex-base changelogs and the debian-tex SVN
repository and found no mention of a change to this file since its
inclusion in either place.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#396002: tetex-bin: fails to install

[Florent Rougon]

Peter Weiss [EMAIL PROTECTED] wrote:

 It seems your file got corrupted for some reason, because:

[...]

 Yes, I think so, too:

[...]

 But no errors in messages about disk getting corrupted.

:-/

I guess we can close the bug, right?

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#395274: bashism in postinst breaks installation/upgrade

[Florent Rougon]

Hi,

Frank Küster [EMAIL PROTECTED] wrote:

 However, the bashism is in an if-clause, and I'm not sure whether the
 shell finds a syntax error while reading the file, or only if it
 actually gets there.  If it does get there, this means the postinst
 script was just about to tell you that it will now exit with an error:
 You should check the files in /etc/texmf/texmf.d, in particular those
 with an *.ucf-dist cousin:  You refused to accept some mandatory changes
 to configuration files.

Umm, I fear this is not the case. I got the same error when upgrading
today and I don't think I've refused any change for TeX packages.
Besides:

/ # lal /etc/texmf/texmf.d
total 52
drwxr-xr-x 2 root root 4096 2006-10-14 19:30 .
drwxr-xr-x 9 root root 4096 2006-10-26 12:27 ..
-rw-r--r-- 1 root root 6706 2006-10-14 19:30 05TeXMF.cnf
-rw-r--r-- 1 root root 1020 2006-10-14 19:30 15Plain.cnf
-rw-r--r-- 1 root root 3347 2006-10-14 19:30 45TeXinputs.cnf
-rw-r--r-- 1 root root 1240 2006-10-14 19:30 55Fonts.cnf
-rw-r--r-- 1 root root  163 2006-10-14 19:30 65BibTeX.cnf
-rw-r--r-- 1 root root  689 2006-10-14 19:30 75DviPS.cnf
-rw-r--r-- 1 root root 2861 2006-10-14 19:30 85Misc.cnf
-rw-r--r-- 1 root root  333 2006-10-14 19:30 90TeXDoc.cnf
-rw-r--r-- 1 root root 6504 2006-10-14 19:30 95NonPath.cnf
/ #

There is no .ucf-dist file here.

Regards,

-- 
Florent, going to lunch, maybe investigating that later...

Bug#395274: bashism in postinst breaks installation/upgrade

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 You seem to fear things that I think are good ;-) This just means that
 Michael's system is fine, and my knowledge of shell is not.

OK, so if I understood right, there is nothing to fix on the systems
where the installation of tex-common 0.36 failed. Therefore, I grabbed
0.37 from Incoming (http://incoming.debian.org/), installed it and
everything seems to be going fine now.

Thanks.

-- 
Florent

Bug#356853: Licensing ae under the LPPL

[Florent Rougon]

I have received this from Alan Jeffrey:

,
| From: Alan Jeffrey email address hidden
| Subject: Re: License of your contributions to the ae package
| To: Florent Rougon [EMAIL PROTECTED]
| Date: Sat, 14 Oct 2006 21:15:58 -0500
| 
| Dear Florent,
| 
| I am happy for any files copyrighted to me as part of the ae package to be
| distributed under the LaTeX Project Public License.
| 
| Thanks for your work!
| 
| Alan.
`

Thanks, Alan!

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: Licence de votre contribution au package ae / License of your contribution to the ae package

[Florent Rougon]

[ French version first; English translation follows ]

Bonjour,

Depuis plusieurs mois, les développeurs Debian[1] s'occupant de TeX, et
notamment Frank Küster, travaillent sur un audit des licences des
différents composants des distributions teTeX et TeX Live. Au cours de
ce travail, nous avons trouvé que certains fichiers du package ae n'ont
pas de licence attachée, ce qui les rend malheureusement impossibles à
distribuer légalement.

Nous pensons que le choix le plus naturel pour le package ae serait la
licence LPPL (the LaTeX Project Public License), dont le texte figure à
l'adresse suivante :

  http://www.latex-project.org/lppl/

Nous avons eu l'accord du mainteneur actuel de ae (Lars Engebretsen, qui
est en Cc) pour préparer une mise à jour de ce package utilisant cette
licence, chose que nous ne pouvons faire qu'avec l'accord de chaque
personne détenant un « copyright » sur une partie de ae.

En examinant le package ae, je suis arrivé à la conclusion que vous
détenez un « copyright » sur le fichier suivant :

  tex/ae.sty

Acceptez-vous que ce fichier soit distribué sous la licence LPPL, en
utilisant le paragraphe suivant, comme suggéré dans la dernière version
de la LPPL ?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(si vous pouviez donner votre réponse dans un mail en anglais, signé
numériquement et envoyé à l'adresse [EMAIL PROTECTED], ce serait
idéal)

Merci pour votre travail, et par avance pour l'attention portée à cette
demande.


  [1] http://www.debian.org/


Hello,

It has been several months since the Debian[1] developers in charge of
TeX, and most notably Frank Küster, started to work on a license audit
of the various components comprising the teTeX and TeX Live
distributions. As part of this work, we found that some files in the ae
package have no license statement, which unfortunately renders them
legally undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, which we can only do with the agreement of every
person holding copyright on a part of ae.

Looking at the ae package, it appears that you hold copyright on the
following file:

  tex/ae.sty

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in English, in a digitally-signed
mail sent to [EMAIL PROTECTED])

Many thanks for your work, and in advance for considering this request.


  [1] http://www.debian.org/

-- 
Florent


pgpdiPSI88Duk.pgp
Description: PGP signature

Bug#356853: Licence de votre contribution au package ae / License of your contribution to the ae package

[Florent Rougon]

[ French version first; English translation follows ]

Bonjour,

Depuis plusieurs mois, les développeurs Debian[1] s'occupant de TeX, et
notamment Frank Küster, travaillent sur un audit des licences des
différents composants de teTeX et TeX Live. Au cours de ce travail, nous
avons trouvé que certains fichiers du package ae n'ont pas de licence
attachée, ce qui les rend malheureusement impossibles à distribuer
légalement.

Nous pensons que le choix le plus naturel pour le package ae serait la
licence LPPL (the LaTeX Project Public License) dont le texte figure à
l'adresse suivante :

  http://www.latex-project.org/lppl/

Nous avons eu l'accord du mainteneur actuel de ae (Lars Engebretsen, qui
est en Cc) pour préparer une mise à jour de ce package utilisant cette
licence, chose que nous ne pouvons faire qu'avec l'accord de chaque
personne détenant un « copyright » sur une partie de ae.

En examinant le package ae, je suis arrivé à la conclusion que vous
détenez un « copyright » sur le fichier suivant :

  tex/aecompl.sty

Acceptez-vous que ce fichier soit distribué sous la licence LPPL, en
utilisant le paragraphe suivant, comme suggéré dans la dernière version
de la LPPL ?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(si vous pouviez donner votre réponse dans un mail en anglais, signé
numériquement et envoyé à l'adresse [EMAIL PROTECTED], ce serait
idéal)

Merci pour votre travail, et par avance pour l'attention portée à cette
demande.


  [1] http://www.debian.org/


Hello,

It has been several months since the Debian[1] developers in charge of
TeX, and most notably Frank Küster, started to work on a license audit
of the various components comprising teTeX and TeX Live. As part of this
work, we found that some files in the ae package have no license
statement, which unfortunately renders them legally undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, which we can only do with the agreement of every
person holding copyright on a part of ae.

Looking at the ae package, it appears that you hold copyright on the
following file:

  src/aecompl.sty

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in English, in a digitally-signed
mail sent to [EMAIL PROTECTED])

Many thanks for your work, and in advance for considering this request.


  [1] http://www.debian.org/

-- 
Florent


pgpqJ6WAFQulU.pgp
Description: PGP signature

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Gilbert Ritschard [EMAIL PROTECTED] wrote:

 This is to confirm that I accept that the file

   ae.sty

 be distributed under the LPPL, with the following statement
  
% This work may be distributed and/or modified under the
% conditions of the LaTeX Project Public License, either version 1.3
% of this license or (at your option) any later version.
% The latest version of this license is in
%   http://www.latex-project.org/lppl.txt
% and version 1.3 or later is part of all distributions of LaTeX
% version 2005/12/01 or later.

Thank you very much for your prompt and positive reply.

 However, as far as I remember, my contribution to the file was really just
 only two lines. I would have no problem to leave the copyright to Lars
 Engebretsen.

That's quite possible. I just had no easy way to determine the extent of
your contribution, and therefore whether it was actually
copyrightable.

Regards,

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

[EMAIL PROTECTED] (Sebastian Rahtz) wrote:

   % This work may be distributed and/or modified under the
   % conditions of the LaTeX Project Public License, either version 1.3
   % of this license or (at your option) any later version.
   % The latest version of this license is in
   %   http://www.latex-project.org/lppl.txt
   % and version 1.3 or later is part of all distributions of LaTeX
   % version 2005/12/01 or later.

 thats fine by me.

Great, thank you.

 (ideally, you would send your answer in a digitally-signed mail)
 
 I'll try...

Success! Your signature verifies without any problem.

Regards,

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Dear Sebastian,

As part of a license audit in progress for the TeX distributions teTeX
and TeX Live, we Debian[1] TeX maintainers found that a number of files
in the ae package have no license statement, which unfortunately renders
them undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, provided that the various copyright holders give us
the permission to do so.

Looking at the ae package, it appears that you hold copyright on the
following file:

  src/aet1.etx

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in a digitally-signed mail)

Many thanks for your work, and in advance for considering this request.

  [1] http://www.debian.org/

-- 
Florent


pgpoweMplR991.pgp
Description: PGP signature

Bug#356853: License of your contributions to the ae package

[Florent Rougon]

Dear Alan,

As part of a license audit in progress for the TeX distributions teTeX
and TeX Live, we Debian[1] TeX maintainers found that a number of files
in the ae package have no license statement, which unfortunately renders
them undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, provided that the various copyright holders give us
the permission to do so.

Looking at the ae package, it appears that you hold copyright on the
following files:

  src/aelatin.mtx
  src/aelatint.mtx
  src/aet1.etx
  src/ot1tt.etx

Do you accept that these files be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in a digitally-signed mail)

Many thanks for your work, and in advance for considering this request.

  [1] http://www.debian.org/

-- 
Florent


pgp7R8JjtOado.pgp
Description: PGP signature

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Dear Rolf,

As part of a license audit in progress for the TeX distributions teTeX
and TeX Live, we Debian[1] TeX maintainers found that a number of files
in the ae package have no license statement, which unfortunately renders
them undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, provided that the various copyright holders give us
the permission to do so.

Looking at the ae package, it appears that you hold copyright on the
following file:

  tex/ae.sty

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in a digitally-signed mail)

Many thanks for your work, and in advance for considering this request.

  [1] http://www.debian.org/

-- 
Florent


pgpqh2Aur3HNI.pgp
Description: PGP signature

Bug#356853: License of your contribution to the ae package

[Florent Rougon]

Dear Matthias,

As part of a license audit in progress for the TeX distributions teTeX
and TeX Live, we Debian[1] TeX maintainers found that a number of files
in the ae package have no license statement, which unfortunately renders
them undistributable.

We think that the most natural choice of license for the ae package
would be the LaTeX Project Public License (LPPL), whose text can be
found at this address:

  http://www.latex-project.org/lppl/

We got the agreement of its current maintainer (Lars Engebretsen, who is
in the Cc field of this mail) to arrange for an update of the ae package
using this license, provided that the various copyright holders give us
the permission to do so.

Looking at the ae package, it appears that you hold copyright on the
following file:

  src/aelatin.mtx

Do you accept that this file be distributed under the LPPL, with the
following statement, as suggested in the latest version of the LPPL?

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.
  % The latest version of this license is in
  %   http://www.latex-project.org/lppl.txt
  % and version 1.3 or later is part of all distributions of LaTeX
  % version 2005/12/01 or later.

(ideally, you would send your answer in a digitally-signed mail)

Many thanks for your work, and in advance for considering this request.

  [1] http://www.debian.org/

-- 
Florent


pgp8GE2xPqusO.pgp
Description: PGP signature

Bug#392146: tetex-base: uninstallable: updmap-sys failed

[Florent Rougon]

reassign 392146 tetex-bin
found 392146 3.0-20
close 392146 3.0-21
merge 392146 392105
thanks

This bug should already be fixed by Frank's upload of tetex-bin.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#392240: tetex-base: fails to configure: updmap-sys

[Florent Rougon]

reassign 392240 tetex-bin
severity 392240 serious
found 392240 3.0-20
close 392240 3.0-21
merge 392240 392105
thanks

This bug should already be fixed by Frank's upload of tetex-bin.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#391653: scalable-cyrfonts-tex: Version 4.8 doesn't comply with the Debian TeX Policy

[Florent Rougon]

Package: scalable-cyrfonts-tex
Version: 4.8
Severity: serious

Hi,

Version 4.8 of scalable-cyrfonts-tex, which is still in testing, doesn't
comply with the Debian TeX Policy (for a start, the updmap.cfg snippet
file doesn't have the magic comment), which might cause all kinds of
updmap breakage, and deserves a RC bug (Frank Küster in bug #391348).

A quick review of version 4.10 indicates that version 4.10 in unstable
should be fine, though.

Therefore, this bug is a simple reminder to make sure the version in
testing doesn't make it into etch.

-- 
Florent

Bug#356853: Scalable LaTeX font: Licensing question regarding ae fonts

[Florent Rougon]

Dear Lars,

Lars Engebretsen [EMAIL PROTECTED] wrote:

 Basically, I don't really have the energy to care about intricacies of
 licenses, but if you feel that a) you want to do the work and provide
 me with a file that I can then upload to CTAN, and b) that this does
 not change the licensing in such a way that the package can no longer
 be in teTeX and friends, I'm fine with doing the necessary updates.

Your conditions look very reasonable to me. I discussed this with Frank
Küster, and we agreed that using the LPPL (the LaTeX Project Public
License) is probably the most natural choice for the ae package.

I had a look at all source files in order to provide you with a
ready-to-upload tarball (or zip file, whichever is more convenient to
you), but there are a few complications: several files weren't written
by you originally, or have been modified by other people. We need these
people (i.e., the copyright holders of the files) to tell us that they
agree distributing these files under the LPPL.

More precisely, I think it would be wise to use the wording suggested in
the LPPL, i.e. :

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.

You can read the whole LPPL text here:

  http://www.latex-project.org/lppl/lppl-1-3c.html


I'll now paste the various contributors I identified, along with the
files they (appear to) hold copyright on:

,
| Alan Jeffrey
| 
|   src/aelatin.mtx
|   src/aelatint.mtx
|   src/aet1.etx
|   src/ot1tt.etx
| 
| 
| Matthias Koeppe
| 
|   src/aelatin.mtx
| 
| 
| Sebastian Rahtz
| 
|   src/aet1.etx
| 
| 
| Denis Roegel
| 
|   tex/aecompl.sty
| 
| 
| Rolf Niepraschk
| 
|   tex/ae.sty
| 
| 
| Gilbert Ritschard
| 
|   tex/ae.sty
`

Do you want me to contact these people, or do you prefer taking care of
that yourself?

In the latter case, I can provide you with their email addresses, as I
have collected them as part of my little investigation.

Many thanks for your cooperation.

Regards,

-- 
Florent


pgpxzBxumdv6o.pgp
Description: PGP signature

Bug#356853: Scalable LaTeX font: Licensing question regarding ae fonts

[Florent Rougon]

[ Resending the message to a different address, as the previous one
  bounced:

[EMAIL PROTECTED]: host resolver3.levonline.com[217.70.32.98] said: 554
[EMAIL PROTECTED]: Recipient address rejected: no such user (in reply
to RCPT TO command) ]

Dear Lars,

Lars Engebretsen [EMAIL PROTECTED] wrote:

 Basically, I don't really have the energy to care about intricacies of
 licenses, but if you feel that a) you want to do the work and provide
 me with a file that I can then upload to CTAN, and b) that this does
 not change the licensing in such a way that the package can no longer
 be in teTeX and friends, I'm fine with doing the necessary updates.

Your conditions look very reasonable to me. I discussed this with Frank
Küster, and we agreed that using the LPPL (the LaTeX Project Public
License) is probably the most natural choice for the ae package.

I had a look at all source files in order to provide you with a
ready-to-upload tarball (or zip file, whichever is more convenient to
you), but there are a few complications: several files weren't written
by you originally, or have been modified by other people. We need these
people (i.e., the copyright holders of the files) to tell us that they
agree distributing these files under the LPPL.

More precisely, I think it would be wise to use the wording suggested in
the LPPL, i.e. :

  % This work may be distributed and/or modified under the
  % conditions of the LaTeX Project Public License, either version 1.3
  % of this license or (at your option) any later version.

You can read the whole LPPL text here:

  http://www.latex-project.org/lppl/lppl-1-3c.html


I'll now paste the various contributors I identified, along with the
files they (appear to) hold copyright on:

,
| Alan Jeffrey
| 
|   src/aelatin.mtx
|   src/aelatint.mtx
|   src/aet1.etx
|   src/ot1tt.etx
| 
| 
| Matthias Koeppe
| 
|   src/aelatin.mtx
| 
| 
| Sebastian Rahtz
| 
|   src/aet1.etx
| 
| 
| Denis Roegel
| 
|   tex/aecompl.sty
| 
| 
| Rolf Niepraschk
| 
|   tex/ae.sty
| 
| 
| Gilbert Ritschard
| 
|   tex/ae.sty
`

Do you want me to contact these people, or do you prefer taking care of
that yourself?

In the latter case, I can provide you with their email addresses, as I
have collected them as part of my little investigation.

Many thanks for your cooperation.

Regards,

-- 
Florent


pgpdEUJjt6Mam.pgp
Description: PGP signature

Bug#390004: tex-common fails to install trying to overwrite `/usr/share/texmf/doc'

[Florent Rougon]

reassign 390004 latex-ucs-doc
close 390004 20041017-6
merge 390004 388376
thanks

This bug belongs to latex-ucs-doc, and has already been fixed there.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#390004: Argh, severities don't match

[Florent Rougon]

severity 390004 serious
merge 390004 388376
thanks


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#373951: tetex-base: FTBFS: rerunning quilt push -a fails

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 -rw-r--r-- 1 root root 0 2006-06-16 16:50:06.0 + build-stamp
 -rw-r--r-- 1 root root 0 2006-06-16 16:50:05.0 + patch-stamp
 frobnitz:/tmp/buildd/tetex-base-3.0# ls -ld --time-style=full-iso stampdir/
 drwxr-xr-x 2 root root 4096 2006-06-16 16:50:06.0 + stampdir/

 Yes, and it's clear why the directory timestamp is newer than
 patch-stamp's:  the other file, build-stamp, has been touched later.
 This should never have worked, no idea why it usually does...

It seems your kernels aren't using subsecond timestamps, therefore it
works everytime the timestamp of stampdir happens to be in the same
second as that of stampdir/patch-stamp (even if stampdir was actually
last updated *after* stampdir/patch-stamp).

 Daniel, I hope this is reproducible on your system, and does not only
 occurr rarely?  If it is, could you please test the following patch?  I

It should be reproducible when the system is under heavy load, so that
both timestamps don't fall in the same second.

-- 
Florent

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Didier Verna [EMAIL PROTECTED] wrote:

 I'm not opposed to that change. However, I still consider it a bug to
 suddenly break working installations without further notice. And no,
 README.Debian is not enough. There should be at least a big blinking red light
 somewhere (probably at package upgrade time) warning the users that something
 has changed.

NEWS.Debian?

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Didier Verna [EMAIL PROTECTED] wrote:

 Or with id, I know. Look, I know it's unrelated to TeX, but I just
 took the opportunity to ask some clarification on this behavior I've never
 really understood on Unix. Why is a new login required to make the change
 effective ? That's all. I never claimed anything was broken.

I'm not sure. Maybe the list of current groups is inherited from father
process to child process and initialized at Unix session start (yes,
there is a notion of Unix sessions, different from X sessions, but I've
lent the book I have about the subject, thus cannot look this up in
detail).

 Didier: why don't you want your TeX users to be members of the 'users'
 group ?

 Where did you see I was against this ??

Er, you figured out that was the way to solve the problem reported in
this bug. This is written in your first message. You called it a
workaround and nevertheless reported the bug with severity grave. That
made me think you weren't ready to accept this workaround.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Didier Verna [EMAIL PROTECTED] wrote:

 Severity grave is justified because the sudden change of write
 permissions on the /var/cache/fonts directory makes the tetex system unusable
 as soon as a new font description has to be generated.

I see.

 Adding people to the users group _manually_ is indeed a workaround. To
 me the real bug is that either this should be done automatically

Adding users to a group grants them privileges. As a consequence, there
is *no way* this can be done without the consent of the admin.

 or, like I said in the other message, people should be warned _big
 time_ that they're gonna have to do it by hand.

Well, let's wait for Frank's opinion on a NEWS.Debian note.

 But still, I'm not opposed to this change ;-)

OK.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 NEWS.Debian?

 Or/and a debconf question of higher priority?

Well, a debconf note looks to me as a workaround for people who don't
have apt-listchanges installed (due to ignorance), since this is purely
informational---no user input needed. But that would also work...

-- 
Florent

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 You did understand me correctly, but I reconsidered.  I guess people who
 install a TeX system first will face the same problem, and will find

[...]

 Therefore I think a debconf note is the only way to address everybody
 we want to. We can still copy the content to NEWS, or keep it in
 README.

OK.

-- 
Florent

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Fine that we agree, but (as indicated in my older mail), I meanwhile
 have found that the directory becomes non-world-writable only when the
 existing debconf question is shown.  Do you agree that the revised
 wording of the question is sufficient?

With s/uses/users/ as Didier noted, yes.

-- 
Florent

Bug#357983: tetex-bin: mktexmf can't write new .mf files

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 That's how it's always been on UNIX systems.

Didier: you can verify this with the 'groups' command.

 teTeX folks, I fear we have to revert this change and make the system
 insecure by default.  I suggest that we change it only for fresh
 installations and leave unstable users to chmod -R.

 Comments?

Well, that's sad---I find the current setup relatively sane.
Didier: why don't you want your TeX users to be members of the 'users'
group? That doesn't sound that insane.

If I understand you correctly, Frank, you are proposing to give the
current setup to fresh installations and have the stuff world-writable
for those continuously upgrading, right? That would be a way to reduce
complaints, for sure...

-- 
Florent

Bug#354113: jadetex: FTBFS: mktexdir failed

[Florent Rougon]

Hi,

Daniel Schepler [EMAIL PROTECTED] wrote:

 From my pbuilder build log:

 ...
 Transcript written on jadetex.log.
 make[1]: Leaving directory `/tmp/buildd/jadetex-3.13'
 pdflatex '\nonstopmode\input{jadetex.dtx}'  latex.log
 kpathsea: Running mktextfm ecrm1000
 mkdir: cannot create directory `././var/cache/fonts/tfm/jknappen': Permission 
 denied

I believe this is a bug in the teTeX packages (which I was about to
report). I think it happened because tetex-base was configured after
tex-common, or something like that. At least, here, I can reproduce it
with the following sequence:

 1. Install tex-common and tetex-base, configure tex-common last (if
needed, use 'dpkg-reconfigure tex-common'). The permissions of
/var/cache/fonts are drwxrwsr-t root:users (I answer 'yes' to the
question manage the cache permissions with debconf?).

 2. Purge tetex-base.

 3. Install tetex-base again. Now, the permissions of /var/cache/fonts
are drwxr-xr-x root:root, which doesn't follow the policy defined
when answering the debconf question in 1 and causes on-the-fly font
creation by non-root users to fail.

A simple 'dpkg-reconfigure tex-common' fixes the permissions of
/var/cache/fonts. But still, I don't understand why the default answer
to the question manage permissions of the cache directory with
debconf? is always 'No', even though I always answer 'Yes'. Usually,
debconf remembers previous answers, right?
  
-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335303: tetex-bin: failed to install: updmap error

[Florent Rougon]

Hi,

Sebastien Helleu [EMAIL PROTECTED] wrote:

 Output of apt:

 Setting up tetex-bin (3.0-10.1) ...

What does 'dpkg -l tetex-base' say?

 Running updmap-sys. This may take some time. ...

[...]

 !!! ERROR: The right location for map files has been
 changed for this release and the map file `dvips35.map' has
 not been found in the right location, but in the obsolete
 location
   /usr/share/texmf/dvips/config/dvips35.map
 instead.

What does 'ls -l /usr/share/texmf/dvips/' give you?
And 'dpkg -S dvips35.map'?

 !!! ERROR: The right location for map files has been
 changed for this release and the map file `pdftex35.map' has
 not been found in the right location, but in the obsolete
 location
   /usr/share/texmf/dvips/config/pdftex35.map
 instead.

Please tell us the output of 'dpkg -S pdftex35.map'.

 !!! ERROR! The map file `dvipdfm35.map' has not been found at all.

Hah. What do you get from 'ls -l /usr/share/texmf/fonts/map'?

Thanks.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335303: tetex-bin: failed to install: updmap error

[Florent Rougon]

Sebastien Helleu [EMAIL PROTECTED] wrote:

 Thanks for reporting. From which version did you upgrade?

 I think from 3.0-10.

You can confirm by looking at /var/log/dpkg.log.

 Interesting, current tetex has 'true' for the last two options. What is
 the output of 'ls /etc/texmf/updmap.d/'? Did you (maybe automatically)
 decline some offered updates of configuration files?

 $ ls -l /etc/texmf/updmap.d/
 total 16
 -rw---  1 root root 2789 2005-10-22 18:11 00updmap.cfg
 -rw-r--r--  1 root root 2787 2005-10-22 18:17 00updmap.cfg.dpkg-dist
 -rw-r--r--  1 root root 2623 2005-10-19 16:10 10tetex-base.cfg
 -rw-r--r--  1 root root 1314 2005-10-19 16:11 20tetex-extra.cfg.dpkg-new

Ah, that can probably explain everything. You probably didn't accept the
updates for 00updmap.cfg and 20tetex-extra.cfg (the former with ucf, I
think; the latter is a conffile). Please:

 1. Backup your old files if you customized them somehow.

 2. Run:

 # mv 00updmap.cfg.dpkg-dist 00updmap.cfg
 # mv 20tetex-extra.cfg.dpkg-new 20tetex-extra.cfg
 # dpkg --configure -a

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335303: tetex-bin: failed to install: updmap error

[Florent Rougon]

Sebastien Helleu [EMAIL PROTECTED] wrote:

 $ ls -l /usr/share/texmf/dvips/
 total 52
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 antp
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 antt
 drwxr-xr-x  2 root root 4096 2005-10-23 02:13 base
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 bluesky
 lrwxr-xr-x  1 root root   16 2005-10-22 18:08 config - /etc/texmf/dvips
 drwxr-xr-x  2 root root 4096 2005-10-23 02:13 gsftopk
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 misc
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 omega
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 pl
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 psfrag
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 pstricks
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 qfonts
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 tetex
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 xypic


Fine.

 $ dpkg -S dvips35.map
 tetex-base: /etc/texmf/map/dvips/tetex/dvips35.map

OK.

 $ dpkg -S pdftex35.map
 tetex-base: /etc/texmf/map/dvips/tetex/pdftex35.map

OK.

 $ ls -l /usr/share/texmf/fonts/map
 total 4
 lrwxr-xr-x  1 root root   22 2005-10-22 18:08 dvipdfm -
 /etc/texmf/map/dvipdfm
 lrwxr-xr-x  1 root root   20 2005-10-22 18:08 dvips -
 /etc/texmf/map/dvips
 drwxr-xr-x  2 root root 4096 2005-10-22 18:08 fontname
 lrwxr-xr-x  1 root root   21 2005-10-22 18:08 pdftex -
 /etc/texmf/map/pdftex

Good. Presumably, the problem was located (only) in /etc/texmf/updmap.d/
as suspected by Ralf.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335303: tetex-bin: failed to install: updmap error

[Florent Rougon]

Ralf Stubner [EMAIL PROTECTED] wrote:

 used. This could cause a wrong search path for mapfiles. What I am
 wondering is why this problem didn't occur during the original 2.0.2 -
 3.0 update. Also, why are dvips35.map and pdftex35.map still available
 in /etx/texmf/dvips? I thought these files are moved somehwere save on
 instalation.

Hmm. Normally, in sarge, you have:

  % dpkg -S dvips35.map pdftex35.map dvipdfm35.map
  tetex-base: /usr/share/texmf/dvips/tetex/dvips35.map
  tetex-base: /usr/share/texmf/dvips/tetex/pdftex35.map
  tetex-base: /usr/share/texmf/dvips/tetex/dvipdfm35.map

but tetex-base/README.Debian.gz (from sarge) says:

,
| 
| 2. Changes in handling of map files (unneeded files in /etc/texmf/dvips)
| ---
| 
| Font map files previously were installed as conffiles (i.e.,
| configuration files managed by dpkg) in older versions of tetex-base
| and tetex-extra (e.g. in woody) in /etc/texmf/dvips. Since it is in
| fact not necessary to change them, they are now treated as ordinary
| files and installed below /usr/share/texmf/dvips. Because of Debian
| Policy (and the way dpkg handles conffiles), the copies in
| /etc/texmf/dvips will not be removed when you upgrade, although they
| are useless. You can quite safely delete them (but then you won't be
| able to downgrade any more unless you purge the packages). Any changes
| you made previously in these files will no longer have any effect.
| 
| It is usually a good idea to remove those files if you have not
| changed them. You can use the script
| /usr/share/doc/tetex-base/remove-oldmaps to do this. The list of files
| is: 
| 
| antp.cfg antt.cfg pl.cfg
| config.qf 
| ar-ext-adobe-bi.map ar-ext-adobe-kb.map ar-ext-urw-kb.map
| ar-ext-urw-urw.map ar-std-adobe-bi.map ar-std-adobe-kb.map
| ar-std-urw-kb.map ar-std-urw-urw.map bakoma-extra.map
| bsr.map bsr-interpolated.map
| lw35extra-adobe-bi.map lw35extra-adobe-kb.map lw35extra-urw-kb.map
| lw35extra-urw-urw.map mathpple-ext.map mtsupp-ext-adobe-bi.map
| mtsupp-ext-adobe-kb.map mtsupp-ext-urw-kb.map mtsupp-ext-urw-urw.map
| mtsupp-std-adobe-bi.map mtsupp-std-adobe-kb.map mtsupp-std-urw-kb.map
| mtsupp-std-urw-urw.map raw-ar-ext-adobe-bi.map raw-ar-ext-adobe-kb.map
| raw-ar-ext-urw-kb.map raw-ar-ext-urw-urw.map raw-ar-std-adobe-bi.map
| raw-ar-std-adobe-kb.map raw-ar-std-urw-kb.map raw-ar-std-urw-urw.map
| raw-lw35extra-adobe-bi.map raw-lw35extra-adobe-kb.map
| raw-lw35extra-urw-kb.map raw-lw35extra-urw-urw.map utopia.map
| 
| Some intermediate versions of tetex deleted those files in maintainer
| scripts (which was a bug). Therefore, if you used testing, unstable or
| some backports after woody's release, they might not exist on your
| system. 
| 
| Do NOT delete other files in the directory, they are still required.
`

However, the preceding list doesn't contain dvips35.map nor
pdftex35.map. Is it incomplete?...

Second observation: if you look at the updmap-sys error messages posted
by Sébastien, you'll see they are generated by 'mapWarn badLocation' for
the first two and by 'mapWarn notFound' for the last one.

This means that we were in the main 'else' clause of locateMapMigrate().
IOW, the new files were not found at all. I wouldn't be surprised to
learn that Sébastien has .dpkg-new files in /etc/texmf/map/dvips/tetex/.

-- 
Florent

Bug#335055: tetex-bin: Uninstallable: rm: cannot remove `/var/lib/texmf/web2c/*fmt': No such file or directory

[Florent Rougon]

Hi,

Kurt Roeckx [EMAIL PROTECTED] wrote:

 It would be nice if this got uploaded soon, since this is causing
 problems on the buildds.

tetex-bin 3.0-10.1 is in incoming with Ralf's fix for this bug. Thanks.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#335231: lmodern: Dummy bug: should not migrate to testing before teTeX 3

[Florent Rougon]

Package: lmodern
Version: 0.92-10
Severity: serious

teTeX 3 won't enter testing before dummy bug #334722 is closed, and
lmodern = 0.92-9 should not enter testing before teTeX 3, otherwise it
would be useless for TeX users since it depends on tex-common and
tex-common conflicts with tetex-bin (= 3.0-4) and
tetex-base (= 3.0-3). Testing users would have to choose between
lmodern and teTeX...

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#334713: [Florian Cramer] Re: tetex-bin: package doesn't install because of missing mfw binary

[Florent Rougon]

Forwarding Florian's answer, since I got it privately.

---BeginMessage---
Am Mittwoch, 19. Oktober 2005 um 23:41:22 Uhr (+0200) schrieb Florent Rougon:
 Hi,
 
 Please tell us what you get from:
 
   # cnf=$ni

The following:

cnf: /var/lib/texmf/web2c/fmtutil.cnf
mfw mfw -   mf.ini

As said, the error happens when I install tetex from scratch.

Bests,

-F

-- 
gopher://cramer.plaintext.cc
http://cramer.plaintext.cc:70


---End Message---


-- 
Florent

Bug#334713: [Florian Cramer] Re: tetex-bin: package doesn't install because of missing mfw binary

[Florent Rougon]

Florent Rougon [EMAIL PROTECTED] wrote:

 The following:

 cnf: /var/lib/texmf/web2c/fmtutil.cnf
 mfw mfw -   mf.ini

 As said, the error happens when I install tetex from scratch.

Maybe you think it is from scratch, but actually isn't? Because with:

  # dpkg -P tetex-extra tetex-bin tetex-base tetex-doc texinfo tex-common

followed by:

  # apt-get install tetex-bin tetex-extra

I get:

  # cnf=$($(kpsewhich --var-value=TEXMFMAIN)/texconfig/tcfmgr \
  dquote cmdsubst --cmd find --file fmtutil.cnf) \
echo cnf: $cnf  grep mfw $cnf; unset cnf
  cnf: /var/lib/texmf/web2c/fmtutil.cnf
  #

i.e., mfw does *not* appear in fmtutil.cnf.

I don't know why (maybe this format is obsolete), but it explains why I
don't get the error you reported.

-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#334713: tetex-bin: package doesn't install because of missing mfw binary

[Florent Rougon]

Forwarding again...

---BeginMessage---
Am Donnerstag, 20. Oktober 2005 um 10:59:01 Uhr (+0200) schrieb Florent Rougon:
 
 I don't know why (maybe this format is obsolete), but it explains why I
 don't get the error you reported.

Thanks. I purged all my latex packages, including the ones that depended
on a tetex install, and this did the trick. Don't ask me why. Probably
there was some old crufty, stale package interfering with the upgrade.

Thanks again,

-F

-- 
gopher://cramer.plaintext.cc
http://cramer.plaintext.cc:70


---End Message---


So, the bug was caused by a stale entry in fmtutil.cnf, as it seems.
Frank, what do you want to do next?

-- 
Florent

Bug#334713: tetex-bin: package doesn't install because of missing mfw binary

[Florent Rougon]

Hi,

Please tell us what you get from:

  # cnf=$($(kpsewhich --var-value=TEXMFMAIN)/texconfig/tcfmgr \
--cmd find --file fmtutil.cnf) \
 echo cnf: $cnf  grep mfw $cnf; unset cnf
  
-- 
Florent



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#320980: [Christoph Bier] Re: Bug#320980: tetex-bin: Updmap error because a map file has not been found

[Florent Rougon]

Frank Küster [EMAIL PROTECTED] wrote:

 Maybe we have a design flaw here in our updmap-magic scheme.  Just that
 it should have revealed itself earlier.  

Nope. :)

 Here, tetex-base, tetex-bin and tetex-extra are upgraded in the same
 apt-get run, and they are configured in the order tetex-base, tetex-bin,
 tetex-extra.  Therefore, when tetex-bin is configured, the new conffiles
 of tetex-extra are still named $conffile.dpkg-new, but the files in
 /var/lib/tex-common/* are already there.  No wonder updmap cannot find
 $conffile; but why didn't this ocurr earlier?

If $conffile is a conffile, since our Policy recommends .cfg files in
/etc/texmf/updmap.d to also be conffiles, $conffile and the conffile in
/etc/texmf/updmap.d that declares it should be simultaneously existent
or non-existent whenever update-updmap is run (because they should be
shipped in the same .deb).

Therefore, if both files are still at the .dpkg-new state and
update-updmap is run (e.g., in your previous scenario, the files are
shipped by tetex-extra and tetex-bin is being configured---I am not even
sure the files would still be at .dpkg-new state, but anyway), the final
map files will get for this particular map the *old* configuration. No
problem. When tetex-extra is itself configured, the files are not at
.dpkg-new state anymore and the final configuration ends up in the final
map files.

Maybe if you manage files in /etc/texmf/updmap.d with ucf, problems can
arise... I didn't consider this scenario.

-- 
Florent

Bug#310321: I cannot reproduce this bug... more detail?

[Florent Rougon]

Thanks, Don.

Don Armstrong [EMAIL PROTECTED] wrote:

 I personally can't get this bug to reproduce here... can you give some
 information as to what actually failed in pdfetex?

 [As I have this version installed on quite a few machines, I'd
 strongly lean to downgrading this bug if no one else can reproduce
 it.]

And, if someone can reproduce it, he should make sure to post the logs
that are (IIRC) pointed to when the package configuration fails and
(again, IIRC) mentioned in the reportbug template. These are essential
clues when it comes to determine the cause of the problem.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309596: tetex-base: FTBFS in experimental: Endless loop.

[Florent Rougon]

Hilmar Preusse [EMAIL PROTECTED] wrote:

 Sure. Here we go.

Thanks.

As you can see, when the second debug snippet is written, Make has
already taken the wrong decision of rebuilding debian/rules (the fact
that the snippet is printed means that Make is running the commands to
update debian/rules):

2005-05-19 15:32:53.37000 +0200 debian/COPYRIGHT.scripts
2005-05-19 15:37:24.0 +0200 debian/common.functions
2005-05-19 15:32:53.4 +0200 debian/common.variables
2005-05-19 15:41:43.75000 +0200 debian/rules
2005-05-19 15:41:29.7 +0200 debian/rules.in
2005-05-19 15:32:53.84000 +0200 debian/variables

debian/rules is newer than all its prerequesites, yet Make wants to
rebuild it. With the next loops, things only get worse as the
prerequesites for debian/rules aren't updated anymore, but debian/rules
gets newer after every loop.

The reason for debian/rules being updated each time is, I think, due to
the commonstuff_update prerequesite in the rule:

  % :: %.in commonstuff_update $(eperl_sourcefiles)

since $(eperl_sourcefiles) is a subset of the files listed in the debug
snippets.

commonstuff_update is a phony target (it is not the name of a file to
update). If I remove it from this rule, debian/rules is updated only
once (not twice anymore), which is exactly what I expect. Also, the GNU
Make manual says about phony targets:

A phony target should not be a prerequisite of a real target file;
  if it is, its commands are run every time `make' goes to update that
  file. As long as a phony target is never a prerequisite of a real
  target, the phony target commands will be executed only when the phony
  target is a specified goal (*note Arguments to Specify the Goals:
  Goals.).

(goals are the targets specified on the command line, such as clean
when running debian/rules clean, or the first target if none is
specified)

So, the Make manual discourages the use of a phony target in this place.
Maybe this can explain the weird behaviour.

Could you try to remove commonstuff_update from the double-colon rule
and tell us if it loops again (and if so, attach the log file with the
debug snippets)? Normally, removing it from rules.in only should be
sufficient since after the first update, debian/rules will have the
double-colon rule without commonstuff_update.

If this solves the problem, I'll post a patch where commonstuff_update
is implemented with a define or an external shell script, and called
in the command sequence for the clean target (since Frank made clean
depend on commonstuff_update) and maybe also in that of the double-colon
rule.

Regards,

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309008: another dir vs. symlink problem

[Florent Rougon]

Hi,

Frank Lichtenheld [EMAIL PROTECTED] wrote:

 tetex-base contains /usr/share/doc/texmf/doc as a symlink.

I suppose you mean /usr/share/texmf/doc.

 In woody the package ivritex contained this as a directory.

This is a bug that was partially fixed in ivritex 1.0-3 and finally
fixed in version 1.1.1-3, according to its changelog (unfortunately, it
seems the proper place to put TeX documentation in wasn't well
documented in woody's tetex packages).

 This can cause problems on woody-sarge upgrades.

Noted. I think adding a Conflicts: ivritex ( 1.1.1-3) would solve the
problem. Since users are supposed to dist-upgrade between major
releases, it shouldn't cause any problem. What do you think?

Thank you for your report.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309008: another dir vs. symlink problem

[Florent Rougon]

Julian Gilbey [EMAIL PROTECTED] wrote:

 In woody, tetex-base already contained this as a symlink, so surely it
 was an RC issue all that time ago already?

Yes. I think the problem was not noticed before because if tetex-base is
unpacked before ivritex, this sentence of Policy applies:

  A directory will never be replaced by a symbolic link to a
  directory or vice versa; instead, the existing state (symlink or
  not) will be left alone and dpkg will follow the symlink if there
  is one.

and therefore, ivritex's stuff is installed in the right place
(/usr/share/doc/texmf) and all goes well. But it is possible that
ivritex is unpacked (not configured, only unpacked) before tetex-base.
That way, /usr/share/texmf/doc is a directory (if installing woody's
ivritex, that is) and then, you have a problem when you want to install
tetex-base's /usr/share/texmf/doc symlink. At least, that is how I
understand the problem.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#309185: tetex-bin: FTBFS in experimental: Endless loop.

[Florent Rougon]

Hi,

Kurt Roeckx [EMAIL PROTECTED] wrote:

 Your package is failing to build in experimental.  It
 seems to be stuck in an endless loop doing this over and
 over again:

[...]

Here is my (partial) understanding of the problem:

debian/rules contains a rule that causes it to be remade (which is
explicitely supported by GNU Make) from debian/rules.in with eperl:

% :: %.in $(eperl_sourcefiles)
eperl -P -o $@ $

However, in $(eperl_sourcefiles)'s expansion, we find
debian/common.variables debian/common.functions, which are real files
*but* are declared as .PHONY targets (it took me a while to spot the
.PHONY declarations and the end of debian/rules, explaining why the
files were being remade every time debian/rules was run...). I suppose
Frank declared them as .PHONY because he wanted them to be updated[1]
whenever possible.

So, debian/rules depends on .PHONY targets. Therefore, it should always
be remade, whenever Make runs it, explaining the endless loop. However,
on my system, and presumably on Frank's, the loop breaks (at least, when
I tried, it was remade only twice). That, I don't understand.

But in my opinion, having .PHONY targets being real files *and* being
depended on is not appropriate, and is causing the problem here (not to
mention headaches). Does it mean that targets depending on the .PHONY
targets should be remade every time, or only when the .PHONY target
files are newer? This sounds ambiguous to me.

I've tested the following patch to debian/rules.in, in order to fix this
problem. debian/common.variables and debian/common.functions are no
longer .PHONY targets. They are updated whenever Make decides to remake
debian/rules. debian/rules is automatically updated when one of its
sources (debian/rules.in and $(eperl_sourcefiles)) is newer.

With this patch, if debian/rules is up-to-date but you have updated the
master files in ../../tetex-common, they will not be copied in the
package build directory to cause debian/rules to be updated. This is
probably something Frank wanted to avoid, but I don't see any elegant
way to that. One way would be with a wrapper script, that checks whether
the master files are newer, updates them if this is the case, and then
runs make; another way would be with a .PHONY target listed as a
prerequesite of every legal top-level target of debian/rules (clean,
build, binary, binary-arch, etc.) that does this job. None of these is
elegant...
--- debian/rules.in.orig	2005-05-16 15:14:51.0 +0200
+++ debian/rules.in	2005-05-16 15:11:48.0 +0200
@@ -66,8 +66,49 @@
 configure:
 	:
 
+# common.variables and common.functions are shared between the tetex-base and
+# tetex-bin source packages. If you want to use this mechanism, check out the
+# tetex-common tree and put it two directories above the package directory.
+# I use ~/src/Packages/tetex-common together with ~/src/Packages/tetex-base/tetex-base-$version/.
+define update-debian-common.variables
+	test -e $(real_common_variables)  \
+	  test $(real_common_variables) -nt debian/common.variables  \
+	  cp $(real_common_variables) debian/common.variables || true
+endef
+
+# $(real_common_variables):
+# # just do nothing if it does not exist
+# 	true
+
+define update-debian-common.functions
+	test -e $(real_common_functions)  \
+	  test $(real_common_functions) -nt debian/common.functions.in  \
+	  cp $(real_common_functions) debian/common.functions.in  \
+  eperl -P -o debian/common.functions debian/common.functions.in \
+  || true
+endef
+
+# $(real_common_functions):
+# # just do nothing if it does not exist
+# 	true
+
+debian/rules: debian/rules.in $(eperl_sourcefiles)
+# Refresh debian/common.variables debian/common.functions every time
+# the rules file is going to be regenerated
+	$(update-debian-common.variables)
+	$(update-debian-common.functions)
+# Regenerate the rules file
+	eperl -P -o $@ $
+
+# Override the general double-colon rule for generating files from their
+# .in eperl sources; otherwise, Make will complain that
+# debian/common.functions depends on itself, since it is in
+# $(eperl_sourcefiles).
+debian/common.functions: debian/common.functions.in debian/common.variables
+	eperl -P -o $@ $
+
 # Eperl is simply great: thanks, Davide!
-% :: %.in $(eperl_sourcefiles) 
+% :: %.in $(eperl_sourcefiles)
 	eperl -P -o $@ $
 
 
@@ -115,30 +156,6 @@
 	-make distclean
 
 
-# common.variables and common.functions are shared between the tetex-base and
-# tetex-bin source packages. If you want to use this mechanism, check out the
-# tetex-common tree and put it two directories above the package directory.
-# I use ~/src/Packages/tetex-common together with ~/src/Packages/tetex-base/tetex-base-$version/.
-debian/common.variables: 
-	test -e $(real_common_variables)  \
-	  test $(real_common_variables) -nt $@  \
-	  cp $(real_common_variables) $@ || true
-
-# $(real_common_variables):
-# # just do nothing if it does not exist
-# 	true
-

Bug#309185: tetex-bin: FTBFS in experimental: Endless loop.

[Florent Rougon]

Kurt Roeckx [EMAIL PROTECTED] wrote:

 Note that I'm doing this on a 2.6 kernel, which has sub-second
 timestamps on files, which might be why you're not seeing it.

Good to know (I'm working with a 2.4 kernel). Now, I have a possible
explanation:

Suppose we start debian/rules with the rules file in 3.0-3.

10 Make sees this rule:

   % :: %.in $(eperl_sourcefiles) 
eperl -P -o $@ $

   The rule applies to the Makefile being executed (debian/rules),
   therefore Make will see if it needs to be updated. In the
   $(eperl_sourcefiles) prerequesite, it sees the two .PHONY
   prerequesites, *automatically* runs the corresponding targets because
   they are .PHONY (this is a hypothesis I am making to explain the
   whole thing), and then, only then, checks whether debian/rules is
   older than any of the prerequesite files, in particular
   debian/common.variables and debian/common.functions that have just
   been updated by the .PHONY target.

   On your system, this is always the case because of the subsecond
   timestamps. Therefore, debian/rules is regenerated and make reruns
   itself with the new one. GOTO 10. :-)

On my and Frank's systems, the loop quickly breaks because it is easy to
do the following in less than 1 second:
  - Make regenerates debian/rules
  - Make reruns itself with the new rules file
  - Make runs the .PHONY targets and updates common.variables and
common.functions

Now, Make checks the time stamps of the new debian/rules and the
newer-but-still-generated-in-the-same-second common.variables and
common.functions, sees that they are all equal and concludes that rules
doesn't need to be regenerated. Thus, the build can start normally.

 The patch seems to work, and it seems to have build fine now.

Good, thanks.

-- 
Florent


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]