Bug#1057016: NMU 1.29-11.1
Thanks for your help on the package, Chris! On Fri, Jan 26, 2024 at 1:03 PM Chris Hofstaedtler wrote: > > Control: tags -1 + pending > > Hi, > > I've uploaded the patch as an NMU versioned 1.29-11.1. It also > includes the janitor changes from salsa. > > The result can be found in the "nmu" branch on salsa, too. > > Chris
Bug#1051254: 7zip: [Merge Request] Add development and library package: lib7zip-dev and lib7zip0
Dear Yokota-san,
Thanks for your review for my MR!
On Tue, Sep 5, 2023 at 7:50 PM yokota wrote:
>
> Hello,
>
> > It's confirmed to work with my package: android-platform-tools
> > which currently includes a copy of lzma.
>
> Your patch breaks existing 7z command.
> Check formats-7z and benchmark-7z-simple test in autopkgtest result.
> https://salsa.debian.org/debian/7zip/-/jobs/4656760
>
> In fact, /usr/lib/7zip/7z.so is not a shared library, but big fat
> plugin for 7z command.
> So, don't replace 7z.so with lib7zip.so.0 .
Sorry for the breakage, and Thanks for the info!
> 7z.so includes some C++ interface for plugin system that not needed
> for liblzma.so.0 in android-platform-tools.
> If you really want to 7-Zip LZMA library, try Debian lzma-dev package.
> But lzma-dev package is quite obsolete because of xz-utils package.
> https://tracker.debian.org/pkg/lzma
lzma-dev is too old. That's why I didn't use it.
src:7zip is confirmed working with my package android-platform-tools.
> /usr/lib/{arch}/android/liblzma.so.0 is exists because the
> android-platform-tools document says
> org.apache.commons.compress.archivers.sevenz class requires this
> native library.
>
> https://salsa.debian.org/android-tools-team/android-platform-tools/-/blob/debian/34.0.4-1/development/sdk/sdk_files_NOTICE.txt#L14611
> > The files in the package org.apache.commons.compress.archivers.sevenz
> > were derived from the LZMA SDK, version 9.20 (C/ and CPP/7zip/),
> > which has been placed in the public domain:
> > "LZMA SDK is placed in the public domain." (http://www.7-zip.org/sdk.html)
The version you mentioned 9.20, I believe, is not true.
Upstream uses:
-
https://android.googlesource.com/platform/external/lzma/+/refs/tags/platform-tools-34.0.4
https://android.googlesource.com/platform/external/lzma/+/refs/tags/platform-tools-34.0.4/C/7zVersion.h
So it shows the version is at least 19.00, which is greater than src:p7zip.
That's the reason I'm excited to find there's src:7zip which is the
latest for lzma/7zip.
> But current org.apache.commons.compress.archivers.sevenz class in
> Debian libcommons-compress-java package uses org.tukaani.xz class in
> Debian libxz-java package to handle LZMA.
> So, I think the document is obsolete, and there is no need to install
> liblzma.so.0 or other native libraries.
>
> Try libcommons-compress-java package to list 7z files.
> 1. Install libxz-java package that not automatically installed.
> 2. Type in from console: "java -jar /usr/share/java/commons-compress.jar
> foo.7z"
I'm not sure about java packages.
src:android-platform-tools is c++ project, and doesn't use java.
So my question is, if 7z.so is not proper, is it possible to expose a
shared library for src:7zip?
Thank you!
Cheers,
Roger
Bug#1051254: 7zip: [Merge Request] Add development and library package: lib7zip-dev and lib7zip0
Package: 7zip Version: 23.01+dfsg-6 Severity: normal Tags: patch Dear Maintainer, https://salsa.debian.org/debian/7zip/-/merge_requests/6 Please kindly consider merge the MR above, to add devel and library package: lib7zip-dev and lib7zip0 It's confirmed to work with my package: android-platform-tools which currently includes a copy of lzma. Thank you! Cheers, Roger
Bug#1027989: Does not work with current ntpdate
control: tags -1 +help On Thu, Jan 5, 2023 at 8:09 AM Klaus Ethgen wrote: > > Package: adjtimex > Version: 1.29-11+b1 > Severity: normal > > Logging the clock screw to optimize parameters in /etc/adjtime is a > major function of adjtimex. But it is now incompatible to the needed > ntpdate: >~> adjtimex -l -h >ntpdate: -p is no longer supported. >ntpdig: querying xxx.xxx.xx.x () >cannot understand ntpdate output Thanks for the report! Package ntpdate became deprecated since bookworm [1] and was replaced by ntpsec-ntpdate [2]. [1] https://packages.debian.org/bookworm/ntpdate [2] https://packages.debian.org/bookworm/ntpsec-ntpdate in adjtimex.c ntpdate command output is supposed to be: /* read and save the significant lines, which should look like this: filter offset: -0.02800 -0.01354 -0.01026 -0.01385 offset -0.013543 1 Sep 11:51:23 ntpdate[598]: adjust time server 1.2.3.4 offset -0.013543 sec */ however, ntpdate provides by ntpsec-ntpdate output like this: $ /usr/sbin/ntpdate -d -q pool.ntp.org ntpdig: querying 208.113.130.146 (pool.ntp.org) ntpdig: querying 138.236.128.36 (pool.ntp.org) ntpdig: querying 68.112.4.226 (pool.ntp.org) ntpdig: querying 66.228.58.20 (pool.ntp.org) org t1: e89fa995.15b83000 rec t2: e89fa995.1f6674d8 xmt t3: e89fa995.1f673573 dst t4: e89fa995.29a78000 org t1: 1693788949.084842 rec t2: 1693788949.122657 xmt t3: 1693788949.122669 dst t4: 1693788949.162712 rec-org t21: 0.037816 xmt-dst t34: -0.040043 2023-09-03 17:55:49.122668 (-0700) -0.001114 +/- 0.038931 pool.ntp.org 208.113.130.146 s2 no-leap so looks like it's hard to get the 4 samples of "filter offset" from current output. If you have any ideas, please let me know. Thank you! Cheers, Roger
Bug#988997: [Pkg-privacy-maintainers] Bug#988997: Signature verification failed, key expired
control: fixed -1 0.3.6-1~exp1 control: fixed -1 0.3.6-2~bpo11+1
Bug#988997: [Pkg-privacy-maintainers] Bug#988997: Signature verification failed, key expired
control: tags -1 +wontfix
Bug#1002666: [Pkg-privacy-maintainers] Bug#1002666: torbrowser-launcher: Package in Bullseye outdated and downloading Tbb fails because of bad certificate
control: fixed -1 0.3.6-1~exp1
Bug#1008763: torbrowser-launcher: Multiarch support
control: tags -1 wontfix
Bug#1002666: [Pkg-privacy-maintainers] Bug#1002666: torbrowser-launcher: Package in Bullseye outdated and downloading Tbb fails because of bad certificate
control: fixed -1 0.3.6-2~bpo11+1 I think this issue was already fixed in bullseye-backports (0.3.6-2~bpo11+1).
Bug#1027673: torbrowser-launcher: Please provide a regular package for torbrowser
control: reassign -1 wnpp control: retitle -1 RFP: Please package tor-browser to replace torbrowser-launcher Package name: tor-browser Version : 115.2.0esr-13.0-1-build2 URL : https://gitlab.torproject.org/tpo/applications/tor-browser License : Mozilla Public License 2.0 (MPL, mostly)
Bug#1042552: torbrowser-launcher: Fails to download the binary due to a broken link
control: fixed -1 0.3.6-1~exp1 control: fixed -1 0.3.6-2~bpo11+1 On Sun, Jul 30, 2023 at 12:33 AM SIMONE DEIANA wrote: > > Package: torbrowser-launcher > Version: 0.3.3-6 > Severity: important > X-Debbugs-Cc: bugreport.debian.acco...@simonedeiana.xyz > > Dear Maintainer, > > Currently the torbrowser-launcher package tries to download the tor browser > binary using an outdated naming scheme. > > Instead of downloading from > https://dist.torproject.org/torbrowser/12.5.1/tor- > browser-linux64-12.5.1_ALL.tar.xz.asc it tries to download (and fails) from > https://dist.torproject.org/torbrowser/12.5.1/tor-browser-linux64-12.5.1_en- > US.tar.xz.asc > > This makes it completely impossible to use the package and urges an > immediate fix. I think you can use the version in backports (0.3.6-2~bpo11+1) to workaround the problem. Cheers, Roger
Bug#1050814: RFS: qbootctl/0.1.2-1 [ITP] -- utility to control Quacomm A/B boot slots
Thanks, Dmitry, for the prompt fix/update! On Sat, Sep 2, 2023 at 2:09 PM Dmitry Baryshkov wrote: > > On Sat, 2 Sept 2023 at 11:23, Roger Shimizu wrote: > > Thanks for your ITP & RFS! > > > > Some nitpicking: > > * debian/README.Debian: > > Please add more description, or remove this file. > > Ack. I've updated the package to drop this file (and also to include > the qbootctl.service file to mark the boot as successful > automatically). > > > * debian/include/scsi/scsi_bsg_ufs.h > > This header is not upstreamed yet? > > This header comes from the Linux kernel itself. It is a part of uABI. > > > Is it possible to use existing debian packaged header? > > Unfortunately, see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1050368 Above ticket is in pending status, so the next upload should fix the issue. So please update this package accordingly then. > > * Do you know whether this package works for QCOM LE / LU baseline systems? > > Most likely, the Linux kernel API and the bootloader are the same. But > I don't think anybody tested it with LE / LU. OK. We can test it easily when it hit Debian archive. I'll upload it later. But hope you can also fix the lintian in the future: W: qbootctl: no-manual-page [usr/bin/qbootctl] I: qbootctl: package-supports-alternative-init-but-no-init.d-script [lib/systemd/system/qbootctl.service] I: qbootctl: systemd-service-file-missing-documentation-key [lib/systemd/system/qbootctl.service] Thank you for your contribution to Debian! Cheers, Roger > > -- > With best wishes > Dmitry
Bug#1050814: RFS: qbootctl/0.1.2-1 [ITP] -- utility to control Quacomm A/B boot slots
control: owner -1 ! control: tags -1 +moreinfo Dear Dmitry, Thanks for your ITP & RFS! Some nitpicking: * debian/README.Debian: Please add more description, or remove this file. * debian/include/scsi/scsi_bsg_ufs.h This header is not upstreamed yet? Is it possible to use existing debian packaged header? * Do you know whether this package works for QCOM LE / LU baseline systems? Cheers, Roger
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear Dmitry, On Tue, Jun 20, 2023 at 9:50 AM Dmitry Baryshkov wrote: > > Hi Roger, > > Just to note, we have updated linux-firmware with the files from > http://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware/RB3_firmware_2022112100-v5.zip Thanks for your info! My previous upload got rejected by ftpmaster. I think there was some misunderstanding, and I provided valid explanation, then uploaded again just now. Hope this time we can pass NEW queue. After that I will update to the latest version you provided. Cheers, Roger
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#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear ftpmaster, I found that the previous upload for linux-board-support-package-dragonboard845c was removed from the NEW queue. I guess it's because you don't want to have the 1st upload to hit the archive. So I reuploaded the 2nd upload again. It should resolve all concerns regarding to ITP this email thread mentioned. Cheers, Roger On Mon, Apr 24, 2023 at 11:23 PM Roger Shimizu wrote: > On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov > wrote: > > > > On 24/04/2023 11:18, Roger Shimizu wrote: > > > On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov > > > wrote: > > >> > > >> On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > > >>> > > >>> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > > >>> wrote: > > >>>> > > >>>> On Wed, 19 Apr 2023 at 10:06, Roger Shimizu > wrote: > > >>>>> > > >>>>> On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > >>>>> wrote: > > >>>>>> > > >>>>>> On Tue, 18 Apr 2023 at 21:36, Roger Shimizu > wrote: > > >>>>>>> > > >>>>>>>> Hello Roger, FTP masters, > > >>>>>>>> Short story: the uploaded > linux-board-support-package-dragonboard845c package (currently in NEW) > contains a file with unclear license background and as such it should not > be allowed into the archive. > > >>>>>>>> The orig.tar.gz file needs to be repackaged before uploading. > > >>>>>>> > > >>>>>>> I tried to repack the orig, and re-upload, but got REJECTED by: > > >>>>>>> > > >>>>>>> > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: > > >>>>>>> Does not match file already existing in the pool. > > >>>>>> > > >>>>>> Usually one would use suffix like -dfsg to mark the repacked > package. > > >>>>>> The -dfsg doesn't make sense in the case of a non-free package, > so you > > >>>>>> can probably use -repack. > > >>>>> > > >>>>> Yes, but upstream uses .zip archive anyhow. > > >>>>> So we have to repack to .orig.tar.* > > >>>> > > >>>> To notify possible users that it's not just a repack of zip, but > also > > >>>> > > >>>>> > > >>>>>> More importantly I'm not sure that this package should be a part > of > > >>>>>> Debian at all. > > >>>>> > > >>>>> Why? > > >>>>> Without bootloader part, we cannot support installer in Debian. > > >>>> > > >>>> This bootloader is already installed by the manufacturer. Please > > >>>> consider these partitions as a firmware. One does not modify the > > >>>> device firmware during Debian installation. > > >>>> > > >>>> Maybe I misunderstand something about the usecase you are facing. > > >>>> Could you please describe it? > > >>> > > >>> RB3 is an open platform. > > >>> You do not know what system user previously installed. > > >> > > >> Yes, that's the point. It could have been customized by the user. > > >> > > >> I always hated some W operating system rewriting the MBR > > >> unconditionally and really liked the way Debian asks user if this is a > > >> desired theing. > > > > > > With prompting user, your concern can be resolved. > > > > > >>> And even Linaro provided two different system, with different > > >>> partition layouts, aosp and linux: > > >>> - > https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/ > > >> > > >> And usually they differ only in the partitioning scheme, in GPT data. > > >> So. Repartitioning the UFS sounds correct to me. Reflashing the > > >> bootloader doesn't sound good. > > >> > > >>> I'm not sure why you suppose the bootloader has to be original. > > >> > > >> I suppose that it's not a task of the DI to update the bootloader. > > > > > > For linaro's image, if user want to switch between AOSP (Android) and > > > Debian, the bootloader has to be flashed. > > > > This was done t
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#1032671: linux: Enable USB_XHCI_PCI_RENESAS on arm64
Dear KiBi, On Fri, Mar 10, 2023 at 9:24 AM Cyril Brulebois wrote: > > Source: linux > Severity: normal > Tags: patch > ... that's why I'm sticking to this > particular architecture in my initial patch. Did you forget to enclose the patch? Do you still have it? Cheers, Roger
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Mon, Apr 24, 2023 at 4:33 AM Dmitry Baryshkov wrote: > > On 24/04/2023 11:18, Roger Shimizu wrote: > > On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov > > wrote: > >> > >> On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > >>> > >>> On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > >>> wrote: > >>>> > >>>> On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > >>>>> > >>>>> On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > >>>>> wrote: > >>>>>> > >>>>>> On Tue, 18 Apr 2023 at 21:36, Roger Shimizu wrote: > >>>>>>> > >>>>>>>> Hello Roger, FTP masters, > >>>>>>>> Short story: the uploaded > >>>>>>>> linux-board-support-package-dragonboard845c package (currently in > >>>>>>>> NEW) contains a file with unclear license background and as such it > >>>>>>>> should not be allowed into the archive. > >>>>>>>> The orig.tar.gz file needs to be repackaged before uploading. > >>>>>>> > >>>>>>> I tried to repack the orig, and re-upload, but got REJECTED by: > >>>>>>> > >>>>>>> linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: > >>>>>>> Does not match file already existing in the pool. > >>>>>> > >>>>>> Usually one would use suffix like -dfsg to mark the repacked package. > >>>>>> The -dfsg doesn't make sense in the case of a non-free package, so you > >>>>>> can probably use -repack. > >>>>> > >>>>> Yes, but upstream uses .zip archive anyhow. > >>>>> So we have to repack to .orig.tar.* > >>>> > >>>> To notify possible users that it's not just a repack of zip, but also > >>>> > >>>>> > >>>>>> More importantly I'm not sure that this package should be a part of > >>>>>> Debian at all. > >>>>> > >>>>> Why? > >>>>> Without bootloader part, we cannot support installer in Debian. > >>>> > >>>> This bootloader is already installed by the manufacturer. Please > >>>> consider these partitions as a firmware. One does not modify the > >>>> device firmware during Debian installation. > >>>> > >>>> Maybe I misunderstand something about the usecase you are facing. > >>>> Could you please describe it? > >>> > >>> RB3 is an open platform. > >>> You do not know what system user previously installed. > >> > >> Yes, that's the point. It could have been customized by the user. > >> > >> I always hated some W operating system rewriting the MBR > >> unconditionally and really liked the way Debian asks user if this is a > >> desired theing. > > > > With prompting user, your concern can be resolved. > > > >>> And even Linaro provided two different system, with different > >>> partition layouts, aosp and linux: > >>> - > >>> https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/ > >> > >> And usually they differ only in the partitioning scheme, in GPT data. > >> So. Repartitioning the UFS sounds correct to me. Reflashing the > >> bootloader doesn't sound good. > >> > >>> I'm not sure why you suppose the bootloader has to be original. > >> > >> I suppose that it's not a task of the DI to update the bootloader. > > > > For linaro's image, if user want to switch between AOSP (Android) and > > Debian, the bootloader has to be flashed. > > This was done this way, because there is no easy way to repartition the > device from the host side. From the installer, that is running on the > device, it is pretty easy to do. One just uses fdisk, parted, or any > other GPT partitioning tool. Thanks for confirmation that Linaro also changes partition layout when flashing between different images (e.g. Android and Debian). We can discuss more in details how to integrate to D-I. > > So I think the logic for D-I should be the same. > > Any way, it's out of scope of this ticket. Let's discuss more when > > integrating to D-I. > > > >>> Linaro's rescue image also rewrite those partitions. > >>> I think D
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Thu, Apr 20, 2023 at 6:31 AM Dmitry Baryshkov wrote: > > On Thu, 20 Apr 2023 at 11:28, Roger Shimizu wrote: > > > > On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov > > wrote: > > > > > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > > > wrote: > > > > > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu wrote: > > > > > > > > > > > > > Hello Roger, FTP masters, > > > > > > > Short story: the uploaded > > > > > > > linux-board-support-package-dragonboard845c package (currently in > > > > > > > NEW) contains a file with unclear license background and as such > > > > > > > it should not be allowed into the archive. > > > > > > > The orig.tar.gz file needs to be repackaged before uploading. > > > > > > > > > > > > I tried to repack the orig, and re-upload, but got REJECTED by: > > > > > > > > > > > > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: > > > > > > Does not match file already existing in the pool. > > > > > > > > > > Usually one would use suffix like -dfsg to mark the repacked package. > > > > > The -dfsg doesn't make sense in the case of a non-free package, so you > > > > > can probably use -repack. > > > > > > > > Yes, but upstream uses .zip archive anyhow. > > > > So we have to repack to .orig.tar.* > > > > > > To notify possible users that it's not just a repack of zip, but also > > > > > > > > > > > > More importantly I'm not sure that this package should be a part of > > > > > Debian at all. > > > > > > > > Why? > > > > Without bootloader part, we cannot support installer in Debian. > > > > > > This bootloader is already installed by the manufacturer. Please > > > consider these partitions as a firmware. One does not modify the > > > device firmware during Debian installation. > > > > > > Maybe I misunderstand something about the usecase you are facing. > > > Could you please describe it? > > > > RB3 is an open platform. > > You do not know what system user previously installed. > > Yes, that's the point. It could have been customized by the user. > > I always hated some W operating system rewriting the MBR > unconditionally and really liked the way Debian asks user if this is a > desired theing. With prompting user, your concern can be resolved. > > And even Linaro provided two different system, with different > > partition layouts, aosp and linux: > > - https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/ > > And usually they differ only in the partitioning scheme, in GPT data. > So. Repartitioning the UFS sounds correct to me. Reflashing the > bootloader doesn't sound good. > > > I'm not sure why you suppose the bootloader has to be original. > > I suppose that it's not a task of the DI to update the bootloader. For linaro's image, if user want to switch between AOSP (Android) and Debian, the bootloader has to be flashed. So I think the logic for D-I should be the same. Any way, it's out of scope of this ticket. Let's discuss more when integrating to D-I. > > Linaro's rescue image also rewrite those partitions. > > I think Debian should do the same. > > > > > My current understanding: > > > - The device comes from the factory with the bootloaders flashed > > > - DI repartitions one of UFS LUNs to replace vendor+system+userdata > > > with the rootfs/home/etc > > > - DI installs all the packages to the target rootfs, including the > > > package with custom kernel hooks > > > - the kernel hooks write the generated android boot img to the boot > > > partition > > > > > > Is there anything else? > > > > Anyway, this is not for this ITP ticket. We can discuss when porting > > to installer. > > Sure. Please ping either me directly or the linux-arm-msm mailing list > when you'd like to discuss it. Getting DI to work on these boards > would be a very welcomed and appreciated both by our group and by the > overall community. Thanks for your understanding! > > > > > I doubt that DI should touch these partitions. Firstly, because of the > > > > > reasons I expressed in my previous email (risk of bricking the board
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Wed, Apr 19, 2023 at 2:47 AM Dmitry Baryshkov wrote: > > On Wed, 19 Apr 2023 at 10:06, Roger Shimizu wrote: > > > > On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov > > wrote: > > > > > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu wrote: > > > > > > > > > Hello Roger, FTP masters, > > > > > Short story: the uploaded linux-board-support-package-dragonboard845c > > > > > package (currently in NEW) contains a file with unclear license > > > > > background and as such it should not be allowed into the archive. > > > > > The orig.tar.gz file needs to be repackaged before uploading. > > > > > > > > I tried to repack the orig, and re-upload, but got REJECTED by: > > > > > > > > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: > > > > Does not match file already existing in the pool. > > > > > > Usually one would use suffix like -dfsg to mark the repacked package. > > > The -dfsg doesn't make sense in the case of a non-free package, so you > > > can probably use -repack. > > > > Yes, but upstream uses .zip archive anyhow. > > So we have to repack to .orig.tar.* > > To notify possible users that it's not just a repack of zip, but also > > > > > > More importantly I'm not sure that this package should be a part of > > > Debian at all. > > > > Why? > > Without bootloader part, we cannot support installer in Debian. > > This bootloader is already installed by the manufacturer. Please > consider these partitions as a firmware. One does not modify the > device firmware during Debian installation. > > Maybe I misunderstand something about the usecase you are facing. > Could you please describe it? RB3 is an open platform. You do not know what system user previously installed. And even Linaro provided two different system, with different partition layouts, aosp and linux: - https://releases.linaro.org/96boards/dragonboard845c/linaro/rescue/21.12/ I'm not sure why you suppose the bootloader has to be original. Linaro's rescue image also rewrite those partitions. I think Debian should do the same. > My current understanding: > - The device comes from the factory with the bootloaders flashed > - DI repartitions one of UFS LUNs to replace vendor+system+userdata > with the rootfs/home/etc > - DI installs all the packages to the target rootfs, including the > package with custom kernel hooks > - the kernel hooks write the generated android boot img to the boot partition > > Is there anything else? Anyway, this is not for this ITP ticket. We can discuss when porting to installer. > > > I doubt that DI should touch these partitions. Firstly, because of the > > > reasons I expressed in my previous email (risk of bricking the board, > > > custom bootloaders being used on these devboards, etc). > > > Secondly, I'd like to point out that RB3/RB5 (and other dragonboards) > > > are in a pretty unique position. Other development boards (QRD, HDK, > > > Open-Q, etc.) do not have public redistributable bootloader archives. > > > > No worries about the brick issue. > > Actually, no. Bricking the device during installer is a very bad thing. I said no worries, because we need to fix those issue when porting to installer. This is ITP ticket, and we need to be focus on packaging firmware first. Cheers, Roger > > We should consider this before releasing it to installer. > > Currently, we just take the 1st step to get everything necessary to > > hit the debian archive. > > Ok, it's up to you, once the archive is free of the Renesas firmware, > but I'd not consider it 'necessary'. The user has to perfectly know > what he is flushing and why. I'd strongly advice to point to the > rescue packages or to the Thundercomm SDK manager instead of packaging > everything into the installer. > > -- > With best wishes > Dmitry
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
On Tue, Apr 18, 2023 at 11:47 AM Dmitry Baryshkov wrote: > > On Tue, 18 Apr 2023 at 21:36, Roger Shimizu wrote: > > > > > Hello Roger, FTP masters, > > > Short story: the uploaded linux-board-support-package-dragonboard845c > > > package (currently in NEW) contains a file with unclear license > > > background and as such it should not be allowed into the archive. > > > The orig.tar.gz file needs to be repackaged before uploading. > > > > I tried to repack the orig, and re-upload, but got REJECTED by: > > > > linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: > > Does not match file already existing in the pool. > > Usually one would use suffix like -dfsg to mark the repacked package. > The -dfsg doesn't make sense in the case of a non-free package, so you > can probably use -repack. Yes, but upstream uses .zip archive anyhow. So we have to repack to .orig.tar.* > More importantly I'm not sure that this package should be a part of > Debian at all. Why? Without bootloader part, we cannot support installer in Debian. > I doubt that DI should touch these partitions. Firstly, because of the > reasons I expressed in my previous email (risk of bricking the board, > custom bootloaders being used on these devboards, etc). > Secondly, I'd like to point out that RB3/RB5 (and other dragonboards) > are in a pretty unique position. Other development boards (QRD, HDK, > Open-Q, etc.) do not have public redistributable bootloader archives. No worries about the brick issue. We should consider this before releasing it to installer. Currently, we just take the 1st step to get everything necessary to hit the debian archive. > > -- > With best wishes > Dmitry Cheers, Roger
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
> Hello Roger, FTP masters, > Short story: the uploaded linux-board-support-package-dragonboard845c package > (currently in NEW) contains a file with unclear license background and as > such it should not be allowed into the archive. > The orig.tar.gz file needs to be repackaged before uploading. I tried to repack the orig, and re-upload, but got REJECTED by: linux-board-support-package-dragonboard845c_0~20190529180356-v4-1.dsc: Does not match file already existing in the pool.
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Dear Dmitry, Thanks for your response! Very informative. And the ultimate goal is to have a debian-installer image. So this firmware upload is just the first step. Let me reply to you inline below. On Mon, Apr 17, 2023 at 3:15 AM Dmitry Baryshkov wrote: > > On Mon, 17 Apr 2023 at 03:09, Roger Shimizu wrote: > > > > Package: wnpp > > Severity: wishlist > > Owner: Roger Shimizu > > X-Debbugs-Cc: debian-de...@lists.debian.org > > > > * Package name: linux-board-support-package-dragonboard845c > > Version : 20190529180356-v4 > > Upstream Author : Linaro > > * URL : > > https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware > > * License : non-free > > Description : Firmware for dragonboard845c / RB3 > > > > This package contains the binary firmware for GPU, USB, DSP hardware > > coprocessors found on SDM845, which is the main SoC on the > > Dragonboard 845c / RB3. > > Generally, I think there is some misunderstanding here. Most of the > firmware has been pushed to linux-firmware already (where possible). > You probably have some other intentions here. If so, please describe them. Thanks for the upstreaming work! I checked package firmware-qcom-soc [1], and found GPU / Audio DSP / Modem firmware is already there. [1] https://packages.debian.org/unstable/firmware-qcom-soc > I took a glance at the package sources on salsa. So, let's go at this > one by one. > > firmware-qcom-dragonboard845c.install: > > [0-9]*/prog_firehose_ddr.elf lib/firmware/qcom/sdm845 > > This is the file that is only used by the _host_ when programming the > device. As such, it should not be a part of the en-device firmware. It > has no use for the RB3 itself. > > [0-9]*/aop.mbn lib/firmware/qcom/sdm845 > > Bootloader. It should not be a part of /lib/firmware/ Since my ultimate goal is to make an installer image, the bootloader part is necessary. Because we don't have the source code for this, and we have to flash this file to one partition of the UFS on the board in order to boot the system, we have to treat it as firmware. If you have a better idea for the path name, rather than /lib/firmware/, please let me know. > [0-9]*/BTFM.bin lib/firmware/qcom/sdm845 > > This is the filesystem image with bluetooth firmware files. Relevant > files are already part of the /lib/firmware/qca. If anything important > is missing there, it should directly into Good to know it's already upstreamed, and it's under qca folder. > [0-9]*/cmnlib.mbn lib/firmware/qcom/sdm845 > [0-9]*/cmnlib64.mbn lib/firmware/qcom/sdm845 > [0-9]*/devcfg.mbn lib/firmware/qcom/sdm845 > > These three files are also used by the bootloader process, and as such > they should not be a part of /lib/firmware. > > [0-9]*/dspso.bin lib/firmware/qcom/sdm845 > > This is probably the only important file for now. This is the > filesystem image with the shared libraries and executable code for the > DSPs when executing compute applications there. > We were putting it to /lib/firmware/qcom/sdm845 and mounting it later, > because it was easier to do so (if the image is not present in > /lib/firmware, the rootfs can try mounting dspso parition). For proper > Debian packaging the image should be unpacked to some agreed location. > fastrpc daemons then should be taught about this location. Yes, we need to integrate this into the installer. > [0-9]*/hyp.mbn lib/firmware/qcom/sdm845 > [0-9]*/imagefv.elf lib/firmware/qcom/sdm845 > [0-9]*/keymaster64.mbn lib/firmware/qcom/sdm845 > [0-9]*/sec.dat lib/firmware/qcom/sdm845 > [0-9]*/storsec.mbn lib/firmware/qcom/sdm845 > [0-9]*/tz.mbn lib/firmware/qcom/sdm845 > [0-9]*/xbl.elf lib/firmware/qcom/sdm845 > [0-9]*/xbl_config.elf lib/firmware/qcom/sdm845 > [0-9]*/qupv3fw.elf lib/firmware/qcom/sdm845 > > Again, mostly bootloader stuff. I highly doubt that /lib/firmware > should be polluted with these files. > > renesas_usb_fw.mem lib/firmware > > So, this is the Renesas firmware, which gets copyrighted by Qualcomm. > We noticed this some time ago (and the fact that the supplier of the > firmware, Thundercomm, also pulled the file without having a clear > origin). We have been trying to clear licensing terms for this file, > however Renesas is unresponsive. Originally this file came from the > author (Renesas) without proper license. Thus I do not believe it > passes required checks by ftpmasters. If this is the issue, we can remove this blob. But basically, this is a non-free package, and if we can redistribute the file it should not be a problem. The file is on linaro archive for years for free download to anymore. And you informed Renesas about this, so if they don't agree with the redistribu
Bug#1034496: ITP: linux-board-support-package-rb5 -- Firmware for RB5
Package: wnpp Severity: wishlist Owner: Roger Shimizu X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: linux-board-support-package-rb5 Version : 20210901-v6 Upstream Author : Linaro * URL : https://releases.linaro.org/96boards/rb5/qualcomm/firmware * License : non-free Description : Firmware for RB5 This package contains the binary firmware for the SM8250, which is the main SoC on the Robotics RB5.
Bug#1034495: ITP: linux-board-support-package-dragonboard845c -- Firmware for dragonboard845c / RB3
Package: wnpp Severity: wishlist Owner: Roger Shimizu X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: linux-board-support-package-dragonboard845c Version : 20190529180356-v4 Upstream Author : Linaro * URL : https://releases.linaro.org/96boards/dragonboard845c/qualcomm/firmware * License : non-free Description : Firmware for dragonboard845c / RB3 This package contains the binary firmware for GPU, USB, DSP hardware coprocessors found on SDM845, which is the main SoC on the Dragonboard 845c / RB3.
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#1008763: torbrowser-launcher: Multiarch support
On Fri, Apr 1, 2022 at 2:03 PM Richard Z wrote: > > I think this lint warning is relevant: > https://lintian.debian.org/tags/package-contains-no-arch-dependent-files?version=2.114.162 > > Might be best to mark it as > Architecture: all Upstream only support amd64 and i386 - https://aus1.torproject.org/torbrowser/update_3/release/ It's useless for other arch to install this package. 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#1012890: android-platform-frameworks-base: ftbfs with GCC-12
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.
Bug#1021713: CalyxOS cannot be installed from Debian 11 since it has very old fastboot version
control: severity -1 wishlist src:android-platform-tools provides binary fastboot, and you can easily install version 29, which is even in bullseye backports. if you need version 30 or above, it's in experimental only.
Bug#1027868: broadcom-sta: please switch to B-D: dh-sequence-dkms (or dh-dkms)
control: tags -1 +pending On Fri, Jan 20, 2023 at 8:58 AM Andreas Beckmann wrote: > > Control: tag -1 patch > > On 16/01/2023 05.58, Roger Shimizu wrote: > >> please switch the Build-Depends of your package from `dkms` to `dh-dkms` > >> or (preferrably) `dh-sequence-dkms`. > >> With the latter you can also drop the `--with dkms` argument to `dh`. > > > > I guess you prefer dh-sequence-dkms, since currently we're using > > dh-dkms already. > > Then this bug report was triggered by the superfluous B-D: dkms ;-) > > (And I can drop the dkms -> dh-dkms dependency for bookworm without > harming your package.) Agreed. Thanks! > >> If you have questions or need help for disabling the module build on > >> unsupported architectures/configurations (that may be exposed when > >> enabling the autopkgtest), don't hesitate to contact me. > > > > I did a code search, and found: > > https://sources.debian.org/src/bbswitch/0.8-14/debian/tests/autopkgtest-pkg-dkms.conf/ > > > > I guess you just meant this, right? > > There are only *.o_shipped for amd64 and i386. I've therefore restricted > the autopkgtest to these two architectures. > > You can find some proposed commits here: > > https://salsa.debian.org/anbe/broadcom-sta/-/merge_requests/1 > > (This unfortunately ended up as a merge request in my fork since your > repository does not allow creation of merge requests.) Until recently, I finally realized that I should apply for the permission for access the MR in your own repo. Still lucky that it's before final freezing, so we can catch up with the next release. Merged to our main repo. And thanks for your ticket, and patience. PS. Seems the main repo now enables the MR feature, so you can create MR if you have new patches. Thanks again! Cheers, Roger
Bug#1027868: broadcom-sta: please switch to B-D: dh-sequence-dkms (or dh-dkms)
Dear Andreas, Thanks for the ticket, and helping to improve this package! On Wed, Jan 4, 2023 at 2:21 AM Andreas Beckmann wrote: > > Source: broadcom-sta > Version: 6.30.223.271-23 > Severity: important > > Hi, > > please switch the Build-Depends of your package from `dkms` to `dh-dkms` > or (preferrably) `dh-sequence-dkms`. > With the latter you can also drop the `--with dkms` argument to `dh`. I guess you prefer dh-sequence-dkms, since currently we're using dh-dkms already. > Please consider adding > Testsuite: autopkgtest-pkg-dkms > to the source stanza in debian/control s.t. the module gets build-tested > against any new kernel version in the archive and breakage is noticed > quickly. Thanks for reminding this. It should be enabled for long. > If you have questions or need help for disabling the module build on > unsupported architectures/configurations (that may be exposed when > enabling the autopkgtest), don't hesitate to contact me. I did a code search, and found: https://sources.debian.org/src/bbswitch/0.8-14/debian/tests/autopkgtest-pkg-dkms.conf/ I guess you just meant this, right? Thanks again! Cheers, Roger
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#1014173: p7zip: Please kindly update to new upstream version
Source: p7zip Version: 16.02+dfsg-8 Severity: wishlist Dear Maintainer, https://www.7-zip.org/sdk.html Upstream has release quite a few releases, some are very interesting: 21.07: Some minor changes and fixes. 21.06: The bug in LZMA encoding function was fixed. 21.03 beta: LZMA dicrionary up to 4 GB. Speed optimizations. 21.02 alpha: macOS and Linux support. Speed optimizations. 19.00: Encryption strength for 7z archives was increased. 18.06: Some speed optimiztions in LZMA/LZMA2 code. 18.05: Some speed optimiztions in LZMA/LZMA2 code. 18.01: Some changes in LZMA2/xz multithreading code for compressing. Some bugs were fixed. Latest 22.00 was just out a few weeks ago, I'm not sure whether it's stable or not. But 21.07 should be stable enough to package. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1014168: lzma: Maybe merge with src:p7zip which shares the same upstream
Source: lzma Version: 9.22-2.2 Severity: normal Dear Maintainer, I'm not sure whether you aware that src:lzma shares the same upstream with src:p7zip: - https://sourceforge.net/projects/p7zip I know src:lzma has longer history than src:p7zip, but it has not been updated for too long time (10+ years). And now there's no accessible git repository on salsa / github for src:lzma. BTW. Previous collab-maint archive is still here: - https://alioth-archive.debian.org/git/collab-maint/lzma.git.tar.xz Condition of src:p7zip is a bit better, the version in unstable is 16.02, which was initially uploaded on 2016, 6 years ago. And there's git repo on salsa for src:p7zip: - https://salsa.debian.org/debian/p7zip I think maintaining both packages is not necessary, and hope can either one to update to the latest upstream verion, 22.00. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1012572: android-platform-frameworks-base: FTBFS with protobuf 3.20.1+
control: tags -1 pending Dear GCS, 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! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#999544: Package new upstream version
control: tags -1 -ftbfs control: severity -1 normal I think currently there's no ftbfs issue for this package. So no immediate urgency to upgrade package. It's still welcome that anyone can help to package the new dependencies to NEW queue. Thanks for the work from you all! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU
On Fri, May 20, 2022 at 2:26 AM Adam D. Barratt wrote: > > On Thu, 2022-05-19 at 18:10 +0900, Roger Shimizu wrote: > > I didn‘t know there's "Testing follows removal automatically" rule, > > and just saw the wiki [1] says ftpmaster can only remove from sid & > > experimental. > > > > I guess we should choose "testing follows removal automatically". > > > > [1] > > https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2C_stable_and_oldstable > > > > For completeness, that section also says: > > " > Note that in most cases it is unnecessary to request removal of your > package from both testing and unstable. Once the package is removed > from unstable, it will automatically be removed from testing once there > are no dependencies keeping it there. > " Thanks, Adam! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1001757: RFS: google-android-installers/1639148153 [NMU] -- Google's Android SDK
Dear Fab, Thanks for your work! I already merged your MR to debian/exp branch. Since there're 128 commits / patches for your one MR, it's actually not possible for me to review deeply. So I'd prefer to upload to experimental first. Your upload to mentors seems to have some more commits / patches than MR. So please make another MR to release all your patches to salsa. After that I can sponsor the upload to experimental. Cheers, Roger On Thu, May 19, 2022 at 6:59 PM Roger Shimizu wrote: > > Dear Bastian, > > Thanks for the ping! > I'll check this package later. > > Cheers, > Roger > > On Thu, May 19, 2022 at 2:09 AM Bastian Germann wrote: > > > > Hi Roger and List, > > > > Can you please comment on this and your plans on the > > google-android-installers package? > > This is from sponsorship-requests and nobody cared about it in months. > > I am not familiar with the Android build system. > > > > Hans-Christoph has commented on the Salsa MR to possibly make Fab Stz the > > new package maintainer. > > > > Thanks, > > Bastian > > > > On Wed, 15 Dec 2021 14:13:32 +0100 Fab Stz wrote: > > > I already sent an email on 21/Oct & 19/Nov to android-tools- > > > de...@lists.alioth.debian.org, Roger Shimizu > > concerning a > > > merge request for that package. I haven't seen an anwser yet. > > > > > > Message was: > > > Hello everybody, > > > > > > I updated the google-android-installers source package and created a > > merge > > > request available here: > > > > > > > > https://salsa.debian.org/android-tools-team/google-android-installers/-/merge_requests/3 > > > > > > It automatically builds packages for almost all SDK components described > > in > > > Google's https://dl.google.com/android/repository/repository2-1.xml > > > > > > Among the covered components there is: build-tools, platforms, > > platform-tools, > > > cmdline-tools, emulator, ndk, sources. > > > > > > Could you have a look and give any feedback please? > > > > > > Once merged & approved, this is ready to be reused with the other SDK > > > repositories of Google. It will permit to create source packages for > > these > > > components: sys-img, add-on, extras...
Bug#1001757: RFS: google-android-installers/1639148153 [NMU] -- Google's Android SDK
Dear Bastian, Thanks for the ping! I'll check this package later. Cheers, Roger On Thu, May 19, 2022 at 2:09 AM Bastian Germann wrote: > > Hi Roger and List, > > Can you please comment on this and your plans on the > google-android-installers package? > This is from sponsorship-requests and nobody cared about it in months. > I am not familiar with the Android build system. > > Hans-Christoph has commented on the Salsa MR to possibly make Fab Stz the new > package maintainer. > > Thanks, > Bastian > > On Wed, 15 Dec 2021 14:13:32 +0100 Fab Stz wrote: > > I already sent an email on 21/Oct & 19/Nov to android-tools- > > de...@lists.alioth.debian.org, Roger Shimizu concerning a > > merge request for that package. I haven't seen an anwser yet. > > > > Message was: > > Hello everybody, > > > > I updated the google-android-installers source package and created a merge > > request available here: > > > > > https://salsa.debian.org/android-tools-team/google-android-installers/-/merge_requests/3 > > > > It automatically builds packages for almost all SDK components described in > > Google's https://dl.google.com/android/repository/repository2-1.xml > > > > Among the covered components there is: build-tools, platforms, > platform-tools, > > cmdline-tools, emulator, ndk, sources. > > > > Could you have a look and give any feedback please? > > > > Once merged & approved, this is ready to be reused with the other SDK > > repositories of Google. It will permit to create source packages for these > > components: sys-img, add-on, extras...
Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU
On Thu, May 19, 2022 at 3:49 AM Paul Gevers wrote: > > Hi Roger, > > On 18-05-2022 18:22, Roger Shimizu wrote: > > This ticket is a follow-up to #100 > > - https://bugs.debian.org/100 > > > > I marked this ticket with ROM and NVIU, because: > > - ROM: I'm member of android tools team > > - NVIU: src:android-platform-tools is actually new version of this > > src:android-platform-system-core package. In order to let > > android-platform-tools latest version migrating to testing > > successfully, we have to remove src:android-platform-tools from > > testing. > > Wouldn't it make more sense to remove it altogether then? I.e. shouldn't > we reassign this bug to ftp.debian.org? (Testing follows removal > automatically). Thanks for the hint, Paul! I didn‘t know there's "Testing follows removal automatically" rule, and just saw the wiki [1] says ftpmaster can only remove from sid & experimental. I guess we should choose "testing follows removal automatically". [1] https://wiki.debian.org/ftpmaster_Removals#Removals_from_testing.2C_stable_and_oldstable Cheers, Roger
Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10 -- ROM; NVIU
This ticket is a follow-up to #100 - https://bugs.debian.org/100 I marked this ticket with ROM and NVIU, because: - ROM: I'm member of android tools team - NVIU: src:android-platform-tools is actually new version of this src:android-platform-system-core package. In order to let android-platform-tools latest version migrating to testing successfully, we have to remove src:android-platform-tools from testing. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1011110: unblock: android-platform-tools/29.0.6-14
Dear Paul, Thanks for your kind help and check! I created a new ticket to remove android-platform-system-core from testing as you suggested. - https://bugs.debian.org/1011210 And there're a few comments below if you're interested ... On Wed, May 18, 2022 at 2:32 AM Paul Gevers wrote: > > Hi, > > On 17-05-2022 06:11, Roger Shimizu wrote: > > [ Other info ] > > Package android-platform-art and android-platform-frameworks-base should be > > migrated at the same time. > > > > unblock android-platform-tools/29.0.6-14 > > unblock android-platform-art/11.0.0+r48-3 > > unblock android-platform-frameworks-base/1:10.0.0+r36-5 > > Our migration software already figured that out [1]: > > Trying easy from autohinter: android-platform-art/11.0.0+r48-3 > android-platform-frameworks-base/1:10.0.0+r36-5 > android-platform-tools/29.0.6-14 > start: 24+0: a-1:a-22:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > orig: 24+0: a-1:a-22:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > Checking if changes enables cruft removal > recur: [] > android-platform-art,android-platform-frameworks-base,android-platform-tools > 41/0 > > [...] > > finish: > [android-platform-art,android-platform-frameworks-base,android-platform-tools] > endloop: 24+0: a-1:a-22:a-0:a-0:i-0:m-0:m-0:p-0:s-1 > now: 37+0: a-6:a-27:a-1:a-1:i-1:m-0:m-0:p-0:s-1 Yes, I also saw this log before, but I cannot understand the meaning. It's with too many abbv. words and expressions. It's better if there's a doc to explain these all. > * amd64: android-libadb, android-libadb-dev, > android-libnativebridge-dev, android-libnativeloader-dev, > android-tools-mkbootimg > * arm64: android-libadb, android-libadb-dev, > android-libnativebridge-dev, android-libnativeloader-dev, > android-tools-mkbootimg > * armel: android-libadb > * armhf: android-libadb > * i386: android-libadb > > So, upgrading those three source packages would make several packages > uninstallable. > > Here you can see an example of why: > https://qa.debian.org/dose/debcheck/unstable_main/1652763601/packages/android-libadb.html#720d4c2b1a6529f2af595048faf0e919 I think those uninstallable packages are simply obsoleted, since no other package depends on them. That's why I removed those packages from new d/control file of android-platform-tools (the new source package). > It took me a while, but the issue is that android-libbase is build by > two source packages: > android-platform-system-core/1:10.0.0+r36-10 > and > android-platform-tools/29.0.6-14 > > The rules file of android-platform-tools adds an extra epoch, so it wins > and the version of android-libbase comes from android-platform-tools at > version 1:29.0.6-14 as rmadison tells me. > > Which means that those packages in the update_output.txt can't be > installed (in unstable) because they have a strict versioned relation > that can't be fulfilled in unstable. Our migration software detects the > problem and prevents it from migrating to testing. I guess these issues should be resolved after bug#1011210 - https://bugs.debian.org/1011210 If not, just let me know, and I'll fix it. Thanks again! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#1011210: RM: android-platform-system-core/1:10.0.0+r36-10
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm Since src:android-platform-system-core is already replaced by src:android-platform-tools, please kindly help to remove src:android-platform-system-core from testing. For stable and eailer suits, we can still keep this package. Thank you!
Bug#1011110: unblock: android-platform-tools/29.0.6-14
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package android-platform-tools (Please provide enough (but not too much) information to help the release team to judge the request efficiently. E.g. by filling in the sections below.) [ Reason ] Previous issue such as #1010231 was already resolved, and now autopkgtest results are all fine: - https://qa.debian.org/excuses.php?package=android-platform-tools - https://qa.debian.org/excuses.php?package=android-platform-art - https://qa.debian.org/excuses.php?package=android-platform-frameworks-base Migration period already passed for a few days, but still cannot be migrated automatically, so I filed this ticket for help. [ Tests ] All 3 packages' autopkgtest got passed, and they run well on my enironment. [ Risks ] None so far. If there's issue, I'll fix it. [ Checklist ] [*] all changes are documented in the d/changelog [*] I reviewed all changes and I approve them [*] attach debdiff against the package in testing [ Other info ] Package android-platform-art and android-platform-frameworks-base should be migrated at the same time. unblock android-platform-tools/29.0.6-14 unblock android-platform-art/11.0.0+r48-3 unblock android-platform-frameworks-base/1:10.0.0+r36-5 Cheers, Roger
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#995172: [Pkg-privacy-maintainers] Bug#995172: torbrowser-launcher; complicated access path to download folder
control: severity -1 wishlist Dear Bita, Thanks for the report! On Mon, Sep 27, 2021 at 10:51 PM bita wrote: > > Package: torbrowser-launcher > Version: 0.3.3-6 > > Yop! The access path to the download folder is > complicated or not easy for all kinds of users. > > home/user/.local/share/torbrowser/tbb/x86_64/tor-browser_us/Browser/Downloads > > A visible folder and a shorter path would be easier; would be > possible to create a shortcut visible on desktop in future > versions? This is actually designed by upstream. So if you want to change it, please request this in upstream: - https://github.com/micahflee/torbrowser-launcher Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#999544: Update golang-v2ray-core to new upstream
Dear Aloïs, Personally I don't use upstream branch, and I don't think it's necessary. But if it meet your workflow, I don't have objectection to add this branch. My workflow is simple: - use "uscan -dd" to download latest or specified upstream tarball - merge debian (or master) branch with upstream tag. Maybe removing some files in "excluded" of d/copyright is necessary. - use gbp command to build Hope it helps. Cheers, Roger On Sun, Nov 14, 2021 at 5:49 PM Aloïs Micard wrote: > > Hello Roger, > > On 14/11/2021 09:11, Roger Shimizu wrote: > > Dear Aloïs, > > > > Thanks for your work to go packages! > > Sorry I don't have time lately. So if you can update the packages and > > fix the RC bugs, it'd be appreciated. > > > > Sure thing. The only thing is: have you push the upstream branch on the > repository? It looks like there's none and therefore `gbp import-orig --uscan` > is failing: > > ``` > creekorful@debuild:~/code/golang-v2ray-core$ gbp import-orig --uscan > gbp:error: Repository does not have branch 'upstream' for upstream sources. > If there is none see > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT > on howto create it otherwise use --upstream-branch to specify it. > ``` > > It could be really helpful if you either push upstream branch or explain me > which workflow you are using. > > > Cheers, > > Roger > > > > Cheers, > > -- > Aloïs Micard > > GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Bug#999544: Update golang-v2ray-core to new upstream
Dear Aloïs, Thanks for your work to go packages! Sorry I don't have time lately. So if you can update the packages and fix the RC bugs, it'd be appreciated. Cheers, Roger On Fri, Nov 12, 2021 at 5:22 PM Aloïs Micard wrote: > > Hello there, I hope you are doing fine! > > I don't know if you recall me, but we've worked a bit together > on Go packages in the past (al...@micard.lu). :) > > I have a request regarding golang-v2ray-core: > > The package will be removed on 01-12-21 because of error with Go 1.17 > which is now the defaults in the archive. > > I wanted to update golang-v2ray-core to latest upstream (4.43.0) and backport > the commit > https://github.com/v2fly/v2ray-core/commit/77b88171d6bd837b76a5ad6e6b23689391530ed6 > in order to get the package to build with Go 1.17 and allow transition to > testing of > golang-github-lucas-clemente-quic-go which is needed to prevent Syncthing > from being > RM of testing. > > The thing is: the Salsa repository for golang-v2ray-core doesn't have > upstream branch, > therefore I'm unable to import new upstream via gbp: > > > ``` > creekorful@debuild:~/code/golang-v2ray-core$ gbp import-orig --uscan > gbp:error: > Repository does not have branch 'upstream' for upstream sources. If there is > none see > file:///usr/share/doc/git-buildpackage/manual-html/gbp.import.html#GBP.IMPORT.CONVERT > on howto create it otherwise use --upstream-branch to specify it. > ``` > > Have you forgot to push upstream branch to Salsa? Or are you using a special > workflow? > > If you can either import latest upstream or push missing upstream branch it > would > be greatly helpful. > > Many thanks. > > Cheers, > > -- > Aloïs Micard > > GPG: DA4A A436 9BFA E299 67CD E85B F733 E871 0859 FCD2
Bug#924912: pristine-tar: Failed to reproduce original tarball python-django_1.11.20.orig.tar.gz
should be caused by: - https://bugs.debian.org/897653 if you upgrade tar to buster version 1.30+dfsg-6 or later, it should be resolved. -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#991892: unblock: repo/2.15.4-6
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package repo [ Reason ] * Cherry-pick upstream patch to make manpages system independent, which shows no CPU cores of build system. * Remove local patch to generate manpages. * d/tests: Add test command on new '--use-superproject' option. * d/control: Add run_test dependencies to Build-Depends field. * d/rules: Enable to run "run_test" script as dh_auto_test. [ Impact ] Only manpages, autopkgtest, and dh_auto_test tests are affected. [ Tests ] All tests passed, including new appended tests. [ Risks ] It's low risk because: * This package is in contrib, and with no reverse dependency. * The changes are limited, only affect manpages and tests. [ Checklist ] [x] all changes are documented in the d/changelog [x] I reviewed all changes and I approve them [x] attach debdiff against the package in testing (include/attach the debdiff against the package in testing) unblock repo/2.15.4-6 debdiff_repo.patch.xz Description: application/xz
Bug#931339: [pkg-gnupg-maint] Bug#931339: gnupg: Change default keyserver?
On Sun, Jul 4, 2021 at 6:00 PM Paul Wise wrote: > > On Tue, 2 Jul 2019 15:55:32 +0200 Guillem Jover wrote: > > > According to the dirmngr(8) man page, the default built-in server is > > «hkps://hkps.pool.sks-keyservers.net». Given the recent attacks, and > > the problems inherent in that network, could we just change the > > default to be «hkps://keys.openpgp.org» instead? > > This is fixed in bullseye, but not buster. Now that sks-keyservers.net > is no longer working, Debian users on bullseye are having issues, so it > would be great if the default could be updated in buster/stretch too: >From changelog, version in buster already [1] updated the default server to keys.openpgp.org Is there any other bug involved? [1] https://tracker.debian.org/news/1060144/accepted-gnupg2-2212-1deb10u1-source-into-proposed-updates-stable-new-proposed-updates/ Cheers, Roger
Bug#976461: [Pkg-privacy-maintainers] Bug#976461: torbrowser-launcher: fails to launch, apparmor=DENIED (incomplete fix for #908068?)
control: tags -1 +moreinfo
On Sat, Dec 5, 2020 at 9:09 PM Andrew Gallagher wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-2
> Severity: important
>
> Dear Maintainer,
>
> I updated torbrowser-launcher from 0.2.9-1~bpo9+1 to 0.3.2-14~bpo10+1. This
> has rendered
> torbrowser-launcher unusable. When invoking, the following error appears in
> syslog:
>
> ```
> Dec 5 11:24:37 whippet kernel: [7222867.725534] audit: type=1400
> audit(1607167477.149:61): apparmor="DENIED" operation="exec"
> profile="/home/*/.local/share/torbrowser/tbb/{i686,x86_64}/tor-browser_*/Browser/firefox"
> name="/usr/bin/dirname" pid=6594 comm="firefox" requested_mask="x"
> denied_mask="x" fsuid=1000 ouid=0
> ```
>
> This appears to be either a regression to, or an incomplete fix for #908068.
> I noticed that the apparmor
> profile for torbrowser has been overridden, and the timestamp is the same as
> that of the upgrade:
Please kindly try latest version in bullseye or buster-backports.
Thank you!
Cheers,
Roger
Bug#910504: Long delay until kernel logs “random: crng init done” and allows eg. gdm3 to start
control: tag -1 +moreinfo Dear Grzegorz, Per the posts below, I guess this issue is already resolved. - https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1685794 - https://lwn.net/Articles/760121/ Can you kindly confirm at your side? Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#971335: broadcom-sta: [patch] Driver improvements, cleanups, fixes
control: fixed -1 6.30.223.271-16 Dear Diego, Finally all your patches reached bullseye (stable to be) and buster (backports). :-) On Tue, Oct 20, 2020 at 2:21 AM Diego Escalante Urrelo wrote: > > Hey Roger, > > Apologies for the radio silence. I just saw that this email ended up > in the spam folder :(. > > Thanks for your comments and eagerness to welcome and test this, I'm > really glad that more people will find this useful :) :) > > Some comments: > > On Thu, Oct 1, 2020 at 11:08 AM Roger Shimizu wrote: > > > My "frankenwl" branch is functionally the same as the above > > > "diegoe_debian" branch, but it certainly makes it less convoluted to try > > > and find problems in the code going forward. That said, I wasn't sure > > > what would be the best way to proceed, or if it was a smart thing to do > > > anyway. I guess this package is on "life support" on most distros, so I > > > doubt there would be a objections on creating a shared new upstream (but > > > I'm not familiar with the packaging of this driver in Debian, or other > > > distros). > > > > Since the upstream seems not active for quite a few years, so I think > > it's totally fine if you want to fork. > > And if you do so, I'm happy to update debian package to follow your > > forked git repo. > > > > Do you think it would be worth it to reach out to maintainers at a few > main distros and see if there's any interest to collaborate on this? > When I was trying to figure out the issues with my card (see below) I > noticed that most distros either copy+paste patches, or brew their own > slightly different versions. I think upstream maintainer is not active, and the binary blob hasn't been updated for years. Anyway you can try to reach them. > > > I'm also aware that cards supported by this driver are "old" but most > > > computers trapped in the broadcom-sta driver are perfectly functional > > > today and will be for a few more years. In my particular case I'm > > > running a macbookpro11,1 (2013) which works flawlessly except for the > > > wifi! (Hah!) -- And I understand most other macbookpro models from > > > around 2013 share this or similar Broadcom cards that use this driver. > > > All those machines should be perfectly functional with Debian right now, > > > and for a few more years. > > > > Yes, I also have two mac devices that use this driver. > > Thanks for your effort to make the driver better. > > I wonder if you have run into the connection timeouts/unstable wifi > issues that many other users run into? I have been trying to debug why > and when this issue happens, but perhaps you might have any clue or > anecdote that might help figure this out. > > The issue seems to appear when using certain (seemingly old) APs that > do not implement anything newer than 802.11n -- meaning that anything > with 802.11ac is usually free of the issue. The problem manifests as > sudden very high latency, and sometimes lost ARP/identity towards the > AP. I have been unable to debug the issue, but I have reasonably > eliminated WMM, power saving (both PCI/card and 802.11 protocol), > b/g/n, and a few other suspects. > > From my own testing it would seem that the firmware blob in the card > (or the blob uploaded by the driver) simply stops reporting new > packets, either queuing them, or simply dropping them silently, which > on user space manifests as progressively higher latency and eventual > lost of connectivity until resync/reconnection happens, or the > firmware behaves again. I don't have the proper network hardware to > test the router side, so I can't 100% confirm what's going on. > > AFAIK, these cards have a hybrid firmware model where there's a ROM > firmware in the card, but by design you have/can upload a RAM firmware > that allows the OEM/IHV to upload new features or fix bugs. Fairly > standard, I understand. But my current hypothesis is that the > particular card I have is an slightly custom module by Apple that has > certain buggy behaviors that get corrected with the RAM firmware made > by Apple. To give some support to this hypothesis, my current card + > AP combo exhibited the same buggy behavior under OSX. However, this > buggy behavior got fixed on OSX a few months after the last ever > release of broadcom-sta for Linux. My hypothesis is that whatever bug > that this ROM firmware has with slow or old APs (whether a Broadcom or > Apple integration bug), got fixed by Apple or Broadcom in an updated > RAM firmware, but said fix missed the window of the last ever > broadcom-sta. > > Anyway, my current understanding is th
Bug#469263: devscripts: new script to access ldap/machines.cgi and login to machines
Update the patch from Guillem Jover to add fuzz rule for hurd and kfreebsd. Hope this patch can be merged some day. -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 deb-porterbox Description: Binary data
Bug#973365: On MacBook Pro (P8600) wifi card with BCM4322 chipset does not work
control: tags -1 +moreinfo On Thu, Oct 29, 2020 at 10:45 PM Giuseppe Sacco wrote: > > Package: broadcom-sta > Version: 6.30.223.271-15 > Severity: major > > Hello, > on an Apple MacBook Pro running debian testing (kernel package is > version 5.9.1-1), I have this card: > > # lspci | fgrep Netw > 02:00.0 Network controller: Broadcom Inc. and subsidiaries BCM4322 > 802.11a/b/g/n Wireless LAN Controller (rev 01) > > The card is recognized and managed by the broadcom-sta driver but it > does not displays the list of available networks: You may try latest 6.30.223.271-16 or its backports version. If it still doesn't work for you, you may try b43 driver [1] [1] https://wiki.debian.org/bcm43xx Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#982761: torbrowser-launcher: I can't start Tor Browser
control: tags -1 +moreinfo +unreproducible On Sun, Feb 14, 2021 at 9:51 AM Debian Live user wrote: > > Package: torbrowser-launcher > Version: 0.3.3-3~bpo10+1 > Severity: important > > Dear Maintainer, > > I can't start Tor Browser. After clicking the icon, nothing happens. > I am using Debian Live. I installed it with torbrowser-launcher from > backports. > For me it looks like it is problem with AppArmor. Here are logs from dmesg. > http://paste.debian.net/hidden/d4c44566/ Thanks for your report! I checked the log above, but I never see such apparmor errors and cannot reproduce locally. So please kindly provide more information. Maybe you can remove local cache of tbb and try again? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988997: [Pkg-privacy-maintainers] Bug#988997: Signature verification failed, key expired
control: severity -1 wishlist On Sun, May 23, 2021 at 3:57 AM Mikko Viinamäki wrote: > > Package: torbrowser-launcher > Version: 0.3.2-14~bpo9+1 Thanks for your report! Just FYI. For stretch, I uploaded 0.3.3-3~bpo9+1 long time ago, and it's still in the policy NEW queue [1]. So not much I can do as pkg maintainer. [1] https://ftp-master.debian.org/backports-new.html 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#988627: unblock: broadcom-sta/6.30.223.271-16.1
control: tags -1 -moreinfo Dear Paul, Thanks for your checking! On Thu, May 27, 2021 at 5:50 PM Paul Gevers wrote: > > Control: tags -1 moreinfo > > Hi, > > On 17-05-2021 02:12, Ben Hutchings wrote: > > Please unblock package broadcom-sta > > > > [ Reason ] > > Fix the unusable broadcom-sta-source package. > > > > [ Impact ] > > It is not possible to build a package using module-assistant and the > > version of broadcom-sta-source in bullseye. However, dkms and > > broadcom-sta-dkms can be used as an alternative. > > > > [ Tests ] > > Only the build processes are being changed. I tested that: > > - broadcom-sta can be built from source > > - module-assistant can build a module package from broadcom-sta-source > > for the current kernel version in bullseye (5.10.0-6-amd64) > > - the resulting binary module package looks like a module package > > built from broadcom-sta-source in buster, modulo version changes > > * I wonder, broadcom-sta has seen quite some uploads the last couple of > years and debhelper is even in oldstable newer than the version > mentioned. How were all these uploads possible? I think "some uploads" means uploading "src:broadcom-sta", which states debhelper version in debian/control. And debian/control is not updated in this unblock request. The source updated in this upload is: debian/control.modules.in which is not used for upload, and will be explained below. > * What is/was the behavior of debhelper if the compat level was not > specified? In the freeze we don't want debhelper compat bumps unless the > package is proven to have no delta regardless of the old-vs-new level. The issue resolved in this upload is: after installing broadcom-sta-source, when user try to build their own deb files by using tool module-assistant, the deb build would fail. The user built deb is not for upload to debian archive, but for private use only. Personally I don't install and use broadcom-sta-source, so I didn't notice this issue for years. I hope things get clear now. Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1
> control: retitle -1 unblock: broadcom-sta/6.30.223.271-17 > > unblock broadcom-sta/6.30.223.271-17 ping. I'm asking because this package is marked as autoremoval from testing on June 8th. Is there any concern regarding to the unblocking? Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988083: unblock: micro-evtd/3.4-6
control: tags -1 -moreinfo On Thu, May 20, 2021 at 4:57 AM Paul Gevers wrote: > > Control: tags -1 moreinfo > > Hi Ryan, > > On 06-05-2021 07:33, Ryan Tandy wrote: > > #988119: the daemon creates its pid and status files with mode 666, > > start-stop-daemon doesn't like that and refuses to stop the daemon. > > > > I don't know what the appropriate severity is for that one. If it's RC I > > can make another upload to fix it. > > I suggest a new upload to fix that issue. But if it's no regression, > maybe we can have the current version migrate first. Yes, #988119 is not a regression issue. I think it's better to let current version migrate first. Current version doesn't have any feature change, so it's quite safe. For #988119 I need some time to fix, and test to confirm it's safe to deliver to bullseye. Thanks for your understanding! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#988627: unblock: broadcom-sta/6.30.223.271-16.1
control: retitle -1 unblock: broadcom-sta/6.30.223.271-17 On Mon, May 17, 2021 at 9:15 AM Ben Hutchings wrote: > > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > X-Debbugs-Cc: bl...@debian.org, clac...@easter-eggs.com, r...@debian.org > > Please unblock package broadcom-sta > > [ Reason ] > Fix the unusable broadcom-sta-source package. > > [ Impact ] > It is not possible to build a package using module-assistant and the > version of broadcom-sta-source in bullseye. However, dkms and > broadcom-sta-dkms can be used as an alternative. > > [ Tests ] > Only the build processes are being changed. I tested that: > - broadcom-sta can be built from source > - module-assistant can build a module package from broadcom-sta-source > for the current kernel version in bullseye (5.10.0-6-amd64) > - the resulting binary module package looks like a module package > built from broadcom-sta-source in buster, modulo version changes > > [ Risks ] > This seems like a low-risk change. > > [ Checklist ] > [X] all changes are documented in the d/changelog > [X] I reviewed all changes and I approve them > [X] attach debdiff against the package in testing > > [ Other info ] Sorry I have to re-upload, because this is non-free and won't get built on buildd. I re-uploaded with binary, with no actual code change since 6.30.223.271-16.1 unblock broadcom-sta/6.30.223.271-17 -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1 diff -Nru broadcom-sta-6.30.223.271/debian/changelog broadcom-sta-6.30.223.271/debian/changelog --- broadcom-sta-6.30.223.271/debian/changelog 2021-05-04 18:11:49.0 +0900 +++ broadcom-sta-6.30.223.271/debian/changelog 2021-05-17 19:39:19.0 +0900 @@ -1,3 +1,21 @@ +broadcom-sta (6.30.223.271-17) unstable; urgency=medium + + * Re-upload with binary since this is non-free and won't get built +on buildd. + + -- Roger Shimizu Mon, 17 May 2021 19:39:19 +0900 + +broadcom-sta (6.30.223.271-16.1) unstable; urgency=medium + + * Non-maintainer upload + * debian/control.modules.in: +- Declare debhelper compat level through a build-dependency + (Closes: #988562) + * debian/rules: +- Fix copying of Debian files in install-source rule + + -- Ben Hutchings Mon, 17 May 2021 01:06:42 +0200 + broadcom-sta (6.30.223.271-16) unstable; urgency=medium * Upload to unstable. diff -Nru broadcom-sta-6.30.223.271/debian/control.modules.in broadcom-sta-6.30.223.271/debian/control.modules.in --- broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-04 18:11:49.0 +0900 +++ broadcom-sta-6.30.223.271/debian/control.modules.in 2021-05-17 19:39:19.0 +0900 @@ -2,7 +2,7 @@ Section: non-free/kernel Priority: optional Maintainer: Cyril Lacoux -Build-Depends: debhelper (>= 8) +Build-Depends: debhelper-compat (= 12) Standards-Version: 3.9.4 Homepage: http://www.broadcom.com/support/802.11/linux_sta.php diff -Nru broadcom-sta-6.30.223.271/debian/rules broadcom-sta-6.30.223.271/debian/rules --- broadcom-sta-6.30.223.271/debian/rules 2021-05-04 18:11:49.0 +0900 +++ broadcom-sta-6.30.223.271/debian/rules 2021-05-17 19:39:19.0 +0900 @@ -45,8 +45,8 @@ # Copy Debian files install -D -m 0755 debian/rules.modules $(source_debdir)/rules - for file in changelog compat control control.modules.in copyright; do \ - install -m 644 debian/$$file $(source_debdir); \ + for file in changelog control control.modules.in copyright; do \ + install -m 644 debian/$$file $(source_debdir) || exit; \ done # Make suitable tarball for module-assisant and kernel-package
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#988048: unblock: broadcom-sta/6.30.223.271-16
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package broadcom-sta [ the reason for the unblock ] It fixes a serious bug #987159 that txpower cannot get/set correctly, with some other fixes. The patches are in experimental for a while and confirmed working without regression. [ the debdiff against the package in testing is attached ] debdiff_broadcom-sta.txt.xz Description: application/xz
Bug#980747:
control: tags -1 +pending uploaded. Now pending in NEW queue.
Bug#904132: ITP: browsh -- Fully interactive, realtime, and modern text-based browser
control: block -1 by 877977 On Fri, Jul 20, 2018 at 8:07 PM Paride Legovini wrote: > > Package: wnpp > Severity: wishlist > Owner: Paride Legovini > > * Package name: browsh > Version : 1.4.6 > Upstream Author : Thomas Buckley-Houston > * URL : https://www.brow.sh/ > * License : LGPL-2.1 > Programming Lang: Go > Description : Fully interactive, realtime, and modern text-based browser I tried to package browsh lately, and currently it can build well. I pushed my work to branch rosh/test under git repo below: * https://salsa.debian.org/go-team/packages/browsh Anyway, it seems to be stuck after launching, showing message: Starting Browsh v1.6.4, the modern text-based web browser. Waiting for Firefox to connect... I guess it's because the headless firefox doesn't start correctly, due to lack of web-ext, which is under RFP: * https://bugs.debian.org/877977 I'm not familiar with nodejs, so it'd be appreciated if anyone can help. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#987762: unblock: adjtimex/1.29-11
On Thu, Apr 29, 2021 at 3:39 PM Roger Shimizu wrote: > > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: unblock > > Please unblock package adjtimex I checked autoremovals [1], seems the package will be removed before it get the chance to migrate if unblock is permitted. [1] https://udd.debian.org/cgi-bin/autoremovals.cgi adjtimex: flagged for removal in 14.9 days Because the severity of the ticket was just raised from important to serious yesterday, it looks strange to me that the autoremoval period is so short, and shorter than the migration period. Is there any way to keep this package for bullseye? Thank you! Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#987762: unblock: adjtimex/1.29-11
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package adjtimex
[ the reason for the unblock ]
It fixes a series bug #944867
that cannot work with latest ntpdate command.
The patch is just to add an additional argument in ntpdate command line,
confirmed to work. So the risk is quite limited.
[ the debdiff against the package in testing is attached ]
diff -Nru adjtimex-1.29/debian/changelog adjtimex-1.29/debian/changelog
--- adjtimex-1.29/debian/changelog 2018-07-25 19:29:50.0 +0900
+++ adjtimex-1.29/debian/changelog 2021-04-28 00:11:49.0 +0900
@@ -1,3 +1,14 @@
+adjtimex (1.29-11) unstable; urgency=medium
+
+ * debian/patches:
+- Add patch to fix ntpdate command (Closes: #944867).
+ * debian/control:
+- Use my debian email.
+- Move Vcs-* to salsa.
+- Add Rules-Requires-Root: no
+
+ -- Roger Shimizu Wed, 28 Apr 2021 00:11:49 +0900
+
adjtimex (1.29-10) unstable; urgency=medium
* debian/patches:
diff -Nru adjtimex-1.29/debian/control adjtimex-1.29/debian/control
--- adjtimex-1.29/debian/control2018-07-24 18:50:56.0 +0900
+++ adjtimex-1.29/debian/control2021-04-28 00:11:49.0 +0900
@@ -1,14 +1,15 @@
Source: adjtimex
Section: admin
Priority: optional
-Maintainer: Roger Shimizu
+Maintainer: Roger Shimizu
Build-Depends:
debhelper (>= 10),
po-debconf
Standards-Version: 3.9.8
+Rules-Requires-Root: no
Homepage: http://metalab.unc.edu/pub/Linux/system/admin/time
-Vcs-Git: https://github.com/rogers0/adjtimex.git
-Vcs-Browser: https://github.com/rogers0/adjtimex
+Vcs-Git: https://salsa.debian.org/debian/adjtimex.git
+Vcs-Browser: https://salsa.debian.org/debian/adjtimex
Package: adjtimex
Architecture: linux-any
diff -Nru adjtimex-1.29/debian/patches/11-Fix-ntpdate-command.patch
adjtimex-1.29/debian/patches/11-Fix-ntpdate-command.patch
--- adjtimex-1.29/debian/patches/11-Fix-ntpdate-command.patch 1970-01-01
09:00:00.0 +0900
+++ adjtimex-1.29/debian/patches/11-Fix-ntpdate-command.patch 2021-04-28
00:11:49.0 +0900
@@ -0,0 +1,25 @@
+From: Roger Shimizu
+Date: Mon, 26 Apr 2021 02:49:16 +0900
+Subject: Fix ntpdate command
+
+Add option "-p4" to ntpdate command due to:
+* http://bugs.debian.org/987625
+
+Closes: #944867
+---
+ adjtimex.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/adjtimex.c b/adjtimex.c
+index 692b722..7699fe5 100644
+--- a/adjtimex.c
b/adjtimex.c
+@@ -1424,7 +1424,7 @@ static void log_times()
+ failntpdate("cannot find ntpdate");
+
+ found_ntpdate:
+- sprintf(command, "%s -q -d %.32s ", paths[i], timeserver);
++ sprintf(command, "%s -q -p4 -d %.32s ", paths[i], timeserver);
+ ifile = popen(command, "r");
+
+ if (ifile == NULL)
diff -Nru adjtimex-1.29/debian/patches/series
adjtimex-1.29/debian/patches/series
--- adjtimex-1.29/debian/patches/series 2018-07-25 19:29:50.0 +0900
+++ adjtimex-1.29/debian/patches/series 2021-04-28 00:11:49.0 +0900
@@ -8,3 +8,4 @@
08-FTCBFS-uses-the-build-architecture-compiler.patch
09-adjtimex.8-Some-fixes-to-the-manual.patch
10-STA_NANO-confuses-adjtimex-8.patch
+11-Fix-ntpdate-command.patch
Bug#987625: ntpdate -p samples number is 1 by default, which is not consistent with manpage
control: found -1 1:4.2.8p10+dfsg-1 control: affects -1 adjtimex control: block 944867 by -1 On Tue, Apr 27, 2021 at 2:33 AM Roger Shimizu wrote: > > I found since buster version, -p samples default value changed from 4, > which is in manpage, to 1. Should be related to this commit: * https://salsa.debian.org/pkg-ntp-team/ntp/-/commit/5263b05 ntpdate/ntpdate.c Line 157 -int sys_samples = DEFSAMPLES; /* number of samples/server */ +int sys_samples = 0;/* number of samples/server, will be modified later */ Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#987625: ntpdate -p samples number is 1 by default, which is not consistent with manpage
Package: ntpdate Version: 1:4.2.8p15+dfsg-1 Severity: important Dear Maintainer, I found since buster version, -p samples default value changed from 4, which is in manpage, to 1. So it will output "filter delay:" and "filter offset:" lines by default in stretch version, 1:4.2.8p10+ based; but will not in buster or later version, 1:4.2.8p12+ based. You can check the output by command: $ ntpdate -d -q pool.ntp.org $ ntpdate -d -p4 -q pool.ntp.org In manpage: -p samples Specify the number of samples to be acquired from each server as the integer samples, with values from 1 to 8 inclusive. The default is 4. So clearly the behaviour is not consistent with manpage. Please kindly fix this, by either change the code, or update the manpage. Thank you! Cheers, Roger
Bug#944867: ntpdate -d -q
control: tags -1 +patch On Sun, Dec 8, 2019 at 1:27 AM Oleg Broytman wrote: > > AFAIU adjtimex.c expects "filter offset:" and there is no "filter > offset:" in the output. As I tested, adding option "-p4" can add "filter offset:" back to result. $ sudo ntpdate -d -p4 -q pool.ntp.org Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#980155: apparmor="DENIED" profile="torbrowser_firefox" name="/proc/874474/cgroup"
control: tags -1 +patch
On Fri, Jan 15, 2021 at 9:36 PM Paul Wise wrote:
>
> Package: torbrowser-launcher
> Version: 0.3.3-3
> Severity: minor
> File: /etc/apparmor.d/torbrowser.Browser.firefox
> Usertags: warnings
>
> When I start torbrowser-launcher I get apparmor denials like the
> following. There don't appear to be any consequences for this denial,
> the Tor Browser window starts up and works just fine. Possibly the
> Firefox sandboxing uses this file but I'm not sure.
>
> Jan 15 20:22:03 audit[874474]: AVC apparmor="DENIED" operation="open"
> profile="torbrowser_firefox" name="/proc/874474/cgroup" pid=874474
> comm="firefox.real" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
Thanks for the report!
Enclose the patch I tested OK on my buster-backports system.
Cheers,
--
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
From: Roger Shimizu
Date: Sun, 25 Apr 2021 22:51:12 +0900
Subject: Update apparmor profile
Closes: #980155
---
apparmor/torbrowser.Browser.firefox | 2 ++
1 file changed, 2 insertions(+)
diff --git a/apparmor/torbrowser.Browser.firefox b/apparmor/torbrowser.Browser.firefox
index 57c0359..095b110 100644
--- a/apparmor/torbrowser.Browser.firefox
+++ b/apparmor/torbrowser.Browser.firefox
@@ -90,6 +90,7 @@ profile torbrowser_firefox @{torbrowser_firefox_executable} {
/usr/share/gnome/applications/ r,
/usr/share/gnome/applications/kde4/ r,
/usr/share/poppler/cMap/ r,
+ /etc/xdg/mimeapps.list r,
# Distribution homepage
/usr/share/homepage/ r,
@@ -121,6 +122,7 @@ profile torbrowser_firefox @{torbrowser_firefox_executable} {
deny @{HOME}/.cache/fontconfig/** rw,
deny @{HOME}/.config/gtk-2.0/ rw,
deny @{HOME}/.config/gtk-2.0/** rw,
+ deny @{PROC}/@{pid}/cgroup r,
deny @{PROC}/@{pid}/net/route r,
deny /sys/devices/system/cpu/cpufreq/policy[0-9]*/cpuinfo_max_freq r,
deny /sys/devices/system/cpu/*/cache/index[0-9]*/size r,
Bug#977730: [Pkg-privacy-maintainers] Bug#977730: torbrowser-launcher: Signature verification failed, key expired
On Sun, Dec 20, 2020 at 3:36 AM Jean-Michel Vourgère wrote: > > Package: torbrowser-launcher > Version: 0.3.3-3 > Severity: important > > Dear Maintainer, > > When installing on a fresh bullseye, torbrowser is downloaded, then this > message is printed: > > > SIGNATURE VERIFICATION FAILED I'm wondering whether you really had this problem on 0.3.3-3 It supposed to be fixed since 0.3.2-12 And personally I cannot reproduce this issue on my system using 0.3.3-3~bpo10+1 Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#987159: broadcom-sta-dkms: error(-1) from calls to @wl_dev_intvar_get; @wl_cfg80211_get_tx_power by networkctl
On Tue, Apr 20, 2021 at 4:10 AM Philip Stewart wrote: > > Hi Roger, > > Since installing the experimental package, I've spent some more time > investigating and it appears the dmesg errors: > > 1. never occur if networkctl is executed as root > 2. always occur if executed as a un-elevated user > 3. sporadically occur if executed when elevated with sudo > > In all cases, the access point MAC address remains zeroed in the > response. Thanks for the confirmation! > Otherwise, the experimental package appears to be an improvement in > that the txpower is now reported and the access point MAC is visible > using 'iw wlan0 link'. I assume it won't make it to the bullseye > release, but do you know if the plan is to merge it into bulleye > post-release? I think backports would be more simple, and fast to upload. Does that work for you? Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#987159: broadcom-sta-dkms: error(-1) from calls to @wl_dev_intvar_get; @wl_cfg80211_get_tx_power by networkctl
On Mon, Apr 19, 2021 at 1:33 AM Philip Stewart wrote: > > Package: broadcom-sta-dkms > Version: 6.30.223.271-15 > Severity: minor > > Dear Maintainer, > > Calls to networkctl, e.g. 'networkctl' or 'networkctl status wlan0', > result in the following error messages in dmesg: > > [ 6969.831960] ERROR @wl_dev_intvar_get : > [ 6969.831968] error (-1) > [ 6969.831979] ERROR @wl_cfg80211_get_tx_power : > [ 6969.831982] error (-1) > > I haven't yet observed any significant detrimental effect as a result > of the errors, merely incomplete status reporting, e.g. missing access > point MAC address. Could you kindly try 6.30.223.271-16~exp1 in experimental? * https://tracker.debian.org/news/1180272/accepted-broadcom-sta-630223271-16exp1-source-all-into-experimental/ It includes some patches to improve txpower, mac setting, etc. Cheers, -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#985636: zsync: Request to add "--auth-no-challenge" option from wget to zsync
Package: zsync Version: 0.6.2-3 Severity: wishlist Dear Maintainer, I tried to add zsync to Jenkins artifacts download, but found zsync cannot authenticate with Jenkins due to a limitation [1]. However, wget can download with option "--auth-no-challenge". So here I request to add similar option to zsync client as well. Thanks! [1] https://www.jenkins.io/doc/book/system-administration/authenticating-scripted-clients -- System Information: Debian Release: 10.8 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64)
Bug#915762: Port to Hurd
https://www.gnu.org/software/hurd/public_hurd_boxen.html hurd has the porterbox: exodar.debian.net
Bug#963058: android-platform-art ftbfs on arm64
control: forwarded -1 https://bugs.llvm.org/show_bug.cgi?id=41504 > runtime/interpreter/mterp/out/mterp_arm64.S > runtime/interpreter/mterp/out/mterp_arm64.S:392:23: error: expected > '[su]xt[bhw]' with optional integer in range [0, 4] > add x25, x21, w0, lsl #2 > ^ same code was built OK on 8.1.0+r23-3, but failed on 8.1.0+r23-4 [1]. So actually it's caused by update of clang. I also found the ticket of clang [2], and upstream android actually already had the fix [3]. [1] https://buildd.debian.org/status/logs.php?pkg=android-platform-art=arm64 [2] https://bugs.llvm.org/show_bug.cgi?id=41504 [3] https://android-review.googlesource.com/c/platform/art/+/940018 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#977019: ITP: golang-golang-x-term -- Go terminal and console support
On Thu, Dec 10, 2020 at 2:18 PM Arnaud Rebillout wrote: > > * Package name: golang-golang-x-term > Version : 0.0~git20201207.ee85cb9-1 > Upstream Author : Go > * URL : https://github.com/golang/term > > Why packaging: this is a new build dependency of docker.io 20.10.0 Seems this is also a new dependency for golang-go.crypto package. Have you packaged anything? or already near upload? Thanks! -- Roger Shimizu, GMT +9 Tokyo PGP/GPG: 4096R/6C6ACD6417B3ACB1
Bug#976337: ITP: golang-github-josharian-intern -- Intern string golang library
Package: wnpp Severity: wishlist Owner: Roger Shimizu * Package name: golang-github-josharian-intern Version : 1.0.0-1 Upstream Author : Josh Bleecher Snyder * URL : https://github.com/josharian/intern * License : Expat Programming Lang: Go Description : Intern string golang library
Bug#975976: ITP: xperia-flashtool -- flashtool for xperia devices
Package: wnpp Severity: wishlist Owner: Roger Shimizu * Package name: xperia-flashtool Version : 0.9.31 Upstream Author : Androxyde * URL : https://github.com/Androxyde/Flashtool * License : GPL-3+, GPL-2+, Apache-2.0, EPL-1.0 and CPL-1.0 Programming Lang: Java Description : flashtool for xperia devices
Bug#975971: ITP: jbbp -- comfortable way to work with binary data in Java
Package: wnpp Severity: wishlist Owner: Roger Shimizu * Package name: jbbp Version : 2.0.2 Upstream Author : Igor Maznitsa * URL : https://github.com/raydac/java-binary-block-parser * License : Apache-2.0 Programming Lang: Java Description : comfortable way to work with binary data in Java
Bug#975964: ITP: uber-pom -- merging maven pom hierarchy parameters
Package: wnpp Severity: wishlist Owner: Roger Shimizu * Package name: uber-pom Version : 1.0.3 Upstream Author : Igor Maznitsa * URL : https://github.com/raydac/uber-pom * License : Apache-2.0 Programming Lang: Java Description : UberPom - merging maven pom hierarchy parameters
Bug#975960: ITP: apk-parser -- Decode binary XML files and get APK meta info
Package: wnpp Severity: wishlist Owner: Roger Shimizu * Package name: apk-parser Version : 2.6.10 Upstream Author : Liu Dong * URL : https://github.com/hsiafan/apk-parser * License : BSD-2-clause and Apache-2.0 Programming Lang: Java Description : Decode binary XML files and get APK meta info
