Bug#946665: mediawiki: autopkgtests may fail due to stderr messages
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
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
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
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 options.output
Bug#933737: nodejs: update tests to account for changes in libuv1 1.30
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
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
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
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
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
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()
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
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
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
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
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
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
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
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
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/65B58DA1 818A D123 0992 275B 23C2 CF89 C67B B4D6 65B5 8DA1 From: Mathieu Trudel-Lapierre 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
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
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&arch=i386&ver=2.5.0-3&stamp=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
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
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
On Sat, Mar 5, 2016 at 6:44 AM, Pierre Chifflier wrote: > On Wed, Feb 24, 2016 at 09:08:58PM -0500, Mathieu Trudel-Lapierre wrote: > > Package: wnpp > > Severity: wishlist > > Owner: "Mathieu Trudel-Lapierre" > > > > * Package name: tpm2-tss > > Version : 0.9.8 > > Upstream Author : Will Arthur > > * 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 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
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
Package: wnpp Severity: wishlist Owner: "Mathieu Trudel-Lapierre" * Package name: tpm2-tools Version : 1.0 Upstream Author : Gang Wei * 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
Package: wnpp Severity: wishlist Owner: "Mathieu Trudel-Lapierre" * Package name: tpm2-tss Version : 0.9.8 Upstream Author : Will Arthur * 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
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 +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
On Wed, Dec 2, 2015 at 6:51 PM, Cyril Brulebois 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 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, 21 Feb 2015 23:14:02 +0100 Emmanuel Bourg 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 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
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 "", line 1, in 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 +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
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 +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 +Signed-off-by: Gene Cumm +--- + 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
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Mathieu Trudel-Lapierre 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
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 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
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
On Sep 12, 2014 6:48 PM, "Olly Betts" 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
On Sat, Jun 14, 2014 at 4:30 PM, Vincent Bernat 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 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 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
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Josselin Mouette 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_PA
Bug#731851: modemmanager: Please update to latest 1.2 release candidate
On Wed, Feb 5, 2014 at 2:50 AM, Guido Günther 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 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
On Tue, Feb 4, 2014 at 4:06 PM, Michael Biebl 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 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
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 pn wpagui -- 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?
On Mon, Mar 11, 2013 at 7:39 PM, Andreas Henriksson wrote: > 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 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
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//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" (Re: Bug#675350: babl: Please ship additional header files)
> From: "Matteo F. Vescovi" > To: Mathieu Trudel-Lapierre > 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 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
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 +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
On Wed, Apr 4, 2012 at 8:59 PM, Cyril Brulebois 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 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
On Mon, Jan 30, 2012 at 1:40 PM, Anton Martchukov 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 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
On Mon, Jan 23, 2012 at 8:57 PM, Mathieu Trudel-Lapierre 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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 rules-opticalraytracer Description: Binary data
Bug#657104: opticalraytracer: FTBFS in a clean schroot
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#656669: gedit-latex-plugin: FTBFS due to latex/latex/environment.py not in POTFILES.in
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#655935: Apologies
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 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#655935: activiz.net: Please use debians default csharp compiler
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 +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#656136: aether: FTBFS due to plexus-component-metadata
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#655479: wpasupplicant: Please consider providing a libeap package.
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 pn wpagui -- no debconf information >From 3de5e59b291b6f58317bb16736f8c0271754378e Mon Sep 17 00:00:00 2001 From: Inaky Perez-Gonzalez 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 --- 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 += ../eap_common/chap.o + +OBJS_peer += ../eap_peer/eap_tls.o +OBJS_peer += ../eap_
Bug#653096: quota: building against libnl3 3.2.3
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 pn rpcbind | portmap 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 +Maintainer: Ubuntu Developers +XSBC-Original-Maintainer: Michael Meskes 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 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 +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") 2>&5 ++{ { $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") 2>&5 + ac_status=$? + $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
Bug#653021: ipvsadm: build against libnl3
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Mathieu Trudel-Lapierre 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 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 XSBC-Original-Maintainer: Alexander Wirt 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
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 -- 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 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,
Bug#564579: asciidoc: Consider using docbook.xsl from docbook-xsl.
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 dblatex pn docbook-utils pn libxml2-utils 2.7.8.dfsg-5ubuntu1 pn xmlto Versions of packages asciidoc suggests: pn source-highlight pn vim-addon-manager -- 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
The previous patch does appear to work but remains technically incorrect. Please see the attached revised patch ;) Regards, Mathieu Trudel-Lapierre Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Mathieu Trudel-Lapierre 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
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 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#648875: FTBFS in restrictive chroots
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 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#648852: FTBFS in restricted chroots
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 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#648782: FTBFS due to undefined symbols
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Mathieu Trudel-Lapierre 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['midi
Bug#584896: Please test with concordance directly
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 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#627127: Possible translation
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 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
Package: wnpp Severity: wishlist * Package name: wimax-tools Version : 1.4.5 Upstream Author : Intel Corporation * URL : http://linuxwimax.org/ * License : BSD Programming Lang: C Description : user-land tools to control WiMAX devices Mathieu Trudel-Lapierre 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
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 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
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 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]
reassign 159090 ksh thanks On Sat, Mar 19, 2011 at 2:04 PM, Jeff Green 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 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
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 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: Related bug 592539
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 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
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/. 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 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 2>&1; then + if ! /usr/sbin/dhcpd $DHCPMODE -t -q > /dev/null 2>&1; 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#611327: lunar-applet: FTBFS with evolution API >= 2.32
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 Freenode: cyphermox, Jabber: mathieu...@gmail.com 4096R/EE018C93 1967 8F7D 03A1 8F38 732E FF82 C126 33E1 EE01 8C93 From: Mathieu Trudel-Lapierre 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#554557: [PATCH] fix FTBFS with binutils-gold
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 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#571681: [PATCH] fix file chooser dialog initalization
Hi, Please see the attached patch which fixes the issue. Mathieu Trudel-Lapierre 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#605837: unblock: concordance/0.22-3
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 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
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 é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
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 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)
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 --- Begin Message --- 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
Package: wnpp Severity: wishlist Owner: Mathieu Trudel-Lapierre * Package name: monitor-edid Version : svn269700 Upstream Author : Anssi Hannula * 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
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
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 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
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 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
On Sun, Jan 31, 2010 at 4:43 PM, dann frazier 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
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
Lucas, Thanks for the notice. However, On Wed, Oct 28, 2009 at 6:39 AM, Lucas Nussbaum 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
On Thu, Aug 27, 2009 at 5:47 AM, martin f krafft wrote: > also sprach Daniel Baumann [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?
On Tue, Aug 18, 2009 at 3:41 AM, Ian Campbell wrote: > Package: wnpp > Severity: wishlist > Owner: Ian Campbell > > 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