Bug#946665: mediawiki: autopkgtests may fail due to stderr messages

[Mathieu Trudel-Lapierre]

Package: mediawiki
Version: 1:1.31.5-3
Severity: minor

Dear Maintainer,

mediawiki autopkgtests may fail with sudo 1.8.29.

The new sudo version handles setting limits differently (actually honours 
pam_limits),
and as such you'd get an Operation not supported error when it tries to set 
RLIMIT_CORE
on some architectures, depending on the infrastructure being used.

This is the only message showing in stderr, and thus fails the tests because of 
stderr.

I suggest adding allow-stderr to all the tests in debian/tests/control except 
for lint
to allow the presence of messages on stderr while running the tests.


-- System Information:
Debian Release: bullseye/sid
  APT prefers focal
  APT policy: (500, 'focal')
Architecture: amd64 (x86_64)

Kernel: Linux 5.3.0-23-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA:fr (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages mediawiki depends on:
pn  apache2 | httpd
pn  mediawiki-classes  
ii  mime-support   3.64ubuntu1
pn  php
pn  php-common 
pn  php-mbstring   
pn  php-mysql | php-pgsql | php-sqlite3 | php-mysqlnd  
pn  php-xml

Versions of packages mediawiki recommends:
pn  default-mysql-server | virtual-mysql-server | postgresql-co  
pn  php-apcu 
pn  php-cli  
pn  php-curl 
pn  php-intl 
pn  php-wikidiff2
ii  python3  3.7.5-1ubuntu1

Versions of packages mediawiki suggests:
pn  clamav
pn  imagemagick | php-gd  
pn  memcached 

Bug#934272: python-asdf: newer pyyaml changes default_flow_style

[Mathieu Trudel-Lapierre]

Package: python-asdf
Version: 2.3.3-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

default_flow_style=None changed to default_flow_style=False by default
in pyyaml 5.1 [1].

I wrote the following pretty heavy-handed patch to address the situation
and maintain previous behavior, though you might want to change the tests
instead and follow the changes made upstream.

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpGHYumu/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch 
python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
--- python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
1969-12-31 19:00:00.0 -0500
+++ python-asdf-2.3.3/debian/patches/fix_pyyaml_default_flow_style.patch
2019-08-08 17:58:05.0 -0400
@@ -0,0 +1,31 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Force yaml.dump() calls to specify default_flow_style=None
+
+default_flow_style changed to False by default, which actually changes
+the output format. Make sure we retain the previous behavior expected
+by the tests.
+
+cf. https://github.com/yaml/pyyaml/issues/265
+
+Index: python-asdf-2.3.3/asdf/block.py
+===
+--- python-asdf-2.3.3.orig/asdf/block.py
 python-asdf-2.3.3/asdf/block.py
+@@ -397,6 +397,7 @@ class BlockManager:
+ offsets, Dumper=yamlutil._yaml_base_dumper, stream=fd,
+ explicit_start=True, explicit_end=True,
+ version=yaml_version,
++default_flow_style=None,
+ allow_unicode=True, encoding='utf-8')
+ 
+ _re_index_content = re.compile(
+Index: python-asdf-2.3.3/asdf/yamlutil.py
+===
+--- python-asdf-2.3.3.orig/asdf/yamlutil.py
 python-asdf-2.3.3/asdf/yamlutil.py
+@@ -340,4 +340,5 @@ def dump_tree(tree, fd, ctx):
+ explicit_start=True, explicit_end=True,
+ version=yaml_version,
+ allow_unicode=True, encoding='utf-8',
++default_flow_style=None,
+ tags=tags)
diff -Nru python-asdf-2.3.3/debian/patches/series 
python-asdf-2.3.3/debian/patches/series
--- python-asdf-2.3.3/debian/patches/series 2019-07-18 08:16:44.0 
-0400
+++ python-asdf-2.3.3/debian/patches/series 2019-08-08 17:56:37.0 
-0400
@@ -3,3 +3,4 @@
 Emulate-importlib.resources-for-Python-3.6.patch
 Remove-loopback-internet-access-test.patch
 Remove-test-that-requires-the-non-existence-of-an-externa.patch
+fix_pyyaml_default_flow_style.patch

Bug#934271: python-tablib: newer pyyaml changes default_flow_style

[Mathieu Trudel-Lapierre]

Package: python-tablib
Version: 0.12.1-3
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

default_flow_style=None changed to default_flow_style=False by default
in pyyaml 5.1 [1].

I wrote the following pretty heavy-handed patch to address the situation
and maintain previous behavior, though you might want to change the tests
instead and follow the changes made upstream.

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpU9xam4/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch
--- python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
1969-12-31 19:00:00.0 -0500
+++ python-tablib-0.12.1/debian/patches/fix_pyyaml_default_flow_style.patch 
2019-08-08 18:06:41.0 -0400
@@ -0,0 +1,30 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Force yaml.dump() calls to specify default_flow_style=None
+
+default_flow_style changed to False by default, which actually changes
+the output format. Make sure we retain the previous behavior expected
+by the tests.
+
+cf. https://github.com/yaml/pyyaml/issues/265
+
+Index: python-tablib-0.12.1/tablib/formats/_yaml.py
+===
+--- python-tablib-0.12.1.orig/tablib/formats/_yaml.py
 python-tablib-0.12.1/tablib/formats/_yaml.py
+@@ -13,12 +13,14 @@ extensions = ('yaml', 'yml')
+ def export_set(dataset):
+ """Returns YAML representation of Dataset."""
+ 
+-return yaml.safe_dump(dataset._package(ordered=False))
++return yaml.safe_dump(dataset._package(ordered=False),
++  default_flow_style=None)
+ 
+ 
+ def export_book(databook):
+ """Returns YAML representation of Databook."""
+-return yaml.safe_dump(databook._package(ordered=False))
++return yaml.safe_dump(databook._package(ordered=False),
++  default_flow_style=None)
+ 
+ 
+ def import_set(dset, in_stream):
diff -Nru python-tablib-0.12.1/debian/patches/series 
python-tablib-0.12.1/debian/patches/series
--- python-tablib-0.12.1/debian/patches/series  1969-12-31 19:00:00.0 
-0500
+++ python-tablib-0.12.1/debian/patches/series  2019-08-08 18:05:44.0 
-0400
@@ -0,0 +1 @@
+fix_pyyaml_default_flow_style.patch

Bug#934269: lavacli: default_flow_style changed in newer pyyaml

[Mathieu Trudel-Lapierre]

Package: lavacli
Version: 0.9.7-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

pyyaml 5.2.1 appears to have some changes in the default flow style used.
Rather than representing sequences and dicts similary to python, it now
defaults to printing them in longform [1]:

 - item 1
 - item 2

etc.

I've written a quick and heavyhanded patch to add default_flow_style=None
to all of the calls to yaml.dump() that otherwise don't include options, but
that might not be the best solution. Maybe upstream would rather fix the tests?

[1] https://github.com/yaml/pyyaml/issues/265


*** /tmp/tmpton7Uz/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/fix_pyyaml_default_flow_style.patch: Make sure all calls
to yaml.dump() include default_flow_style=None, to retain previous behavior
that is checked for in tests, unless it's already otherwise specified.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch 
lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
--- lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
1969-12-31 19:00:00.0 -0500
+++ lavacli-0.9.7/debian/patches/fix_pyyaml_default_flow_style.patch
2019-08-08 16:56:08.0 -0400
@@ -0,0 +1,185 @@
+Index: lavacli-0.9.7/lavacli/commands/aliases.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/aliases.py
 lavacli-0.9.7/lavacli/commands/aliases.py
+@@ -99,7 +99,7 @@ def handle_list(proxy, options, _):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -112,7 +112,7 @@ def handle_show(proxy, options, config):
+ if options.output_format == "json":
+ print(json.dumps(alias))
+ elif options.output_format == "yaml":
+-print(yaml.dump(alias).rstrip("\n"))
++print(yaml.dump(alias, default_flow_style=None).rstrip("\n"))
+ else:
+ if config["version"] >= (2019, 5):
+ print("name   : %s" % alias["name"])
+Index: lavacli-0.9.7/lavacli/commands/device_types.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/device_types.py
 lavacli-0.9.7/lavacli/commands/device_types.py
+@@ -260,7 +260,7 @@ def handle_aliases(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(aliases))
+ elif options.output_format == "yaml":
+-print(yaml.dump(aliases).rstrip("\n"))
++print(yaml.dump(aliases, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Aliases:")
+ for alias in aliases:
+@@ -287,7 +287,7 @@ def handle_list(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(device_types))
+ elif options.output_format == "yaml":
+-print(yaml.dump(device_types).rstrip("\n"))
++print(yaml.dump(device_types, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Device-Types:")
+ for dt in device_types:
+@@ -301,7 +301,7 @@ def handle_show(proxy, options):
+ if options.output_format == "json":
+ print(json.dumps(dt))
+ elif options.output_format == "yaml":
+-print(yaml.dump(dt).rstrip("\n"))
++print(yaml.dump(dt, default_flow_style=None).rstrip("\n"))
+ else:
+ print("name: %s" % dt["name"])
+ print("description : %s" % dt["description"])
+Index: lavacli-0.9.7/lavacli/commands/devices.py
+===
+--- lavacli-0.9.7.orig/lavacli/commands/devices.py
 lavacli-0.9.7/lavacli/commands/devices.py
+@@ -337,7 +337,7 @@ def handle_list(proxy, options, config):
+ if options.output_format == "json":
+ print(json.dumps(devices))
+ elif options.output_format == "yaml":
+-print(yaml.dump(devices).rstrip("\n"))
++print(yaml.dump(devices, default_flow_style=None).rstrip("\n"))
+ else:
+ print("Devices:")
+ for device in devices:
+@@ -386,7 +386,7 @@ def handle_show(proxy, options, config):
+ if 

Bug#933737: nodejs: update tests to account for changes in libuv1 1.30

[Mathieu Trudel-Lapierre]

Package: nodejs
Version: 10.15.2~dfsg-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu eoan ubuntu-patch

Dear Maintainer,

Please add the included patch for tests, which comes from upstream. This
fixes tests when building /testing against libuv1 > 1.27, which has been
changed from return EINVAL on an unbound sock, to returning EBADF.

*** /tmp/tmpED3lWj/bug_body

In Ubuntu, the attached patch was applied to achieve the above:

  * debian/patches/update_test_libuv1_ebadf.patch: Starting in libuv 1.27.0,
test-dgram-address.js should expect EBADF instead of EINVAL.


Thanks for considering the patch.


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

Kernel: Linux 5.2.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru nodejs-10.15.2~dfsg/debian/patches/series 
nodejs-10.15.2~dfsg/debian/patches/series
--- nodejs-10.15.2~dfsg/debian/patches/series   2019-01-31 03:52:02.0 
-0500
+++ nodejs-10.15.2~dfsg/debian/patches/series   2019-08-02 13:02:32.0 
-0400
@@ -12,3 +12,4 @@
 fix_disable_cctest.patch
 benchmark_without_alice.patch
 temporarily_silence_buffer_deprecations.patch
+update_test_libuv1_ebadf.patch
diff -Nru nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch 
nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch
--- nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch   
1969-12-31 19:00:00.0 -0500
+++ nodejs-10.15.2~dfsg/debian/patches/update_test_libuv1_ebadf.patch   
2019-08-02 13:01:32.0 -0400
@@ -0,0 +1,30 @@
+From 04f30e1a7a5a2f49b611314578758e2009ec2152 Mon Sep 17 00:00:00 2001
+From: cjihrig 
+Date: Sat, 16 Mar 2019 13:45:54 -0400
+Subject: [PATCH] test: update test for libuv update
+
+Starting in libuv 1.27.0, test-dgram-address.js should expect
+EBADF instead of EINVAL.
+
+PR-URL: https://github.com/nodejs/node/pull/26707
+Reviewed-By: Santiago Gimeno 
+Reviewed-By: Anna Henningsen 
+Reviewed-By: Richard Lau 
+Reviewed-By: Refael Ackermann 
+Reviewed-By: Ruben Bridgewater 
+Reviewed-By: James M Snell 
+---
+ test/parallel/test-dgram-address.js | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/test/parallel/test-dgram-address.js 
b/test/parallel/test-dgram-address.js
+index f14b910fc27a..2a41755e1c2e 100644
+--- a/test/parallel/test-dgram-address.js
 b/test/parallel/test-dgram-address.js
+@@ -77,5 +77,5 @@ if (common.hasIPv6) {
+ 
+   assert.throws(() => {
+ socket.address();
+-  }, /^Error: getsockname EINVAL$/);
++  }, /^Error: getsockname EBADF$/);
+ }

Bug#906124: Additional debug info

[Mathieu Trudel-Lapierre]

On Thu, Jul 18, 2019 at 10:01 AM Colin Watson  wrote:
> On Mon, Jul 08, 2019 at 09:15:49PM +0300, Vladislav Yarmak wrote:
> > On Mon, 8 Jul 2019 14:57:08 +0100 Colin Watson 
> > wrote:
[...]

> > @@ -720,7 +718,16 @@ grub_cmd_linux (grub_command_t cmd __att
> > return GRUB_ERR_NONE;
> >   }
> > grub_dprintf ("linux", "linuxefi failed (%d)\n", grub_errno);
> > -   grub_errno = GRUB_ERR_NONE;
> > +   /* Preserve default workflow if verify module is loaded and
> > +  signatures are being checked. Condition below is even with
> > +  code which parses "check_signatures" variable in verify.c */
> > +   const char *env_chk_sig = grub_env_get ("check_signatures");
> > +   if (env_chk_sig &&
> > +   (env_chk_sig[0] == '1' || env_chk_sig[0] == 'e') &&
> > +   grub_dl_get("verify"))
> > + grub_errno = GRUB_ERR_NONE;
> > +   else
> > + goto fail;
> >   }
> >   }
> >  }

I'm concerned that this approach does not necessarily fit the bill for
every environment either. For one thing, we really don't want things
to return GRUB_ERR_NONE anymore (so the fallback patch ought to go
anyway, it defeats the purpose of Secure Boot); but also, it is not a
given that if SB fails to validate, that verify is sufficient
validation. I see this as a deployment-specific option, and probably a
matter of whether the module is included in an signed GRUB UEFI binary
or not, rather than whether some environment settings are present.
Config and environment can be changed on the fly, a signed binary
succesfully loaded by firmware and enforcing SB is much more difficult
to trick in letting things get loaded. This is further complicated by the fact
that anything could also load, or decide not to load, the verify module.
Whether something is loaded or available as a module is not sufficient to
decide whether you want to further validate and allow a kernel or not.

In short, I have very much the same opinion as what Colin expresses below.

>
> This specific approach isn't suitable, I'm afraid.  The copied code is
> too fragile (things could go badly wrong if the check_signatures parsing
> were changed upstream and we forgot to update this patch to match).
> More importantly, this approach encodes an implicit assumption that if
> that environment variable is set then some other bit of code is actually
> set up to consume it and verify the kernel in some other way.  This is
> not robust, because there's nothing to say that the pgp module is loaded
> if the linux module is loaded: it would be quite possible to have an
> image that contains the linux module but not the pgp module, and then
> you have a UEFI Secure Boot bypass just by setting check_signatures=1.
> (Note that the module layout is a bit different in 2.04 than in 2.02,
> which is why it's important to prepare this patch against the latest
> version.)
>
[...]

> In fact, perhaps part of the solution could be to integrate the shim
> checking with the verifiers framework, and then linuxefi would (if

It's supposed to get ported to the verifiers framework now that we
have that available; I expect making sure PGP can be done via
verifiers too, and then integration would be pretty, efficient, and
solid.

> anything) just need to check that some appropriate verifier has been
> run, rather than the current code that predates verifiers and does the
> check by hand.  This would make much more logical sense: rather than
> scattering verification logic around all over the place, it would all be
> neatly encapsulated in verifiers.  Doing this would probably be part of
> a useful path to getting shim verification upstream, too.  And, even if
> we do end up backporting this to 2.02 which doesn't have verifiers, it's
> always easier to unroll a well-encapsulated approach into a series of
> ad-hoc checks than the other way round.
>

Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1

Bug#926716: lsof: FTBFS on linux in tests

[Mathieu Trudel-Lapierre]

On Tue, Apr 9, 2019 at 1:25 PM Andres Salomon  wrote:
>
> On Tue, 09 Apr 2019 10:57:47 -0400
> Mathieu Trudel-Lapierre  wrote:
>
> > Package: lsof
> > Version: 4.91+dfsg-1
> > Severity: normal
> > Tags: patch
> > User: ubuntu-de...@lists.ubuntu.com
> > Usertags: origin-ubuntu disco ubuntu-patch
> >
> > Dear Maintainer,
> >
> > lsof FTBFS on linux in tests rebuilds; due to the changes in
> > major()/minor() macros.
> >
> > In Ubuntu, the attached patch was applied to achieve the following:
> >
> >   * debian/patches/majorminor: Fix ftbfs due to missing major/minor
> > macros in tests; by including sysmacros.h where appropriate.
> >
> >
>
> Thanks! Is this due to a change in libc6 2.29?

This was a change in glibc 2.28 [1]; though deprecation started in 2.25.

[1] 
https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=commit;h=e16deca62e16f645213dffd4ecd1153c37765f17

Kind regards,

Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1

Bug#926716: lsof: FTBFS on linux in tests

[Mathieu Trudel-Lapierre]

Package: lsof
Version: 4.91+dfsg-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu disco ubuntu-patch

Dear Maintainer,

lsof FTBFS on linux in tests rebuilds; due to the changes in major()/minor()
macros.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/majorminor: Fix ftbfs due to missing major/minor macros in
tests; by including sysmacros.h where appropriate.


Thanks for considering the patch.


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

Kernel: Linux 5.0.0-8-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru lsof-4.91+dfsg/debian/patches/majorminor 
lsof-4.91+dfsg/debian/patches/majorminor
--- lsof-4.91+dfsg/debian/patches/majorminor1969-12-31 19:00:00.0 
-0500
+++ lsof-4.91+dfsg/debian/patches/majorminor2019-04-09 10:32:58.0 
-0400
@@ -0,0 +1,37 @@
+Index: lsof-4.91+dfsg/tests/LTlib.c
+===
+--- lsof-4.91+dfsg.orig/tests/LTlib.c
 lsof-4.91+dfsg/tests/LTlib.c
+@@ -231,26 +231,32 @@ _PROTOTYPE(static X2DEV_T x2dev,(char *x
+  */
+ 
+ #if   !defined(major_S)
++#include 
+ #define   major_S major
+ #endif/* defined(major_S) */
+ 
+ #if   !defined(minor_S)
++#include 
+ #define   minor_S minor
+ #endif/* defined(minor_S) */
+ 
+ #if   !defined(unit_S)
++#include 
+ #define   unit_S(x)   0
+ #endif/* defined(unit_S) */
+ 
+ #if   !defined(major_X)
++#include 
+ #define   major_X(dp, em) major(x2dev(dp, em))
+ #endif/* defined(major_X) */
+ 
+ #if   !defined(minor_X)
++#include 
+ #define   minor_X(dp, em) minor(x2dev(dp, em))
+ #endif/* defined(minor_X) */
+ 
+ #if   !defined(unit_X)
++#include 
+ #define   unit_X(dp, em)  0
+ #endif/* defined(unit_X) */
+ 
diff -Nru lsof-4.91+dfsg/debian/patches/series 
lsof-4.91+dfsg/debian/patches/series
--- lsof-4.91+dfsg/debian/patches/series2015-09-13 17:37:47.0 
-0400
+++ lsof-4.91+dfsg/debian/patches/series2019-04-09 10:52:45.0 
-0400
@@ -3,3 +3,4 @@
 tests
 obsolete
 preset-ccdate
+majorminor

Bug#922320: plymouth: drop manpage link for plymouth-log-viewer

[Mathieu Trudel-Lapierre]

Package: plymouth
Version: 0.9.4-1
Severity: minor

Dear Maintainer,

plymouth-log-viewer seems to have been removed in recent releases. As such,
a symlink for the manpage in debian/plymouth.links is also not necessary:

/usr/share/man/man8/plymouth.8.gz
/usr/share/man/man8/plymouth-log-viewer.8.gz


Thanks!

Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1

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

Kernel: Linux 4.18.0-11-generic (SMP w/4 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages plymouth depends on:
ii  init-system-helpers  1.56+nmu1
ii  libc62.28-0ubuntu1
ii  libdrm2  2.4.97-1
ii  libplymouth4 0.9.3-1ubuntu12
ii  lsb-base 10.2018112800ubuntu1
ii  systemd  240-5ubuntu3
ii  udev 240-5ubuntu3

Versions of packages plymouth recommends:
ii  plymouth-theme-ubuntu-logo [plymouth-theme]  0.9.3-1ubuntu12
ii  plymouth-theme-ubuntu-text [plymouth-theme]  0.9.3-1ubuntu12

Versions of packages plymouth suggests:
pn  desktop-base 
pn  plymouth-themes  

-- no debconf information

Bug#910013: modemmanager: new upstream release - 1.8.2

[Mathieu Trudel-Lapierre]

On Mon, Oct 1, 2018 at 7:09 AM SZ Lin  wrote:
>
> Source: modemmanager
> Version: 1.7.990-1
> Severity: wishlist
>
> Dear Maintainer,
>
> Please update modemmanager to latest release 1.8.2,
> I am willing to offer my help in new version of packaging.
>

Thanks!

This is already in progress (well, pretty much done, really). I'm
waiting for my sponsor to review the package and upload it.

Kindly,

Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1

Bug#910326: parted: include sys/sysmacros.h missing for major(), minor()

[Mathieu Trudel-Lapierre]

Package: parted
Version: 3.2-21
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

parted 3.2-21 FTBFS in latest test rebuild on ubuntu. major() and minor()
macros are being used without include sys/sysmacros.h, leading to undefined
symbols at linking for these macros.

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/sysmacros_for_major_minor.patch: include sys/sysmacros.h to
account for the user of major() and minor() macros.


Thanks for considering the patch.


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

Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru parted-3.2/debian/patches/series parted-3.2/debian/patches/series
--- parted-3.2/debian/patches/series2018-04-09 07:15:46.0 -0400
+++ parted-3.2/debian/patches/series2018-10-04 14:45:21.0 -0400
@@ -27,3 +27,4 @@
 libparted-dasd-add-test-cases-for-the-new-fdasd-func.patch
 fat-resize-long-path.patch
 fat-resize-retain-boot-code.patch
+sysmacros_for_major_minor.patch
diff -Nru parted-3.2/debian/patches/sysmacros_for_major_minor.patch 
parted-3.2/debian/patches/sysmacros_for_major_minor.patch
--- parted-3.2/debian/patches/sysmacros_for_major_minor.patch   1969-12-31 
19:00:00.0 -0500
+++ parted-3.2/debian/patches/sysmacros_for_major_minor.patch   2018-10-04 
14:55:03.0 -0400
@@ -0,0 +1,19 @@
+From: Mathieu Trudel-Lapierre 
+Subject: Incldue sys/sysmacros.h for major() and minor()
+
+---
+ libparted/arch/linux.c |   51 
-
+ 1 file changed, 26 insertions(+), 25 deletions(-)
+
+Index: b/libparted/arch/linux.c
+===
+--- a/libparted/arch/linux.c
 b/libparted/arch/linux.c
+@@ -40,6 +40,7 @@
+ #include 
+ #include 
+ #include /* for uname() */
++#include   /* for major(), minor() */
+ #include 
+ #include 
+ #ifdef ENABLE_DEVICE_MAPPER

Bug#910325: libdebian-installer: Build correctly with Werror=implicit-fallthrough

[Mathieu Trudel-Lapierre]

Package: libdebian-installer
Version: 0.110
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

it appears that libdebian-installer fails to build in our latest rebuild tests
with GCC 7 -- implicit-fallthrough warning / error is in place, which means
GCC will complain about src/tree.c's code for rotating trees when adding new
nodes. The fix is pretty simple, as the code is straightforward.


In Ubuntu, the attached patch was applied to achieve the following:

  * src/tree.c: Silence GCC's implicit-fallthrough warning by being explicit
in this binary tree rotate code that there's not fallthrough; we're
covering all tree rotation cases already (all paths in switch() already
return().


Thanks for considering the patch.


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

Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), 
LANGUAGE=en_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru libdebian-installer-0.110ubuntu2/src/tree.c 
libdebian-installer-0.110ubuntu3/src/tree.c
--- libdebian-installer-0.110ubuntu2/src/tree.c 2017-05-04 11:46:32.0 
-0400
+++ libdebian-installer-0.110ubuntu3/src/tree.c 2018-10-04 14:22:53.0 
-0400
@@ -198,6 +198,7 @@
 case 1:
   return di_tree_node_rotate_right_double (node);
   }
+  break;
 case -1:
 case 0:
 case 1:

Bug#909247: devscripts: grub-excuses: be interactive and colourful

[Mathieu Trudel-Lapierre]

On Thu, 20 Sep 2018 12:15:21 +0200 Mattia Rizzolo wrote:
> Package: devscripts
> Version: 2.18.4
> Severity: wishlist
> User: devscri...@packages.debian.org
> Usertags: grep-excuses
>
> Mathieu here [0] announced a new tool in ubuntu-dev-tools to parse
> ubuntu's update_excuses.yaml.
> The goal is extremily similar to devscripts' grep-excuses, but it
> accomplishes the work in a *much* nicer way.
>
> I dare to propose to rewrite our grep-excuses to use the functionalities
> provided by the python3 module ubuntu_archive_assistant that they wrote.
>

Well, my thought as I wrote the tool was to make it work with Debian
too, but I haven't had much luck doing some things outside of using the
Launchpad API... but there's also that I'm more familiar with that, so
maybe people have some tricks up their sleeve that I'm not aware of,
aside from using madison... I couldn't figure a way to grab Debian build
logs and results (which are useful when considering migration of
packages in Ubuntu anyway) aside from putting together the URLs, and
then you're at the mercy of these things changing.

To improve on this, we should also make it easier to parse excuses and
update_output.txt. I started a discussion about this at
https://github.com/Debian/britney2/issues/3.

I'll get started on a PR for the code changes I was thinking off on that
related aspect of things.

-- 
Mathieu Trudel-Lapierre 
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1




signature.asc
Description: OpenPGP digital signature

Bug#903910: fusiondirectory: please clarify triggers as await/noawait

[Mathieu Trudel-Lapierre]

Package: fusiondirectory
Version: 1.0.19-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

"await" triggers are run before a package is configured. If B activates A,
then A's trigger code in the postinst must be run before A can be configured.

Triggers do not specify a ordering dependency however, so apt can very well
have A in a state where it is not configurable, and installing B then fails.
This is a limitation of triggers: They are not exposed in Packages files, so
we don't see them.

What this means is that packages with await triggers either need to have all
triggering packages depend on them (e.g. B Depends A), or they need to be
moved to noawait.


*** /tmp/tmpB12mXt/bug_body

>From my quick look at fusiondirectory, there seems to be no particular reason
for triggers to be in "await" state, so the included patch specifies the
triggers explicitly as "noawait":

  * debian/fusiondirectory.triggers: Be specific about using interest-noawait
for the triggers -- there's no need to block in awaiting the triggers for
locale, plugins updates. (LP: #1780996)


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), 
LANGUAGE=ja:fr_CA:en (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru fusiondirectory-1.0.19/debian/fusiondirectory.triggers 
fusiondirectory-1.0.19/debian/fusiondirectory.triggers
--- fusiondirectory-1.0.19/debian/fusiondirectory.triggers  2014-08-08 
05:06:26.0 -0400
+++ fusiondirectory-1.0.19/debian/fusiondirectory.triggers  2018-07-12 
10:49:07.0 -0400
@@ -1,2 +1,2 @@
-interest fusiondirectory-setup
-interest /usr/share/fusiondirectory/plugins
+interest-noawait fusiondirectory-setup
+interest-noawait /usr/share/fusiondirectory/plugins

Bug#901019: haskell-hedgehog: please update to 0.6

[Mathieu Trudel-Lapierre]

Source: haskell-hedgehog
Severity: normal

Dear Maintainer,

Please update to new release 0.6. Among other things, it fixes failures to
build on 32-bit architectures (commit 2abbe3fe).

Thanks!

/ Matt

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

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

Bug#901012: haskell-wl-pprint-annotated: build with rtsopts=-N breaks s390x

[Mathieu Trudel-Lapierre]

Package: haskell-wl-pprint-annotated
Version: 0.1.0.0-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

s390x build appears to break in s390x in Ubuntu, but also in Debian, and on
a few other arches in Debian (mips*, armel). Symptoms are tests breaking
because RTS does not recognize the -N option.

-N appears to not really be required for the tests to work correctly, so the
benefit of being able to run concurrently on multiple CPUs (from what I gather
is the point of -N) is limited on the architectures where it works, and clearly
breaks build on many other arches.

>From what I gather by looking into this, -N is generally not considered to be
a great default, so there seems to be no harm in disabling special rtsopts
handling. At the very leasts, tests are still run and appear to be passing
everywhere.


*** /tmp/tmp03NFJK/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/rtsopts_disable_N.patch: don't set --with-rtsopts=-N; it
breaks tests on s390x and doesn't buy much elsewhere.


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-22-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru 
haskell-wl-pprint-annotated-0.1.0.0/debian/patches/rtsopts_remove_N.patch 
haskell-wl-pprint-annotated-0.1.0.0/debian/patches/rtsopts_remove_N.patch
--- haskell-wl-pprint-annotated-0.1.0.0/debian/patches/rtsopts_remove_N.patch   
1969-12-31 16:00:00.0 -0800
+++ haskell-wl-pprint-annotated-0.1.0.0/debian/patches/rtsopts_remove_N.patch   
2018-06-07 17:15:31.0 -0700
@@ -0,0 +1,17 @@
+---
+ wl-pprint-annotated.cabal |2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+Index: b/wl-pprint-annotated.cabal
+===
+--- a/wl-pprint-annotated.cabal
 b/wl-pprint-annotated.cabal
+@@ -46,7 +46,7 @@ test-suite wl-pprint
+   hs-source-dirs:
+ test
+   default-extensions: FlexibleInstances TypeSynonymInstances DeriveFunctor 
DeriveFoldable DeriveTraversable DeriveGeneric DefaultSignatures
+-  ghc-options: -Wall -threaded -rtsopts -with-rtsopts=-N
++  ghc-options: -Wall -threaded
+   build-depends:
+ base   >= 4.8  && < 5,
+ containers >= 0.4  && < 0.6,
diff -Nru haskell-wl-pprint-annotated-0.1.0.0/debian/patches/series 
haskell-wl-pprint-annotated-0.1.0.0/debian/patches/series
--- haskell-wl-pprint-annotated-0.1.0.0/debian/patches/series   1969-12-31 
16:00:00.0 -0800
+++ haskell-wl-pprint-annotated-0.1.0.0/debian/patches/series   2018-06-07 
17:15:13.0 -0700
@@ -0,0 +1 @@
+rtsopts_remove_N.patch

Bug#900943: haskell-src-exts-util: build downloads from the internet

[Mathieu Trudel-Lapierre]

Package: haskell-src-exts-util
Version: 0.2.2-2
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu cosmic ubuntu-patch

Dear Maintainer,

haskell-src-exts-utils appears to attempt to connect to the internet to check
repository for new versions. This potentially breaks reproducibility, and
fails to build on Ubuntu (where there is no internet access for builds).

I've attached a tiny fix.

*** /tmp/tmp4Bmmil/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: set DEB_SETUP_BIN_NAME appropriately to avoid trying to grab
data from the internet at build time.


Thanks for considering the patch.


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

Kernel: Linux 4.15.0-22-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), 
LANGUAGE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru haskell-src-exts-util-0.2.2/debian/rules 
haskell-src-exts-util-0.2.2/debian/rules
--- haskell-src-exts-util-0.2.2/debian/rules2018-04-09 14:07:38.0 
-0700
+++ haskell-src-exts-util-0.2.2/debian/rules2018-06-06 15:44:04.0 
-0700
@@ -1,6 +1,6 @@
 #!/usr/bin/make -f
 
-DEB_SETUP_BIN_NAME = cabal
+DEB_SETUP_BIN_NAME = debian/hlibrary.setup
 DEB_CABAL_PACKAGE = src-exts-util
 DEB_DEFAULT_COMPILER = ghc
 DEB_BUILD_DEPENDENCIES = build-arch

Bug#806713: disk-detect/multipath: update checks for changed mpath alias names

[Mathieu Trudel-Lapierre]

On Fri, Feb 10, 2017 at 1:02 PM, Cyril Brulebois  wrote:

> Hi,
>
> Hendrik Brueckner  (2015-11-30):
> > Dear maintainers,
> >
> > An update in the multipath-tools, [1], changed the naming scheme for
> > mpath aliases created when the user friendly names option is specified.
> >
> > The alias naming changed from mpath0 to mpatha replacing the numeric
> > digits with alphabetic letters.  The patch below updates the
> > disk-detect.sh to correctly detect multipath devices with the new
> > naming scheme.
>
> AFAICT from the current manpage, when this option is not specified, WWID
> are used instead, so there's no need to keep the [0-9] part in the
> check, right? This seems confirmed by my reading of #806900 so I think
> I'll push the patch to master right away.
>
>
That's perhaps right; we could possibly do away with the [0-9] part in the
check. The reason for changing it to [a-z] was only to have the smallest
amount of changes possible. I don't see what benefit that would really
bring though, but I haven't looked at multipath in a while.


> > On the people/cyphermox/mpath-detect branch in the d-i/hw-detect
> > repository, there is already a patch for the same problem.  I could
> > not find a bug report for it.  So that's why I am opening this one to
> > keep this problem in mind.  It would be great if you could help me to
> > understand the practice on how such problem fixes becomes integrated.
>
> Unfortunately lack of manpower means patches are sometimes not reviewed
> or merged for a long time. :(
>

I also could have been more proactive at this; I'll update the branches
shortly -- there has been further changes to partman-multipath and
hw-detect to help with multipath support.


>
> > Apart from the disk-detect package, the partman-multipath package is
> > also affected by mpath naming change.  I will open a separate bug report
> > and attach a patch to solve the naming there.
>
> I'll try and look at the various patches after Mathieu's reply in
> #806900. I might even propose them through proposed-updates if the next
> RC looks good for multipath support.
>

I'm sorry, I just don't see what I should be replying to? We're really not
far from multipath support working (given that it does appear to work
reasonably well in Ubuntu). Let me do the merges to get Ubuntu based on the
right new versions of Debian, then we can do one round of reviewing all the
patches.


/ Matt

Bug#733988: Broadcast DHCP messages

[Mathieu Trudel-Lapierre]

Hi,

In Ubuntu we have applied the attached patch to solve this issue.

Essentially, the DHCP messages need to be broadcast since when there are
multiple interfaces, you might otherwise send from a different interface
than the one you'll receive responses on while the interfaces are not yet
configured.

This fixes yiaddr to INADDR_ANY (which was missing for some DHCP message
types) and sets the broadcast bit.

Kindly,

Mathieu Trudel-Lapierre <mathieu...@gmail.com>
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1
From: Mathieu Trudel-Lapierre <mathieu.trudel-lapie...@canonical.com>
Subject: Set broadcast when sending DHCPREQUEST and DHCPDISCOVER
Bug-Debian: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=733988
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1327412

We need to do this, since our devices are probably not configured yet and
there may be more than one device we're trying to do DHCP on on the same
network. Otherwise, things might be dropped.

Patch is originally from here:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1327412/comments/5
... but the reporter "patpat" has not provided contact information, and
this is independently verifiable by looking at RFC 2131, section 4.1,
page 24.

---
 usr/kinit/ipconfig/dhcp_proto.c |8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Index: b/usr/kinit/ipconfig/dhcp_proto.c
===
--- a/usr/kinit/ipconfig/dhcp_proto.c
+++ b/usr/kinit/ipconfig/dhcp_proto.c
@@ -201,8 +201,14 @@ static int dhcp_send(struct netdev *dev,
 	bootp.hlen	= dev->hwlen;
 	bootp.xid	= dev->bootp.xid;
 	bootp.ciaddr	= INADDR_ANY;
-	bootp.yiaddr	= dev->ip_addr;
+	/* yiaddr should always be set to 0 for the messages we're likely
+	 * to send as a DHCP client: DHCPDISCOVER, DHCPREQUEST, DHCPDECLINE,
+	 * DHCPINFORM, DHCPRELEASE
+	 * cf. RFC2131 section 4.1.1, table 5.
+	 */
+	bootp.yiaddr	= INADDR_ANY;
 	bootp.giaddr	= INADDR_ANY;
+	bootp.flags	= htons(0x8000);
 	bootp.secs	= htons(time(NULL) - dev->open_time);
 	memcpy(bootp.chaddr, dev->hwaddr, 16);
 

Bug#826665: libdebian-installer: libd-i EFI detection can pass while efibootmgr's/efivar's will fail

[Mathieu Trudel-Lapierre]

Package: libdebian-installer
Version: 0.102
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu yakkety ubuntu-patch

Dear Maintainer,

EFI detection in libd-i can in some cases pass while efibootmgr will fail to
set BootEntry due to efivar's checks actually looking for efivars or vars
instead of just the existence of /sys/firmware/efi.

In Ubuntu; I'm applying the following patch to libdebian-installer's detection
code:

  * src/system/efi.c: validate the presence of efivars *or* vars under
/sys/firmware/efi to decide whether we should show the system as running
in EFI mode; either of these paths is required for efibootmgr to set a
BootEntry at the end of installation.

Admittedly, this can still fail if for some reason efivars or vars are present
but empty, but this isn't any different than for /sys/firmware/efi itself.

/sys/firmware/efi/vars should mostly always be around, as it appears to come
straight from the kernel; /sys/firmware/efi/efivars is typically to be mounted
by the init system (this happens at least in systemd src/core/mount-setup.c).

In Ubuntu this is bug:
https://bugs.launchpad.net/ubuntu/+source/libdebian-installer/+bug/1582320

Thanks for considering the patch.


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

Kernel: Linux 4.4.0-23-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru libdebian-installer-0.102ubuntu1/src/system/efi.c libdebian-installer-0.102ubuntu2/src/system/efi.c
--- libdebian-installer-0.102ubuntu1/src/system/efi.c	2015-12-23 19:24:26.0 -0500
+++ libdebian-installer-0.102ubuntu2/src/system/efi.c	2016-06-03 21:22:39.0 -0400
@@ -26,8 +26,9 @@
  * exists */
 int di_system_is_efi(void)
 {
-	int ret = access("/sys/firmware/efi", R_OK);
-	if (ret == 0)
+	int efivars_access = access("/sys/firmware/efi/efivars", R_OK);
+	int vars_access = access("/sys/firmware/efi/vars", R_OK);
+	if (efivars_access == 0 || vars_access == 0)
 	{
 		/* Have we been told to ignore EFI in partman-efi? */
 		ret = access("/var/lib/partman/ignore_uefi", R_OK);

Bug#821937: liblouisutdml: not all of the test suite passes

[Mathieu Trudel-Lapierre]

Source: liblouisutdml
Version: 2.5.0-3
Severity: minor

Dear Maintainer,

Looks like not all of the test suite passes for liblouisutdml, it would be a
good thing to review the current scripts and either remove the test if it can
not be fixed, or to correct run_test_suite.sh.

https://buildd.debian.org/status/fetch.php?pkg=liblouisutdml=i386=2.5.0-3=1458174662

make  check-TESTS
make[4]: Entering directory '/«PKGBUILDDIR»/tests'
make[5]: Entering directory '/«PKGBUILDDIR»/tests'
XFAIL: testTranslateString
PASS: tripleTrans
FAIL: run_test_suite.sh
===
   liblouisutdml 2.5.0: tests/test-suite.log
===

# TOTAL: 3
# PASS:  1
# SKIP:  0
# XFAIL: 1
# FAIL:  1
# XPASS: 0
# ERROR: 0

.. contents:: :depth: 2

XFAIL: testTranslateString
==

Can't open infput file '(null)'
XFAIL testTranslateString (exit status: 1)

FAIL: run_test_suite.sh
===


TESTS

./run_test_suite.sh: 41: cd: can't cd to /«PKGBUILDDIR»/tests/test_suite/test_*
Running test_*...
  ROR
ummary:

Tests run: 1, Failures: 0, Expected failures: 0, Errors: 1

FAIL run_test_suite.sh (exit status: 1)


Testsuite summary for liblouisutdml 2.5.0

# TOTAL: 3
# PASS:  1
# SKIP:  0
# XFAIL: 1
# FAIL:  1
# XPASS: 0
# ERROR: 0


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports'), (99, 'xenial-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Bug#819207: ITP: arch-detect -- detect architectures supported by your machine/kernel

[Mathieu Trudel-Lapierre]

On Thu, Mar 24, 2016 at 6:50 PM, Adam Borowski  wrote:

> Package: wnpp
> Severity: wishlist
> Owner: Adam Borowski 
>
> * Package name: arch-detect
>   Upstream Author : me
> * URL : https://github.com/kilobyte/arch-detect
> * License : MIT
>   Programming Lang: mostly assembler
>   Description : detect architectures supported by your machine/kernel
>
>
It seems like the naming would clash with archdetect (from hw-detect, built
with some libdebian-installer magic).

That package is currently just a udeb, but it *does* make sense as a
standard package, there might simply be a need to do some renaming.

I'm not saying it's a bad name, just that there already exists an
archdetect, and having just a - as a difference may be confusing. It may be
worth combining the two "projects" if possible. I know archdetect should
work on kfreebsd-*.



>  This package lets you enumerate architectures that your kernel can run.
>  The check is for the ability to run machine code and supporting
> appropriate
>  syscall ABI -- you may need to install userland libraries in a chroot,
>  container or via multiarch to actually execute non-static binaries of such
>  architectures.
>

What would the expected output be on a typical amd64 system? Does it
differentiate between EFI and non-EFI?

/ Matt

Bug#818477: mokutil not built on all EFI architectures

[Mathieu Trudel-Lapierre]

Package: mokutil
Version: 0.2.0-1
Severity: normal

Dear Maintainer,

mokutil appears to only be available on amd64. However, grub-efi-* packages
exist for amd64, i386, ia64, arm, and arm64, all of which may be susceptible
to be chainloaded from a shim on that architecture.

While packages may not exist for shim on the relevant architectures yet, it
would be helpful to users if they could already have access to using mokutil
to control shim if they have set it up themselves.

To make sure mokutil is built on all the same architectures as grub; I suggest
using the same form for specifying Architectures:

any-amd64 any-arm any-arm64 any-i386 any-ia64


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports'), (99, 'xenial-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages mokutil depends on:
ii  libc62.21-0ubuntu6
ii  libssl1.0.0  1.0.2g-1ubuntu2

mokutil recommends no packages.

mokutil suggests no packages.

-- no debconf information

Bug#815846: ITP: tpm2-tss -- TPM (Trusted Platform Module) 2.0 Software Stack

[Mathieu Trudel-Lapierre]

On Sat, Mar 5, 2016 at 6:44 AM, Pierre Chifflier <pol...@debian.org> wrote:

> On Wed, Feb 24, 2016 at 09:08:58PM -0500, Mathieu Trudel-Lapierre wrote:
> > Package: wnpp
> > Severity: wishlist
> > Owner: "Mathieu Trudel-Lapierre" <mathieu...@gmail.com>
> >
> > * Package name: tpm2-tss
> >   Version : 0.9.8
> >   Upstream Author : Will Arthur <will.c.art...@intel.com>
> > * URL : https://github.com/01org/TPM2.0-TSS
> > * License : MIT/BSD
> >   Programming Lang: C, C++
> >   Description : TPM (Trusted Platform Module) 2.0 Software Stack
> >
> > TPM2.0-TSS is a software stack comprising a few layers:
> >  - Feature API (FAPI)
> >  - Enhanced System API (ESAPI)
> >  - System API (SAPI)
> >  - TPM Command Transmission Interface (TCTI)
> >  - Trusted Access Broker/Resource Manager (TAB/RM)
> >
> > These are used to interface with TPM chips to provide specific
> cryptographic
> > services to the system in a secure manner.
> >
> > TPM2.0-TSS is a requirement (for tss2 and tcti) for tpm2-tools
> (TPM2.0-tools),
> > for which I will file another ITP.
> >
> > It may be relevant here to merge efforts for maintaining TPM tools in a
> team,
> > there has been lots of work by pollux in maintaining the trousers stack
> for
> > which this project seeks to be an improvement / evolution.
> >
>
> Hi Mathieu,
>

Hi Pierre,


>
> I was indeed intending to package it, since we discussed that during the
> last TCG meeting in San Francisco.
> If you are OK to create a team and a project on alioth, I can do it if
> you want.
>
>
Yeah, let's create a team and projet on alioth. Feel free to do it; or we
could simply maintain this on collab-maint. For now, I pushed the work I
have to github as a temporary spot so I don't lose it:

https://github.com/cyphermox/tpm2-tools
https://github.com/cyphermox/tpm2-tss

Like I said, this is only temporary for myself, we should move this off
github and onto alioth before upload.

However, I did notice some potential issues: tpm2-tss ships some png files
in the source tarball (or at least in the git snapshot I took), and I
understand those probably ought not be shipped. As for tpm2-tools, it
potentially links against openssl, so we should address that or check if
it's a false positive from lintian.

Regards,

Mathieu Trudel-Lapierre <mathieu...@gmail.com>
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/65B58DA1 818A D123 0992 275B 23C2  CF89 C67B B4D6 65B5 8DA1

Bug#816632: open-iscsi: should allow setting a custom initiatorName on install

[Mathieu Trudel-Lapierre]

Package: open-iscsi
Version: 2.0.873+git0.3b4b4500-13
Severity: normal

Dear Maintainer,

It appears as though open-iscsi always generates a random initiatorName from
scratch on installation; either as it runs in the installer, or as it is first
installed on the system.

Furthermore, this would then lead to the initiatorName changing from in the
installer environment and on the installed system, as it seems that
/etc/iscsi/initiatorname.iscsi isn't copied from the installer to the target.

Now, on some secured setups, the host needs to authenticate also by
initiatorName to the target, and that sometimes requires using one's own
naming scheme for the initiator name.

open-iscsi should allow using a custom initiatorName at least in the installer,
where it currently always creates /etc/iscsi/initiatorname.iscsi using
iscsi-iname. I've been testing code to allow setting the initiatorName in the
installer, but this will only work if there is an added test whether the
file exists.

Patch follows:

--- open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi-udeb.start   
2015-08-20 09:51:06.0 -0400
+++ open-iscsi-2.0.873+git0.3b4b4500/debian/open-iscsi-udeb.start   
2016-03-01 15:10:59.0 -0500
@@ -4,15 +4,17 @@
 # and without all the sanity checks. The installer is a clean environment, so
 # we don't need all of that.
 
-# Generate a unique InitiatorName and save it
-INAME=`iscsi-iname -p iqn.1993-08.org.debian:01`
-echo "## DO NOT EDIT OR REMOVE THIS FILE!" > /etc/iscsi/initiatorname.iscsi
-echo "## If you remove this file, the iSCSI daemon will not start." >> 
/etc/iscsi/initiatorname.iscsi
-echo "## If you change the InitiatorName, existing access control lists" >> 
/etc/iscsi/initiatorname.iscsi
-echo "## may reject this initiator.  The InitiatorName must be unique">> 
/etc/iscsi/initiatorname.iscsi
-echo "## for each iSCSI initiator.  Do NOT duplicate iSCSI InitiatorNames." >> 
/etc/iscsi/initiatorname.iscsi
-printf "InitiatorName=$INAME\n"  >> /etc/iscsi/initiatorname.iscsi
-chmod 600 /etc/iscsi/initiatorname.iscsi
+if [ ! -f /etc/iscsi/initiatorname.iscsi ]; then
+   # Generate a unique InitiatorName and save it
+   INAME=`iscsi-iname -p iqn.1993-08.org.debian:01`
+   echo "## DO NOT EDIT OR REMOVE THIS FILE!" > 
/etc/iscsi/initiatorname.iscsi
+   echo "## If you remove this file, the iSCSI daemon will not start." >> 
/etc/iscsi/initiatorname.iscsi
+   echo "## If you change the InitiatorName, existing access control 
lists" >> /etc/iscsi/initiatorname.iscsi
+   echo "## may reject this initiator.  The InitiatorName must be 
unique">> /etc/iscsi/initiatorname.iscsi
+   echo "## for each iSCSI initiator.  Do NOT duplicate iSCSI 
InitiatorNames." >> /etc/iscsi/initiatorname.iscsi
+   printf "InitiatorName=$INAME\n"  >> /etc/iscsi/initiatorname.iscsi
+   chmod 600 /etc/iscsi/initiatorname.iscsi
+fi
 
 modprobe -q iscsi_tcp 2>/dev/null >&2
 /sbin/iscsid






-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports'), (99, 'xenial-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

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

Versions of packages open-iscsi depends on:
ii  debconf [debconf-2.0]  1.5.58ubuntu1
ii  init-system-helpers1.28ubuntu2
ii  libc6  2.21-0ubuntu6
ii  udev   229-1ubuntu4

Versions of packages open-iscsi recommends:
ii  busybox-initramfs  1:1.22.0-15ubuntu1

open-iscsi suggests no packages.

-- Configuration Files:
/etc/iscsi/iscsid.conf [Errno 13] Permission non accordée: 
u'/etc/iscsi/iscsid.conf'

-- debconf information excluded

Bug#815849: ITP: tpm2-tools -- TPM (Trusted Platform Module) 2.0 tools

[Mathieu Trudel-Lapierre]

Package: wnpp
Severity: wishlist
Owner: "Mathieu Trudel-Lapierre" <mathieu...@gmail.com>

* Package name: tpm2-tools
  Version : 1.0
  Upstream Author : Gang Wei <gang@intel.com>
* URL : https://github.com/01org/tpm2.0-tools
* License : BSD
  Programming Lang: C, C++
  Description : TPM (Trusted Platform Module) 2.0 tools

This package includes tools to use for interacting with TPM chips for
various purposes, such as for attestation, key management, encryption
or signing.

Since there seems to be a growing number of TPM-related packages in
Debian it may be useful to combine efforts in a team.

Bug#815846: ITP: tpm2-tss -- TPM (Trusted Platform Module) 2.0 Software Stack

[Mathieu Trudel-Lapierre]

Package: wnpp
Severity: wishlist
Owner: "Mathieu Trudel-Lapierre" <mathieu...@gmail.com>

* Package name: tpm2-tss
  Version : 0.9.8
  Upstream Author : Will Arthur <will.c.art...@intel.com>
* URL : https://github.com/01org/TPM2.0-TSS
* License : MIT/BSD
  Programming Lang: C, C++
  Description : TPM (Trusted Platform Module) 2.0 Software Stack

TPM2.0-TSS is a software stack comprising a few layers:
 - Feature API (FAPI)
 - Enhanced System API (ESAPI)
 - System API (SAPI)
 - TPM Command Transmission Interface (TCTI)
 - Trusted Access Broker/Resource Manager (TAB/RM)

These are used to interface with TPM chips to provide specific cryptographic
services to the system in a secure manner.

TPM2.0-TSS is a requirement (for tss2 and tcti) for tpm2-tools (TPM2.0-tools),
for which I will file another ITP.

It may be relevant here to merge efforts for maintaining TPM tools in a team,
there has been lots of work by pollux in maintaining the trousers stack for
which this project seeks to be an improvement / evolution.

Bug#808791: gummi: May ship in invalid directories after autoreconf

[Mathieu Trudel-Lapierre]

Package: gummi
Version: 0.6.5-6
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu xenial ubuntu-patch

Dear Maintainer,

In Ubuntu, I've noticed that gummi tries to ship locale files in
the /usr/@DATADIRNAME@ directory, litterally.

Now, I haven't done much background investigation on this, and I suspect
it is failing in Ubuntu and not currently happening in Debian because of a
difference in the toolchain package versions.

What happens precisely is that rather than correctly replacing @DATADIRNAME@
with 'share', the value is kept unreplaced. It should be sufficient to replace
uses of $(prefix)/$(DATADIRNAME) with $(datadir).

In any case, I'm including a patch for your convenience, since I expect some
time in the future gummi may catch the same issue in Debian.

If such an occurence does happen, you'll notice lintian warnings too:
W: gummi: non-standard-dir-in-usr usr/@DATADIRNAME@/
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/ar/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/ca/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/cs/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/da/LC_MESSAGES/gummi.mo
W: gummi: file-in-unusual-dir usr/@DATADIRNAME@/locale/de/LC_MESSAGES/gummi.mo
[...]

*** /tmp/tmpcMIZb0/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/patches/upgrade_datadir.patch: replace outdated uses of
$(DATADIRNAME) with $(datadir).


Thanks for considering the patch.


-- System Information:
Debian Release: stretch/sid
  APT prefers xenial-updates
  APT policy: (500, 'xenial-updates'), (500, 'xenial-security'), (500, 
'xenial'), (100, 'xenial-backports'), (99, 'xenial-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.2.0-19-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru gummi-0.6.5/debian/patches/series gummi-0.6.5/debian/patches/series
--- gummi-0.6.5/debian/patches/series	2015-11-28 19:09:50.0 -0500
+++ gummi-0.6.5/debian/patches/series	2015-12-22 19:59:50.0 -0500
@@ -3,3 +3,4 @@
 libgthread-2.0_link.patch
 use-system-synctex.patch
 no-predictable-tmpfiles.patch
+upgrade_datadir.patch
diff -Nru gummi-0.6.5/debian/patches/upgrade_datadir.patch gummi-0.6.5/debian/patches/upgrade_datadir.patch
--- gummi-0.6.5/debian/patches/upgrade_datadir.patch	1969-12-31 19:00:00.0 -0500
+++ gummi-0.6.5/debian/patches/upgrade_datadir.patch	2015-12-22 20:26:26.0 -0500
@@ -0,0 +1,20 @@
+From: Mathieu Trudel-Lapierre <mathieu...@ubuntu.com>
+Subject: Replace outdated prefix/DATADIRNAME with just datadir.
+---
+ po/Makefile.in.in |3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+Index: b/po/Makefile.in.in
+===
+--- a/po/Makefile.in.in
 b/po/Makefile.in.in
+@@ -33,8 +33,7 @@ exec_prefix = @exec_prefix@
+ datadir = @datadir@
+ datarootdir = @datarootdir@
+ libdir = @libdir@
+-DATADIRNAME = @DATADIRNAME@
+-itlocaledir = $(prefix)/$(DATADIRNAME)/locale
++itlocaledir = $(datadir)/locale
+ subdir = po
+ install_sh = @install_sh@
+ # Automake >= 1.8 provides @mkdir_p@.

Bug#806900: partman-multipath: correct mpath device detection and bindings

[Mathieu Trudel-Lapierre]

On Wed, Dec 2, 2015 at 6:51 PM, Cyril Brulebois <k...@debian.org> wrote:

> Hi,
>

[...]


> > Below you can find a patch that solves both problems.  Feedback is
> welcome.
>
> Mathieu mentioned branches a while ago:
>   https://lists.debian.org/debian-boot/2015/05/msg00271.html
>
>
That's spot on, it's exactly what is needed in partman-multipath.

Still, shouldn't we also copy over the wwids file from the installer onto
the target?

hw-detect needs a similar change, which I've already done at [1], and some
changes for the output of multipath -l in partman-base at [2].

[1]
http://anonscm.debian.org/cgit/d-i/hw-detect.git/commit/?h=people/cyphermox/mpath-detect
[2]
http://anonscm.debian.org/cgit/d-i/partman-base.git/log/?h=people/cyphermox/multipath5

Mathieu Trudel-Lapierre <mathieu...@gmail.com>
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C  80D3 C7DA A946 DC95 CA5A

Bug#649772: libdoxia-java: FTBFS in a restrictive chroot

[Mathieu Trudel-Lapierre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 21 Feb 2015 23:14:02 +0100 Emmanuel Bourg <ebo...@apache.org>
wrote:
> Hi Artur,
> 
> Thank you for forwarding this patch. Do you have more details on
> the build failure it solves? I'm asking because it builds fine in
> Debian so far.
> 
> 

doxia builds would fail on Ubuntu because the buildds don't have
network access and we only do source builds; because of this it
wouldn't be able to find the required dependencies for build.

So, the changes did a few things:

- - tell maven to work offline
- - Add libjaxen-java and libmave-install-plugin-java
- - import built jars back into the maven repo
- - add doxia-logging-api which appeared to be needed for building
documentation.

However, I just sent two builds of doxia to the Ubuntu builders
(effectively, having them build 1.1.4-3 as-is), and things are working
fine. Feel free to close the bug without applying any of the proposed
changes :)

Regards,

- -- 
Mathieu Trudel-Lapierre <mathieu...@gmail.com>
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/DC95CA5A 36E2 CF22 B077 FEFE 725C  80D3 C7DA A946 DC95 CA5A
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBCAAGBQJV5I9aAAoJEMfaqUbclcpaBZAQAKX6tHJMLlmsxyai8T3n587h
kBKSJcUsGGoNV3tfTSkvxQr6WslGBETAtoMInLS/X5hqpKsWKfJnoKS5wXGuvUIJ
Zjf+Smh7PBpn1rf1j6Pu4vPbtFOKDaMsEXHYDVRLcdObQqJ10pdGNJljDyG3RgvF
UdK6LRJz3PHXsC0HaVPqr3QZAjaAZ8ylkHG+/LRqQt+e9w/wZO+jPwUFqkphYTa8
b6yh7KveITuT2H1KYD2FCK4LC1kVZpL+3L7DDjYpDHy8oal78ghiUQWUfscZNfXq
lMToouPCLoRDHdHBEbfIIO7WEfyFtKCVHJcMTdyI3lphja/NQVAfJI6amtYlilyS
Fe4WYWQmAhVe1zsPNRWE/4OwvdC+amRTe+rLP7lCtM+vPTxrEyCgut1vHkm3UEwf
rODDS7Ib+ayN8RjHbJ7Ijv7yHF7v/J7IlcNnS5e9PaKxZx7FAHbUx1sEtwBVnMV6
El2iMvL9jU/IsEbTZFIgZUEqdIhb7urkjJ/ItbsS+xmbjmg0G0ZbIx9IYfdPDQJP
9Vn0rvncra/h6Hhqt/znXdoZjj/RDvzvRqGnCo5PzG9YgBK+zSnq5KNG/vn7WXm6
O03HMN6+31hAycQhypsEEwtEpANuiW75KQg+WiqJ9eDF7qwxIUc/c57MPfVSqzH0
xnbQnQxGvGrZc62oGPlB
=1idB
-END PGP SIGNATURE-

Bug#795990: pytsk: inlining Object_init breaks importing pytsk3

[Mathieu Trudel-Lapierre]

Package: pytsk
Version: 20150406-2
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch

Dear Maintainer,

While doing a rebuild of pytsk to unblock a few things as part of the GCC 5
transition; I've tried running one of the tsk examples (istat, specifically),
and noticed that pytsk3 doesn't import at all:

$ python -c 'import pytsk3'
Traceback (most recent call last):
  File string, line 1, in module
ImportError: /usr/lib/python2.7/dist-packages/pytsk3.x86_64-linux-gnu.so: 
undefined symbol: Object_init

I've added the patch used, as proposed upstream, to solve the issue:

  * debian/patches/fix_object_init_undefined.patch: don't inline Object_init,
doing so breaks importing pytsk3.

This was noticed specifically when unblocking the following:
 afflib/3.7.6-2ubuntu2
 xmount/0.7.3-1build1
 sleuthkit/4.1.3-11ubuntu2
 dff/1.3.0+dfsg.1-4.1build3
 pytsk/ppc64el/20150406-2

The above don't appear to include any special Ubuntu patches that would affect
pytsk aside from the GCC 5 transition.

Thanks for considering the patch.


-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports'), (99, 'wily-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-3-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru pytsk-20150406/debian/patches/fix_object_init_undefined.patch pytsk-20150406/debian/patches/fix_object_init_undefined.patch
--- pytsk-20150406/debian/patches/fix_object_init_undefined.patch	1970-01-01 01:00:00.0 +0100
+++ pytsk-20150406/debian/patches/fix_object_init_undefined.patch	2015-08-18 15:27:36.0 +0200
@@ -0,0 +1,41 @@
+From: Mathieu Trudel-Lapierre mathieu...@ubuntu.com
+Subject: Don't inline Object_init
+
+Inlining here, at least when building with GCC as we do; makes the Object_init
+symbols not be found.
+
+https://github.com/py4n6/pytsk/wiki/Building mentions removing the inline
+keywords to fix the issue; and building with clang already wouldn't inline
+this.
+
+---
+ class.c |2 +-
+ class.h |2 +-
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+Index: b/class.c
+===
+--- a/class.c
 b/class.c
+@@ -22,7 +22,7 @@
+ // Noone should instantiate Object directly. this should be already
+ // allocated therefore:
+ 
+-DLL_PUBLIC PYTSK_INLINE void Object_init(Object this) {
++DLL_PUBLIC void Object_init(Object this) {
+   this-__class__ = __Object;
+   this-__super__ = NULL;
+ };
+Index: b/class.h
+===
+--- a/class.h
 b/class.h
+@@ -371,7 +371,7 @@ struct Object_t {
+ #define CLASSOF(obj)\
+   ((Object)obj)-__class__
+ 
+-DLL_PUBLIC PYTSK_INLINE void Object_init(Object);
++DLL_PUBLIC void Object_init(Object);
+ 
+ DLL_PUBLIC extern struct Object_t __Object;
+ 
diff -Nru pytsk-20150406/debian/patches/series pytsk-20150406/debian/patches/series
--- pytsk-20150406/debian/patches/series	1970-01-01 01:00:00.0 +0100
+++ pytsk-20150406/debian/patches/series	2015-08-18 15:17:02.0 +0200
@@ -0,0 +1 @@
+fix_object_init_undefined.patch

Bug#795596: syslinux 6.03 generates unbootable binaries

[Mathieu Trudel-Lapierre]

Package: syslinux
Version: 3:6.03+dfsg-8
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu wily ubuntu-patch

Dear Maintainer,

It looks like syslinux 6.03, especially when built with GCC 5, produces
unbootable binaries. We noticed this in Ubuntu; I've applied the cherry-picked
upstream patch attached which appears to solve the problem.

Thanks for considering the patch.


-- System Information:
Debian Release: jessie/sid
  APT prefers wily-updates
  APT policy: (500, 'wily-updates'), (500, 'wily-security'), (500, 'wily'), 
(100, 'wily-backports'), (99, 'wily-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.1.0-3-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
diff -Nru syslinux-6.03+dfsg/debian/patches/0001-SYSAPPEND-Fix-space-stripping.patch syslinux-6.03+dfsg/debian/patches/0001-SYSAPPEND-Fix-space-stripping.patch
--- syslinux-6.03+dfsg/debian/patches/0001-SYSAPPEND-Fix-space-stripping.patch	1970-01-01 01:00:00.0 +0100
+++ syslinux-6.03+dfsg/debian/patches/0001-SYSAPPEND-Fix-space-stripping.patch	2015-08-13 20:40:07.0 +0200
@@ -0,0 +1,58 @@
+From 3106dcd19061b4443c5beba4f0e09412e8d37fbe Mon Sep 17 00:00:00 2001
+From: Dany St-Amant dany.ephemeral.2...@icloud.com
+Date: Fri, 28 Nov 2014 13:48:32 -0500
+Subject: [PATCH] SYSAPPEND: Fix space stripping
+
+The description of SYSAPPEND for the DMI information states that the spaces
+are replaced by underscores, but this replacement does not occur in 6.03.
+
+Signed-off-by: Dany St-Amant dany.ephemeral.2...@icloud.com
+Signed-off-by: Gene Cumm gene.c...@gmail.com
+---
+ com32/elflink/ldlinux/readconfig.c | 2 +-
+ com32/menu/readconfig.c| 2 +-
+ core/sysappend.c   | 2 +-
+ 3 files changed, 3 insertions(+), 3 deletions(-)
+
+diff --git a/com32/elflink/ldlinux/readconfig.c b/com32/elflink/ldlinux/readconfig.c
+index 347f826..24f1cc9 100644
+--- a/com32/elflink/ldlinux/readconfig.c
 b/com32/elflink/ldlinux/readconfig.c
+@@ -330,7 +330,7 @@ static char *copy_sysappend_string(char *dst, const char *src)
+ char c;
+ 
+ while ((c = *src++)) {
+-	if (c = ' '  c == '\x7f') {
++	if (c = ' ' || c == '\x7f') {
+ 	if (!was_space)
+ 		*dst++ = '_';
+ 	was_space = true;
+diff --git a/com32/menu/readconfig.c b/com32/menu/readconfig.c
+index b7814be..257b042 100644
+--- a/com32/menu/readconfig.c
 b/com32/menu/readconfig.c
+@@ -299,7 +299,7 @@ static char *copy_sysappend_string(char *dst, const char *src)
+ char c;
+ 
+ while ((c = *src++)) {
+-	if (c = ' '  c == '\x7f') {
++	if (c = ' ' || c == '\x7f') {
+ 	if (!was_space)
+ 		*dst++ = '_';
+ 	was_space = true;
+diff --git a/core/sysappend.c b/core/sysappend.c
+index 5c3f650..758703e 100644
+--- a/core/sysappend.c
 b/core/sysappend.c
+@@ -35,7 +35,7 @@ static char *copy_and_mangle(char *dst, const char *src)
+ char c;
+ 
+ while ((c = *src++)) {
+-	if (c = ' '  c == '\x7f') {
++	if (c = ' ' || c == '\x7f') {
+ 	if (!was_space)
+ 		*dst++ = '_';
+ 	was_space = true;
+-- 
+2.5.0
+
diff -Nru syslinux-6.03+dfsg/debian/patches/series syslinux-6.03+dfsg/debian/patches/series
--- syslinux-6.03+dfsg/debian/patches/series	2015-04-07 07:24:26.0 +0200
+++ syslinux-6.03+dfsg/debian/patches/series	2015-08-13 20:46:07.0 +0200
@@ -4,3 +4,4 @@
 0004-gnu-efi-git.patch
 0005-load-linux-correct-type.patch
 0006-load-linux-protected-mode.patch
+0001-SYSAPPEND-Fix-space-stripping.patch

Bug#789826: Patch attached

[Mathieu Trudel-Lapierre]

Hi,

Admittedly, this is a rather heavy-handed approach, but changing epsilon
for the Collinear() calls to 1e-3 instead of 1e-4 lets the builds complete
successfully on all architectures, including i386.

This appears to be as being related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=323 , in other words, because
the CrossProduct as it is being calculated is probably having values
rounded multiple times.

Attached is a patch that has been applied on Ubuntu to change the epsilon
value used for the Line2 tests.

I think this warrants being brought up to the upstream too, perhaps they
have a preferred way of dealing with this.

Kindly,

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: Allow for a bit more rounding when verifying collinearity

---
 src/Line2_TEST.cc |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Index: b/src/Line2_TEST.cc
===
--- a/src/Line2_TEST.cc
+++ b/src/Line2_TEST.cc
@@ -147,7 +147,7 @@ TEST(Line2Test, CollinearPoint)
 
   pt.Set(0, 0.1);
   EXPECT_FALSE(lineA.Collinear(pt));
-  EXPECT_TRUE(lineA.Collinear(pt, 1e-4));
+  EXPECT_TRUE(lineA.Collinear(pt, 1e-3));
   {
 math::Line2d ptLine(pt, pt);
 EXPECT_FALSE(lineA.Collinear(ptLine));
@@ -159,7 +159,7 @@ TEST(Line2Test, CollinearPoint)
 
   pt.Set(0, -0.1);
   EXPECT_FALSE(lineA.Collinear(pt));
-  EXPECT_TRUE(lineA.Collinear(pt, 1e-4));
+  EXPECT_TRUE(lineA.Collinear(pt, 1e-3));
   {
 math::Line2d ptLine(pt, pt);
 EXPECT_FALSE(lineA.Collinear(ptLine));

Bug#783977: partman-auto: should create efi partitions as fat32 rather than free

[Mathieu Trudel-Lapierre]

Package: partman-auto
Severity: normal
Tags: patch

Dear Maintainer,

It looks like partman-auto, in the recipe-amd64-efi recipes, uses free
rather than say, fat32 as a partition type for the EFI partitions it tries
to create. This has the unfortunate side-effect of not letting partman-efi do
all that it may try to do, such as setting a name for the EFI partition (see
partman-efi's update.d/efi_sync_flag). This happens because decode_recipe
defaults to using 'ext2' to describe that partition, which doesn't match
partman-efi's checks.

A patch is attached.


-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.19.0-15-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
From c717f8418513a268c708b496dccb80422a385eaf Mon Sep 17 00:00:00 2001
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Date: Fri, 1 May 2015 14:58:24 -0400
Subject: [PATCH] Initially define efi partitions as fat32 for amd64/i386

---
 recipes-amd64-efi/atomic | 2 +-
 recipes-amd64-efi/home   | 2 +-
 recipes-amd64-efi/multi  | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-amd64-efi/atomic b/recipes-amd64-efi/atomic
index 2e81c4f..2995fa2 100644
--- a/recipes-amd64-efi/atomic
+++ b/recipes-amd64-efi/atomic
@@ -1,6 +1,6 @@
 partman-auto/text/atomic_scheme ::
 
-538 538 1075 free
+538 538 1075 fat32
 	$iflabel{ gpt }
 	$reusemethod{ }
 	method{ efi }
diff --git a/recipes-amd64-efi/home b/recipes-amd64-efi/home
index ed12a51..77a49b3 100644
--- a/recipes-amd64-efi/home
+++ b/recipes-amd64-efi/home
@@ -1,6 +1,6 @@
 partman-auto/text/home_scheme ::
 
-538 538 1075 free
+538 538 1075 fat32
 	$iflabel{ gpt }
 	$reusemethod{ }
 	method{ efi }
diff --git a/recipes-amd64-efi/multi b/recipes-amd64-efi/multi
index 37e03d6..bb3ff08 100644
--- a/recipes-amd64-efi/multi
+++ b/recipes-amd64-efi/multi
@@ -1,6 +1,6 @@
 partman-auto/text/multi_scheme ::
 
-538 538 1075 free
+538 538 1075 fat32
 	$iflabel{ gpt }
 	$reusemethod{ }
 	method{ efi }
-- 
2.1.4

Bug#769327: jansson doc needlessly Depends on libjs-backbone

[Mathieu Trudel-Lapierre]

Package: jansson
Version: 2.7-1
Severity: minor
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu vivid ubuntu-patch

Dear Maintainer,

When looking at the Depends for each of the binary packages shipped by the
jansson source, I noticed libjs-backbone. This package sticked out in Ubuntu
because it's the only package that wasn't in the main component.

I dug in a bit more, and while trying to see if libjs-backbone was really
required I noticed it's not used anywhere by the documentation itself; unlike
other depends (jquery, etc.), it's not sourced by the html at all; a quick
grep for backbone in /usr/share/doc/libjansson-doc/ proves this.

This made me conclude that while libjs-backbone may have been required before,
it is no longer a requirement in version 2.7, and may thus be removed so as
not to install additional packages for no reason.

Thanks!

*** /tmp/tmpfvbS6m/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * Don't pull in libjs-backbone (LP: #1392025)
- debian/control: don't have libjansson-doc Depends on libjs-backbone.
- debian/libjansson-doc.links: don't add links to backbone.js.


Thanks for considering the patch.


-- System Information:
Debian Release: jessie/sid
  APT prefers vivid-updates
  APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), 
(100, 'vivid-proposed'), (100, 'vivid-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.16.0-24-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'debian/changelog'

=== modified file 'debian/control'
--- a/debian/control	2013-12-22 15:31:36 +
+++ b/debian/control	2014-11-12 20:41:56 +
@@ -45,7 +46,6 @@ Package: libjansson-doc
 Section: doc
 Architecture: all
 Depends: ${misc:Depends},
- libjs-backbone,
  libjs-jquery,
  libjs-underscore,
  libjs-sphinxdoc (= 1.0)

=== modified file 'debian/libjansson-doc.links'
--- a/debian/libjansson-doc.links	2012-01-27 21:54:54 +
+++ b/debian/libjansson-doc.links	2014-11-12 19:26:32 +
@@ -1,3 +1,2 @@
 /usr/share/javascript/jquery/jquery.js /usr/share/doc/libjansson-doc/html/_static/jquery.js
 /usr/share/javascript/underscore/underscore.js /usr/share/doc/libjansson-doc/html/_static/underscore.js
-/usr/share/javascript/backbone/backbone.js /usr/share/doc/libjansson-doc/html/_static/backbone.js

Bug#759045: congruity: updated patch

[Mathieu Trudel-Lapierre]

On Sep 12, 2014 6:48 PM, Olly Betts o...@survex.com wrote:


 Mathieu:  We have a tested fix now, and one with upstream's blessing.  Let
 me know if you'd like me to NMU it.


Yes, Olly, please feel free to NMU it.

Cheers,

/ Matt

Bug#751594: [Pkg-utopia-maintainers] Bug#751594: network-manager: dnsmasq incompatible with network manager and systemd

[Mathieu Trudel-Lapierre]

On Sat, Jun 14, 2014 at 4:30 PM, Vincent Bernat ber...@debian.org wrote:
[...]
 So, NetworkManager checks if somebody is listening to the right DBus
 address. With Debian and systemd, since dnsmasq is DBus enabled, it will
 be started at this point. Otherwise, the patch also tries to run dnsmasq
 itself.

 Then, there is another patch to use a private DBus name to avoid using
 dnsmasq from the system I suppose. The relevant entry is here:


Exactly. The issue is that it's not just incompatible with systemd,
but more or less with just about any other dnsmasq instance that could
be started either with just installing the dnsmasq package (regardless
of it actually being properly configured and in use), in some ways
incompatible with the libvirtd / qemu instances of dnsmasq... In
general, it's just not necessarily meant for running multiple
instances of dnsmasq that speak to each other.

 network-manager (0.9.6.0-0ubuntu4) quantal; urgency=low

   * debian/patches/dns-dnsmasq-interface-and-dbus-path.patch: set the address
 dnsmasq (and bind) plugins should listen on for DNS resolution to 
 127.0.1.1,
 as opposed to 127.0.0.1 to avoid conflicts with other instances that might
 need to run on the system with that address.
 Also set the dnsmasq DBus service name to our own custom name:
 org.freedesktop.NetworkManager.dnsmasq, which will also avoid conflicting
 with other dnsmasq instances which might have --enable-dbus enabled.
 (LP: #1034946)

  -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com  Tue, 21 Aug 2012 
 11:45:46 -0400

 Maybe Mathieu (in copy) can tell us if this has been forwarded upstream.


It hasn't yet -- upstreaming the dnsmasq patches I wrote is still a
work in progress: I've started to prepare clean patches in a pristine
git tree, but I can't put time in fast enough to keep up with master.

You'll likely also want to have the patch to configure dnsmasq via
DBus rather than restarting it all the time, and that's the one that
needs to most work, I wanted to update it to use the SetServersEx
instead of SetServers DBus method; which would avoid a minor
regression.

So, to quickly get the patches you could use the ones from trusty or
utopic, they should apply cleanly to the version in unstable.

Regards,

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


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

Bug#726935: network-manager-gnome: nm-connection-editor segfaults when importing .ovpn config

[Mathieu Trudel-Lapierre]

Seems to me like the problem is simply that there is a missing
parameter to vpn_connection_import(). It should in effect have about
the same signature as vpn_connection_new().

The attached updated patch seems to fix the issue. (Taken from Ubuntu,
against n-m-applet 0.9.8.8)


Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Josselin Mouette j...@debian.org
Subject: Set passwords as agent-owned when they need to, to allow users
without modify.system permissions to easily configure their connections.
Last-Update: 2014-03-18

---
 src/applet-device-wifi.c|   25 +
 src/connection-editor/ce-page.h |1 +
 src/connection-editor/new-connection.c  |2 ++
 src/connection-editor/page-bond.c   |1 +
 src/connection-editor/page-bond.h   |1 +
 src/connection-editor/page-bridge.c |1 +
 src/connection-editor/page-bridge.h |1 +
 src/connection-editor/page-dsl.c|1 +
 src/connection-editor/page-dsl.h|1 +
 src/connection-editor/page-ethernet.c   |1 +
 src/connection-editor/page-ethernet.h   |1 +
 src/connection-editor/page-infiniband.c |1 +
 src/connection-editor/page-infiniband.h |1 +
 src/connection-editor/page-mobile.c |   11 +++
 src/connection-editor/page-mobile.h |1 +
 src/connection-editor/page-vlan.c   |1 +
 src/connection-editor/page-vlan.h   |1 +
 src/connection-editor/page-vpn.c|   11 +++
 src/connection-editor/page-vpn.h|2 ++
 src/connection-editor/page-wifi.c   |   14 ++
 src/connection-editor/page-wifi.h   |1 +
 src/connection-editor/page-wimax.c  |1 +
 src/connection-editor/page-wimax.h  |1 +
 src/gnome-bluetooth/nma-bt-device.c |5 +
 src/libnm-gtk/nm-wifi-dialog.c  |4 
 src/mobile-helpers.c|3 +++
 src/utils/utils.c   |7 +++
 src/utils/utils.h   |3 +++
 src/wireless-security/ws-wep-key.c  |7 +++
 src/wireless-security/ws-wpa-psk.c  |5 +
 30 files changed, 116 insertions(+)

Index: b/src/applet-device-wifi.c
===
--- a/src/applet-device-wifi.c
+++ b/src/applet-device-wifi.c
@@ -577,6 +577,7 @@ _do_new_auto_connection (NMApplet *apple
 	NMSettingWirelessSecurity *s_wsec = NULL;
 	NMSetting8021x *s_8021x = NULL;
 	const GByteArray *ssid;
+	NM80211ApFlags flags;
 	NM80211ApSecurityFlags wpa_flags, rsn_flags;
 	GtkWidget *dialog;
 	MoreInfo *more_info;
@@ -603,6 +604,7 @@ _do_new_auto_connection (NMApplet *apple
 	/* If the AP is WPA[2]-Enterprise then we need to set up a minimal 802.1x
 	 * setting and ask the user for more information.
 	 */
+	flags = nm_access_point_get_flags (ap);
 	rsn_flags = nm_access_point_get_rsn_flags (ap);
 	wpa_flags = nm_access_point_get_wpa_flags (ap);
 	if (   (rsn_flags  NM_802_11_AP_SEC_KEY_MGMT_802_1X)
@@ -634,6 +636,29 @@ _do_new_auto_connection (NMApplet *apple
 		nm_connection_add_setting (connection, NM_SETTING (s_8021x));
 	}
 
+	if (utils_default_to_private_connection (applet-nm_client)) {
+		if (!s_con) {
+			s_con = (NMSettingConnection *) nm_setting_connection_new ();
+			nm_connection_add_setting (connection, NM_SETTING (s_con));
+		}
+		nm_setting_connection_add_permission (s_con, user, g_get_user_name (), NULL);
+
+		if ((rsn_flags  NM_802_11_AP_SEC_KEY_MGMT_PSK) ||
+		(wpa_flags  NM_802_11_AP_SEC_KEY_MGMT_PSK)) {
+			if (!s_wsec) {
+s_wsec = (NMSettingWirelessSecurity *) nm_setting_wireless_security_new ();
+nm_connection_add_setting (connection, NM_SETTING (s_wsec));
+			}
+			g_object_set (s_wsec, NM_SETTING_WIRELESS_SECURITY_PSK_FLAGS, NM_SETTING_SECRET_FLAG_AGENT_OWNED, NULL);
+		} else if (flags  NM_802_11_AP_FLAGS_PRIVACY) {
+			if (!s_wsec) {
+s_wsec = (NMSettingWirelessSecurity *) nm_setting_wireless_security_new ();
+nm_connection_add_setting (connection, NM_SETTING (s_wsec));
+			}
+			g_object_set (s_wsec, NM_SETTING_WIRELESS_SECURITY_WEP_KEY_FLAGS, NM_SETTING_SECRET_FLAG_AGENT_OWNED, NULL);
+		}
+	}
+
 	/* If it's an 802.1x connection, we need more information, so pop up the
 	 * Dialog Of Doom.
 	 */
Index: b/src/connection-editor/ce-page.h
===
--- a/src/connection-editor/ce-page.h
+++ b/src/connection-editor/ce-page.h
@@ -48,6 +48,7 @@ typedef void (*PageNewConnectionFunc) (G
const char *detail,
NMRemoteSettings *settings,
PageNewConnectionResultFunc result_func,
+   NMClient *client,
gpointer user_data);
 
 #define CE_TYPE_PAGE

Bug#731851: modemmanager: Please update to latest 1.2 release candidate

[Mathieu Trudel-Lapierre]

On Wed, Feb 5, 2014 at 2:50 AM, Guido Günther a...@sigxcpu.org wrote:
[...]
 I have just imported at least all versions available from
 snapshots.debian.org so we have some history. Would it be o.k. to push
 this now to alioth even before we released a version?

Yes, it's fine.

[...]

 I think we should target experimental first but it's your call as
 maintainers.

Agreed.


Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


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

Bug#731851: modemmanager: Please update to latest 1.2 release candidate

[Mathieu Trudel-Lapierre]

On Tue, Feb 4, 2014 at 4:06 PM, Michael Biebl bi...@debian.org wrote:
[...]
 1.2.0 is out now. I was able to build a package with the attached two
 minor patches. I can try to find the time to NMU to experimental.

 I did some more cleanups. The code is available at:

 https://honk.sigxcpu.org/gitweb/?p=scratchbuilds/modemmanager.git
 git://honk.sigxcpu.org/git/scratchbuilds/modemmanager.git


I think we should be fine to start with this for the tree in
collab-maint, once it's uploaded?

[...]

 Matthieu, would you be open to moving the debian maintenance into
 collab-maint/modemmanager.git on alioth so Guido can commit directly to it?

 I haven't done any MM related work lately and it's unlikely to change atm.

Sure, let's.

I'm trying to avoid delta between Ubuntu and Debian for MM though, so
we should make sure nothing important went missing for Debian or
Ubuntu.

Also, what about the story with the KDE team? Are they ready to
probably break plasma-nm/libmm-qt if we land 1.2 in sid? 1.0 is still
only in experimental...

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


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

Bug#729934: wpasupplicant: please consider providing debug packages

[Mathieu Trudel-Lapierre]

Package: wpasupplicant
Version: 1.0-3ubuntu4
Severity: wishlist

Dear Maintainer,

I was debugging an issue we got in Ubuntu due to enabling CONFIG_P2P... Turns
out it's fairly complicated to debug issues in wpa when they are reported,
since most people won't have debug symbols installed for wpasupplicant.

It would be useful to provide wpasupplicant-dbg at least to allow installing
the debug packages.


-- System Information:
Debian Release: wheezy/sid
  APT prefers trusty-updates
  APT policy: (500, 'trusty-updates'), (500, 'trusty-security'), (500, 
'trusty'), (100, 'trusty-backports'), (50, 'trusty-proposed')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
armhf

Kernel: Linux 3.12.0-1-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wpasupplicant depends on:
ii  adduser   3.113+nmu3ubuntu2
ii  initscripts   2.88dsf-41ubuntu3
ii  libc6 2.17-93ubuntu4
ii  libdbus-1-3   1.6.12-0ubuntu10
ii  libnl-3-200   3.2.16-0ubuntu1
ii  libnl-genl-3-200  3.2.16-0ubuntu1
ii  libpcsclite1  1.8.6-3ubuntu1b1
ii  libreadline5  5.2+dfsg-2
ii  libssl1.0.0   1.0.1e-3ubuntu1
ii  lsb-base  4.1+Debian11ubuntu4

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  none
pn  wpaguinone

-- no debconf information


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

Bug#700588: modemmanager 0.7 for debian experimental?

[Mathieu Trudel-Lapierre]

On Mon, Mar 11, 2013 at 7:39 PM, Andreas Henriksson andr...@fatal.sewrote:

 On Mon, Mar 11, 2013 at 03:59:39PM -0400, Mathieu Trudel-Lapierre wrote:
 [...]
 
 I started doing some work on Ubuntu for this. It's interesting
 though, as
 it's usually Michael who handles modemmanager directly in Debian.

 Michael is one of the primary reasons he pointed to you is that he
 is very busy right now with other things (also mentioning bzr).


Fair enough. I started, or more precisely cleaned up what I had a bit and
rebased on 0.7.990; it builds here on Ubuntu and I shipped it to a PPA to
build cleanly:

https://launchpad.net/~network-manager/+archive/modemmanager-next/+sourcepub/3023373/+listing-archive-extra

It builds fine in sbuild here with libqmi 1.0-1. I'll track it later to see
whether it completes this build. Then there is some work done by Marius
Kotsbak I'll merge, and I'll be ready for constructive criticism (ie.
sponsoring).

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93

Bug#694821: urfkill: init script points to the wrong path to urfkilld

[Mathieu Trudel-Lapierre]

Package: urfkill
Version: 0.4.0-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu raring ubuntu-patch

Dear Maintainer,

The init script for urfkilld has /usr/triplet/urfkill/urfkilld as a path
to the urfkilld binary. This path is missing lib/.

Furthermore, it seems to me like DEB_HOST_MULTIARCH doesn't need to be
redefined, it should already be available with dh 9.

*** /tmp/tmpSBshPp/bug_body

In Ubuntu, the attached patch was applied to achieve the following:

  * debian/rules: clean up sample comments, simplify rules to make use of
DEB_HOST_MULTIARCH as it is already available.
  * debian/urfkill.init.in: fix typo: add lib/ to the multiarch path to the
urfkilld binary.


Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers raring-updates
  APT policy: (500, 'raring-updates'), (500, 'raring-security'), (500, 
'raring'), (100, 'raring-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.5.0-17-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'debian/rules'
--- debian/rules	2012-07-24 22:48:51 +
+++ debian/rules	2012-11-30 17:09:53 +
@@ -1,20 +1,11 @@
 #!/usr/bin/make -f
 # -*- makefile -*-
-# Sample debian/rules that uses debhelper.
-# This file was originally written by Joey Hess and Craig Small.
-# As a special exception, when this file is copied by dh-make into a
-# dh-make output file, you may use that output file without restriction.
-# This special exception was added by Craig Small in version 0.37 of dh-make.
 
 # Uncomment this to turn on verbose mode.
 #export DH_VERBOSE=1
 
 export DEB_BUILD_HARDENING=1
 
-DEB_HOST_MULTIARCH ?= $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)
-
-.PHONY: override_dh_strip override_dh_auto_clean override_dh_auto_configure
-
 debian/urfkill.init: debian/urfkill.init.in
 	sed -e s/@DEB_HOST_MULTIARCH@/$(DEB_HOST_MULTIARCH)/g $?  debian/`basename $? .in`
 	chmod 755 $@

=== modified file 'debian/urfkill.init.in'
--- debian/urfkill.init.in	2012-07-24 22:48:51 +
+++ debian/urfkill.init.in	2012-11-30 17:02:12 +
@@ -14,7 +14,7 @@
 PATH=/sbin:/usr/sbin:/bin:/usr/bin
 DESC=urfkill # Introduce a short description here
 NAME=urfkill # Introduce the short server's name here
-DAEMON=/usr/@DEB_HOST_MULTIARCH@/urfkill/urfkilld # Introduce the server's location here
+DAEMON=/usr/lib/@DEB_HOST_MULTIARCH@/urfkill/urfkilld # Introduce the server's location here
 DAEMON_ARGS= # Arguments to run the daemon with
 PIDFILE=/var/run/$NAME.pid
 SCRIPTNAME=/etc/init.d/$NAME

Bug#675350: closed by Matteo F. Vescovi mfv.deb...@gmail.com (Re: Bug#675350: babl: Please ship additional header files)

[Mathieu Trudel-Lapierre]

 From: Matteo F. Vescovi mfv.deb...@gmail.com
 To: Mathieu Trudel-Lapierre mathieu...@ubuntu.com
 Cc: 675350-d...@bugs.debian.org
 Date: Fri, 1 Jun 2012 12:15:59 +0200
 Subject: Re: Bug#675350: babl: Please ship additional header files
 Hi!
[...]
 I've consulted upstream to see if it has some kind of sense to apply
 these changes directly on their code.
 Well, they told me that, instead of changing babl source, it would be
 better to fix gnome-scan code ;-) And I agree with them.

Thanks. I was able to investigate into this again and figured out a
way to fix gnome-scan without involving such changes to Babl.
However...


 I'm not comfortable with exposing what upstream considers private API
 just because a package is trying to misuse it. If you really need this
 API to become public, please treat the issue upstream.

None of this is specifically mentioned anywhere as being private API;
nor a misuse of the API. The Babl object is explicitly defined as a
union of the other object types to allow using internal members
without casting. It's also done the same way on the website main page.

However, I do agree that it's an issue to be brought upstream:
documentation needs to be very much clarified.

Regards, and thanks for the prompt responses;

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#675350: babl: Please ship additional header files

[Mathieu Trudel-Lapierre]

Package: babl
Version: 0.1.10-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu quantal ubuntu-patch

Dear Maintainer,

gnome-scan makes use of the Babl objects directly; expecting to be working on a 
BablFormat object. This is required to port gnome-scan to the new 
libgegl/libbabl versions; and appears to require additional header files.

To successfully port gnome-scan to the new gegl and babl libraries I've needed 
as a minimum the additional babl-classes.h file which is required to properly 
define a Babl object as a union of the other Babl types (esp. BablFormat) and 
babl-format.h (defining BablFormat itself).

*** /tmp/tmpSu1h0T/bug_body
In Ubuntu, the attached patch was applied to achieve the following:

  * debian/babl-includes.patch: add all headers files as files to ship;
otherwise some packages (gnome-scan) fail to build.

Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers quantal-updates
  APT policy: (500, 'quantal-updates'), (500, 'quantal-security'), (500, 
'quantal'), (100, 'quantal-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.4.0-3-generic (SMP w/4 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== added directory 'debian/patches'
=== added file 'debian/patches/babl-includes.patch'
--- debian/patches/babl-includes.patch	1970-01-01 00:00:00 +
+++ debian/patches/babl-includes.patch	2012-05-31 12:14:34 +
@@ -0,0 +1,40 @@
+From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
+Subject: Add more headers to files to install to /usr/include/
+
+---
+ babl/Makefile.am |5 +
+ babl/Makefile.in |5 +
+ 2 files changed, 2 insertions(+), 8 deletions(-)
+
+Index: b/babl/Makefile.am
+===
+--- a/babl/Makefile.am
 b/babl/Makefile.am
+@@ -62,10 +62,7 @@ h_sources  =\
+ 	babl-util.h
+ 
+ library_includedir=$(includedir)/babl-$(BABL_API_VERSION)/babl
+-libinc_hdrs = \
+-	babl-macros.h   \
+-	babl-types.h\
+-	babl.h
++libinc_hdrs = $(h_sources)
+ libinc_generated_hdrs = \
+ 	babl-version.h
+ library_include_HEADERS = \
+Index: b/babl/Makefile.in
+===
+--- a/babl/Makefile.in
 b/babl/Makefile.in
+@@ -385,10 +385,7 @@ h_sources = \
+ 	babl-util.h
+ 
+ library_includedir = $(includedir)/babl-$(BABL_API_VERSION)/babl
+-libinc_hdrs = \
+-	babl-macros.h   \
+-	babl-types.h\
+-	babl.h
++libinc_hdrs = $(h_sources)
+ 
+ libinc_generated_hdrs = \
+ 	babl-version.h

=== added file 'debian/patches/series'
--- debian/patches/series	1970-01-01 00:00:00 +
+++ debian/patches/series	2012-05-24 20:09:44 +
@@ -0,0 +1 @@
+babl-includes.patch

Bug#667140: concordance: ftbfs with GCC-4.7

[Mathieu Trudel-Lapierre]

On Wed, Apr 4, 2012 at 8:59 PM, Cyril Brulebois k...@debian.org wrote:
 Here's a patch to fix this FTBFS. No intent to NMU.

Thanks. I expect to get around to fixing this today, along with
updating to Concordance 0.24.


Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#627975: Status of wimax-tools ITP

[Mathieu Trudel-Lapierre]

On Mon, Jan 30, 2012 at 1:40 PM, Anton Martchukov an...@martchukov.com wrote:
 On Mon, Jan 30, 2012 at 09:32:54AM -0500, Mathieu Trudel-Lapierre wrote:

 Thanks for reply. I now have wimax hardware and wimax
 operator and want to try it, so maybe can help with pushing
 this forward up to network manager recognizing it.

 No, there's actually a serious problem, in the form of a patch needed
 in wpasupplicant to provide wimax itself.

 Are there any bug number for this?

 Wimax-tools in fact it pretty much done already, but won't help
 achieving much without the rest of the wimax SDK.

 Are there any ITP/RFPs created, so I can have a look?

(for background, the ITP for wimax-tools is just pending an upload
after sponsoring. Not really blocked by anything, but NM support for
Wimax is theoretically blocked by the Wimax SDK.)

There isn't another ITP for the wimax SDK (which I'd call wimax as a
source package). Feel free to create one, or we can collaborate to
help this go faster. The main task would be to get the wpasupplicant
patches accepted upstream.

As for the related bug in wpasupplicant:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655479

Note that wimax itself seems rather dead as a software project, hence
the lack of clear progress on this. linuxwimax.org appears largely
down if you're looking for the files and documentation; though they
are available in a git tree on freedesktop and mirrored elsewhere (see
lists.linuxwimax.org).

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#657104: opticalraytracer: FTBFS in a clean schroot

[Mathieu Trudel-Lapierre]

Package: opticalraytracer
Version: 3.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Dear Maintainer,

opticalraytracer fails to build in a clean schroot. Since the build process
removes build.xml, there is then no rule file to build the binaries. See the
build logs in Ubuntu:

https://launchpadlibrarian.net/88517645/buildlog_ubuntu-precise-i386.opticalraytracer_3.2-1_FAILEDTOBUILD.txt.gz

This happens to work when just debuild is called because dpkg-source then
re-patches in build.xml just before getting to the debian/rules build target,
which does not happen in a schroot:

dpkg-source: info: mise en place de build-xml.patch
dpkg-source: info: mise en place de jar-path.patch
dpkg-source: info: mise en place de disable-ant-propertyfile.patch
dpkg-source: info: construction de opticalraytracer à partir de 
./opticalraytracer_3.2.orig.tar.gz
dpkg-source: info: construction de opticalraytracer dans 
opticalraytracer_3.2-1ubuntu1.debian.tar.gz
dpkg-source: info: construction de opticalraytracer dans 
opticalraytracer_3.2-1ubuntu1.dsc
 debian/rules build

A simple fix to this is to have build require the patch target so that build.xml
is added back in again.

Thanks for considering the attached patch.

I've also noticed ant clean gets called at least twice when starting the build
process, I think it might be possible to simplify things to make it unnecessary
to unpatch and repatch (especially given that format 3.0 (quilt) is used).


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-9-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'debian/changelog'

=== modified file 'debian/rules'
--- debian/rules	2011-12-09 20:23:33 +
+++ debian/rules	2012-01-24 01:40:22 +
@@ -45,7 +45,7 @@
 	dh_testdir
 	touch configure-stamp
 
-build: build-stamp
+build: build-stamp patch
 
 build-stamp: configure-stamp  $(QUILT_STAMPFN)
 		dh_testdir

Bug#657104: opticalraytracer: FTBFS in a clean schroot

[Mathieu Trudel-Lapierre]

On Mon, Jan 23, 2012 at 8:57 PM, Mathieu Trudel-Lapierre
mathieu...@ubuntu.com wrote:
 Thanks for considering the attached patch.

 I've also noticed ant clean gets called at least twice when starting the build
 process, I think it might be possible to simplify things to make it 
 unnecessary
 to unpatch and repatch (especially given that format 3.0 (quilt) is used).

Actually, here's a much better patch that actually also fixes exactly that. ;)

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


rules-opticalraytracer
Description: Binary data

Bug#656669: gedit-latex-plugin: FTBFS due to latex/latex/environment.py not in POTFILES.in

[Mathieu Trudel-Lapierre]

Package: gedit-latex-plugin
Version: 3.3.2-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Dear Maintainer,

gedit-latex-plugins fails to build in the latest rebuild test for Ubuntu
precise; due to latex/latex/environment.py containing strings to be translated
but not being listed in po/POTFILES.in.

Please consider the attached patch which appears to correct the issue.

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-9-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== added file 'debian/patches/03-environment-translations.patch'
--- debian/patches/03-environment-translations.patch	1970-01-01 00:00:00 +
+++ debian/patches/03-environment-translations.patch	2012-01-20 19:28:44 +
@@ -0,0 +1,12 @@
+Index: gedit-latex-plugin/po/POTFILES.in
+===
+--- gedit-latex-plugin.orig/po/POTFILES.in	2012-01-20 14:18:32.49628 -0500
 gedit-latex-plugin/po/POTFILES.in	2012-01-20 14:28:41.421427886 -0500
+@@ -14,6 +14,7 @@
+ latex/bibtex/actions.py
+ latex/bibtex/views.py
+ latex/latex/actions.py
++latex/latex/environment.py
+ latex/latex/views.py
+ latex/outline.py
+ latex/tools/views.py

=== modified file 'debian/patches/series'
--- debian/patches/series	2011-10-04 21:00:22 +
+++ debian/patches/series	2012-01-20 19:28:16 +
@@ -1,2 +1,3 @@
 01-templates-in-systemdir.patch
 02-remove-debug.patch
+03-environment-translations.patch

Bug#656136: aether: FTBFS due to plexus-component-metadata

[Mathieu Trudel-Lapierre]

Package: aether
Version: 1.13.1-1
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Dear Maintainer,

aether appears to fail to build because maven can't parse the version number
associated with the plexus-component-metadata plugin. debian/maven.rules
specifies it as 1.5.x like others, but this doesn't appear to work. Setting
the version number to 1.5.5 specifically for plexus-component-metadata lets
the build complete successfully.

Thanks for considering this patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-8-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== modified file 'debian/maven.rules'
--- debian/maven.rules	2011-12-10 00:45:07 +
+++ debian/maven.rules	2012-01-12 13:22:29 +
@@ -18,7 +18,7 @@
 
 org.codehaus.plexus plexus-classworlds jar s/2\..*/2.x/ * *
 org.codehaus.plexus plexus-component-annotations jar s/.*/1.5.x/ * *
-org.codehaus.plexus plexus-component-metadata maven-plugin s/.*/1.5.x/ * *
+org.codehaus.plexus plexus-component-metadata maven-plugin s/.*/1.5.5/ * *
 org.codehaus.plexus plexus-utils jar s/2\..*/2.x/ * *
 
 junit junit jar s/.*/4.x/

Bug#655935: activiz.net: Please use debians default csharp compiler

[Mathieu Trudel-Lapierre]

Package: activiz.net
Version: 1:1.0~git2023-1
Followup-For: Bug #655935
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

I think this can be rather easily achieved by just patching the upstream
CMakelist to look for mono-csc rather than just csc. I've attached the
patch we've added in Ubuntu to resolve the issue.

Thanks for considering the patch.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-8-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
=== added file 'debian/patches/mono-csc-path.patch'
--- debian/patches/mono-csc-path.patch	1970-01-01 00:00:00 +
+++ debian/patches/mono-csc-path.patch	2012-01-12 12:44:08 +
@@ -0,0 +1,16 @@
+From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
+Subject: Fix name for the mono-csc compiler.
+
+Index: activiz.net/CMakeLists.txt
+===
+--- activiz.net.orig/CMakeLists.txt	2012-01-11 22:24:14.52670 +0100
 activiz.net/CMakeLists.txt	2012-01-11 22:27:49.012160122 +0100
+@@ -107,7 +107,7 @@
+ INCLUDE(${Mummy_DIR}/FindCsharp.cmake)
+ 
+ IF(NOT csc_EXECUTABLE)
+-  FIND_PROGRAM(csc_EXECUTABLE csc)
++  FIND_PROGRAM(csc_EXECUTABLE mono-csc)
+ ENDIF(NOT csc_EXECUTABLE)
+ IF(NOT csc_EXECUTABLE)
+   MESSAGE(FATAL_ERROR error: C# compiler not found. csc_EXECUTABLE='${csc_EXECUTABLE}')

=== modified file 'debian/patches/series'
--- debian/patches/series	2011-10-31 15:44:31 +
+++ debian/patches/series	2012-01-11 21:27:30 +
@@ -6,3 +6,4 @@
 doxygenversion.patch
 removedoxfromall.patch
 removeusersguide.patch
+mono-csc-path.patch

Bug#655935: Apologies

[Mathieu Trudel-Lapierre]

Ah, my apologies for adding an extra patch attachment; I hadn't seen
the original report already contained one (oops).

So... Sorry ;)

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#655479: wpasupplicant: Please consider providing a libeap package.

[Mathieu Trudel-Lapierre]

Package: wpasupplicant
Version: 0.7.3-6
Severity: wishlist

Dear Maintainer,

I'm in the process of packaging wimax and wimax-tools in order to enable WiMAX
support in NetworkManager (and provide user-space libraries for manual use).

Unfortunately, the WiMAX sdk depends on a libeap package that should be built
from the wpasupplicant source. Fedora has included a patch, initially coming
from the linux-wimax people to achieve this; and mainly depends on building
wpasupplicant slightly differently and possibly providing an extra package
for a libeap library.

I've attached the patch for your convenience.

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (510, 'precise-updates'), (510, 'precise'), (500, 
'precise-updates'), (500, 'precise-security'), (500, 'precise')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-8-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages wpasupplicant depends on:
ii  adduser   3.113ubuntu2
ii  initscripts   2.88dsf-13.10ubuntu8
ii  libc6 2.13-24ubuntu2
ii  libdbus-1-3   1.4.16-1ubuntu2
ii  libnl-3-200   3.2.3-2ubuntu1
ii  libnl-genl-3-200  3.2.3-2ubuntu1
ii  libpcsclite1  1.7.4-2ubuntu1
ii  libreadline6  6.2-8
ii  libssl1.0.0   1.0.0e-2ubuntu4
ii  lsb-base  4.0-0ubuntu17

wpasupplicant recommends no packages.

Versions of packages wpasupplicant suggests:
pn  libengine-pkcs11-openssl  none
pn  wpaguinone

-- no debconf information
From 3de5e59b291b6f58317bb16736f8c0271754378e Mon Sep 17 00:00:00 2001
From: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
Date: Sat, 2 Oct 2010 00:11:51 -0700
Subject: [PATCH] eap_peer: create a libeap library, with header files and pkg-config [v2]

This adds infrastructe in src/eap_peer to make libeap.so and install
the needed header files and pkg-config files.

Now, this is quite dirty and probably not what we want in the long
term, but serves as an starting point:

 - we don't build from the wpa_supplicant directory because the
   objects the .so have to be built with -fPIC. So if you need to
   build both the binary and the library:

   make -C wpa_supplicant
   make -C src/eap_peer clean
   make -C src/eap_peer

   As I said, it's dirty -- we'd need either wpa_supplicant linking
   against the library properly (but that seems not to be desirable)
   or a multiple object build approach ala automake.

 - need to use 'override CFLAGS' in src/eap_peer/Makefile, otherwise
   any CFLAGS setting will kill the build infrastructure. I miss
   AM_CFLAGS.

 - adds 'eap_register_methods()' that will register every compiled in
   method.

Signed-off-by: Inaky Perez-Gonzalez inaky.perez-gonza...@intel.com
---
 build_release  |   12 +++
 src/eap_peer/Makefile  |  191 ++--
 src/eap_peer/eap_methods.c |  114 ++
 src/eap_peer/eap_methods.h |1 +
 src/eap_peer/libeap0.pc|   10 +++
 5 files changed, 320 insertions(+), 8 deletions(-)
 create mode 100644 src/eap_peer/libeap0.pc

diff --git a/src/eap_peer/Makefile b/src/eap_peer/Makefile
index 3651056..58c067a 100644
--- a/src/eap_peer/Makefile
+++ b/src/eap_peer/Makefile
@@ -1,11 +1,190 @@
-all:
-	@echo Nothing to be made.
+LIBEAP_NAME = libeap
+LIBEAP_CURRENT = 0
+LIBEAP_REVISION = 0
+LIBEAP_AGE = 0
+
+LIBEAP = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT).$(LIBEAP_REVISION).$(LIBEAP_AGE)
+LIBEAP_SO = $(LIBEAP_NAME).so.$(LIBEAP_CURRENT)
+
+.PHONY: all clean install uninstall
+
+all: $(LIBEAP)
+
+ifndef CC
+CC=gcc
+endif
+
+ifndef CFLAGS
+CFLAGS = -MMD -O0 -Wall -g
+endif
+
+CONFIG_TLS=openssl
+
+INCLUDE_INSTALL_DIR=/usr/include/eap_peer
+
+ifndef LIB
+LIB = lib
+endif
+
+# Got to use override all across the board, otherwise a 'make
+# CFLAGS=XX' will kill us because the command line's CFLAGS will
+# overwrite Make's and we'll loose all the infrastructure it sets.
+override CFLAGS += -I. -I.. -I../crypto -I../utils -I../common
+
+# at least for now, need to include config_ssid.h and config_blob.h from
+# wpa_supplicant directory
+override CFLAGS += -I ../../wpa_supplicant
+
+OBJS_both += ../utils/common.o
+OBJS_both += ../utils/os_unix.o
+OBJS_both += ../utils/wpa_debug.o
+OBJS_both += ../utils/base64.o
+OBJS_both += ../utils/wpabuf.o
+OBJS_both += ../crypto/md5.o
+OBJS_both += ../crypto/sha1.o
+OBJS_both += ../crypto/sha1-tlsprf.o
+OBJS_both += ../crypto/aes-encblock.o
+OBJS_both += ../crypto/aes-wrap.o
+OBJS_both += ../crypto/aes-ctr.o
+OBJS_both += ../crypto/aes-eax.o
+OBJS_both += ../crypto/aes-omac1.o
+OBJS_both += ../crypto/ms_funcs.o
+OBJS_both += ../crypto/sha256.o
+
+
+OBJS_both += ../eap_common/eap_peap_common.o
+OBJS_both += ../eap_common/eap_psk_common.o
+OBJS_both += ../eap_common/eap_pax_common.o
+OBJS_both += ../eap_common/eap_sake_common.o
+OBJS_both += ../eap_common/eap_gpsk_common.o
+OBJS_both += 

Bug#653096: quota: building against libnl3 3.2.3

[Mathieu Trudel-Lapierre]

Package: quota
Version: 4.00-1
Severity: minor

Dear Maintainer,

libnl3 3.2.3 is now in unstable. It would be nice if quota could be rebuilt
against it.

Seems like the rebuild (from testing it on Ubuntu) will require patching the
source to take into account changes in the name of the development libraries
for libnl3, as well as the split of the netlink modules into separate
libraries.

I've attached the debdiff of the changes I'm proposing for Ubuntu, which patch
the configure script to take into account the changes.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-6-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages quota depends on:
ii  debconf [debconf-2.0]  1.5.41ubuntu1
ii  e2fslibs   1.42~WIP-2011-10-16-1ubuntu1
ii  libc6  2.13-23ubuntu1
ii  libdbus-1-31.4.16-1ubuntu1
ii  libldap-2.4-2  2.4.25-4ubuntu1
ii  libnl-3-2003.2.3-2
ii  libnl-genl-3-200   3.2.3-2
ii  libwrap0   7.6.q-21
ii  lsb-base   4.0-0ubuntu17

quota recommends no packages.

Versions of packages quota suggests:
pn  libnet-ldap-perl   none
pn  rpcbind | portmap  none
diff -u quota-4.00/debian/control quota-4.00/debian/control
--- quota-4.00/debian/control
+++ quota-4.00/debian/control
@@ -1,9 +1,11 @@
 Source: quota
 Section: admin
 Priority: optional
-Maintainer: Michael Meskes mes...@debian.org
+Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
+XSBC-Original-Maintainer: Michael Meskes mes...@debian.org
 Build-Depends: debhelper (= 6.0.7~), gettext, libwrap0-dev, e2fslibs-dev,
-   po-debconf (= 0.5.0), libldap2-dev, libssl-dev, quilt (= 0.46-7), libnl3-dev,
+   po-debconf (= 0.5.0), libldap2-dev, libssl-dev, quilt (= 0.46-7),
+   libnl-3-dev, libnl-genl-3-dev,
libdbus-1-dev
 Standards-Version: 3.9.2
 Homepage: http://sourceforge.net/projects/linuxquota
diff -u quota-4.00/debian/changelog quota-4.00/debian/changelog
--- quota-4.00/debian/changelog
+++ quota-4.00/debian/changelog
@@ -1,3 +1,12 @@
+quota (4.00-1ubuntu1) UNRELEASED; urgency=low
+
+  * debian/patches/port-to-libnl3-3.2.patch: make sure we support building
+against libnl3 3.2.x; which now splits the different netlink modules.
+  * debian/control: update Build-Depends: libnl3-dev - libnl-3-dev,
+libnl-genl-3-dev.
+
+ -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com  Fri, 23 Dec 2011 11:24:35 -0500
+
 quota (4.00-1) unstable; urgency=low
 
   * New Upstream version 4.00
diff -u quota-4.00/debian/patches/series quota-4.00/debian/patches/series
--- quota-4.00/debian/patches/series
+++ quota-4.00/debian/patches/series
@@ -3,0 +4 @@
+port-to-libnl3-3.2.patch
only in patch2:
unchanged:
--- quota-4.00.orig/debian/patches/port-to-libnl3-3.2.patch
+++ quota-4.00/debian/patches/port-to-libnl3-3.2.patch
@@ -0,0 +1,72 @@
+From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
+Subject: Allow building against libnl3 3.2.x, which splits the netlink modules
+
+Index: quota/configure.in
+===
+--- quota.orig/configure.in	2011-12-23 11:47:16.999487574 -0500
 quota/configure.in	2011-12-23 11:47:17.027487575 -0500
+@@ -123,7 +123,7 @@
+ if test x$enable_netlink != xno; then
+ 	PKG_CHECK_MODULES([DBUS], [dbus-1])
+ 
+-	PKG_CHECK_MODULES([NL], [libnl-3.0], [NETLINKLIBS=$NL_LIBS $DBUS_LIBS], [NETLINKLIBS=])
++	PKG_CHECK_MODULES([NL], [libnl-3.0 libnl-genl-3.0], [NETLINKLIBS=$NL_LIBS $DBUS_LIBS CPPFLAGS=$NL_CFLAGS $CPPFLAGS], [NETLINKLIBS=])
+ 	if test -z $NETLINKLIBS -o -z $DBUS_LIBS; then
+ 		if test x$enable_netlink = xyes; then
+ 			AC_MSG_ERROR([Required libraries for quota netlink daemon not found.])
+Index: quota/configure
+===
+--- quota.orig/configure	2011-12-23 11:47:17.003487574 -0500
 quota/configure	2011-12-23 11:48:40.903492443 -0500
+@@ -3962,12 +3962,12 @@
+ pkg_cv_NL_CFLAGS=$NL_CFLAGS
+  elif test -n $PKG_CONFIG; then
+ if test -n $PKG_CONFIG  \
+-{ { $as_echo $as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \libnl-3.0\; } 5
+-  ($PKG_CONFIG --exists --print-errors libnl-3.0) 25
++{ { $as_echo $as_me:${as_lineno-$LINENO}: \$PKG_CONFIG --exists --print-errors \libnl-3.0 libnl-genl-3.0\; } 5
++  ($PKG_CONFIG --exists --print-errors libnl-3.0 libnl-genl-3.0) 25
+   ac_status=$?
+   $as_echo $as_me:${as_lineno-$LINENO}: \$? = $ac_status 5
+   test $ac_status = 0; }; then
+-  pkg_cv_NL_CFLAGS=`$PKG_CONFIG --cflags libnl-3.0 2/dev/null`
++  pkg_cv_NL_CFLAGS=`$PKG_CONFIG --cflags libnl-3.0 libnl-genl-3.0 2/dev/null`
+ else
+   pkg_failed=yes
+ fi

Bug#653021: ipvsadm: build against libnl3

[Mathieu Trudel-Lapierre]

Package: ipvsadm
Version: 1:1.25.clean-1
Severity: wishlist

Dear Maintainer,

libnl3 3.2.3 is now in Debian unstable. It would be nice if ipvsadm
could be built against it.

Attached are two patches which allow this: one debdiff from Ubuntu
changes to port to libnl3,
and an extra patch to support libnl3 3.2.x.

-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'),
(500, 'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.2.0-6-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: When building against libnl3; make sure we get the right cflags and
 libs
Forwarded: yes

Index: ipvsadm/Makefile
===
--- ipvsadm.orig/Makefile	2011-12-21 15:18:16.477534000 -0500
+++ ipvsadm/Makefile	2011-12-21 16:02:25.245788763 -0500
@@ -77,7 +77,8 @@
 OBJS		= ipvsadm.o config_stream.o dynamic_array.o
 LIBS		= $(POPT_LIB)
 ifneq (0,$(HAVE_NL))
-LIBS		+= $(shell pkg-config --libs libnl-3.0)
+INCLUDE		+= $(shell pkg-config --cflags libnl-3.0 libnl-genl-3.0)
+LIBS		+= $(shell pkg-config --libs libnl-3.0 libnl-genl-3.0)
 endif
 DEFINES		= -DVERSION=\$(VERSION)\ -DSCHEDULERS=\$(SCHEDULERS)\ \
 		  $(POPT_DEFINE)
Index: ipvsadm/libipvs/Makefile
===
--- ipvsadm.orig/libipvs/Makefile	2011-12-21 15:18:16.477534000 -0500
+++ ipvsadm/libipvs/Makefile	2011-12-21 15:59:15.08134 -0500
@@ -4,6 +4,7 @@
 CFLAGS		= -Wall -Wunused -Wstrict-prototypes -g -fPIC
 ifneq (0,$(HAVE_NL))
 CFLAGS		+= -DLIBIPVS_USE_NL
+INCLUDE  += $(shell pkg-config --cflags libnl-3.0 libnl-genl-3.0)
 endif
 
 INCLUDE		+= $(shell if [ -f ../../ip_vs.h ]; then	\
diff -u ipvsadm-1.25.clean/debian/changelog ipvsadm-1.25.clean/debian/changelog
--- ipvsadm-1.25.clean/debian/changelog
+++ ipvsadm-1.25.clean/debian/changelog
@@ -1,3 +1,9 @@
+ipvsadm (1:1.25.clean-1ubuntu2) oneiric; urgency=low
+
+  * Port to libnl3.
+
+ -- Colin Watson cjwat...@ubuntu.com  Mon, 08 Aug 2011 17:23:22 +0100
+
 ipvsadm (1:1.25.clean-1ubuntu1) natty; urgency=low
 
   * libipvs/libipvs.c: upstream patch (r64) to fix incorrect activeconns,
diff -u ipvsadm-1.25.clean/debian/control ipvsadm-1.25.clean/debian/control
--- ipvsadm-1.25.clean/debian/control
+++ ipvsadm-1.25.clean/debian/control
@@ -4,7 +4,7 @@
 Maintainer: Ubuntu Developers ubuntu-devel-disc...@lists.ubuntu.com
 XSBC-Original-Maintainer: Alexander Wirt formo...@debian.org
 Standards-Version: 3.8.3
-Build-Depends: debhelper (= 5), libpopt-dev, po-debconf, libnl-dev
+Build-Depends: debhelper (= 5), libpopt-dev, po-debconf, libnl3-dev
 
 Package: ipvsadm
 Architecture: any
diff -u ipvsadm-1.25.clean/libipvs/libipvs.c ipvsadm-1.25.clean/libipvs/libipvs.c
--- ipvsadm-1.25.clean/libipvs/libipvs.c
+++ ipvsadm-1.25.clean/libipvs/libipvs.c
@@ -32,7 +32,7 @@
 struct ip_vs_getinfo ipvs_info;
 
 #ifdef LIBIPVS_USE_NL
-struct nl_handle *sock = NULL;
+struct nl_sock *sock = NULL;
 int family, try_nl = 1;
 #endif
 
@@ -64,7 +64,7 @@
 {
 	int err = EINVAL;
 
-	sock = nl_handle_alloc();
+	sock = nl_socket_alloc();
 	if (!sock) {
 		nlmsg_free(msg);
 		return -1;
@@ -79,7 +79,7 @@
 
 	/* To test connections and set the family */
 	if (msg == NULL) {
-		nl_handle_destroy(sock);
+		nl_socket_free(sock);
 		sock = NULL;
 		return 0;
 	}
@@ -95,12 +95,12 @@
 
 	nlmsg_free(msg);
 
-	nl_handle_destroy(sock);
+	nl_socket_free(sock);
 
 	return 0;
 
 fail_genl:
-	nl_handle_destroy(sock);
+	nl_socket_free(sock);
 	sock = NULL;
 	nlmsg_free(msg);
 	errno = err;
only in patch2:
unchanged:
--- ipvsadm-1.25.clean.orig/Makefile
+++ ipvsadm-1.25.clean/Makefile
@@ -79,7 +79,7 @@
 OBJS		= ipvsadm.o config_stream.o dynamic_array.o
 LIBS		= $(POPT_LIB)
 ifneq (0,$(HAVE_NL))
-LIBS		+= -lnl
+LIBS		+= $(shell pkg-config --libs libnl-3.0)
 endif
 DEFINES		= -DVERSION=\$(VERSION)\ -DSCHEDULERS=\$(SCHEDULERS)\ \
 		  $(POPT_DEFINE)

Bug#649772: libdoxia-java: FTBFS in a restrictive chroot

[Mathieu Trudel-Lapierre]

Package: libdoxia-java
Version: 1.1.4-1
Severity: normal
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise ubuntu-patch

Dear Maintainer,

We've identified a few issues with rebuilding doxia in Ubuntu precise.

Since buildds are fairly restrictive and do not allow downloading data from
the Internet, doxia at least fails building when it goes looking for the jar
files for version 1.1.4 from the central maven repository; when building
documentation.

It also appears that libjaxen-java is now required globally at build-time,
as requested for jdom, via plexus-component-metadata.

Furthermore, I've run into smaller problems when trying to fix the issues
above; and have had to slightly adjust doxia-modules and doxia-book
dependencies (specified in their .pom files).

I ran test locally with sbuild, disconnecting all network access once it
got all the build-deps installed.

See the following build logs from the Ubuntu buildds for further details:
- Missing jaxen: 
https://launchpadlibrarian.net/85417405/buildlog_ubuntu-precise-i386.doxia_1.1.4-1_FAILEDTOBUILD.txt.gz
- Download attempts: 
https://launchpadlibrarian.net/85601926/buildlog_ubuntu-precise-i386.doxia_1.1.4-1ubuntu1_FAILEDTOBUILD.txt.gz

I realize the changes I have applied might not be the most efficient; but they
appear to properly resolve the issue and allow building in offline chroot both
for Debian unstable and Ubuntu precise.

Kind regards,

/ Matt


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages libdoxia-java depends on:
ii  libplexus-containers-java  1.0~beta3.0.7-5
ii  libplexus-i18n-java1.0-beta-10-3  
ii  libplexus-utils-java   1:1.5.15-4 
ii  libxerces2-java2.11.0-2ubuntu1

Versions of packages libdoxia-java recommends:
ii  fop1:1.0.dfsg2-3ubuntu1
ii  libcommons-configuration-java  1.7-1   
ii  libcommons-httpclient-java 3.1-10  
ii  libitext1-java 1.4-4   
ii  libjaxp1.3-java1.3.05-1ubuntu1 
ii  liblog4j1.2-java   1.2.16-2

Versions of packages libdoxia-java suggests:
pn  libdoxia-java-doc  none

-- no debconf information
diff -Nru doxia-1.1.4/debian/changelog doxia-1.1.4/debian/changelog
--- doxia-1.1.4/debian/changelog	2011-09-10 18:58:15.0 -0400
+++ doxia-1.1.4/debian/changelog	2011-11-23 16:14:47.0 -0500
@@ -1,3 +1,18 @@
+doxia (1.1.4-2) unstable; urgency=low
+
+  * debian/rules: import the jar files we just built if we're bootstrapping
+with an old version of doxia, to make sure we have all the necessary new
+symbols.
+  * debian/patches/0008-doxia-logging-deps.patch: adjust dependencies for
+doxia-modules and doxia-book, which should require doxia-logging-api in
+their pom files.
+  * debian/maven.properties: force maven to work offline, since we can't rely
+on downloading anything in buildds.
+  * debian/control: add libjaxen-java (required by jdom/plexus) and
+libmaven-install-plugin-java (needed to import jar files to the local repo).
+
+ -- Mathieu Trudel-Lapierre mathieu...@ubuntu.com  Wed, 23 Nov 2011 14:55:50 -0500
+
 doxia (1.1.4-1) unstable; urgency=low
 
   [Gabriele Giacone]
diff -Nru doxia-1.1.4/debian/control doxia-1.1.4/debian/control
--- doxia-1.1.4/debian/control	2011-09-09 18:28:03.0 -0400
+++ doxia-1.1.4/debian/control	2011-11-23 14:49:18.0 -0500
@@ -11,7 +11,7 @@
  libplexus-i18n-java, libplexus-utils-java, libxerces2-java, junit, libxerces2-java,  
  default-jdk-doc, libcommons-configuration-java-doc, liblog4j1.2-java-doc,  
  libmaven2-core-java-doc, libplexus-containers-java-doc, libplexus-utils-java-doc,  
- libmaven-javadoc-plugin-java 
+ libmaven-javadoc-plugin-java, libjaxen-java, libmaven-install-plugin-java
 Standards-Version: 3.9.2
 Vcs-Svn: svn://svn.debian.org/svn/pkg-java/trunk/doxia
 Vcs-Browser: http://svn.debian.org/wsvn/pkg-java/trunk/doxia
diff -Nru doxia-1.1.4/debian/maven.properties doxia-1.1.4/debian/maven.properties
--- doxia-1.1.4/debian/maven.properties	2011-09-09 18:28:03.0 -0400
+++ doxia-1.1.4/debian/maven.properties	2011-11-23 14:49:18.0 -0500
@@ -2,4 +2,5 @@
 # For example:
 
 maven.test.skip=true
+maven.settings.offline=true
 
diff -Nru doxia-1.1.4/debian/patches/0008-doxia-logging-deps.patch doxia-1.1.4/debian/patches/0008-doxia-logging-deps.patch
--- doxia-1.1.4/debian/patches/0008-doxia-logging-deps.patch	1969-12-31 19:00:00.0 -0500
+++ doxia-1.1.4/debian/patches/0008-doxia-logging-deps.patch	2011-11-23 13:03:42.0 -0500
@@ -0,0 +1,38 @@
+From: Mathieu Trudel-Lapierre

Bug#564579: asciidoc: Consider using docbook.xsl from docbook-xsl.

[Mathieu Trudel-Lapierre]

Package: asciidoc
Version: 8.6.6-1
Followup-For: Bug #564579
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu precise

We're running into a similar problem on Ubuntu: buildds are a restricted
environment under which you can't download arbitrary files from the web,
which makes at least the 'herbstluftwm' package fail to build on all
architectures. I'm sure there's any other package using asciidoc to try
and build manpages that would be affected in the same way.

See 
https://launchpadlibrarian.net/84910068/buildlog_ubuntu-precise-i386.herbstluftwm_0.1%2Bgit2011.11.06-1_FAILEDTOBUILD.txt.gz

The required files exist in the docbook-xsl package, so instead of referring
to the URL to the docbook.xsl page in the stylesheets installed under
/etc/asciidoc/docbook-xsl, asciidoc should refer to the files provided
by the docbook-xsl package and add a Depends on docbook-xsl.


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages asciidoc depends on:
ii  python  2.7.2-7ubuntu4

Versions of packages asciidoc recommends:
pn  dblatexnone 
pn  docbook-utils  none 
pn  libxml2-utils  2.7.8.dfsg-5ubuntu1
pn  xmlto  none 

Versions of packages asciidoc suggests:
pn  source-highlight   none
pn  vim-addon-manager  none

-- no debconf information



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

Bug#649018: Better patch correcting the issue

[Mathieu Trudel-Lapierre]

The previous patch does appear to work but remains technically incorrect.

Please see the attached revised patch ;)

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: Correctly pass format strings to fltk functions expecting those.
Last-Update: 2011-11-16

Index: bist/src/util.cpp
===
--- bist.orig/src/util.cpp	2011-11-16 17:32:52.216281000 -0500
+++ bist/src/util.cpp	2011-11-16 17:36:32.684441611 -0500
@@ -1566,7 +1566,7 @@
   string the_choice=string(_(File with name)) + 
 string(_( )) + string(the_file) + string(_( )) +
 string(_(already exist.\nDo you want to overwrite it?));
-  return fl_choice(the_choice.c_str(),_(No),_(Yes),NULL);
+  return fl_choice(%s,_(No),_(Yes),NULL,the_choice.c_str());
 
 }
 
Index: bist/src/immagine.cpp
===
--- bist.orig/src/immagine.cpp	2011-11-16 17:24:46.086009000 -0500
+++ bist/src/immagine.cpp	2011-11-16 17:39:48.280432894 -0500
@@ -2788,7 +2788,7 @@
   warn +=  _warning[i] + \n;
 }
 if(warn!=){
-  fl_alert(warn.c_str());
+  fl_alert(%s,warn.c_str());
 }
   }
   void immagine::print_errors(){
@@ -2797,7 +2797,7 @@
   errori+= _error[i] +\n;
 }
 if(errori!=){
-  fl_alert(errori.c_str());
+  fl_alert(%s,errori.c_str());
 }
 
   }
@@ -6276,7 +6276,7 @@
 can_write=1;
   }else{
 if(graphics){
-  fl_message(strerror(errno));
+  fl_message(%s,strerror(errno));
 }else{
   perror(NULL);
 }
Index: bist/src/editor.cpp
===
--- bist.orig/src/editor.cpp	2011-11-16 17:24:46.086009000 -0500
+++ bist/src/editor.cpp	2011-11-16 17:41:08.872429299 -0500
@@ -394,7 +394,7 @@
 void edit_nowar_cb(Fl_Widget* w, void* v){
   const static char* man=Copyright (C)  2005  Valerio Benfante.\nThis  is  free software; see the file COPYING for copying conditions.\nThere is NO warranty; not even for MERCHANTABILITY or  FITNESS FOR A PARTICULAR PURPOSE.\nThe logo is copyright (C) 2005 Luisa Russo and is released under GNU GPL;
 
-  fl_message(man);
+  fl_message(%s,man);
 }
 
 

Bug#649018: bist: FTBFS when building with -Werror=format-security

[Mathieu Trudel-Lapierre]

Package: bist
Version: 0.5.1-3
Severity: important
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oneiric ubuntu-patch

Dear Maintainer,

bist appears to FTBFS on Ubuntu precise when build with the
-Werror=format-security parameter passed to GCC 4.6. [1]

This is because some fltk functions such as fl_warn, fl_choice, and others
expect a format string as first argument. However, in the case where the
format string stands by itself, -Werror=format-security will still require
one to pass format parameters to be interpolated: in this case, something
like NULL is sufficient.

The attached patch resolve this issue by adding NULLs as a final parameter
to the relevant fltk functions.

[1] 
https://launchpadlibrarian.net/85118405/buildlog_ubuntu-precise-amd64.bist_0.5.1-3_FAILEDTOBUILD.txt.gz

Regards,


-- System Information:
Debian Release: wheezy/sid
  APT prefers precise-updates
  APT policy: (500, 'precise-updates'), (500, 'precise-security'), (500, 
'precise'), (100, 'precise-backports')
Architecture: amd64 (x86_64)

Kernel: Linux 3.1.0-2-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages bist depends on:
ii  libc6  2.13-20ubuntu5  
ii  libcairo2  1.10.2-6ubuntu3 
ii  libexpat1  2.0.1-7.2   
ii  libfltk1.1 1.1.10-8
ii  libgcc11:4.6.2-2ubuntu1
ii  libglib2.0-0   2.30.1-2ubuntu1 
ii  libncurses55.9-2   
ii  libpango1.0-0  1.29.4-2ubuntu1 
ii  libstdc++6 4.6.2-2ubuntu1  
ii  libtinfo5  5.9-2   
ii  libx11-6   2:1.4.4-4   
ii  libxpm41:3.5.9-4   

bist recommends no packages.

bist suggests no packages.

-- no debconf information
From: Mathieu Trudel-Lapierre mathieu.trudel-lapie...@canonical.com
Subject: pass terminating NULLs to fl_ functions expecting formats.
Last-Update: 2011-11-16

Index: bist/src/util.cpp
===
--- bist.orig/src/util.cpp	2011-11-16 17:32:52.216281000 -0500
+++ bist/src/util.cpp	2011-11-16 17:36:32.684441611 -0500
@@ -1566,7 +1566,7 @@
   string the_choice=string(_(File with name)) + 
 string(_( )) + string(the_file) + string(_( )) +
 string(_(already exist.\nDo you want to overwrite it?));
-  return fl_choice(the_choice.c_str(),_(No),_(Yes),NULL);
+  return fl_choice(the_choice.c_str(),_(No),_(Yes),NULL,NULL);
 
 }
 
Index: bist/src/immagine.cpp
===
--- bist.orig/src/immagine.cpp	2011-11-16 17:24:46.086009000 -0500
+++ bist/src/immagine.cpp	2011-11-16 17:39:48.280432894 -0500
@@ -2788,7 +2788,7 @@
   warn +=  _warning[i] + \n;
 }
 if(warn!=){
-  fl_alert(warn.c_str());
+  fl_alert(warn.c_str(),NULL);
 }
   }
   void immagine::print_errors(){
@@ -2797,7 +2797,7 @@
   errori+= _error[i] +\n;
 }
 if(errori!=){
-  fl_alert(errori.c_str());
+  fl_alert(errori.c_str(),NULL);
 }
 
   }
@@ -6276,7 +6276,7 @@
 can_write=1;
   }else{
 if(graphics){
-  fl_message(strerror(errno));
+  fl_message(strerror(errno),NULL);
 }else{
   perror(NULL);
 }
Index: bist/src/editor.cpp
===
--- bist.orig/src/editor.cpp	2011-11-16 17:24:46.086009000 -0500
+++ bist/src/editor.cpp	2011-11-16 17:41:08.872429299 -0500
@@ -394,7 +394,7 @@
 void edit_nowar_cb(Fl_Widget* w, void* v){
   const static char* man=Copyright (C)  2005  Valerio Benfante.\nThis  is  free software; see the file COPYING for copying conditions.\nThere is NO warranty; not even for MERCHANTABILITY or  FITNESS FOR A PARTICULAR PURPOSE.\nThe logo is copyright (C) 2005 Luisa Russo and is released under GNU GPL;
 
-  fl_message(man);
+  fl_message(man, NULL);
 }
 
 

Bug#648852: FTBFS in restricted chroots

[Mathieu Trudel-Lapierre]

Package: uapevent
Version: 1.4-1

Hi,

We're discovered an issue with uapevent while building it for Ubuntu
precise: it attempts to copy (install) compiled files to an
unreachable or restricted path:

make[1]: Entering directory `/build/buildd/uapevent-1.4'
cc  -Wall -c -o uapevent.o uapevent.c
cc -lrt -o uapevent uapevent.o
cp: cannot create regular file `../../uapevent': Permission denied
make[1]: *** [build] Error 1
make[1]: Leaving directory `/build/buildd/uapevent-1.4'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2

On our buildds, this would essentially mean /, but on my system
(outside a chroot, but building in a separate directory than the
original source) it also means it tries to clobber the actual source
directory used, and fortunately fails to do so ;)

I was able to workaround the issue by adding a simple override to
dh_auto_build that would set INSTALLDIR to an absolute directory, thus
avoiding it being rewritten with ../..:

override_dh_auto_build:
INSTALLDIR=$(CURDIR)/debian/tmp dh_auto_build


Kind regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#648875: FTBFS in restrictive chroots

[Mathieu Trudel-Lapierre]

Package: uaputl
Version: 1.12-1
Tags: patch
User: ubuntu-de...@lists.ubuntu.com
Usertags: origin-ubuntu oneiric ubuntu-patch

Hi,

We're discovered an issue with uaputl 1.12-1 while building it for
Ubuntu precise: it attempts to copy (install) compiled files to an
unreachable or restricted path:

make[1]: Entering directory `/build/buildd/uaputl-1.12'
cc  -Wall -c -o uaputl.o uaputl.c
uaputl.c: In function 'apcmd_sys_config':
uaputl.c:3817:29: warning: 'argv_dummy' may be used uninitialized in
this function [-Wuninitialized]
cc  -Wall -c -o uapcmd.o uapcmd.c
cc -lrt -o uaputl uaputl.o uapcmd.o
cp: cannot create regular file `../../uaputl': Permission denied
make[1]: *** [build] Error 1
make[1]: Leaving directory `/build/buildd/uaputl-1.12'
dh_auto_build: make -j1 returned exit code 2
make: *** [build] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2


On our buildds, this would essentially mean /, but on my system it
also means it tries to clobber the actual source directory used, and
fortunately fails to do so ;)

I was able to workaround the issue by adding a simple override to
dh_auto_build that would set INSTALLDIR to an absolute directory, thus
avoiding it being rewritten with ../..:

override_dh_auto_build:
install -d $(CURDIR)/debian/tmp
INSTALLDIR=$(CURDIR)/debian/tmp dh_auto_build


Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


uaputl_1.12-1ubuntu1.debdiff
Description: Binary data

Bug#648782: FTBFS due to undefined symbols

[Mathieu Trudel-Lapierre]

Package: supercollider
Version: 1:3.4.4-2

A recent rebuild test in Ubuntu for supercollider 1:3.4.4-2 shows that
it fails to build [1], due to restrictions imposed at linking time:

g++ -o build/sclang -Wl,-rpath-link,build -Wl,-rpath-link,/usr/lib
-lreadline Source/lang/LangSource/cmdLineFuncs.o -Lbuild -lsclang
build/libsclang.so: undefined reference to `cwiid_set_rumble'
build/libsclang.so: undefined reference to `uregex_groupCount_44'
build/libsclang.so: undefined reference to `rl_reset_line_state'
build/libsclang.so: undefined reference to `rl_bind_key'
build/libsclang.so: undefined reference to `cwiid_set_mesg_callback'
build/libsclang.so: undefined reference to `rl_event_hook'
build/libsclang.so: undefined reference to `rl_replace_line'
build/libsclang.so: undefined reference to `u_charsToUChars_44'
build/libsclang.so: undefined reference to `rl_set_keyboard_input_timeout'
build/libsclang.so: undefined reference to `rl_redisplay'
build/libsclang.so: undefined reference to `rl_crlf'
build/libsclang.so: undefined reference to `cwiid_set_err'
build/libsclang.so: undefined reference to `cwiid_set_led'
build/libsclang.so: undefined reference to `cwiid_set_rpt_mode'
build/libsclang.so: undefined reference to `rl_basic_word_break_characters'
build/libsclang.so: undefined reference to `rl_readline_name'
build/libsclang.so: undefined reference to `cwiid_close'
build/libsclang.so: undefined reference to `readline'
build/libsclang.so: undefined reference to `cwiid_enable'
build/libsclang.so: undefined reference to `uregex_findNext_44'
build/libsclang.so: undefined reference to `cwiid_open'
build/libsclang.so: undefined reference to `uregex_start_44'
build/libsclang.so: undefined reference to `add_history'
build/libsclang.so: undefined reference to `uregex_open_44'
build/libsclang.so: undefined reference to `uregex_end_44'
build/libsclang.so: undefined reference to `cwiid_disable'
build/libsclang.so: undefined reference to `uregex_setText_44'
build/libsclang.so: undefined reference to `cwiid_get_id'
collect2: ld returned 1 exit status

Readline, libicu and cwiid do not appear to be linked against in the
right order in the build process, which yields the undefined
references above. The same error happens on all architectures we test
[2] (amd64, i386, armel, powerpc), but I suspect it also comes up on
the other architectures in Debian as well.

Attached is a patch that resolves the issue, it would be helpful if
you could include it in your package or review it.

[1] 
https://launchpadlibrarian.net/84969289/buildlog_ubuntu-precise-amd64.supercollider_1%3A3.4.4-2_FAILEDTOBUILD.txt.gz
[2] https://launchpad.net/ubuntu/+source/supercollider/1:3.4.4-2

Kind regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Subject: Fixup environment variables used for linking against
 readline, libicu, curl, cwiid.
Last-Update: 2011-11-14

Index: supercollider-3.4.4/common/SConstruct
===
--- supercollider-3.4.4.orig/common/SConstruct	2011-11-14 19:02:02.133345172 -0500
+++ supercollider-3.4.4/common/SConstruct	2011-11-14 19:06:28.665338281 -0500
@@ -575,6 +575,7 @@
 if PLATFORM == 'darwin' or conf.CheckCHeader('unicode/uregex.h'):
 libraries['libicu'] = Environment(
  LINKFLAGS = '-licui18n -licuuc -licudata',
+ LIBS = [ 'icui18n', 'icuuc', 'icudata' ],
 )
 else:
 print libicu not found
@@ -1048,15 +1049,6 @@
 langEnv.Append(
 LINKFLAGS = '-Wl,-rpath-link,build -Wl,-rpath-link,' + FINAL_PREFIX + '/lib')
 
-if env['CURL']:
-langEnv.Append(CPPDEFINES = ['HAVE_LIBCURL'])
-merge_lib_info(langEnv, libraries['libcurl'])
-
-if env['READLINE'] and env['LANG'] and env['GPL3']:
-langEnv.Append(CPPDEFINES = ['HAVE_READLINE'])
-merge_lib_info(langEnv, libraries['readline'])
-
-
 libsclangEnv = langEnv.Clone(
 PKGCONFIG_NAME = 'libsclang',
 PKGCONFIG_DESC = 'SuperCollider synthesis language library',
@@ -1127,6 +1119,15 @@
 if env['LANG']:
 merge_lib_info(libsclangEnv, libraries['libicu'])
 
+if env['CURL']:
+langEnv.Append(CPPDEFINES = ['HAVE_LIBCURL'])
+merge_lib_info(libsclangEnv, libraries['libcurl'])
+
+if env['READLINE'] and env['LANG'] and env['GPL3']:
+langEnv.Append(CPPDEFINES = ['HAVE_READLINE'])
+merge_lib_info(libsclangEnv, libraries['readline'])
+
+
 # optional features
 if features['midiapi']:
 merge_lib_info(libsclangEnv, libraries['midiapi'])
@@ -1161,8 +1162,8 @@
 # HAVE_LID does the right thing in SC_LID.cpp source
 libsclangSources += ['Source/lang/LangPrimSource/SC_LID.cpp']
 if features['wii']:
-libsclangEnv.Append(CPPDEFINES = 'HAVE_WII')
-libsclangEnv.Append(LINKFLAGS = '-lcwiid')
+langEnv.Append(CPPDEFINES = 'HAVE_WII

Bug#627127: Possible translation

[Mathieu Trudel-Lapierre]

Does the following sound better for translating to German?

+ Ethos is a library providing a standard system of reusable extensions. The
+ goal is to allow plugin developers to reuse the same code in different
+ applications and thereby make better use of their time.


Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#584896: Please test with concordance directly

[Mathieu Trudel-Lapierre]

Hi,

congruity uses concordance's python bindings to speak to the remotes.

Would it be possible for you to try using concordance directly just to
make sure if this is reproducible in the underlying library as well?

Essentially, this would be as simple as saving the file you are
loading to your remote, and using concordance from the command line
with the file name.

Thanks, and regards, (and sorry for the delays)

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#627975: ITP: wimax-tools -- user-land tools for controlling WiMAX devices

[Mathieu Trudel-Lapierre]

Package: wnpp
Severity: wishlist

* Package name: wimax-tools
  Version : 1.4.5
  Upstream Author : Intel Corporation linux-wi...@intel.com
* URL : http://linuxwimax.org/
* License : BSD
  Programming Lang: C
  Description : user-land tools to control WiMAX devices

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#584896: Needs testing with congruity 15-1 in unstable

[Mathieu Trudel-Lapierre]

Hi,

congruity 15-1 has just been uploaded to unstable. Any chance you
could try to see if your model can be properly configured with this
new release?

Release 15 includes using new API from concordance 0.22 which was
introduced to support Harmony 700 devices, I think your model is
included in this as well.

Regards.

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#620076: leftover files in /var/lib/dhcp3 from migration from 3.x to 4.1.1-x

[Mathieu Trudel-Lapierre]

Package: isc-dhcp-client
Version: 4.1.1-P1-16

This was reported [1] while running an upgrade from Maverick to Natty:

Preparing to replace dhcp3-client 3.1.3-2ubuntu6 (using
.../dhcp3-client_4.1.1-P1-15ubuntu5_all.deb) ...
Unpacking replacement dhcp3-client ...
dpkg: warning: unable to delete old directory '/var/lib/dhcp3':
Directory not empty

I've managed to possibly identify the issue: the dhclient.leases file
in /var/lib/dhcp3 is copied to /var/lib/dhcp/ as a basis for dhclient
to use after the upgrade, but the file from /var/lib/dhcp3 is then
just left behind. What would remove this file would be to purge
dhcp3-client.

I suggest the dhclient.leases file be moved instead, or removed
immediately after the copy. While this *does* break the leases if ever
the upgrade was to fail, further leases can be obtained without
interfering too much with the functionality of dhclient.

[1] - https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/745008

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#159090: acct: -f - option works for pipe:[xxx] but not socket:[xxx]

[Mathieu Trudel-Lapierre]

reassign 159090 ksh
thanks

On Sat, Mar 19, 2011 at 2:04 PM, Jeff Green j...@kikisoso.org wrote:
[...]
 The problem show specifically when using the ksh package, as opposed to
 the pdksh package (or possibly others).
[...]
 If the shell is switched to pdksh, tcsh, or sh (which I suppose is dash), then
 the pipe works okay, e.g.:

This being the case, I'd be tempted to say it's really an issue with
ksh's handling of pipes, not lastcomm and all not supporting sockets
-- especially when it works with many of the most common shells.

Please let me know if you disagree or can explain the reasoning
further to say the issue is in acct -- for now, reassigning to ksh,
since ls also sees the pipe building fd/0 as a socket.

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#608142: concordance 0.23

[Mathieu Trudel-Lapierre]

Yup, getting ready to upload this starting next week, provided
unstable is free then.

Most of the work is ready, just need to re-test building and make sure
it works with the remotes I have.

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#611825: isc-dhcp-server: DHCPv6 server difficult to start / cohabit with DHCPv4

[Mathieu Trudel-Lapierre]

Package: isc-dhcp-server
Version: 4.1.1-P1-15
Severity: normal

It appears to me like it's pretty hard to install isc-dhcp and set it
up according to the type of server one wants to use; e.g. setting it
up as a DHCPv6 server specifically, or having a DHCPv6 server
alongside a DHCPv4 server.

I think a little more could be done to facilitate such setups and
avoid people editing the isc-dhcp-server init script (and potentially
losing their changes in an update).

It's far from ideal I realize, but attached is a patch which attempts
to make this a little simpler: setting up a DHCPv6 server from there
is a matter of symlinking the init script or copying it to a new name
and editing a file /etc/default/basename_of_init_script. Setting up
the mode of the server (to serve v4 or v6 addresses) is set as an
additional option in that file.

-- System Information:
Debian Release: squeeze/sid
  APT prefers natty-updates
  APT policy: (500, 'natty-updates'), (500, 'natty-security'), (500, 'natty')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.37-12-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash


Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
=== modified file 'debian/isc-dhcp-server.init.d'
--- debian/isc-dhcp-server.init.d	2010-11-09 17:40:49 +
+++ debian/isc-dhcp-server.init.d	2011-02-01 21:40:42 +
@@ -15,11 +15,12 @@
 ### END INIT INFO
 
 PATH=/sbin:/bin:/usr/sbin:/usr/bin
+DEFAULTS_FILE=/etc/default/`basename $0`
 
 test -f /usr/sbin/dhcpd || exit 0
 
 # It is not safe to start if we don't have a default configuration...
-if [ ! -f /etc/default/isc-dhcp-server ]; then
+if [ ! -f $DEFAULTS_FILE ]; then
 	echo /etc/default/isc-dhcp-server does not exist! - Aborting...
 	echo Run 'dpkg-reconfigure isc-dhcp-server' to fix the problem.
 	exit 0
@@ -28,8 +29,8 @@
 . /lib/lsb/init-functions
 
 # Read init script configuration (so far only interfaces the daemon
-# should listen on.)
-[ -f /etc/default/isc-dhcp-server ]  . /etc/default/isc-dhcp-server
+# should listen on and DHCP mode (v4 or v6).)
+[ -f $DEFAULTS_FILE ]  . $DEFAULTS_FILE
 
 NAME=dhcpd
 DESC=ISC DHCP server
@@ -37,10 +38,10 @@
 
 test_config()
 {
-	if ! /usr/sbin/dhcpd -t -q  /dev/null 21; then
+	if ! /usr/sbin/dhcpd $DHCPMODE -t -q  /dev/null 21; then
 		echo dhcpd self-test failed. Please fix the config file.
 		echo The error was: 
-		/usr/sbin/dhcpd -t
+		/usr/sbin/dhcpd $DHCPMODE -t
 		exit 1
 	fi
 }
@@ -66,7 +67,7 @@
 		test_config
 		log_daemon_msg Starting $DESC $NAME
 		start-stop-daemon --start --quiet --pidfile $DHCPDPID \
-			--exec /usr/sbin/dhcpd -- -q $INTERFACES
+			--exec /usr/sbin/dhcpd -- $DHCPMODE -q $INTERFACES
 		sleep 2
 
 		if check_status -q; then

=== modified file 'debian/isc-dhcp-server.postinst'
--- debian/isc-dhcp-server.postinst	2010-11-09 17:40:49 +
+++ debian/isc-dhcp-server.postinst	2011-02-01 21:40:42 +
@@ -43,6 +43,11 @@
 # This is a POSIX shell fragment
 #
 
+# DHCP mode to use:
+#  -4  -  standard IPv4 DHCP (default)
+#  -6  -  DHCPv6
+DHCPMODE=-4
+
 # On what interfaces should the DHCP server (dhcpd) serve DHCP requests?
 #	Separate multiple interfaces with spaces, e.g. eth0 eth1.
 INTERFACES=
@@ -82,6 +87,12 @@
 	fi
 fi
 
+# ISC DHCP 4 introduces DHCPv6. That also means we need to ship an extra
+# lease file.
+if [ ! -e /var/lib/dhcp/dhcpd6.leases ]; then
+	touch /var/lib/dhcp/dhcpd6.leases
+fi
+
 [ -x /sbin/restorecon ]  restorecon /var/lib/dhcp/dhcpd.leases
 
 init_script_error_handler()

=== modified file 'debian/isc-dhcp-server.postrm'
--- debian/isc-dhcp-server.postrm	2010-06-15 23:20:30 +
+++ debian/isc-dhcp-server.postrm	2011-02-01 21:40:42 +
@@ -12,6 +12,7 @@
 purge)
 	# Remove database
 	rm -f /var/lib/dhcp/dhcpd.leases /var/lib/dhcp/dhcpd.leases~
+	rm -f /var/lib/dhcp/dhcpd6.leases /var/lib/dhcp/dhcpd6.leases~
 
 	# Remove database directory
 	if [ -d /var/lib/dhcp ]; then

Bug#611825: Related bug 592539

[Mathieu Trudel-Lapierre]

Seems like I went a little fast with filing this one. There is a
related report in bug 592539.

I'm not particularly for or against either solution, but initially
felt it was better to ship just one init script when my guess is that
people will usually use just one of the protocols / DHCP servers at
once.

Regards,

Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#611327: lunar-applet: FTBFS with evolution API = 2.32

[Mathieu Trudel-Lapierre]

Package: lunar-applet
Version: 2.0-2
Severity: important

lunar-applet appears to FTBFS when built against new evolution API
(seems like it's specific to evo/e-d-s = 2.32):

gcc -I. -g -O2 -g -O2 -fno-strict-aliasing -I.
-Wl,-Bsymbolic-functions -Wl,--as-needed -o lunar-applet
lunar_applet-lunar.o lunar_applet-calendar-client.o
lunar_applet-calendar-sources.o -pthread -pthread  -llunar-1
/usr/lib/libgnomeui-2.so -lSM -lICE /usr/lib/libgnomevfs-2.so
-lecal-1.2 -lical -licalss -licalvcal -ledataserverui-1.2 -lebook-1.2
-lcamel-1.2 -ledataserver-1.2 /usr/lib/libsqlite3.so -lnss3 -lnssutil3
-lsmime3 -lssl3 -lplds4 -lplc4 -lnspr4 -lpthread -ldl
/usr/lib/libxml2.so -lsoup-2.4 -lpanel-applet-2 /usr/lib/libgconf-2.so
/usr/lib/libbonoboui-2.so /usr/lib/libgnomecanvas-2.so
/usr/lib/libgnome-2.so /usr/lib/libpopt.so /usr/lib/libart_lgpl_2.so
/usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so
/usr/lib/libatk-1.0.so /usr/lib/libgio-2.0.so
/usr/lib/libpangoft2-1.0.so /usr/lib/libpangocairo-1.0.so
-lgdk_pixbuf-2.0 -lm /usr/lib/libcairo.so /usr/lib/libpango-1.0.so
/usr/lib/libfreetype.so -lz -lfontconfig /usr/lib/libbonobo-2.so
/usr/lib/libbonobo-activation.so /usr/lib/libORBit-2.so
/usr/lib/libgmodule-2.0.so /usr/lib/libgobject-2.0.so
/usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so
lunar_applet-calendar-client.o: In function `get_source_color':
/build/buildd/lunar-applet-2.0/src/calendar-client.c:675: undefined
reference to `e_source_get_color'
collect2: ld returned 1 exit status
make[3]: *** [lunar-applet] Error 1

This can be easily fixed with the attached patch, which can be applied
regardless of evolution and e-d-s version, since it uses an alternate
function to e_source_get_color that has been available since before
evolution 2.

This was found on a no-change rebuilt for natty against new evolution
API. As a reference, the full build log for amd64 was here:
http://launchpadlibrarian.net/62929195/buildlog_ubuntu-natty-amd64.lunar-applet_2.0-2build2_FAILEDTOBUILD.txt.gz
, though this applies for all arches.

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93
From: Mathieu Trudel-Lapierre mathieu...@ubuntu.com
Subject: Replace the use of deprecated e_source_get_color().
Bug-Ubuntu: http://launchpad.net/bugs/708721
Forwarded: yes, http://code.google.com/p/lunar-applet/issues/detail?id=9

The e_source_get_color() call causes a FTBFS with evolution  2.32, because
it has been deprecated and then removed from the API. A simpler method for
retrieving the hex color spec already existed and already returns NULL if there
is no color set, so replacing most of the work done in get_source_color to
just directly return a copy of what e_source_peak_color_spec returns makes
sense.

g_strdup kept to avoid unnecessary changes elsewhere in lunar-applet code. It
will return NULL if e_source_peak_color_spec() returns NULL.

Index: lunar-applet/src/calendar-client.c
===
--- lunar-applet.orig/src/calendar-client.c	2011-01-27 10:37:04.711822754 -0500
+++ lunar-applet/src/calendar-client.c	2011-01-27 10:42:00.467822754 -0500
@@ -672,11 +672,8 @@
   g_return_val_if_fail (E_IS_CAL (esource), NULL);
 
   source = e_cal_get_source (esource);
-  if (e_source_get_color (source, color)) {
-return g_strdup_printf (%06x, color);
-  }
-  
-  return NULL;
+
+  return g_strdup (e_source_peek_color_spec (source));
 }
 
 static inline int

Bug#571681: [PATCH] fix file chooser dialog initalization

[Mathieu Trudel-Lapierre]

Hi,

Please see the attached patch which fixes the issue.

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


08_file_save_dialog.dpatch
Description: Binary data

Bug#554557: [PATCH] fix FTBFS with binutils-gold

[Mathieu Trudel-Lapierre]

Hi,

Admittedly, there is already a known fix, but I'm proposing to use a
slightly different change.

Wouldn't it be slightly better to correct the full build process to
build/link against zlib? I may well be wrong in assuming this, so I'll
be happy to be told it's not a good idea ;)

The attached patch applies this change to the PKG_CONFIG line in
configure.in (adding a check for zlib). Because of this, it also
requires running autoreconf in the debian/rules build target.

Regards,

Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


99_build_with_gcc_4_5.dpatch
Description: Binary data

Bug#605837: unblock: concordance/0.22-3

[Mathieu Trudel-Lapierre]

Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock

Please unblock package concordance 0.22-3.

This new version applies a fix specific to Harmony 525 remotes (and
other devices using the same design/arch) to properly define memory
limits to use when flashing config to the remote.

The patch as it is included has already been tested as reported in bug
594615. Furthermore, as it's directly targetted at only this specific
device, I'm very confident it doesn't introduce regressions.

Thanks for considering,

Mathieu Trudel-Lapierre

 concordance (0.22-3) unstable; urgency=low

   * Include flash size detection patch that should fix data loss errors
 when flashing a Harmony 525. (Closes: 594615)
 - add debian/patches/h525-flash-size-detection.patch
 - update debian/patches/series
   * Also update the maintainer field due to GPG key change.

-- 
Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93



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

Bug#594615: Testing a patch to fix the 525

[Mathieu Trudel-Lapierre]

Thanks, i will prepare an updated 0.22 or 0.23 with this patch today.
Le 2010-11-26 22:52, Aristeu Sergio Rozanski Filho a...@ruivo.org a
écrit :
 On Wed, Nov 03, 2010 at 08:41:52AM -0400, Mathieu Trudel-Lapierre wrote:
 Can you guys test the following patch? (it's from the concordance
 mailing list)

 --

 diff -u -p -r1.12 remote_info.h
 --- libconcord/remote_info.h 1 Aug 2010 14:35:52 - 1.12
 +++ libconcord/remote_info.h 3 Nov 2010 01:18:26 -
 @@ -313,7 +313,7 @@ static const TArchInfo ArchList[]={
 {
 SERIAL_LOCATION_FLASH, // serial_location
 0x000110, // serial_address
 - 0x00, // flash_base
 + 0x80, // flash_base
 0x81, // firmware_base
 0x82, // config_base
 0x81, // firmware_update_base

 ---

 Unfortunately I don't have a 525 (though I will try to acquire one for
 testing future updates on something other than my 670).
 I tested with a XBOX360 model (same arch, 9) and it works. I'm using a
patched
 0.22-2 package with this patch and it works.

 --
 Aristeu

Bug#594615: Testing a patch to fix the 525

[Mathieu Trudel-Lapierre]

Can you guys test the following patch? (it's from the concordance
mailing list)

--

diff -u -p -r1.12 remote_info.h
--- libconcord/remote_info.h1 Aug 2010 14:35:52 -   1.12
+++ libconcord/remote_info.h3 Nov 2010 01:18:26 -
@@ -313,7 +313,7 @@ static const TArchInfo ArchList[]={
{
SERIAL_LOCATION_FLASH,  // serial_location
0x000110,   // serial_address
-   0x00,   // flash_base
+   0x80,   // flash_base
0x81,   // firmware_base
0x82,   // config_base
0x81,   // firmware_update_base

---

Unfortunately I don't have a 525 (though I will try to acquire one for
testing future updates on something other than my 670).

-- 
Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


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

Bug#599239: gauche-gtk: FTBFS against gdk-pixbuf 2.22.0-1 (experimental)

[Mathieu Trudel-Lapierre]

Package: gauche-gtk
Version: 0.4.1-13
Severity: serious
Tags: experimental patch
Justification: fails to build from source (but built successfully in the past)

It appears that if built against gdk-pixbuf as it is in experimental
(basically with gdk-pixbuf headers separate from the gtk2.0 files),
gauche-gtk does not complete build as it fails to analyze headers.

Passing on the patch that was applied on Ubuntu to fix the problem, since
you may want to apply it once past the current release cycle.

-- System Information:
Debian Release: squeeze/sid
  APT prefers maverick-updates
  APT policy: (500, 'maverick-updates'), (500, 'maverick-security'), (500, 
'maverick')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.35-22-generic (SMP w/4 CPU cores)
Locale: LANG=fr_CA.utf8, LC_CTYPE=fr_CA.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
---BeginMessage---
Index: gauche-gtk-0.4.1/src/h2stub.scm
===
--- gauche-gtk-0.4.1.orig/src/h2stub.scm2010-10-04 16:48:03.671800269 
-0400
+++ gauche-gtk-0.4.1/src/h2stub.scm 2010-10-04 16:49:16.551800273 -0400
@@ -33,6 +33,7 @@
 
 ;; Gtk and Pango version (major.minor) we're dealing with
 (define gtk-version   (make-parameter 2.0))
+(define gdk-pixbuf-version   (make-parameter 2.0))
 (define pango-version (make-parameter 1.0))
 
 ;; Directories to search input header files.
@@ -44,6 +45,9 @@
#`pkg-config --variable=includedir gtk+-,(gtk-version)
  (cut port-string-list ))
(call-with-input-process
+   #`pkg-config --variable=includedir 
gdk-pixbuf-,(gdk-pixbuf-version)
+ (cut port-string-list ))
+   (call-with-input-process
#`pkg-config --variable=includedir pango
  (cut port-string-list ))
'(/usr/include /usr/local/include))
@@ -60,6 +64,9 @@
 (define gtk-directory
   (make-parameter (find-header-dir #`gtk-,(gtk-version)/gtk/gtk.h
*header-search-paths* )))
+(define gdk-pixbuf-directory
+  (make-parameter (find-header-dir 
#`gdk-pixbuf-,(gdk-pixbuf-version)/gdk-pixbuf/gdk-pixbuf.h
+   *header-search-paths* )))
 (define pango-directory
   (make-parameter (find-header-dir #`pango-,(pango-version)/pango/pango.h
*header-search-paths*)))
@@ -1283,7 +1290,7 @@
  (call-with-input-file GDKFILES port-string-list)))
 
 (define (parse-gdk-pixbuf)
-  (parse-headers #`,(gtk-directory)/gdk-pixbuf
+  (parse-headers #`,(gdk-pixbuf-directory)/gdk-pixbuf
  (call-with-input-file GDKPIXBUFFILES port-string-list)))
 
 (define (parse-gtk)
---End Message---

Bug#584071: ITP: monitor-edid -- tool to retrieve monitor EDID information

[Mathieu Trudel-Lapierre]

Package: wnpp
Severity: wishlist
Owner: Mathieu Trudel-Lapierre mathieu...@gmail.com


* Package name: monitor-edid
  Version : svn269700
  Upstream Author : Anssi Hannula an...@mandriva.org
* URL : http://wiki.mandriva.com/en/Tools/monitor-edid
* License : GPL3+
  Programming Lang: C++, Perl
  Description : tool to retrieve monitor EDID information

 This tool is used to retrieve EDID information from a monitor using
 instrumentation provided by SYSFS, usually through the drm drivers.
 EDID information is used to attempt to get a clear representation of
 a display's recommended resolution, physical size, form factor, as well
 as other useful tidbits of information.


Mathieu Trudel
mathieu...@gmail.com



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

Bug#506701: acct: should not segfault on gzip files

[Mathieu Trudel-Lapierre]

This bug needs to be reported upstream...

In the meantime, there is a workaround:

zcat [gzipped pacct file] | lastcomm -f -

Mathieu Trudel
mathieu...@gmail.com



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

Bug#578695: RFA: acct

[Mathieu Trudel-Lapierre]

Le mercredi 21 avril 2010 à 23:04 +0200, Patrick Matthäi a écrit :
 Package: wnpp
 Severity: normal
 
 Hello,
 
 In the past I have sponsored the acct package.
 The actual maintainer is in my opionion not active enough to maintain
 a package in Debian properly and does not respond to my emails/reports.
 So I request a RFA for this package.

Patrick,

I am sorry, I have not seen emails from you recently about acct?

I am working on the new release that needs to be packaged, version
6.5.4.

Regards,

-- 
Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


signature.asc
Description: Ceci est une partie de message numériquement signée

Bug#575384: ethos: diff for NMU version 0.2.2-1.1

[Mathieu Trudel-Lapierre]

Le mercredi 07 avril 2010 à 16:10 +0200, Andreas Henriksson a écrit :
 On Wed, Apr 07, 2010 at 03:38:20PM +0200, Stefano Zacchiroli wrote:
  Andreas: I've uploaded more or less the same patch of yours. Given that
  you are a DD, next time you might want to consider doing a very long
  DELAYED upload straight ahead when you prepare your NMU. That way, if
  the maintainer does not intervene, there is no need to give an
  additional stab at the patch to have it hit the archive. Of course,
  YMMV. Thanks a lot for your patch!
 
 AFAIK nothing uses ethos in debian yet, so there was no immediate hurry
 to fix it since it could easily be removed from testing if needed.
 
 Given that Mathieu actually replies to my mails, I wanted to give him
 a chance to take care of the packages himself.
 (Mathieu, please group-reply instead of private replies to me
 so others can see your replies.)
 

Yikes, sorry, I am still intending to get this completed. I apologize
again for the time it takes. I'm not going to get into the reasons for
these delays :)

Andreas or Stefano, would you be able to review my package for
emerillon, since it is complete? (see
http://mentors.debian.net/debian/pool/main/e/emerillon/ )

Also, I'm not entirely familiar with the NMU process, could someone
clarify what I am supposed to do at this point, either by email, or we
could get in contact on IRC...

Regards,

-- 
Mathieu Trudel-Lapierre mathieu...@gmail.com
Freenode: cyphermox, Jabber: mathieu...@gmail.com
4096R/EE018C93 1967 8F7D 03A1 8F38 732E  FF82 C126 33E1 EE01 8C93


signature.asc
Description: Ceci est une partie de message numériquement signée

Bug#567871: SYSFS{}= will be deprecated in a future udev version

[Mathieu Trudel-Lapierre]

On Sun, Jan 31, 2010 at 4:43 PM, dann frazier da...@debian.org wrote:
 SYSFS{}= will be removed in a future udev version, please use ATTR{}= to 
 match the event device, or ATTRS{}= to match a parent device, in 
 /lib/udev/rules.d/60-libconcord1.rules


Thanks!

I had noticed this as well, and it should be resolved soon.

Regards,

/ Matt



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

Bug#561184: Please package josm new upstream version

[Mathieu Trudel-Lapierre]

Package: josm
Version: 0.0.svn2255-1

Hi,

Could you please package the new upstream version for josm? Upstream
lists svn2561 as their current stable version.

Thanks!

Mathieu Trudel
mathieu...@gmail.com



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

Bug#552837: concordance: FTBFS: confname.h:530: error: comma at end of enumerator list

[Mathieu Trudel-Lapierre]

Lucas,

Thanks for the notice. However,

On Wed, Oct 28, 2009 at 6:39 AM, Lucas Nussbaum
lu...@lucas-nussbaum.net wrote:
 Relevant part:
 gcc -DHAVE_CONFIG_H -I.   -I../libconcord  -Wall -ansi -pedantic-errors 
 -L../libconcord  -MT concordance-concordance.o -MD -MP -MF 
 .deps/concordance-concordance.Tpo -c -o concordance-concordance.o `test -f 
 'concordance.c' || echo './'`concordance.c
 In file included from /usr/include/unistd.h:568,
                  from concordance.c:75:
 /usr/include/bits/confname.h:530: error: comma at end of enumerator list
 concordance.c: In function 'cb_print_percent_status':
 concordance.c:170: warning: cast from pointer to integer of different size
 make[2]: *** [concordance-concordance.o] Error 1


Perhaps it's simply my lack of skills at C/C++, but I fail to
understand why /usr/include/bits/confname.h throwing an error is an
error in concordance -- I also know it's the same include in the i386
build.

I just want a second opinion, but I think this is caused by bug #551656.

I'm pretty sure concordance wouldn't be the only package failing this
way, does this warrant bumping up the severity of bug #551656?

/ Matt



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

Bug#543825: acct -- The GNU Accounting utilities for process and login accounting

[Mathieu Trudel-Lapierre]

On Thu, Aug 27, 2009 at 5:47 AM, martin f krafftmadd...@debian.org wrote:
 also sprach Daniel Baumann dan...@debian.org [2009.08.27.0931 +0200]:
 I am orphaning acct.

 Maintaining a package requires time and skills. Please only adopt this
 package if you will have enough time and attention to work on it.

 I'd be willing to sponsor anyone who will dedicate to maintaining
 acct.


My apologies for responding to this so late.

I am interested in maintaining acct. I will update this bug as an ITA shortly.

Interestingly, I had been developing some kind of replacement for it
in perl, following special needs from my workplace that weren't quite
addressed by acct.

/ Matt



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

Bug#512599: Still interested in packaging conguity?

[Mathieu Trudel-Lapierre]

On Tue, Aug 18, 2009 at 3:41 AM, Ian Campbelli...@hellion.org.uk wrote:
 Package: wnpp
 Severity: wishlist
 Owner: Ian Campbell i...@hellion.org.uk

 Hi Mathieu,

 Are you still planning to package congruity?

Yes, still interested, and almost done.

 I've just completed a rough draft
 packaging before I found this ITP. I'm happy to hand over what I've got to you

As it turns out, I was finishing it up and pushing to
mentors.debian.net yesterday. Most of the waiting was for concordance
to be accepted in Debian/Ubuntu so that dependencies would be there.

 or else perhaps you would consider sponsoring the package for me?

Wish I could. Sadly, I'm also somewhat of a beginner in this. I know
my way around packaging better and better now, but I'm not a DD, DM,
or Ubuntu MOTU; yet.

I'd still be interested in looking at what you've done to compare,
since it's always good to see how others work to know if I can do
things better :)

I'm open to options such as co-maintaining the package, too. I just
don't know how it can be done unless one of us is a DD or DM.

/ Matt



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