Bug#1061207: marked as pending in android-platform-art
Control: tag -1 pending Hello, Bug #1061207 in android-platform-art reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/android-tools-team/android-platform-art/-/commit/5f306b2ce25f7f976ddda6b20d6145ca6b4509a0 Prepare to release 14.0.0+r15-2 d/control and d/rules: Use default clang/lld version Closes: #1061207 (this message was generated automatically) -- Greetings https://bugs.debian.org/1061207
Bug#1043074: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1043074 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/a4f7584d200b0128d266dcfbe0fb298487966194 Prepare to release 4.34.0+ds-2 d/control: Add protoc-gen-go-1-3 to B-D to fix ftbfs Closes: #1043074 (this message was generated automatically) -- Greetings https://bugs.debian.org/1043074
Bug#1000022: marked as pending in android-platform-tools
Control: tag -1 pending Hello, Bug #122 in android-platform-tools reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/android-tools-team/android-platform-tools/-/commit/138b1f38ecbab3d312bd583849304ca5f421982d d/control: Remove D-B libpcre3-dev, which is not used Closes: #122 (this message was generated automatically) -- Greetings https://bugs.debian.org/122
Bug#1040323: android-libnativehelper: undeclared file conflict with android-libnativehelper-dev from bullseye
control: tag -1 +pending uploaded fix to bullseye-backport pending for NEW queue check
Bug#1034367: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1034367 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/580fc9accf3ca22089ed80e84097cca1b75e697f Prepare to release 4.34.0+ds-1 * Repack to remove geoip data from source due to license. Closes: #1034367 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034367
Bug#1034367: marked as pending in golang-v2ray-core
> I'm afraid this fix is incomplete. The source package still contains the > data files with a non-free license and hence Debian is redistrbuting > them. golang-v2ray-core needs to be repacked to completly get rid of the > files. Yes, current fix just removes the geoip data from binary package. For source package, considering current hard freeze status, we cannot update the source package. I plan to do it after bookworm releasing. For bookworm, can I lower the severity to keep this package? Otherwise, this package and rdepends package will be removed from testing/bookworm suite soon. Cheers, Roger
Bug#1034982: marked as pending in android-platform-tools
Control: tag -1 pending Hello, Bug #1034982 in android-platform-tools reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/android-tools-team/android-platform-tools/-/commit/306d8baf16f46ce19d8b58afd7016d862f77f12b Resolve upgrade issue from bullseye to bookworm One .so alias was moved from android-libnativehelper to android-libnativehelper-dev. So need this breaks, and replaces fixes for d/control. This was already handled in debian/exp, but forgot to cherry-pick to sid. Closes: #1034982 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034982
Bug#1034367: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1034367 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/d204696ce754ee8605f97bb277b23bcda5f1b0da Prepare to release 4.34.0-9 Remove geoip data and test code due to license Closes: #1034367 (this message was generated automatically) -- Greetings https://bugs.debian.org/1034367
Bug#1014831: android-platform-frameworks-base: aapt2 command does not work at all
control: found -1 1:13.0.0+r30-1~exp1 still occurs in latest experimental version.
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Dear Hans-Christoph, Now the main blocker for migrating android-platform-tools from experimental to sid is: - https://qa.debian.org/excuses.php?experimental=1=android-platform-tools And blocker for migrating android-platform-frameworks-base is Bug#1014831 - https://bugs.debian.org/1014831 I still don't have good way to resolve it. One idea is to enable all the embedded *_test.cpp code, and to see whether the tests pass or not. Cheers, Roger On Mon, Feb 13, 2023 at 12:17 AM Hans-Christoph Steiner wrote: > > > Roger, it is great to see your progress on android-platform-tools. Are you > thinking of trying to get it into bookworm? If so, let me know how I can > help. > It would be really valuable to have there, but I don't know how much work > it'll be.
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Dear Jochen,
> Oups, sorry. The attached patch against android-platform-tools fixes the
> issue for me.
Very appreciated!
I tried the patch in pbuilder and porterbox, and found the patch need
slight modify.
Enclosed is the patch confirmed working on my side.
BTW. The patch was already incorporated into
android-platform-tools/33.0.3-1~exp8
Thanks again for your kind help!
Cheers,
Roger
Description: Implement const_iterator::operator--
Forwarded: not-needed
Needed for
android-platform-frameworks-base/libs/androidfw/LoadedArsc.cpp
when compiling against libstdc++.
---
--- a/system/incremental_delivery/incfs/util/include/util/map_ptr.h
+++ b/system/incremental_delivery/incfs/util/include/util/map_ptr.h
@@ -180,6 +180,11 @@ public:
return *this;
}
+const const_iterator& operator--() {
+safe_ptr_--;
+return *this;
+}
+
const_iterator& operator+=(int n) {
safe_ptr_ = safe_ptr_ + n;
return *this;
@@ -321,6 +326,14 @@ public:
return temp;
}
+template = 0>
+const map_ptr operator--(int) {
+map_ptr temp = *this;
+LIBINCFS_MAP_PTR_DEBUG_CODE(verified_ = false);
+--ptr_;
+return temp;
+}
+
template = 0>
map_ptr operator+(const S n) const {
return map_ptr(map_, ptr_ + n, verified_block_);
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
Dear Jochen, Thanks for your reply, and kindness trying to help! > On Thu, Feb 9, 2023 at 1:30 PM Jochen Sprickerhof wrote: > What exactly did you test? Please try the version in experimental. and also refer the version info of this ticket: Found in versions android-platform-frameworks-base/1:10.0.0+r36-5, android-platform-frameworks-base/13~beta3-1~exp1 Fixed in version android-platform-frameworks-base/1:10.0.0+r36-6 Cheers, Roger
Bug#1012890: android-platform-frameworks-base: ftbfs with GCC-12
control: tags -1 +help + Hans-Christoph Dear Hans-Christoph, It'd be appreciated if you can help this ticket. I tried a few ways, but it still doesn't work. On Sat, Feb 4, 2023 at 12:09 AM Roger Shimizu wrote: > > control: reopen -1 > > Yes, it ftbfs on sid now. > And I tried latest upstream 13.0.0_r24, result is the same. > Have to fix this issue before we can migrate to sid. Error log is not originally reported, for latest error log please refer to: - https://bugs.debian.org/1012890#17 I guess the issue is caused due to upstream using clang stdc++ lib, but we're using gcc/g++ one. Those two have slight differences. Cheers, Roger
Bug#1028832: marked as pending in golang-github-cloudflare-circl
Control: tag -1 pending Hello, Bug #1028832 in golang-github-cloudflare-circl reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-cloudflare-circl/-/commit/82cd45e68a8648089467100cbaeeef0da5422bbf Prepare to release 1.3.1-2 Fix FTBFS issue: * debian/control: Add golang-golang-x-crypto-dev to B-D and Depends * debian/rules: Remove path internal/shake/testdata which does not exist Closes: #1028832 (this message was generated automatically) -- Greetings https://bugs.debian.org/1028832
Bug#1012572: android-platform-frameworks-base: FTBFS with protobuf 3.20.1+
Dear Mattia, Thanks for the remind! I'll upload the patch to sid soon. Cheers, Roger On Sun, Dec 4, 2022 at 8:49 PM Mattia Rizzolo wrote: > Hello Roger, > > On Fri, Jun 10, 2022 at 09:48:06PM +0900, Roger Shimizu wrote: > > I tried your patch by installing protobuf in experimental > > and confirmed it builds well, and all tests are also OK. > > Will upload after protobuf 3.20 (or later) hits unstable. > > Thanks for your support! > > You uploaded this patch to experimental, however I see no sign of v13 to > be uploaded to unstable anytime soon. > > Can you please apply this same patch also in unstable? > > -- > regards, > Mattia Rizzolo > > GPG Key: 66AE 2B4A FCCF 3F52 DA18 4D18 4B04 3FCD B944 4540 .''`. > More about me: https://mapreri.org : :' : > Launchpad user: https://launchpad.net/~mapreri `. `'` > Debian QA page: https://qa.debian.org/developer.php?login=mattia `- >
Bug#1014831: android-platform-frameworks-base: aapt2 command does not work at all
Package: android-platform-frameworks-base Version: 1:13~beta3-1~exp1 Severity: serious Justification: must Dear Maintainer, aapt2 does not work at all, even `aapt2 version` fails. So I disabled the aapt2 invoking while building for 1:13~beta3-1~exp1: - https://salsa.debian.org/android-tools-team/android-platform-frameworks-base/-/commit/887382e Need to fix this issue before uploading to sid. Cheers, Roger
Bug#1009818: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1009818 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/10b9a5eeded5cee1d1c8b0eb8edec6b12a6e2cf8 Prepare to release 4.34.0-7 d/patches: Cherry pick from upstream to fix issues - Crashes when VMess Protocol is used. - CVE-2021-4070 DoS by Authenticated VMess Server. Closes: #1009818, #1010377 (this message was generated automatically) -- Greetings https://bugs.debian.org/1009818
Bug#1010386: marked as pending in golang-v2ray-core
Control: tag -1 pending Hello, Bug #1010386 in golang-v2ray-core reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-v2ray-core/-/commit/19ecbaa06ef95033c736ee7506dd4d8c8205ebce Prepare to release 4.34.0-6 * debian/patches: - Amend patch 02 to skip 1 tests to fix ftbfs on armel and armhf. Closes: #1010386 (this message was generated automatically) -- Greetings https://bugs.debian.org/1010386
Bug#999334: android-platform-tools: FTBFS: error: no member named 'unique_lock' in namespace 'std'
control: tags -1 +help I pushed a few patches to salsa that can resolve previously reported ftbfs issues, however there're still other ftbfs issues. For amd64, pbuilder reports: :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ :1:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_initialize_static_storage, artInitializeStaticStorageFromCode, 0x20 ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1154:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL_FOR_CLINIT art_quick_initialize_static_storage, artInitializeStaticStorageFromCode ^ :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ :1:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_resolve_type, artResolveTypeFromCode, 0x20 ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1155:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL_FOR_CLINIT art_quick_resolve_type, artResolveTypeFromCode ^ :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1156:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_resolve_type_and_verify_access, artResolveTypeAndVerifyAccessFromCode ^ :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1157:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_resolve_method_handle, artResolveMethodHandleFromCode ^ :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1158:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_resolve_method_type, artResolveMethodTypeFromCode ^ :12:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,(144 + 16*8) ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1159:1: note: while in macro instantiation ONE_ARG_SAVE_EVERYTHING_DOWNCALL art_quick_resolve_string, artResolveStringFromCode ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1282:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,64 ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1544:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,16 ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:1559:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,16 ^ art/runtime/arch/x86_64/quick_entrypoints_x86_64.S:2263:24: error: expected newline .cfi_restore_state .cfi_def_cfa rsp,80 ^ for other ARCH, there might be other errors as well. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1002227: golang-github-templexxx-xor: FTBFS: dh_auto_test: error: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 4 github.com/templexxx/xor returned exit code 1
control: tags -1 +moreinfo unreproducible control: severity -1 important Dear Lucas, Thanks for the report! > During a rebuild of all packages in sid, your package failed to build > on amd64. However, I cannot reproduce this ftbfs issue in my sid pbuilder environment. The dh_auto_test can pass without problem. Can you kindly retest? Do we have a workflow regarding to such case? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1002666: [Pkg-privacy-maintainers] Bug#1002666: torbrowser-launcher: Package in Bullseye outdated and downloading Tbb fails because of bad certificate
control: severity -1 important control: tags -1 +moreinfo +unreproducible On Mon, Dec 27, 2021 at 7:45 AM Richard Z wrote: > > Package: torbrowser-launcher > Version: 0.3.3-6 > Severity: grave > Justification: renders package unusable > X-Debbugs-Cc: r...@linux-m68k.org > > Dear Maintainer, > > > the version in Bullseye seems to old, it never succeeds > downloading the Tor Browser. I see there are newer packages > in testing/unstable, could those be backported? Thanks for your report! I tried 0.3.3-6 locally, and can download latest 11.0.3 TBB without issue. Of course I can upload a backports version, but I guess it will be the same on your side. Maybe you can clean up ~/.local/share/torbrowser/ folder and try again. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1
Dear Paul, On Thu, May 27, 2021 at 5:36 PM Paul Gevers wrote: > > Hi Roger, > > On Mon, 17 May 2021 18:58:37 +0900 Roger Shimizu > wrote: > > However I find this package cannot be source upload, due to non-free. > > I'll upload with binary again with version -17 later. > > After that, I'll amend your unblock request. > > Just for future reference, you don't need to upload a new source, just > the binaries build from that source would be fine. Small advantage: the > migration timer isn't reset. Thanks for your information! I'll try to upload in binary next time in such case. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988562: broadcom-sta: diff for NMU version 6.30.223.271-16.1
Dear Ben, Thanks for the report and NMU! On Mon, May 17, 2021 at 8:21 AM Ben Hutchings wrote: > > Control: tags 988562 + patch > Control: tags 988562 + pending > > Dear maintainer, > > I've prepared an NMU for broadcom-sta (versioned as 6.30.223.271-16.1) > and uploaded it. > > The changes are attached as a debdiff, but you can also merge the > "debian" branch of <https://salsa.debian.org/benh/broadcom-sta.git>. However I find this package cannot be source upload, due to non-free. I'll upload with binary again with version -17 later. After that, I'll amend your unblock request. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#978684: autopkgtest should test the installed package
> As pointed in the see autopkgtest specification [1] linked from the > release team documentation [2] “the tests must test the *installed* > version of the package”. The autopkgtest from this package only uses the > source package, and as such violates the specification. Displaying it as > an example in the wiki [3] may not be advisable. Thanks for spotting this! I edited the wiki to add this is a bad example for autopkgtest. And I'm going to remove the debian/tests folder on the next upload. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
On Wed, Dec 30, 2020 at 3:46 AM Hans-Christoph Steiner wrote: > > Ok, I fixed the dependency issue, now it gets reliably to the point rosh > gets to: Thanks for fixing the build dependency issue! I fixed a few other issues (operator script & mterp generation, etc), and pushed to rosh/refine branch. Current build breaking point is the same as previous one. I tried to use different c++ library, such as libstdc++-8-dev, and clang-9, but seems no help. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976891: [Android-tools-devel] Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
On Thu, Dec 24, 2020 at 6:33 AM Hans-Christoph Steiner wrote: > > As far as I know, the blocker for fastbook is android-platform-art. It > has a crazy upstream build system. Right now, it almost building, but > the build is currently dying on this error: I fixed the above issue by branch "rosh/refine". And current error is: In file included from runtime/stack_map.cc:17: In file included from runtime/stack_map.h:22: In file included from libartbase/arch/instruction_set.h:21: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/string:40: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/char_traits.h:39: In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_algobase.h:64: /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/bits/stl_pair.h:218:11: error: field has incomplete type 'art::Stats' _T2 second;///< The second member ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/ext/aligned_buffer.h:91:28: note: in instantiation of template class 'std::pair' requested here : std::aligned_storage ^ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976913: golang-github-henrydcase-nobs: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_build: error: cd obj-powerpc64le-linux-gnu && go install -trimpath -v -p 160
forwarded -1 https://github.com/henrydcase/nobs/issues/37 from upstream: > only x86-64 and aarch64 is currently supported. why would you need i386 > exactly? So currently maybe we can only build for amd64 and arm64. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
On Wed, Dec 23, 2020 at 5:38 AM Hans-Christoph Steiner wrote: > > Thanks for jumping in Roger! I reviewed it with cdesai, and we thought > those libraries were not used on the "host" version, only when built as > part of Android OS. I do think libfec would be useful if someone wants > to package adbd for Debian. The Google Android Tools builds do not > include adbd for the host, only for the Android OS. I uploaded my current work to branch rosh/fastboot and build log can be checked by: - http://debomatic-amd64.debian.net/distribution#unstable/android-platform-system-core/10.0.0+r36-1~stage2/buildlog >From the build log, I think fastboot still depends on fs_mgr, which depends on the new libs I mentioned previously (such as android-libfec). Maybe you have workaround not building fs_mgr completely, but currently I don't have no idea. > Right now, the only blocker I know about is the assembler code in > android-platform-art, which Michel and I are working on now. Yes, I also noticed this part lately. Hope you have good news on this. Cheers -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976891: fastboot exits with "fake placeholder until fastboot builds" message
I'm trying to restore fastboot back to build for 1:10.0.0+r36-1~stage1.3 however, seems there're a few new dependencies. one is android-libfec inside src:android-platform-system-extras I already uploaded to NEW queue. another two is: - https://android.googlesource.com/platform/external/avb - https://android.googlesource.com/platform/system/vold Hope we can still catch up with bullseye... Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976940: marked as done (golang-refraction-networking-utls: FTBFS on ppc64el (arch:all-only src pkg): dh_auto_test: error: cd obj-powerpc64le-linux-gnu && go test -vet=off -v -p 160 github.com/refr
control: reopen -1 control: severity -1 normal previous fix was just ignoring the test failure on ppc64el. so reopen, but lower the severity.
Bug#975209: FTBFS: src/v2ray.com/core/transport/internet/quic/conn.go:11:2: cannot find package "github.com/lucas-clemente/quic-go"
control: reassign -1 golang-v2ray-core-dev 4.31.0+ds-1~exp1 golang-v2ray-core-dev should depend on golang-github-lucas-clemente-quic-go-dev
Bug#974915: marked as pending in golang-github-cheekybits-genny
Control: tag -1 pending Hello, Bug #974915 in golang-github-cheekybits-genny reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/golang-github-cheekybits-genny/-/commit/ad1eb2a559992bc9fc272d3edc7f190906964c3c Prepare to release 1.0.0-7 * d/control: - Move Breaks+Replaces: golang-github-cheekybits-genny-dev (<< 1.0.0-4) to package genny. Thanks to Andreas Beckmann for the advice. Closes: #974915 (this message was generated automatically) -- Greetings https://bugs.debian.org/974915
Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release
On Thu, Sep 24, 2020 at 1:49 PM Lev Lamberov wrote: > > I've installed torbrowser-launcher from experimental and can confirm > that it works properly for me. Thanks for you work on it! Dear Lev, Thanks for your confirmation! I uploaded -14 to unstable and buster-backports. So for debian it should be OK now. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#970768: torbrowser-launcher: error while checking version number after TorBrowser 10.0 release
Dear Lev, Thanks for your report! On Wed, Sep 23, 2020 at 4:00 PM Lev Lamberov wrote: > > Package: torbrowser-launcher > Version: 0.3.2-13 > Severity: grave > Tags: upstream > Justification: renders package unusable > > Dear Maintainer, > > because of faulty version number check, torbrowser-launcher cannot > correctly handle TorBrowser 10.0 release. Now it shows the following > error message: > > The version of Tor Browser you have installed is earlier than it > should be, which could be a sign of an attack! > > Seems that because of this error it is not possible to install the new > release of TorBrowser, and installation of it is run everytime when > running torbrowser-launcher. So, torbrowser-launcher simply doesn't do > what it should (install and run TorBrowser), which make it unusable. > > There is an upstream issued already reported, see #498 [#498], and > merge request submitted. > > [#498] https://github.com/micahflee/torbrowser-launcher/issues/498 I just uploaded 0.3.2-14~exp1 to experimental. Since I cannot launch TBB after downloading it. (I'm using buster + backports) Can you kindly help to confirm it works on your side? Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#960603: google-android-installers binaries rejected
Dear Adrian, Thanks for your hint! On Thu, May 14, 2020 at 11:50 PM Adrian Bunk wrote: > > On Thu, May 14, 2020 at 11:16:47PM +0900, Roger Shimizu wrote: > > On Thu, May 14, 2020 at 10:27 PM Adrian Bunk wrote: > > > > > > Source: google-android-installers > > > Version: 1472023576+nmu4 > > > Severity: grave > > > Tags: ftbfs > > > > > > bunk@coccia:~$ cat > > > /srv/ftp-master.debian.org/queue/reject/google-android-installers_1472023576+nmu4_all.changes.reason > > > > > > Version check failed: > > > Your upload included the binary package > > > google-android-platform-21-installer, version 21+r02+nmu3, for all, > > > however testing already has version 21+r02+nmu3. > > > > It's weird since I cannot find 21+r02+nmu3 in tracker: > > * https://tracker.debian.org/pkg/google-android-installers > > Tracker lists source package versions, not binary package versions. > > Source packages and binary packages can have different versions. > The most common example are binNMUs. > > > maybe other src package also produce this binary pkg? > > No, the versions for the binary packages are defined in > debian/rules. > > "apt-cache show" says: > > Package: google-android-platform-23-installer > Source: google-android-installers (1472023576+nmu3) > Version: 23+r03+nmu3 > > Package: google-android-platform-24-installer > Source: google-android-installers (1472023576+nmu3) > Version: 24+r02+nmu3 Now I understood it. And it actually the same as #915657, previous NMU. Sorry for not checking it for the first place. Bow! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#960603: google-android-installers binaries rejected
On Thu, May 14, 2020 at 10:27 PM Adrian Bunk wrote: > > Source: google-android-installers > Version: 1472023576+nmu4 > Severity: grave > Tags: ftbfs > > bunk@coccia:~$ cat > /srv/ftp-master.debian.org/queue/reject/google-android-installers_1472023576+nmu4_all.changes.reason > > Version check failed: > Your upload included the binary package google-android-platform-21-installer, > version 21+r02+nmu3, for all, > however testing already has version 21+r02+nmu3. It's weird since I cannot find 21+r02+nmu3 in tracker: * https://tracker.debian.org/pkg/google-android-installers maybe other src package also produce this binary pkg? -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#949461: repo is an empty package in unstable/testing, failing it's autopkg tests
Dear Marcos, Thanks for your email and contribution! > An update to this package, based on salsa's repository, is available in > https://github.com/marado/repo . It bumps repo's version to the latest, > as well as fixes the empty package issue. However we usually don't update so much stuff in one ticket. I think you'd better open merge-request on salsa if you want those patches be merged. PS. I saw this issue is already resolved by one merge-request. So I uploaded the package. You should be able to see it in testing in a few days (usually 2). Looking forward to your activity on salsa! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#959002: broadcom-sta-dkms: Wl driver 6.30.223.271 (r587334) failed with code 21
control: notfixed -1 6.30.223.271-14 control: severity -1 important Dear Gert, Please CC me when you reply. Thank you! > bullseye: > status installed broadcom-sta-dkms:all 6.30.223.271-14 > buster-backports: > status installed broadcom-sta-dkms:all 6.30.223.271-14~bpo10+1 > This also did not work with same errors. > At the buster-backports version I tried the command dpkg-reconfigure > broadcom-sta-dkms , that gave same errors. > Also restarts did not help. I thought you worked well with previous version, but failed with new version, so marked this ticket as grave. Now I understand your report is not about a regression. So lower the severity. All hardware I have still work well with latest version (6.30.223.271-14), so I think your hardware may be not supported by this driver. We cannot say whether a specific hardware is supported by this driver or not, until we tried it. > I have no idea this has some relation, but at April a new version of > wireless-regdb is upgraded with lot of changes. If you can modprobe the driver sucessfully, but have problem connecting to some Wifi AP, it may be related to wireless-regdb. So I don't think it matters for your case. > I do not understand why this problem is marked as fixed at > 6.30.223.271-14, because this just is the version I used when I got the > problem. Sorry, I mistook your problem for another one. So I update the flag this time. > Is my device not supported and broadcom-sta-dkms:all 6.30.223.271-14 > working without problem for other devices? I guess so, and you'd better try other drivers listed on wiki: - https://wiki.debian.org/bcm43xx - https://wiki.debian.org/brcm80211 - https://help.ubuntu.com/community/WifiDocs/Driver/bcm43xx > In that case perhaps the installation Wiki should be updated to show the > exceptions? I'm afraid that's not possible because only the hardware vendor can decide such. And usually package maintainer don't have all hardware .. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#958257: golang-github-cheekybits-genny: Installs no Golang files
control: fixed -1 1.0.0-3 control: close -1 > Package installs no golang files. Fixed by my latest upload. Sorry I didn't find this report before uploading. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#959002: broadcom-sta-dkms: Wl driver 6.30.223.271 (r587334) failed with code 21
control: tags -1 +moreinfo control: found -1 6.30.223.271-10 control: fixed -1 6.30.223.271-14 Dear Gert, > Because I recently had trouble with Wifi after an upgrade of package > firmware-b43-installer, > I purged this package and tried to install package broadcom-sta-dkms, > according to the recently updated instruction at > https://wiki.debian.org/wl . > Installation uses the package from bullseye/testing not from some backport. Thanks for your report! I have a few questions: * please kindly provide the debian version you use. I guess it should be 6.30.223.271-10, which is in stable/buster. * have you tried the step in wiki: "3. (Optional) Rescue if install/build fails in previous step"? * can you try the backports version? detail procedure is already explained in wiki. I guess it's already fixed by 6.30.223.271-14~ or backports version in buster and stretch. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles
On Sun, Jan 5, 2020 at 11:24 PM intrigeri wrote: > > Hi, > > Roger Shimizu (2020-01-05): > > I find this is due to below files were shipped by previous version of > > torbrowser-launcher, but not as conffile. > > /etc/apparmor.d/local/torbrowser.Tor.tor > > /etc/apparmor.d/local/torbrowser.Browser.firefox > > Yes. > > > But now they're shipped with conffile, though in size zero. > > That's indeed the problem IMO. See below for my reasoning. > > > So new conffiles complain they don't match with existing ones. > > Right. Thanks for your confirmation! > > It can be fixed by removing the old files when they match the checksum > > of old shipped ones. > > The fix will be uploaded soon. > > I think this can help for files under /etc/apparmor.d/local/ that the > package does not install at all anymore (be it via dh-apparmor or as > conffiles). This would clean up stuff and that's good :) > > But I don't think it will help for local/torbrowser.Tor.tor and > local/torbrowser.Browser.firefox, which this bug report was initially > about. > > FYI, the very purpose of the files under /etc/apparmor.d/local/ is to > be modified by the system administrator, that is, to diverge from > what's shipped by packages under /etc/apparmor.d/. The content of > these files will, by design, always be: local changes, done manually, > and that packages and dpkg should not fiddle with. > > So, if /etc/apparmor.d/local/* are conffiles, and if the administrator > is using this facility, upon upgrades their local changes will > necessarily conflict with the (empty) version installed by the > package, and dpkg will ask what to do. That would be pretty annoying, > since the answer to dpkg's question in this case will always be "keep > my local changes, because that's what this file is for after all :)". > > I hope this clarifies the drawback I see in handling these files > as conffiles. Yes, I didn't find a way to exclude local profile from being listed as conffile, until I find: - https://stackoverflow.com/questions/3398511/prevent-creation-of-conffiles Now I can confirmed that patch below to debian/rules can do the trick: +override_dh_installdeb: +dh_installdeb +sed -i '\:/etc/apparmor.d/local/:d' debian/*/DEBIAN/conffiles I'll upload this fix soon. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles
On Wed, Dec 11, 2019 at 1:00 AM Andreas Beckmann wrote: > > I can reproduce this with piuparts on the upgrade path > jessie -> (stretch) -> (buster) -> bullseye > There was no torbrowser-launcher in stretch or buster, therefore the > jessie version was kept installed and finally upgraded to bullseye. > There are no local modfications to these files. > > Setting up torbrowser-launcher (0.3.2-4) ... > > Configuration file '/etc/apparmor.d/local/torbrowser.Browser.firefox' >==> File on system created by you or by a script. >==> File also in package provided by package maintainer. > What would you like to do about it ? Your options are: > Y or I : install the package maintainer's version > N or O : keep your currently-installed version > D : show the differences between the versions > Z : start a shell to examine the situation >The default action is to keep your current version. > *** torbrowser.Browser.firefox (Y/I/N/O/D/Z) [default=N] ? dpkg: error > processing package torbrowser-launcher (--configure): >end of file on stdin at conffile prompt I find this is due to below files were shipped by previous version of torbrowser-launcher, but not as conffile. /etc/apparmor.d/local/torbrowser.Tor.tor /etc/apparmor.d/local/torbrowser.Browser.firefox But now they're shipped with conffile, though in size zero. So new conffiles complain they don't match with existing ones. It can be fixed by removing the old files when they match the checksum of old shipped ones. The fix will be uploaded soon. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#934119: [Pkg-privacy-maintainers] Bug#934119: torbrowser-launcher: Erroneously manages /etc/apparmor.d/local/torbrowser.* as conffiles
Dear Intrigeri, Thanks for your report, and sorry I just had time to look at this issue. On Wed, Aug 7, 2019 at 5:21 PM wrote: > > Package: torbrowser-launcher > Version: 0.3.2-1 > Severity: normal > > With this version, /etc/apparmor.d/local/torbrowser.Browser.firefox > and /etc/apparmor.d/local/torbrowser.Tor.tor are managed as conffiles > again, while they should not: they're supposed to be created/deleted > as needed by bits of maintainer scripts generated by dh_apparmor. So you mean we should revert 9fdce2a576782bb0790416bcf739b31ceb869c6b? > A problematic consequence is that if I have local tweaks in those > files (which is their actual intended purpose), I'm asked on upgrade > to resolve the conflict between my configuration and the empty one > shipped by the package. > > I believe we've had the same bug in the past, that got fixed in > d0deb2f923edbaf3c2801c46d74b7925c5605593. I'm not sure what > exact rm_conffile call would be suitable here (depends on which > upgrade paths we shall support). d0deb2f923edbaf3c2801c46d74b7925c5605593 was just add entries of rm_conffile line. I'm not sure why we should remove rm_conffile here. Please provide more info if possible. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#794466: Virtualbox backport for Stretch?
On Fri, Aug 23, 2019 at 5:33 PM Gianfranco Costamagna wrote: > > I'm not sure backports team will be happy with this... > and the lack of upstream cooperation is still an issue. Backports team won't complain if the package is in testing. And I think release team won't complain now since it's not in freezing stage. Lack of upstream support usually means we won't have it in stable. But if user decide to use backports by their own choice, they should be able to do that. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#794466: Virtualbox backport for Stretch?
control: severity -1 normal Since buster is already released, let's let the package migrate to testing and upload to backports as before. Cheers, Roger
Bug#926042: torbrowser-launcher should not be included in Buster
severity: -1 normal Buster is released, so I guess it's okay to reduce the severity to let it migrate to testing again. I'll try to backports to stable and sloppy later. Cheers, -- Roger Shimizu, GMT -3 Curitiba PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#927165: debian-installer: improve support for LUKS
On Tue, Jun 11, 2019 at 12:06 AM Guilhem Moulin wrote: > > Hi there, > > On Mon, 15 Apr 2019 at 23:24:19 +0200, Cyril Brulebois wrote: > >>> One could argue that cryptodisk support has never been supported by > >>> d-i anyway, > >> > >> Yup, and I suppose that's why I overlooked this in my mail to > >> debian-boot :-P Jonathan Carter had a similar report last week > >> > >> https://alioth-lists.debian.net/pipermail/pkg-cryptsetup-devel/2019-April/008196.html > > > > While I'm usually fine to dismiss some bug reports as “it's unsupported, > > sorry”, making users' life harder doesn't seem really reasonable… :/ > > During last week's gathering at MiniDebConf Hamburg we (cryptsetup package > maintainer + KiBi) talked and came up with the following guide/notes: > > https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html Thank for the above doc, which is quite easy understanding and straightforward! I didn't notice this until it's mentioned by release announcement of D-I RC2 [1]. I confirmed with /boot set up in LUKS1, everything works fine. It‘d configure non encrypted /boot when in D-I, then after finishing D-I, and reboot to system, manually make LUKS1 for /boot partition. However, I found adding: GRUB_PRELOAD_MODULES="luks cryptodisk" to /etc/default/grub is not necessary. GRUB_ENABLE_CRYPTODISK=y is the only setting need to append manually. (/etc/fstab /etc/crypttab need to be edited for sure) Thanks again for your effort on the guide/notes above! [1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#924151: grub2-common: wrong grub.cfg for efi boot and fully encrypted disk
After reading release announcement of D-I RC2 [1], it's got my attention that there's an well written doc [2]. It's mentioned that /boot should be in LUKS1, due to grub doesn't support LUKS2 yet [3], which is why this ticket originally reported, I guess. I confirmed with /boot set up in LUKS1, everything works fine. It‘d configure non encrypted /boot when in D-I, then after finishing D-I, and reboot to system, manually make LUKS1 for /boot partition. Detail procedure is in the doc [2]. [1] https://lists.debian.org/debian-devel-announce/2019/06/msg5.html [2] https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html [3] https://savannah.gnu.org/bugs/?55093 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#919293: [pkg-gnupg-maint] Bug#919293: FTBFS: Test keys expired 2019-01-06
user debian-rele...@lists.debian.org usertag -1 + bsp-2019-01-jp-tokyo thanks On Tue, Jan 15, 2019 at 2:03 AM Julian Andres Klode wrote: > > Source: gpgme1.0 > Severity: serious > User: ubuntu-de...@lists.ubuntu.com > Usertags: origin-ubuntu disco > > See https://dev.gnupg.org/T3815 and > https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=66376f3e206a1aa791d712fb8577bb3490268f60 I'm trying to see this issue in Tokyo BSP 2019/January. - https://wiki.debian.org/BSP/2019/01/ja/Tokyo This issue can be reproduced under my ARCH=i386 git-pbuilder environment: gbp buildpackage --git-pristine-tar --git-pbuilder However it cannot be reproduced under simple git-buildpackage command in stretch: gbp buildpackage -us -uc --git-pristine-tar I'll try to dig more later. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#917707: golang-github-gin-gonic-gin: FTBFS: dh_auto_test: cd obj-x86_64-linux-gnu && go test -vet=off -v -p 2 github.com/gin-gonic/gin github.com/gin-gonic/gin/binding github.com/gin-gonic/gin/gin
user debian-rele...@lists.debian.org usertags -1 + bsp-2019-01-jp-tokyo thanks I'm trying to see this issue in Tokyo BSP 2019/January. - https://wiki.debian.org/BSP/2019/01/ja/Tokyo But it builds fine under my ARCH=i386 git-pbuilder environment. And it seems fine on reproducible-builds: - https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/golang-github-gin-gonic-gin.html I guess it's a temporary FTBFS due to some dependencies, which is fixed already. We can continue to observe the result from reproducible-builds for a while. If it continuous OK, we can safely close this ticket. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#916605: [Pkg-privacy-maintainers] Bug#916605: torbrowser-launcher: I can't start torbrowser-launcher
control: severity -1 important Thanks for your report! On Sun, Dec 16, 2018 at 11:21 PM Freach wrote: > > Package: torbrowser-launcher > Version: 0.3.1-2 > Severity: grave > Justification: renders package unusable > > When I first time installed and started,it prompted me to install something > for > the first time start.After the automatic installation is completed,it auto > quit > this torbrowser-launcher,Then I clicked the run torbrowser-launcher > agin,Nothing happend and it not start,if I type"torbrowser-launcher"in the > terminal.It show these:"Tor Browser Launcher > By Micah Lee, licensed under MIT > version 0.3.1 > https://github.com/micahflee/torbrowser-launcher > Launching Tor Browser. > Running /home/anon/.local/share/torbrowser/tbb/x86_64/tor-browser_en-US/start- > tor-browser.desktop > Launching './Browser/start-tor-browser --detach'... > QFileSystemWatcher::removePaths: list is empty > QFileSystemWatcher::removePaths: list is empty > " I'm sorry that it doesn't occur on my environment. And I don't see other similar report neither in debian ML nor upstream. So I guess it's related your environment. Did you ever install this package before? And you may try "torbrowser-launcher --settings" command to download it again by force. Please share your experience if you tried. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#913540: "crypto: stream: repeat IV detected" after upgrading to newest version.
On Tue, Nov 13, 2018 at 11:20 PM Roger Shimizu wrote:
>
> On Mon, Nov 12, 2018 at 11:06 AM Gong S. wrote:
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Package: shadowsocks-libev
> > Version: 3.2.1+ds-1
> >
> > After upgrading to the latest version, any connection attempts through the
> > proxy would be closed with:
> > 2018-11-12 09:46:44 ERROR: invalid password or cipher
> > 2018-11-12 09:46:45 ERROR: crypto: stream: repeat IV detected
> > despite the passwords are correct.
> > If I downgrade to the previous version (3.2.0+ds-5) it works as normal.
> > Config files "/etc/shadowsocks-libev/config.json:
> > {
> > "server":[REDACTED],
> > "server_port":[REDACTED],
> > "local_port":1080,
> > "password":[REDACTED],
> > "timeout":4,
> > "method":"aes-256-cfb"
> > }
>
> Thanks for your report!
>
> I think maybe it's related upstream ticket:
> - https://github.com/shadowsocks/shadowsocks-libev/issues/2215
>
> I'll try to upload a version with the patch, so you can test.
I didn't upload because I find a similar issue on upstream ticket:
- https://github.com/shadowsocks/shadowsocks-libev/issues/2217
Can you tell me your client? If it's go version, please report this
ticket to that repository.
And I'm going to lower the level of this ticket. I don't think
blocking migration to testing is necessary.
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#913540: "crypto: stream: repeat IV detected" after upgrading to newest version.
On Mon, Nov 12, 2018 at 11:06 AM Gong S. wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Package: shadowsocks-libev
> Version: 3.2.1+ds-1
>
> After upgrading to the latest version, any connection attempts through the
> proxy would be closed with:
> 2018-11-12 09:46:44 ERROR: invalid password or cipher
> 2018-11-12 09:46:45 ERROR: crypto: stream: repeat IV detected
> despite the passwords are correct.
> If I downgrade to the previous version (3.2.0+ds-5) it works as normal.
> Config files "/etc/shadowsocks-libev/config.json:
> {
> "server":[REDACTED],
> "server_port":[REDACTED],
> "local_port":1080,
> "password":[REDACTED],
> "timeout":4,
> "method":"aes-256-cfb"
> }
Thanks for your report!
I think maybe it's related upstream ticket:
- https://github.com/shadowsocks/shadowsocks-libev/issues/2215
I'll try to upload a version with the patch, so you can test.
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#913366: [Pkg-privacy-maintainers] Bug#913366: torbrowser-launcher: more apparmor fixes needed, otherwise fails to launch
control: severity -1 important control: tags -1 +pending On Sat, Nov 10, 2018 at 9:54 AM Diederik de Haas wrote: > > Package: torbrowser-launcher > Version: 0.3.1-1 > Severity: grave > Tags: upstream patch > Justification: renders package unusable Thanks for your report! However this is not grave level, IMHO. I think important should be proper. > I had applied the patch before, but I guess it got overwritten with a > new version (which I thought wasn't supposed to happen without asking). > Applied the patch again and then torbrowser started again. > > For completeness sake, this is the patch intrigeri submitted upstream, > but the upstream pull request is now already waiting more then a month > for approval/merge, so it's probably good to apply this patch to the > Debian package in the meantime. It'd be included in next upload. Thanks! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy
On Sat, Sep 15, 2018 at 2:11 PM, intrigeri wrote: > Roger Shimizu: >> On Mon, Sep 10, 2018 at 11:58 PM, gregor herrmann wrote: >>> On Mon, 10 Sep 2018 10:43:32 -0400, Antoine Beaupré wrote: >>> After upgrading to 0.2.9-4, adequate complains: >>> >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Tor.tor >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Browser.plugin-container >>> torbrowser-launcher: obsolete-conffile >>> /etc/apparmor.d/local/torbrowser.Browser.firefox > >> Sorry, I don't have these errors when upgrading package. > > To reproduce, I think you need 1. adequate installed; > 2. upgrading from a specific version of the package. I confirmed I already had adequate installed previously. $ dpkg -l adequate Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++--=-=-== ii adequate 0.15.1all Debian package quality testing tool On Sun, Sep 16, 2018 at 2:35 AM, gregor herrmann wrote: >> > After getting rid of them, I have a starting torbrowser again. >> > >> > Looks like some dpkg-maintscript-helper(1) magic is needed here ... >> >> Could you provide an example, or even patch? >> Thanks! > > After looking at the package/repo: > > The files under /etc/apparmor.d/local were created in 0.2.9-1 (with > the upstream import) and were removed in 0.2.9-2, probably with > 0016-Remove-apparmor-local-path-from-setup.py.patch. Or maybe with > debian/patches/0015-AppArmor-remove-boilerplate-from-local-override-file.patch. > Or with both :) > > This is somewhat confusing but 0.2.9-1 seems to be the only release > with > > drwxr-xr-x root/root 0 2018-01-29 15:17 ./etc/apparmor.d/local/ > -rw-r--r-- root/root 134 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Browser.firefox > -rw-r--r-- root/root 133 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Browser.plugin-container > -rw-r--r-- root/root 133 2018-01-28 19:33 > ./etc/apparmor.d/local/torbrowser.Tor.tor > > (That also means that adequate must have warned me earlier?) > > Anyway, these conffiles are not shipped any more; either that's a > mistake or they need to be properly removed. I tried to install 0.2.9-1 and upgrade to 0.2.9-4, but still didn't reproduced. I tested it again after enabling adequate by set 'Adequate::Enabled "true";' in /etc/apt/apt.conf.d/20adequate But same result. BTW. Old packages can be found on snapshot.d.o [1]. [1] http://snapshot.debian.org/package/torbrowser-launcher/ # dpkg -i torbrowser-launcher_0.2.9-1_amd64.deb (Reading database ... 272854 files and directories currently installed.) Preparing to unpack torbrowser-launcher_0.2.9-1_amd64.deb ... Unpacking torbrowser-launcher (0.2.9-1) over (0.2.9-1) ... Setting up torbrowser-launcher (0.2.9-1) ... Processing triggers for desktop-file-utils (0.23-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for man-db (2.7.6.1-2) ... # dpkg -i torbrowser-launcher_0.2.9-4_amd64.deb (Reading database ... 272854 files and directories currently installed.) Preparing to unpack torbrowser-launcher_0.2.9-4_amd64.deb ... Unpacking torbrowser-launcher (0.2.9-4) over (0.2.9-1) ... Setting up torbrowser-launcher (0.2.9-4) ... Installing new version of config file /etc/apparmor.d/torbrowser.Browser.firefox ... Installing new version of config file /etc/apparmor.d/torbrowser.Browser.plugin-container ... Installing new version of config file /etc/apparmor.d/torbrowser.Tor.tor ... Processing triggers for desktop-file-utils (0.23-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for man-db (2.7.6.1-2) ... > There is already debian/torbrowser-launcher.maintscript which IMO > needs three new lines: > > rm_conffile /etc/apparmor.d/local/torbrowser.Tor.tor 0.2.9-2~ > torbrowser-launcher > rm_conffile /etc/apparmor.d/local/torbrowser.Browser.plugin-container > 0.2.9-2~ torbrowser-launcher > rm_conffile /etc/apparmor.d/local/torbrowser.Browser.firefox 0.2.9-2~ > torbrowser-launcher > > Or maybe s/0.2.9-2~/0.2.9-5~/ , if I'm reading dpkg-maintscript-helper(1) > correctly. Thanks for the hint! I'll try this snippet. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#908463: [Pkg-privacy-maintainers] Bug#908463: torbrowser-launcher: Fails to start "Web Content" processes due to outdated AppArmor policy
On Mon, Sep 10, 2018 at 11:58 PM, gregor herrmann wrote: > On Mon, 10 Sep 2018 10:43:32 -0400, Antoine Beaupré wrote: > >> Disabling the apparmor profiles fix this: >> >> aa-complain torbrowser.Tor.tor >> aa-complain torbrowser.Browser.firefox > > After upgrading to 0.2.9-4, adequate complains: > > torbrowser-launcher: obsolete-conffile > /etc/apparmor.d/local/torbrowser.Tor.tor > torbrowser-launcher: obsolete-conffile > /etc/apparmor.d/local/torbrowser.Browser.plugin-container > torbrowser-launcher: obsolete-conffile > /etc/apparmor.d/local/torbrowser.Browser.firefox Sorry, I don't have these errors when upgrading package. # dpkg -i torbrowser-launcher_0.2.9-4_amd64.deb (Reading database ... 272719 files and directories currently installed.) Preparing to unpack torbrowser-launcher_0.2.9-4_amd64.deb ... Unpacking torbrowser-launcher (0.2.9-4) over (0.2.9-3) ... Setting up torbrowser-launcher (0.2.9-4) ... Installing new version of config file /etc/apparmor.d/torbrowser.Browser.firefox ... Processing triggers for desktop-file-utils (0.23-1) ... Processing triggers for mime-support (3.60) ... Processing triggers for man-db (2.7.6.1-2) ... > After getting rid of them, I have a starting torbrowser again. > > Looks like some dpkg-maintscript-helper(1) magic is needed here ... Could you provide an example, or even patch? Thanks! BTW. I have pushed not-released-yet 0.2.9-5 to branch debian/sid on salsa. Maybe you can simply build the package by git-buildpackage, and test the latest appamor profile from intrigeri. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#908068: [Pkg-privacy-maintainers] Bug#908068: torbrowser-launcher fails with torbrowser 8.0
On Thu, Sep 6, 2018 at 4:41 AM, gregor herrmann wrote: > Package: torbrowser-launcher > Version: 0.2.9-3 > Severity: grave > Tags: upstream > Justification: renders package unusable > User: pkg-apparmor-t...@lists.alioth.debian.org > Usertags: buggy-profile > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Today torbrowser 8.0 was released, and after updating it (from > torbrowser 7.x, started with torbrowser-launcher), the new version > doesn't start: thanks for your report! have you tried experimental version [1]? It's working in my environment without any patch or hack. [1] https://wiki.debian.org/TorBrowser#Debian_.22experimental.22 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#893988: wide-dhcpv6-client-udeb: not installable: depends on non-udeb libfl2
On Sun, Mar 25, 2018 at 11:27 PM, Cyril Brulebois <k...@debian.org> wrote: > Hey, > > Roger Shimizu <rogershim...@gmail.com> (2018-03-25): >> On Sun, Mar 25, 2018 at 11:15 PM, Roger Shimizu <rogershim...@gmail.com> >> wrote: >> > Just a nitpicking. >> > The build cannot be triggered again by "dpkg-buildpackage -uc -us" >> > after one build. >> > It was OK in previous version. >> >> I tested it again, and the problem is gone now. >> Sorry for the false positive info. Bow! > > I had tested that and I wasn't able to reproduce this. Maybe what > happened is you had a build with the build-deb directory, you renamed > it build, and there were stray files from the previous build? Maybe. > You may want to push your tree to git too (I tried git fetch but found > no new commits there). ;) I already pushed the tag. But still waiting the ftp-master to accept my upload, after that I can safely push to master branch. > Thanks for your swift actions, much appreciated! No problem. And I just don't want to break d-i. (although I still need to fix armel later) Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#893988: wide-dhcpv6-client-udeb: not installable: depends on non-udeb libfl2
On Sun, Mar 25, 2018 at 11:15 PM, Roger Shimizu <rogershim...@gmail.com> wrote: > > Just a nitpicking. > The build cannot be triggered again by "dpkg-buildpackage -uc -us" > after one build. > It was OK in previous version. I tested it again, and the problem is gone now. Sorry for the false positive info. Bow! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#893988: wide-dhcpv6-client-udeb: not installable: depends on non-udeb libfl2
Dear KiBi,
On Sun, Mar 25, 2018 at 5:19 PM, Cyril Brulebois <k...@debian.org> wrote:
> Control: tag -1 patch
>
> Hi Roger,
>
> Roger Shimizu <rogershim...@gmail.com> (2018-03-25):
>> Do you have any suggestion, except adding udeb support to package flex?
>
> It looks acceptable to me to use the static library in the udeb, so I've
> tried building it against libfl.a, and that seems to do the job since
> the libfl2 dependency goes away. I'm not sure it's reasonable to do that
> for both the deb and the udeb, though; so I've looked into making it
> conditional, and only building the udeb against the static library.
Thanks for your suggestion and patches!
I agree with you that static linking for udeb only.
> Unfortunately, it looks like the build system doesn't support out of
> tree builds, so I've had to copy all files under build-{deb,udeb},
> instead of just running ../configure, make, make install from there.
> I've picked rsync to do this, but feel free to use anything else.
Yes, the build system is quite old, it's a software wrote 10 years ago.
Really thanks for your patches that overcome the issue.
I just don't like the name "build-deb", which is too close to "build-udeb".
So I change it to "build", with some other cleanups.
My patch is enclosed, and it's based on yours.
> I've also chosen to clean things up using an override_dh_auto_clean
> target, so that most modifications are seen at once in debian/rules, but
> you may want to use debian/clean instead.
Just a nitpicking.
The build cannot be triggered again by "dpkg-buildpackage -uc -us"
after one build.
It was OK in previous version.
However, this is small issue, so I already uploaded.
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From 42d2b0dd8694a92e5176c993b56f8ec3c54376ed Mon Sep 17 00:00:00 2001
From: Roger Shimizu <rogershim...@gmail.com>
Date: Sun, 25 Mar 2018 22:40:50 +0900
Subject: [PATCH] d/rules: Cleanup
Now build two versions under the directories below:
- build: nornal version. The same as previous one.
- build-udeb: udeb version, which staticly linked with libfl2 (flex
library)
---
debian/changelog | 3 ++-
debian/rules | 36
2 files changed, 18 insertions(+), 21 deletions(-)
diff --git a/debian/changelog b/debian/changelog
index 200cc24..fb4b5ed 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -2,7 +2,8 @@ wide-dhcpv6 (20080615-21) UNRELEASED; urgency=medium
* debian/rules:
- Introduce separate deb/udeb builds, copying source files under
- build-{deb,udeb} since support for out-of-tree build seems broken.
+ {build,build-udeb} since support for out-of-tree build seems
+ broken.
- Don't try to build only the dhcp6c binary in the udeb tree, as the
install target tries to install everything anyway.
- Patch Makefile.in to build the dhcp6c binary against static flex
diff --git a/debian/rules b/debian/rules
index 1f021df..724bb1e 100755
--- a/debian/rules
+++ b/debian/rules
@@ -9,28 +9,26 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all
%:
dh $@
-build-deb/.stamp:
- rsync --exclude debian/ --exclude .pc/ -a * build-deb && touch $@
-
-build-udeb/.stamp:
- rsync --exclude debian/ --exclude .pc/ -a * build-udeb && touch $@
- # Build against the static flex library to avoid picking an extra dependency on libfl2 (#893988):
- sed "s,^CLIENTLIBS=.*,CLIENTLIBS=$$(find /usr/lib/$$(dpkg-architecture -qDEB_BUILD_MULTIARCH) -name libfl.a)," -i build-udeb/Makefile.in
-
-override_dh_auto_configure: build-deb/.stamp build-udeb/.stamp
- cd build-deb && \
- ./configure --prefix=/usr --mandir=\$${prefix}/share/man \
- --with-localdbdir=/var/lib/dhcpv6 --sysconfdir=/etc/wide-dhcpv6
- cd build-udeb && \
- ./configure --prefix=/usr --mandir=\$${prefix}/share/man \
- --with-localdbdir=/var/lib/dhcpv6 --sysconfdir=/etc/wide-dhcpv6
+override_dh_auto_configure:
+ # sed command below is to build against the static flex library
+ # to avoid picking an extra dependency on libfl2 (#893988)
+ for dir in build build-udeb; do \
+ rsync -a --exclude debian/ --exclude .pc/ --exclude .git/ . $$dir; \
+ [ $$dir = "build-udeb" ] && \
+ sed "s,^CLIENTLIBS=.*,CLIENTLIBS=$$(find /usr/lib/$$(dpkg-architecture -qDEB_BUILD_MULTIARCH) -name libfl.a)," \
+ -i $$dir/Makefile.in; \
+ cd $$dir && \
+ ./configure --prefix=/usr --mandir=\$${prefix}/share/man \
+ --with-localdbdir=/var/lib/dhcpv6 --sysconfdir=/etc/wide-dhcpv6 && \
+ cd -; \
+ done
override_dh_auto_build:
- $(MAKE) -C build-deb
+ $(MAKE) -C build
$(MAKE) -C build-udeb
override_dh_auto_install:
- $(MAKE) -C build-deb prefix=$(CURDIR)/debian/tmp/usr install
+ $(MAKE) -C build prefix=$(CURDIR)/debian/tmp/usr install
$(MAKE) -C build-udeb prefix=$(CURDIR)/debian/tmp-ud
Bug#893008: wide-dhcpv6 FTBFS with flex 2.6.4-6
On Thu, Mar 15, 2018 at 10:55 PM, Adrian Bunk <b...@debian.org> wrote: > Source: wide-dhcpv6 > Version: 20080615-19 > Severity: serious > Tags: buster sid patch > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wide-dhcpv6.html > > ... > gcc -Wl,-z,relro -Wl,-z,now -o dhcp6ctl dhcp6_ctlclient.o base64.o auth.o > strlcpy.o strlcat.o arc4random.o -lfl > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libfl.so: undefined > reference to `yylex' > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:74: dhcp6ctl] Error 1 > > > Fix is attached. Dear Adrian, Unfortunately, after this fix, it introduces a regression #893988. (which is due to flex, not your patch) If you have suggestion, except adding udeb support to package flex, please kindly let me know. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#893988: wide-dhcpv6-client-udeb: not installable: depends on non-udeb libfl2
On Sun, Mar 25, 2018 at 9:35 AM, Cyril Brulebois <k...@debian.org> wrote: > Package: wide-dhcpv6-client-udeb > Version: 20080615-20 > Severity: serious > > (Please keep debian-b...@lists.debian.org and me in copy of your > replies.) > > Hi, > > Your package is no longer installable because it depends on non-udeb > libfl2. That makes netcfg uninstallable as well, which means a very > serious regression for d-i. Sorry for this regression. I confirm if building under stretch, 20080615-20 is fine, without depending on libfl2. So obviously it's because the new flex package in unstable, 2.6.4-6. If building the previous version, 20080615-19, under unstable, I guess it would have the same result. Now we need the fix. Do you have any suggestion, except adding udeb support to package flex? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#893008: wide-dhcpv6 FTBFS with flex 2.6.4-6
control: tags -1 +pending On Thu, Mar 15, 2018 at 10:55 PM, Adrian Bunk <b...@debian.org> wrote: > Source: wide-dhcpv6 > Version: 20080615-19 > Severity: serious > Tags: buster sid patch > > https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/wide-dhcpv6.html > > ... > gcc -Wl,-z,relro -Wl,-z,now -o dhcp6ctl dhcp6_ctlclient.o base64.o auth.o > strlcpy.o strlcat.o arc4random.o -lfl > /usr/lib/gcc/x86_64-linux-gnu/7/../../../x86_64-linux-gnu/libfl.so: undefined > reference to `yylex' > collect2: error: ld returned 1 exit status > make[1]: *** [Makefile:74: dhcp6ctl] Error 1 > > > Fix is attached. Dear Adrian, Thanks for the report and patch! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#885885: fixed in broadcom-sta 6.30.223.271-8
On Tue, Mar 6, 2018 at 12:18 AM, Gianfranco Costamagna <locutusofb...@debian.org> wrote: > Hello, > >>But I don't know where the patch (of ubuntu) comes from. > > it comes from an Ubuntu developer, but you can just apply the upstream patch > on top of the i386 branch Got it. It's done. https://salsa.debian.org/broadcom-sta-team/broadcom-sta/commit/b6d7001b9977000772e8de0300364aa2d334c693 >>And ubuntu version is the same as debian, which is 6.30.223.271-8. >>So this is weird. > > yes, I personally syncd it, but would be nice to fix i386 anyway, because > even if the package is amd64 only, people might have multiarch enabled. Thanks for telling me to pull the patch! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#885885: fixed in broadcom-sta 6.30.223.271-8
Dear Gianfranco, On Wed, Feb 21, 2018 at 4:59 PM, Gianfranco Costamagna <locutusofb...@debian.org> wrote: > Hello Roger! > > I see the Ubuntu patch for kernel 4.14, is applied also on i386 branch > > --- a/i386/src/shared/linux_osl.c > > Did you forget to apply it there? Thanks for letting me know! I see the patch from a link "diff from 6.30.223.271-7ubuntu1 (in Ubuntu) to 6.30.223.271-8" - https://launchpadlibrarian.net/357862331/broadcom-sta_6.30.223.271-7ubuntu1_6.30.223.271-8.diff.gz But I don't know where the patch (of ubuntu) comes from. And ubuntu version is the same as debian, which is 6.30.223.271-8. So this is weird. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#888236: [Pkg-privacy-maintainers] Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'
On Wed, Jan 31, 2018 at 12:55 AM, Antoine Beaupré <anar...@debian.org> wrote: > On 2018-01-30 23:53:47, Roger Shimizu wrote: >> On Tue, Jan 30, 2018 at 4:13 PM, intrigeri <intrig...@debian.org> wrote: >>> Antoine Beaupre: >>>> This bug makes torbrowser-launcher completely unusable on Debian >>>> stretch, as soon as the browser is updated (as it should). >>> >>>> What's expected from stable users here? Is there going to be a stable >>>> update for this? >>> >>> torbrowser-launcher is not included in Debian Stretch. >> >> Yes, it's not included in stretch. >> However, it can be included into stretch-backports and >> jessie-backports-sloppy repo. >> I'll make the bpo release when 0.2.9-1 hit testing. > > Ah. Duh. Sorry for messing that one up. :) > > Let me know if you need help with the backports - i'll try to fix things > instead of complaining here... ;) Almost all backports version were uploaded by me [0]. [0] https://tracker.debian.org/pkg/torbrowser-launcher And since it already passed the backports new queue, no help is need here so far. However if you really want to help backports, here's one :P - https://bugs.debian.org/882126 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#888236: [Pkg-privacy-maintainers] Bug#888236: torbrowser-launcher: broken by Tor Browser 7.5: No such file or directory: '.../Docs/sources/versions'
On Tue, Jan 30, 2018 at 4:13 PM, intrigeri <intrig...@debian.org> wrote: > Antoine Beaupre: >> This bug makes torbrowser-launcher completely unusable on Debian >> stretch, as soon as the browser is updated (as it should). > >> What's expected from stable users here? Is there going to be a stable >> update for this? > > torbrowser-launcher is not included in Debian Stretch. Yes, it's not included in stretch. However, it can be included into stretch-backports and jessie-backports-sloppy repo. I'll make the bpo release when 0.2.9-1 hit testing. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#884419: [Pkg-privacy-maintainers] Bug#884419: torbrowser-launcher: debian/rules clean does not run dh_clean
control: severity -1 important control: tags -1 +patch +pending On Fri, Dec 15, 2017 at 9:56 AM, Andreas Beckmann <a...@debian.org> wrote: > Without calling dh_clean, all the temporary stuff in debian/ is retained, > but luckily dpkg-source chokes on unwanted binaries, refusing to create > a source package full of binary cruft. > > The override_dh_clean target needs to call dh_clean in addition to any > further cleanup it does. Thanks for the report! Though it's policy related, I don't think it deserves testing removal level. Anyway, I pushed a commit [0] to fix this. I also confirmed in my box that adding dh_clean is not enough. It need purging build/ folder manually. [0] https://anonscm.debian.org/cgit/pkg-privacy/packages/torbrowser-launcher.git/commit/?id=f5a953e Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#868280: even after purging and installing fresh torbrowser-launcher doesn't work.
latest version 0.2.8 is already available in jessie-backports-sloppy, stretch-backports, buster and sid. So please kindly help to confirm your problem is solved. Thank you! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#864733: [Pkg-privacy-maintainers] Bug#864733: Error: "Download error: Download Error: 404 Not Found", Debian stable
Control: notfound -1 0.2.8-1 On Sun, Sep 10, 2017 at 5:15 AM, Nikolas Nyby <niko...@gnu.org> wrote: > > Hi, > I received this error in version 0.2.7-3 of this package. I'm using > Debian testing. Here's the output of torbrowser-launcher: > > $ torbrowser-launcher > Tor Browser Launcher > By Micah Lee, licensed under MIT > version 0.2.7 > https://github.com/micahflee/torbrowser-launcher > Downloading and installing Tor Browser for the first time. > Downloading > https://dist.torproject.org/torbrowser/update_2/release/Linux_x86_64-gcc3/x/en-US > Download Error: Download Error: 404 Not Found 'torbrowser_launcher.launcher.DownloadErrorException'> Could you try the latest version 0.2.8-1, which was just migrated to buster? Thanks! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#861744: torbrowser-launcher: Should not be part of Stretch
Dear Maintainer, Is it time to upload backports of 0.2.7-3 to stretch? I'm also wondering why it didn't hit testing yet. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#861536: runit-init: Cannot reboot or shutdown after installing (or removing) the package.
On Fri, 26 May 2017 11:28:48 +0200 Ivo De Decker <iv...@debian.org> wrote: > If the maintainer isn't interested in making sure that this package works as > expected, it isn't fit for a stable release... FYI. The maintainer cannot respond this for the time being [0]. [0] https://www.debian.org/News/2017/20170417 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpiyl1AnAYm8.pgp Description: PGP signature
Bug#861282: packer: FTBFS
On Thu, 25 May 2017 13:00:39 -0400 (EDT) JD Friedrikson <m...@jdfriedrikson.me> wrote: > The new changes package nicely and pass the tests just fine. I can confirm > that the fix works for qemu. I'm having some issues with Virtualbox, but I've > also always had trouble with Virtualbox and packer with the machine; the > binary I've compiled straight from Packer's git project also fails in the > same way so it's probably not related. > > Can someone step in and confirm that the new patches work with Virtualbox? Thanks for your verifacation under qemu. So I'm going to release, as the autoremoval dealline is drawing very near.. If you meet other issues, please report again. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpqd_pK5_EgM.pgp Description: PGP signature
Bug#861282: packer: FTBFS
On Tue, 23 May 2017 21:35:06 -0400 (EDT) JD Friedrikson <m...@jdfriedrikson.me> wrote: > Am I doing something wrong here? Yes, I got fail by local "gbp buildpackage", too. Previous -4 release is the same result. So it's not a regression of my patch. I build this package well by git-pbuilder. (and of course it built well on debian's buildd) I didn't confirm below commands one by one, but I guess it should be: # below: if you didn't do this before sudo apt install git-buildpackage pristine-tar cowbuilder git-pbuilder create gbp clone --pristine-tar https://anonscm.debian.org/git/pkg-go/packages/packer.git cd packer # below: routine building work git checkout fix_861282 gbp buildpackage --git-ignore-branch --git-pristine-tar --git-pbuilder --git-export-dir=../build-area Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpY42iAbbC1q.pgp Description: PGP signature
Bug#861282: packer: FTBFS
On Mon, 22 May 2017 12:22:18 -0400 (EDT) JD Friedrikson <m...@jdfriedrikson.me> wrote: > Here are the four patches that are related to this issue: > > https://github.com/hashicorp/packer/commit/28ee60d216e49d565d654443b57295ce37197db1 > https://github.com/hashicorp/packer/commit/249cb690e04477582aefadf4350a087bf4e33a87 > https://github.com/hashicorp/packer/commit/ee5d13611fb8aca1f1014f9bcd65c18fffdd1b2b > https://github.com/hashicorp/packer/commit/a0052fdb687f80ac07e67d7a0f39dcf3a66e32dd > > 28ee60d216e49d565d654443b57295ce37197db1 is the patch that is currently > packaged with debian > > 249cb690e04477582aefadf4350a087bf4e33a87 concerns vendor files which Debian > doesn't appear to carry as part of the source package > > ee5d13611fb8aca1f1014f9bcd65c18fffdd1b2b and > a0052fdb687f80ac07e67d7a0f39dcf3a66e32dd both concern drivers to proprietary > software (which Debian also does not seem to carry) so both need to be > trimmed before applying > > After removing the references to missing files, > a0052fdb687f80ac07e67d7a0f39dcf3a66e32dd works just fine. > > ee5d13611fb8aca1f1014f9bcd65c18fffdd1b2b is the one I'm having trouble with > currently as it's failing for openstack's and amazon's ssh.go files. Not sure > what changes we're carrying for those as I haven't dug too deep, but that's > where I'm at now. Thanks for your info! I pushed a commit to new branch fix_861282, that applied: ee5d13611fb8aca1f1014f9bcd65c18fffdd1b2b a0052fdb687f80ac07e67d7a0f39dcf3a66e32dd (https://anonscm.debian.org/cgit/pkg-go/packages/packer.git/log/?h=fix_861282) Please help to test whether it fixes your problem. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpub9wA77KlN.pgp Description: PGP signature
Bug#858250: Bug#861953: unblock: runc/0.1.1+dfsg1-3
control: tag 858250 -pending control: affects 858250 -stretch +sid control: notfound 858250 0.1.1+dfsg1-2 On Thu, 18 May 2017 12:48:11 +0100 Jonathan Wiltshire <j...@debian.org> wrote: > Control: tag -1 wontfix moreinfo > > Hi, > > On 2017-05-08 00:40, Roger Shimizu wrote: > > Since you say it should fix unstable first, then stretch or t-p-u, > > now I think we may just leave runc/0.1.1+dfsg1-2 (current in stretch) > > as it is in stretch. Because it builds OK (without FTBFS) for stretch. > > The #858250 FTBFS only occurs on unstable. > > If runc currently builds in stretch, there is no need to touch it (and > #858250 should be tagged 'sid'). > > It's not clear from #858250 if that is actually the case or not though. Thanks for your explanation! Yes, it builds well in stretch. I did a s/unstable/testing/ for latest changelog, and upload it to DoM: http://debomatic-amd64.debian.net/distribution#testing/runc/0.1.1+dfsg1-2/buildlog So I close the unblock request, and mark the original bug only affects unstable. It's not a RC for stretch. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpTlJqJghWa2.pgp Description: PGP signature
Bug#862769: libbloom FTBFS on amd64: error: expected error 0.100000 but observed 0.200000
control: forwarded -1 https://github.com/jvirkki/libbloom/issues/7 control: severity -1 important On Tue, 16 May 2017 22:34:42 +0300 Adrian Bunk <b...@debian.org> wrote: > Source: libbloom > Version: 1.4-6 > Severity: serious > > https://buildd.debian.org/status/fetch.php?pkg=libbloom=amd64=1.4-6=1494930635=0 > > ... > /«PKGBUILDDIR»/build/test-libbloom > - Running basic tests - > - basic - > bloom at 0x7ffc4a988c30 not initialized! > bloom at 0x7ffc4a988c30 not initialized! > bloom at 0x7ffc4a988c30 > ->entries = 102 > ->error = 0.10 > ->bits = 488 > ->bits per elem = 4.792529 > ->bytes = 61 > ->hash functions = 4 > - add_random(10, 0.10, 10, 0, 1, 32, 1) - > bloom at 0x7ffc4a988b20 > ->entries = 10 > ->error = 0.10 > ->bits = 47 > ->bits per elem = 4.792529 > ->bytes = 6 > ->hash functions = 4 > entries: 10, error: 0.10, count: 10, coll: 2, error: 0.20, bytes: 6 > error: expected error 0.10 but observed 0.20 > Makefile:124: recipe for target 'test' failed > make[2]: *** [test] Error 1 Thanks for the report! Considering that: - The build actually suceeded, but failed at unit test. - the unit test fails at low rate. Recent releases only changed Makefile and intended to fix FTBFS issue on kFreeBSD and Hurd. It doesn't affect amd64. Previous amd64 was built OK, and all other ARCHs are all built OK on latest release. - If restart the amd64, it should build OK. Actually I ever built on DoM: http://debomatic-amd64.debian.net/distribution#unstable/libbloom/1.4-6/buildlog So lower the severity. I already raised this unit test issues upstream. Hope upstream can give a clue on this. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpE2O0wk1lUd.pgp Description: PGP signature
Bug#858250: Bug#861953: unblock: runc/0.1.1+dfsg1-3
control: tag 861953 -moreinfo On Mon, 8 May 2017 08:40:52 +0900 Roger Shimizu <rogershim...@gmail.com> wrote: > What's your opinion? I proposed two plans. Either is fine to me. Please kindly help to decide, so as to avoid a few packages get removed in stretch. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpMqSLt0g9kU.pgp Description: PGP signature
Bug#860618: golang-github-seccomp-libseccomp-golang: FTBFS on i386: dh_auto_test
unblock report filed: #862108 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpDcNjbHuTyp.pgp Description: PGP signature
Bug#858250: Bug#861953: unblock: runc/0.1.1+dfsg1-3
[ CC: original Bug #858250 ] On Sun, 07 May 2017 21:02:00 + Niels Thykier <ni...@thykier.net> wrote: > Roger Shimizu: > > Package: release.debian.org > > Severity: normal > > User: release.debian@packages.debian.org > > Usertags: unblock > > > > Please unblock package runc > > > > Since there's already a newer package in unstable, I guess it's > > necessary to use "testing-proposed-updates" > > > > Here I'm fixing #858250, which is FTBFS RC issue. > > > Hi Roger, > > Thanks for working on fixing #858250 for stretch. :) > > Before there is an upload to testing-proposed-updates, the original bug > should be resolved in unstable first. That means that #858250 should be > closed in unstable first. > > On a related note, the Debian Bug Tracker can determine which suites are > affected by looking at found + fixed versions, so there is no need to > have two bugs for this (which is why I have merged #861966 back into > #858250). #858250 is not easy to fix for unstable, since there's already newer version runc/1.0.0~rc2+git20161109.131.5137186-2, with newer version of Build-Depends golang-github-opencontainers-specs/1.0.0~rc2+git20160926.38.1c7c27d-1. As stated by #858250, runc is FTBFS with golang-github-opencontainers-specs/1.0.0~rc2+git20160926.38.1c7c27d-1. So my original plan was just patch d/control to limit the version of Build-Depends. Since you say it should fix unstable first, then stretch or t-p-u, now I think we may just leave runc/0.1.1+dfsg1-2 (current in stretch) as it is in stretch. Because it builds OK (without FTBFS) for stretch. The #858250 FTBFS only occurs on unstable. What's your opinion? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgplaYcX_k6Ze.pgp Description: PGP signature
Bug#858250: Fails to build, build-depends not strict enough
control: clone -1 -2 control: notfound -1 runc 1.0.0~rc2+git20161109.131.5137186-2 control: affects -1 stretch control: retitle -1 Fails to build for stretch, build-depends not strict enough control: notfound -2 runc 0.1.1+dfsg1-2 control: affects -2 sid control: retitle -2 Fails to build for sid, build-depends not strict enough My commit to stretch branch will fix stretch only. For sid, we need to find another way. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpcI3EnkzByq.pgp Description: PGP signature
Bug#858250: Fails to build, build-depends not strict enough
Since there's already a newer package in unstable, it's necessary to use "testing-proposed-updates", so I write to release team by filing unblock request: https://bugs.debian.org/861953 Changes are pushed to mentors branch (updated): https://anonscm.debian.org/cgit/pkg-go/packages/runc.git/commit/?id=14fb6ea Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp53bYrlb594.pgp Description: PGP signature
Bug#860618: golang-github-seccomp-libseccomp-golang: FTBFS on i386: dh_auto_test
On Sat, 6 May 2017 12:29:08 +0900 Roger Shimizu <rogershim...@gmail.com> wrote: > releasing commit pushed to branch mentors. > package is uploaded to mentors for RFS. upload sponsored by deferred/2 (BTS#861936). updated commit pushed to branch mentors2, with tag. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp8mWhfYd5A1.pgp Description: PGP signature
Bug#860618: golang-github-seccomp-libseccomp-golang: FTBFS on i386: dh_auto_test
releasing commit pushed to branch mentors. package is uploaded to mentors for RFS. tested to build on DoM: http://debomatic-i386.debian.net/distribution#unstable/golang-github-seccomp-libseccomp-golang/0.0~git20150813.0.1b506fc-2/buildlog http://debomatic-amd64.debian.net/distribution#unstable/golang-github-seccomp-libseccomp-golang/0.0~git20150813.0.1b506fc-2/buildlog Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpF0WENRsU3z.pgp Description: PGP signature
Bug#860660: golang-github-cznic-fileutil: FTBFS on i386: dh_auto_test
control: forwarded -1 https://github.com/cznic/fileutil/issues/16 control: tag -1 +patch Backport the patch from upstream, FTBFS issue seems fixed. So I pushed commit to master (w/o the releasing commit), and mentors branch with the releasing commit. Package is uploaded to mentors for RFS. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp2bFHUyOGrJ.pgp Description: PGP signature
Bug#860703: golang-github-jacobsa-fuse: FTBFS on i386: dh_auto_build
On Tue, 2 May 2017 16:34:02 +0900 Roger Shimizu <rogershim...@gmail.com> wrote: > but the following errors still exist. I don't have clue yet. > > > src/github.com/jacobsa/fuse/internal/buffer/runtime.go:22: missing function > > body for "memclr" > > src/github.com/jacobsa/fuse/internal/buffer/runtime.go:27: missing function > > body for "memmove" Finally find a way to fix it. So pushed my commits to master (w/o releasing commit), and mentors branch (w/ releasing commit). Package is uploaded to mentors for RFS. Please kindly help to sponsor the upload. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpOgrrfeTSNt.pgp Description: PGP signature
Bug#860703: golang-github-jacobsa-fuse: FTBFS on i386: dh_auto_build
> src/github.com/jacobsa/fuse/fusetesting/stat_linux.go:33: cannot use
> sys.(*syscall.Stat_t).Nlink (type uint32) as type uint64 in assignment
issue above can be resolved by the patch enclosed.
but the following errors still exist. I don't have clue yet.
> src/github.com/jacobsa/fuse/internal/buffer/runtime.go:22: missing function
> body for "memclr"
> src/github.com/jacobsa/fuse/internal/buffer/runtime.go:27: missing function
> body for "memmove"
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From: Roger Shimizu <rogershim...@gmail.com>
Date: Tue, 2 May 2017 09:56:18 +0900
Subject: 1st step
---
fusetesting/stat_linux.go | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fusetesting/stat_linux.go b/fusetesting/stat_linux.go
index eec3568..ccf1f7e 100644
--- a/fusetesting/stat_linux.go
+++ b/fusetesting/stat_linux.go
@@ -30,7 +30,7 @@ func extractBirthtime(sys interface{}) (birthtime time.Time, ok bool) {
}
func extractNlink(sys interface{}) (nlink uint64, ok bool) {
- nlink = sys.(*syscall.Stat_t).Nlink
+ nlink = (uint64)(sys.(*syscall.Stat_t).Nlink)
ok = true
return
}
Bug#860710: [pkg-go] Bug#860710: golang-google-api: FTBFS on i386: dh_auto_test
On Mon, 1 May 2017 16:07:07 +0200 "Dr. Tobias Quathamer" <to...@debian.org> wrote: > This is not correct. Unblocks are never triggered automatically. You > always need to file an unblock request. > > See this mail for more details: > https://lists.debian.org/debian-devel-announce/2017/02/msg1.html I read those notices from release team for a few times. Maybe the word "automatically" is misleading, but from what I experienced, I feel some packages got unblocked without filing unblock BTS request. "You must contact us to ensure the fix is unblocked - do not rely on the release team to notice on their own." (from https://release.debian.org/stretch/freeze_policy.html) AFAICS, the release team will find those proper unblock-able packages on their own, but other developers should not suppose release team will find all such cases, so it's always safer to send the unblock request. > Anyway, I've done that now for you. > https://bugs.debian.org/861613 Really appreciated! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpqGQlyaH410.pgp Description: PGP signature
Bug#860710: [pkg-go] Bug#860710: golang-google-api: FTBFS on i386: dh_auto_test
On Mon, 1 May 2017 11:48:45 +0200 "Dr. Tobias Quathamer" <to...@debian.org> wrote: > I've just uploaded your fix to unstable, thanks for your work! Are you > going to file an unblock request bug report? Thanks for your help to upload! I find if RC bug is closed by the upload, unblock will be triggered automatically (or release team is monitoring on these, so they will unblock when see it). For example, the following package was uploaded yesterday, now in "WAITING" status: https://qa.debian.org/excuses.php?package=golang-github-jacobsa-bazilfuse If unblock is not triggered automatically, I'll file unblock request this weekend. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpw2PmwrhbAV.pgp Description: PGP signature
Bug#860633: golang-gopkg-asn1-ber.v1: FTBFS on i386: dh_auto_test: go test -v -p 1 gopkg.in/asn1-ber.v1 returned exit code 2
There's a pull-request patch upstream: https://github.com/go-asn1-ber/asn1-ber/pull/7/commits/4563065 But unfortunately it's not clean, and only consider 32-bit system. Need to figure out a better way. -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpnv4Q2lge4d.pgp Description: PGP signature
Bug#860710: golang-google-api: FTBFS on i386: dh_auto_test
Control: tag -1 +patch I pushed a fix commit to stretch branch in git repo. Confirmed that FTBFS fixed on DoM: http://debomatic-i386.debian.net/distribution#unstable/golang-google-api/0.0~git20161128.3cc2e59-2/buildlog Package also uploaded to mentors for RFS. Please help to upload. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpcDGr9Cc7g5.pgp Description: PGP signature
Bug#857923: golang-go-dbus: build-depend on obsoleted package golang-gocheck-dev
On Wed, 5 Apr 2017 08:35:17 +0200 Mattia Rizzolo <mat...@debian.org> wrote: > On Wed, Apr 05, 2017 at 08:51:05AM +0900, Roger Shimizu wrote: > > I already checked in the final releasing commit into mentors branch. > > I didn't go for master branch, in case anything missing before this release. > > ok, if you are going to move everything to master and tag it once it's > uploaded. It's uploaded by my sponsor already. Thanks for your push :-D > > Instead of NMU, maybe QA upload is more proper for this purpose? > > Not really: QA uploads are for packages that are orphaned, without > maintainer. > https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu-qa-upload Indeed. Thanks for your info! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp4KTz1ylrKx.pgp Description: PGP signature
Bug#857923: golang-go-dbus: build-depend on obsoleted package golang-gocheck-dev
On Tue, 4 Apr 2017 20:11:36 +0200 Mattia Rizzolo <mat...@debian.org> wrote: > How is it going the look for a sponsor? > I can sponsor it if you want (just I do not have commit rights to the > repo, so you should preper everything - also note that it would be an > NMU, as for some reason the package is not formally team maintained, I > wonder if it should be hijacked into the team). Thanks, Mattia! I emailed my go-pkg sponsor, but hasn't got a reply. I already checked in the final releasing commit into mentors branch. I didn't go for master branch, in case anything missing before this release. Instead of NMU, maybe QA upload is more proper for this purpose? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgp660GTOBO2G.pgp Description: PGP signature
Bug#857923: golang-go-dbus: build-depend on obsoleted package golang-gocheck-dev
Control: tags -1 +patch pending Just pushed a fix to git repo: https://anonscm.debian.org/cgit/pkg-go/packages/golang-go-dbus.git/commit/?id=7dd07f6 I'll ask sponsor to upload later. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 pgpWsY80J5rWV.pgp Description: PGP signature
Bug#851876: Bug#855193: RFS: slt/0.0.git20140301-2.1 [RC][NMU] -- TLS reverse-proxy with SNI multiplexing (TLS virtual hosts)
On Thu, Feb 16, 2017 at 1:36 AM, James Cowgill <jcowg...@debian.org> wrote: > > On 15/02/17 11:24, Roger Shimizu wrote: >> Dear James, >> >> On Wed, Feb 15, 2017 at 7:51 PM, James Cowgill <jcowg...@debian.org> wrote: >>> >>> So do you know why the tests only pass when using 2 CPUs? That seems >>> pretty fishy to me. Maybe there is an underlying bug here? >> >> I'm not sure the reason. >> I was just trying to help on the FTBFS RC bug during BSP Tokyo. > > I found the actual cause - there's a race condition in the testsuite > which will usually (100% in practice) cause it to deadlock on single > processor systems. You can look at the bug I filed upstream if you want. Thanks for catching the race condition bug! But can we do something to prevent the autoremove of the package soon? I guess the testcase issue can be lower to non-RC level then. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#851876: slt: FTBFS (Test killed with quit: ran too long (10m0s))
On Sat, Feb 11, 2017 at 3:55 PM, Roger Shimizu <rogershim...@gmail.com> wrote: > Control: tag -1 +patch > > Enclosed is the patch to disable the test. Propose a better patch. So test will be skipped only if there's only 1-core in the build system. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 From: Roger Shimizu <rogershim...@gmail.com> Date: Sun, 12 Feb 2017 22:17:14 +0900 Subject: [PATCH] debian/rules: Run dh_auto_test only if CPUs >= 2 Closes: #851876 --- debian/changelog | 8 debian/rules | 8 2 files changed, 16 insertions(+) diff --git a/debian/changelog b/debian/changelog index 633b11e..53b7747 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +slt (0.0.git20140301-3) UNRELEASED; urgency=medium + + [ Roger Shimizu ] + * debian/rules: +- Run dh_auto_test only if CPUs >= 2 (Closes: #851876). + + -- Roger Shimizu <rogershim...@gmail.com> Sun, 12 Feb 2017 22:16:24 +0900 + slt (0.0.git20140301-2) unstable; urgency=medium * wrap-and-sort -ast diff --git a/debian/rules b/debian/rules index e8db377..0d33c78 100755 --- a/debian/rules +++ b/debian/rules @@ -8,3 +8,11 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all override_dh_installman: ronn < man/slt.8.ronn >debian/slt.8 dh_installman + +# Run test only if CPUs >= 2. See Bug#851876 +override_dh_auto_test: +ifneq ($(shell nproc), 1) + dh_auto_test +else + @echo dh_auto_test skipped on 1-Core CPU platform +endif
Bug#854500: iqtree: FTBFS on single-CPU machines (ERROR: You have specified more threads than CPU cores available)
Control: tag -1 +patch Enclosed is the patch to run dh_auto_test only if CPUs >= 2. Confirmed to build fine on 1-core amd64 box (virtualbox environment). Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 From: Roger Shimizu <rogershim...@gmail.com> Date: Sat, 11 Feb 2017 17:23:06 +0900 Subject: [PATCH] debian/rules: Run dh_auto_test only if CPUs >= 2 Closes: #854500 --- debian/changelog | 8 debian/rules | 2 ++ 2 files changed, 10 insertions(+) diff --git a/debian/changelog b/debian/changelog index 1bed007..d3c3d63 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +iqtree (1.5.3+dfsg-2) UNRELEASED; urgency=medium + + [ Roger Shimizu ] + * debian/rules: +- Run dh_auto_test only if CPUs >= 2 (Closes: #854500). + + -- Roger Shimizu <rogershim...@gmail.com> Sat, 11 Feb 2017 17:21:32 +0900 + iqtree (1.5.3+dfsg-1) unstable; urgency=medium * New upstream version diff --git a/debian/rules b/debian/rules index 6147979..6709e2c 100755 --- a/debian/rules +++ b/debian/rules @@ -60,7 +60,9 @@ override_dh_auto_test: # iqtreeomp=`find $(CURDIR) -name iqtree-omp -type f -executable` ; \ # ln -s iqtree-omp `dirname $$iqtreeomp`/iqtree ; \ # fi +ifneq ($(shell nproc), 1) sed '/ myprefix/,$$d' debian/Documents_source/example.sh > example.short echo 'time $(CURDIR)/build.omp/iqtree-omp -s example.phy -omp 2 -redo' >> example.short time sh example.short rm example.short +endif
Bug#851876: slt: FTBFS (Test killed with quit: ran too long (10m0s))
Control: tag -1 +patch Enclosed is the patch to disable the test. I already tried to set the test timeout to 30 minutes, but it still fails on 1-core amd64 box (virtualbox environment). So the patch is the tentative fix so far. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 From: Roger Shimizu <rogershim...@gmail.com> Date: Sat, 11 Feb 2017 15:04:59 +0900 Subject: [PATCH] debian/rules: Disable the test temporarily Test still fails on 1-core amd64 box, after setting 30 minutes timeout Closes: #851876 --- debian/changelog | 10 ++ debian/rules | 5 + 2 files changed, 15 insertions(+) diff --git a/debian/changelog b/debian/changelog index 633b11e..f6eec41 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,13 @@ +slt (0.0.git20140301-4) UNRELEASED; urgency=medium + + [ Roger Shimizu ] + * debian/rules: +- Disable the test temporarily. + Because test still fails on 1-core amd64 box, after setting 30 minutes + timeout (Closes: #851876). + + -- Roger Shimizu <rogershim...@gmail.com> Sat, 11 Feb 2017 15:02:32 +0900 + slt (0.0.git20140301-2) unstable; urgency=medium * wrap-and-sort -ast diff --git a/debian/rules b/debian/rules index e8db377..f412797 100755 --- a/debian/rules +++ b/debian/rules @@ -8,3 +8,8 @@ export DEB_BUILD_MAINT_OPTIONS = hardening=+all override_dh_installman: ronn < man/slt.8.ronn >debian/slt.8 dh_installman + +# still fails on 1-core amd64 box, after set 30 minutes timeout +# so disable the test temporarily +override_dh_auto_test: + #dh_auto_test -- -timeout 30m
Bug#844396: linux-image-4.8.0-1-686-pae: hitting any key make the system halt
Dear Jean-Jacques, > linux-image-4.8.0-1-686-pae: hitting any key make the system halt > There is no problem with an external keyboard when I post with it. Did you try latest 4.9 series kernel in testing? Same behavior? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#820381: rar crashes.
Dear Martin, I see this issue on RC bug list. > I've just pushed a new version of rar to the repo, can you let me know > if this has fixed the issue? I don't see there's a Vcs-* in debian/control [0]. And latest release in debian was on year 2015 [1]. [0] https://sources.debian.net/src/rar/2:5.3.b2-1/debian/control/ [1] https://tracker.debian.org/news/703609 So where's the new version, please? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
