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#1066028: apt upgrade /apt-key manual page inconsistency
Package: apt Version: 2.6.1 Severity: important Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I'm installing a package. Instructions told me to run apt update When I did so, there was an error message. * What exactly did you do (or not do) that was effective (or ineffective)? I did NOT use the apt-key commandline. * What was the outcome of this action? I was told by apt update to see the apt-key manual page under DEPRICATED for information on how to proceed with this situation. I did so and was told to replace something I didn't type with something I don't need. As said before: I never used the apt-key commandline. I just got the message from apt update. * What outcome did you expect instead? I expected at least some clear information on how to proceed. Windows users apparently know that when you get an error message "Router didnot issue an IP addresss" that something entirely different is going on. I'm a stupid Linux user. I expect error messages to point me in the right direction. (i.e. "permission denied" when that's the case and not "directory doesn't exist or .. or ... (nothing about permissions). -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "armhf"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "1"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "tasks"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Architectures ""; APT::Architectures:: "armhf"; APT::Architectures:: "arm64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "zstd"; APT::Compressor::zstd::Cost "60"; APT::Compressor::zstd::CompressArg ""; APT::Compressor::zstd::CompressArg:: "-19"; APT::Compressor::zstd::UncompressArg ""; APT::Compressor::zstd::UncompressArg:: "-d"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg ""; APT::Compressor::lzma::UncompressArg:: "--format=lzma"; APT::Compressor::lzma::UncompressArg:: "-d"; Dir "/"; Dir::State "var/lib/apt"; Dir::State::lists "lists/"; Dir::State::cdroms "cdroms.list"; Dir::State::extended_states "extended_states"; Dir::State::status "/var/lib/dpkg/status"; Dir::Cache "var/cache/apt"; Dir::Cache::archives "archives/"; Dir::Cache::srcpkgcache "srcpkgcache.bin"; Dir::Cache::pkgcache "pkgcache.bin"; Dir::Etc "etc/apt"; Dir::Etc::sourcelist "sources.list"; Dir::Etc::sourceparts "sources.list.d"; Dir::Etc::main "apt.conf"; Dir::Etc::netrc "auth.conf"; Dir::Etc::netrcparts "auth.conf.d"; Dir::Etc::parts "apt.conf.d"; Dir::Etc::preferences "preferences";
Bug#1065674: bugs.debian.org: Disable Shutdown Beep
Package: bugs.debian.org Severity: minor X-Debbugs-Cc: slow_sp...@att.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? Every time I select Applications
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#1050283: Warning: unsandboxed permission
Package: apt Version: 2.2.4 Severity: normal Tags: upstream X-Debbugs-Cc: slow_sp...@att.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** When using Synaptic, the following error pops up: W: Download is performed unsandboxed as root as file '/root/.synaptic/tmp//tmp_sh' couldn't be accessed by user '_apt'. - pkgAcquire::Run (13: Permission denied) This is a bothersome problem and probably should be fixed. Please see: https://askubuntu.com/questions/908800/what-does-this-apt-error- message-download-is-performed-unsandboxed-as-root#908825 *** End of the template - remove these template lines *** -- Package-specific info: -- apt-config dump -- APT ""; APT::Architecture "amd64"; APT::Build-Essential ""; APT::Build-Essential:: "build-essential"; APT::Install-Recommends "true"; APT::Install-Suggests "0"; APT::Sandbox ""; APT::Sandbox::User "_apt"; APT::Authentication ""; APT::Authentication::TrustCDROM "true"; APT::NeverAutoRemove ""; APT::NeverAutoRemove:: "^firmware-linux.*"; APT::NeverAutoRemove:: "^linux-firmware$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*$"; APT::NeverAutoRemove:: "^linux-image-[a-z0-9]*-[a-z0-9]*$"; APT::NeverAutoRemove:: "^postgresql-"; APT::VersionedKernelPackages ""; APT::VersionedKernelPackages:: "linux-.*"; APT::VersionedKernelPackages:: "kfreebsd-.*"; APT::VersionedKernelPackages:: "gnumach-.*"; APT::VersionedKernelPackages:: ".*-modules"; APT::VersionedKernelPackages:: ".*-kernel"; APT::Never-MarkAuto-Sections ""; APT::Never-MarkAuto-Sections:: "metapackages"; APT::Never-MarkAuto-Sections:: "contrib/metapackages"; APT::Never-MarkAuto-Sections:: "non-free/metapackages"; APT::Never-MarkAuto-Sections:: "restricted/metapackages"; APT::Never-MarkAuto-Sections:: "universe/metapackages"; APT::Never-MarkAuto-Sections:: "multiverse/metapackages"; APT::Move-Autobit-Sections ""; APT::Move-Autobit-Sections:: "oldlibs"; APT::Move-Autobit-Sections:: "contrib/oldlibs"; APT::Move-Autobit-Sections:: "non-free/oldlibs"; APT::Move-Autobit-Sections:: "restricted/oldlibs"; APT::Move-Autobit-Sections:: "universe/oldlibs"; APT::Move-Autobit-Sections:: "multiverse/oldlibs"; APT::LastInstalledKernel "5.10.0-25-amd64"; APT::Periodic ""; APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Download-Upgradeable-Packages "0"; APT::Periodic::AutocleanInterval "0"; APT::Periodic::Unattended-Upgrade "0"; APT::Update ""; APT::Update::Post-Invoke-Success ""; APT::Update::Post-Invoke-Success:: "/usr/bin/test -e /usr/share/dbus-1/system-services/org.freedesktop.PackageKit.service && /usr/bin/test -S /var/run/dbus/system_bus_socket && /usr/bin/gdbus call --system --dest org.freedesktop.PackageKit --object-path /org/freedesktop/PackageKit --timeout 4 --method org.freedesktop.PackageKit.StateHasChanged cache-update > /dev/null; /bin/echo > /dev/null"; APT::Update::Post-Invoke-Success:: "if /usr/bin/test -w /var/cache/app-info -a -e /usr/bin/appstreamcli; then appstreamcli refresh-cache > /dev/null || true; fi"; APT::Architectures ""; APT::Architectures:: "amd64"; APT::Compressor ""; APT::Compressor::. ""; APT::Compressor::.::Name "."; APT::Compressor::.::Extension ""; APT::Compressor::.::Binary ""; APT::Compressor::.::Cost "0"; APT::Compressor::zstd ""; APT::Compressor::zstd::Name "zstd"; APT::Compressor::zstd::Extension ".zst"; APT::Compressor::zstd::Binary "false"; APT::Compressor::zstd::Cost "60"; APT::Compressor::lz4 ""; APT::Compressor::lz4::Name "lz4"; APT::Compressor::lz4::Extension ".lz4"; APT::Compressor::lz4::Binary "false"; APT::Compressor::lz4::Cost "50"; APT::Compressor::gzip ""; APT::Compressor::gzip::Name "gzip"; APT::Compressor::gzip::Extension ".gz"; APT::Compressor::gzip::Binary "gzip"; APT::Compressor::gzip::Cost "100"; APT::Compressor::gzip::CompressArg ""; APT::Compressor::gzip::CompressArg:: "-6n"; APT::Compressor::gzip::UncompressArg ""; APT::Compressor::gzip::UncompressArg:: "-d"; APT::Compressor::xz ""; APT::Compressor::xz::Name "xz"; APT::Compressor::xz::Extension ".xz"; APT::Compressor::xz::Binary "xz"; APT::Compressor::xz::Cost "200"; APT::Compressor::xz::CompressArg ""; APT::Compressor::xz::CompressArg:: "-6"; APT::Compressor::xz::UncompressArg ""; APT::Compressor::xz::UncompressArg:: "-d"; APT::Compressor::bzip2 ""; APT::Compressor::bzip2::Name "bzip2"; APT::Compressor::bzip2::Extension ".bz2"; APT::Compressor::bzip2::Binary "bzip2"; APT::Compressor::bzip2::Cost "300"; APT::Compressor::bzip2::CompressArg ""; APT::Compressor::bzip2::CompressArg:: "-6"; APT::Compressor::bzip2::UncompressArg ""; APT::Compressor::bzip2::UncompressArg:: "-d"; APT::Compressor::lzma ""; APT::Compressor::lzma::Name "lzma"; APT::Compressor::lzma::Extension ".lzma"; APT::Compressor::lzma::Binary "xz"; APT::Compressor::lzma::Cost "400"; APT::Compressor::lzma::CompressArg ""; APT::Compressor::lzma::CompressArg:: "--format=lzma"; APT::Compressor::lzma::CompressArg:: "-6"; APT::Compressor::lzma::UncompressArg "";
Bug#1049438: r-cran-rgdal: autopkgtest needs update for new version of r-cran-sp
Dear Andreas,
Further, it looks as though r-cran-sf is not available at the point of failure,
but may reading of your output may be guesswork. Are you turning warnings into
errors? Locally, I cannot reproduce the problem with sf available for sp 2.0-0;
when sf is not available, I do see problems (but more extensive than yours).
Hope this helps,
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
From: Roger Bivand
Sent: 18 August 2023 14:54
To: Andreas Tille; Paul Gevers; 1049...@bugs.debian.org; Edzer Pebesma
Cc: Debian R
Subject: Re: Bug#1049438: r-cran-rgdal: autopkgtest needs update for new
version of r-cran-sp
Dear Andreas,
No idea, but note that rgdal, rgeos, maptools and rgrass7 will be archived in
October 2023.
This has been drawn to the attention of those interested on mailing lists since
late 2022: https://github.com/r-spatial/evolution,
https://r-spatial.org/r/2022/04/12/evolution.html,
https://r-spatial.org/r/2022/12/14/evolution2.html, etc.
sp 2.0-0 by default uses sf, not rgdal, for all CRS and transformation, unless
somehow you are setting an environment variable or an R option to look for
rgdal instead. This option will stop working by the end of September 2023.
So the interaction you are seeing, but which I can't reproduce, is from your
build of sf with your build of PROJ and GDAL in conjuction with the new
default settings of sp to use sf not rgdal.
So no updates to rgdal are going to be forthcoming, and your build system will
have to move now very quickly to catch up with impending changes. rgdal will be
leaving CRAN in about six weeks, you may move to forthcoming sp 2.1-0 which
drops rgdal completely if that is easier.
Best wishes,
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
From: Andreas Tille
Sent: 18 August 2023 13:58
To: Paul Gevers; 1049...@bugs.debian.org; Roger Bivand
Cc: Debian R
Subject: Re: Bug#1049438: r-cran-rgdal: autopkgtest needs update for new
version of r-cran-sp
Control: tags -1 upstream
Control: forwarded -1 Roger Bivand
Hi Roger,
the CI tests in Debian uncovered some conflict between recent rgdal and
version 2.0 of sp. As you either can see in the bug report that was
filed[1] or in a recent CI build log[2] it fails with
In CRS("+init=epsg:4326") :> sp.tr <- spTransform(sp, CRS("+init=epsg:3857"))
sf required for evolution_status==2L
Error in spTransform(sp, CRS("+init=epsg:3857")) :
source crs creation failed: Invalid PROJ string syntax
Calls: spTransform -> spTransform
It would be great if you could adapt rgdal to the latest version of sp.
Kind regards
Andreas.
[1] https://bugs.debian.org/1049438
[2] https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/jobs/4562837#L790
--
http://fam-tille.de/
Bug#1049438: r-cran-rgdal: autopkgtest needs update for new version of r-cran-sp
Dear Andreas,
No idea, but note that rgdal, rgeos, maptools and rgrass7 will be archived in
October 2023.
This has been drawn to the attention of those interested on mailing lists since
late 2022: https://github.com/r-spatial/evolution,
https://r-spatial.org/r/2022/04/12/evolution.html,
https://r-spatial.org/r/2022/12/14/evolution2.html, etc.
sp 2.0-0 by default uses sf, not rgdal, for all CRS and transformation, unless
somehow you are setting an environment variable or an R option to look for
rgdal instead. This option will stop working by the end of September 2023.
So the interaction you are seeing, but which I can't reproduce, is from your
build of sf with your build of PROJ and GDAL in conjuction with the new
default settings of sp to use sf not rgdal.
So no updates to rgdal are going to be forthcoming, and your build system will
have to move now very quickly to catch up with impending changes. rgdal will be
leaving CRAN in about six weeks, you may move to forthcoming sp 2.1-0 which
drops rgdal completely if that is easier.
Best wishes,
Roger
--
Roger Bivand
Emeritus Professor
Norwegian School of Economics
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway
roger.biv...@nhh.no
From: Andreas Tille
Sent: 18 August 2023 13:58
To: Paul Gevers; 1049...@bugs.debian.org; Roger Bivand
Cc: Debian R
Subject: Re: Bug#1049438: r-cran-rgdal: autopkgtest needs update for new
version of r-cran-sp
Control: tags -1 upstream
Control: forwarded -1 Roger Bivand
Hi Roger,
the CI tests in Debian uncovered some conflict between recent rgdal and
version 2.0 of sp. As you either can see in the bug report that was
filed[1] or in a recent CI build log[2] it fails with
In CRS("+init=epsg:4326") :> sp.tr <- spTransform(sp, CRS("+init=epsg:3857"))
sf required for evolution_status==2L
Error in spTransform(sp, CRS("+init=epsg:3857")) :
source crs creation failed: Invalid PROJ string syntax
Calls: spTransform -> spTransform
It would be great if you could adapt rgdal to the latest version of sp.
Kind regards
Andreas.
[1] https://bugs.debian.org/1049438
[2] https://salsa.debian.org/r-pkg-team/r-cran-rgdal/-/jobs/4562837#L790
--
http://fam-tille.de/
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#1038892: thunderbird: Crashes on startup, "Exiting due to channel error."
Package: thunderbird Version: 1:102.12.0-1 Severity: grave Justification: renders package unusable Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** On starting, thunderbird exits with the last line of "Exiting due to channel error.": $ thunderbird --verbose INFO -> [[ ... using verbose mode ... ]] DEBUG -> call '/usr/lib/thunderbird/thunderbird ' ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ATTENTION: default value of option mesa_glthread overridden by environment. ExceptionHandler::GenerateDump cloned child 9079 ExceptionHandler::SendContinueSignalToChild sent continue signal to child ExceptionHandler::WaitForContinueSignal waiting for continue signal... Exiting due to channel error. $ I have tried changing profiles through the profile manager as well as completely removing the .thunderbird directory (copying to .thunderbird.old and then restarting) but the crash remains. The result is the same starting in safe mode. I can't find the debug symbols to attempt further debugging. Let me know if there is more information I can give you. Thank you! roger -- System Information: Debian Release: trixie/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.3.0-1-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages thunderbird depends on: ii debianutils 5.7-0.4 ii fontconfig 2.14.1-4 ii kdialog 4:22.12.3-1 ii libasound2 1.2.9-1 ii libatk1.0-0 2.48.3-1 ii libc62.36-9 ii libcairo-gobject21.16.0-7 ii libcairo21.16.0-7 ii libdbus-1-3 1.14.8-1 ii libdbus-glib-1-2 0.112-3 ii libevent-2.1-7 2.1.12-stable-8 ii libffi8 3.4.4-1 ii libfontconfig1 2.14.1-4 ii libfreetype6 2.12.1+dfsg-5 ii libgcc-s113.1.0-6 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-1+b1 ii libglib2.0-0 2.74.6-2 ii libgtk-3-0 3.24.37-2 ii libicu72 72.1-3 ii libnspr4 2:4.35-1.1 ii libnss3 2:3.90-2 ii libotr5 4.1.1-5 ii libpango-1.0-0 1.50.14+ds-1 ii librnp0 0.16.3-1 ii libstdc++6 13.1.0-6 ii libvpx7 1.12.0-1 ii libx11-6 2:1.8.6-1 ii libx11-xcb1 2:1.8.6-1 ii libxcb-shm0 1.15-1 ii libxcb1 1.15-1 ii libxext6 2:1.3.4-1+b1 ii libxrandr2 2:1.5.2-2+b1 ii psmisc 23.6-1 ii x11-utils7.7+5 ii zenity 3.44.0-1 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages thunderbird recommends: ii hunspell-en-us [hunspell-dictionary] 1:2020.12.07-2 Versions of packages thunderbird suggests: ii apparmor 3.0.8-3 ii fonts-lyx 2.3.7-1 ii libgssapi-krb5-2 1.20.1-2 -- no debconf information
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#1035904: dpkg currently warning about merged-usr systems (revisited)
On 15/05/2023 19:00, Simon McVittie wrote: > On Sun, 14 May 2023 at 23:37:34 +0200, Josh Triplett wrote: >> People build things on Debian that are not Debian packages. People >> compile binaries on Debian, and expect them to work on any system that >> has sufficiently new libraries. > > *raises hand* > > Hello, I represent an example of those people. With my $work hat on, > I'm involved in maintaining a family of Debian derivatives (the Steam > Runtime) that is used to run Steam games on arbitrary distributions, > including but not limited to Debian. Some of these binaries are built > on a Debian derivative, but run on an arbitrary other distribution, > using a RPATH[1] to find their non-glibc dependencies. As another much smaller example, which I hope is still relevant, I have taken binaries from Debian stable or oldstable armel and run them for diagnostic purposes on embedded boards which only have Busybox installed and for which I don't have a convenient build environment. Regards, Roger PS Apologies if I've followed up incorrectly - I read debian-devel through an NNTP gateway.
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#1034419: bugs.debian.org: Printing Fails To Allow 0.0" Margins
Package: bugs.debian.org Severity: important X-Debbugs-Cc: slow_sp...@att.net Dear Maintainer, * What led up to the situation? Tried to print borderless (full-bleed) in various programs, but print dialog always has minimal border.
Bug#1032029: mosquitto ignores ip address for websocket listeners
Unfortunately this was marked as spam, so I didn't see it.
The attached patch will deny the use of listener bind addresses for
websockets listeners. I also note that using a more recent version of
libwebsockets does not display the same problem.
Regards,
Roger
On Sun, 26 Feb 2023 at 19:39, Helmut Grohne wrote:
> Package: mosquitto
> Version: 2.0.11-1
> Severity: serious
> Tags: security
> X-Debbugs-Cc: Debian Security Team
>
> If you configure a websocket listener for mosquitto with an IP address
> to bind to, mosquitto will instead bind the wildcard address. This
> renders a secure configuration insecure.
>
> A simple configuration producing this behaviour is a default
> installation together with one config update:
>
> $ cat /etc/mosquitto/conf.d/listen.conf
> bind_address localhost
> listener 9001 127.0.0.1
> protocol websockets
> $
>
> If you (re)start mosquitto, you can see the insecure bind:
>
> $ ss -tlp
> ...
> LISTEN0 4096 *:9001 *:*
> users:(("mosquitto",pid=269,fd=7))
> ...
> $
>
> The mosquitto.conf manual page in section 5 says that for websockets,
> you can only give an IP address as bind address, which kinda implies
> that you can given an IP address there. I think it is a reasonable
> expectation that binding to 127.0.0.1 should be secure.
>
> I am filing this as severity serious, because normally a security
> vulnerability would be grave, but this vulnerability only surfaces in a
> (possibly common) non-default configuration. Hence lowering to serious.
>
> I note (mostly for myself) that the following invocation reproduces the
> problem:
>
> debvm-create -- --include iproute2,mosquitto --customize-hook='printf
> "bind_address localhost\\nlistener 9001 127.0.0.1\\nprotocol websockets\\n"
> > "$1/etc/mosquitto/conf.d/listen.conf"'
>
> Helmut
>
diff --git a/src/conf.c b/src/conf.c
index 592ea9796..046ccefb5 100644
--- a/src/conf.c
+++ b/src/conf.c
@@ -1837,6 +1837,10 @@ static int config__read_file_core(struct mosquitto__config *config, bool reload,
*/
}else if(!strcmp(token, "websockets")){
#ifdef WITH_WEBSOCKETS
+ if(cur_listener->host){
+log__printf(NULL, MOSQ_LOG_ERR, "Error: Websockets does not allow a listener bind address.");
+return MOSQ_ERR_INVAL;
+ }
cur_listener->protocol = mp_websockets;
#else
log__printf(NULL, MOSQ_LOG_ERR, "Error: Websockets support not available.");
Bug#1031320: bugs.debian.org: Scanner Programs Are Slow To Find USB Scanner
Package: bugs.debian.org Severity: normal X-Debbugs-Cc: slow_sp...@att.net Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I turn on the multifunction printer with scanner. I start a scanner program. I wait upwards of 90 seconds for it to find the scanner. * What exactly did you do (or not do) that was effective (or ineffective)? Tried different programs, and all have the same timeout issue. * What was the outcome of this action? * What outcome did you expect instead? Should immediately find the scanner that is turned on and waiting. *** End of the template - remove these template lines ***
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#1027034: simple-scan: Too slow to find scanners.
Package: simple-scan Version: 3.38.1-1 Severity: important X-Debbugs-Cc: slow_sp...@att.net The programmer states that this is an old version and so they cannot diagnose the problem. Dear Maintainer, *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? * What exactly did you do (or not do) that was effective (or ineffective)? * What was the outcome of this action? * What outcome did you expect instead? *** End of the template - remove these template lines *** -- Package-specific info: -- System Information: Debian Release: 11.6 APT prefers stable APT policy: (700, 'stable'), (500, 'stable-updates'), (500, 'stable-security') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-20-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages simple-scan depends on: ii dbus-user-session [default-dbus-session-bus] 1.12.24-0+deb11u1 ii dbus-x11 [dbus-session-bus] 1.12.24-0+deb11u1 ii dconf-gsettings-backend [gsettings-backend] 0.38.0-2 ii libc6 2.31-13+deb11u5 ii libcairo2 1.16.0-5 ii libcolord21.4.5-3 ii libgdk-pixbuf2.0-02.40.2-2 ii libglib2.0-0 2.66.8-1 ii libgtk-3-03.24.24-4+deb11u2 ii libgusb2 0.3.5-1 ii libpackagekit-glib2-181.2.2-2 ii libsane1 1.0.31-4.1 ii libwebp6 0.6.1-2.1 ii libwebpmux3 0.6.1-2.1 ii xdg-utils 1.1.3-4.1 ii zlib1g1:1.2.11.dfsg-2+deb11u2 simple-scan recommends no packages. simple-scan suggests no packages. -- no debconf information
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#1021531: patch for Debian stable
Attached the patch for Debian stable, please let me know if I should
create an MR towards
https://salsa.debian.org/gnome-team/evolution-ews/-/tree/debian/3.38.3-1
From b1ef96f7daee840c4695a3ffccb3ea843cbd8068 Mon Sep 17 00:00:00 2001
From: Roger Meier
Date: Mon, 13 Sep 2021 16:32:02 +0200
Subject: [PATCH] Contacts: Retrieve user S/MIME certificate
see https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3
---
src/EWS/addressbook/e-book-backend-ews.c | 335 +--
src/EWS/addressbook/ews-oab-decoder.c| 54 +++-
src/EWS/common/e-ews-connection.c| 8 +-
src/EWS/common/e-ews-item.c | 65 +
src/EWS/common/e-ews-item.h | 5 +
5 files changed, 431 insertions(+), 36 deletions(-)
diff --git a/src/EWS/addressbook/e-book-backend-ews.c b/src/EWS/addressbook/e-book-backend-ews.c
index 197d49fd..9bf75100 100644
--- a/src/EWS/addressbook/e-book-backend-ews.c
+++ b/src/EWS/addressbook/e-book-backend-ews.c
@@ -60,6 +60,10 @@
#define X_EWS_CHANGEKEY "X-EWS-CHANGEKEY"
#define X_EWS_GAL_SHA1 "X-EWS-GAL-SHA1"
#define X_EWS_PHOTO_CHECK_DATE "X-EWS-PHOTO-CHECK-DATE" /* MMDD of the last check for photo */
+#define X_EWS_CERT_KIND "X-EWS-CERT-KIND"
+
+#define E_EWS_CERT_KIND_USER "UserSMIMECertificate"
+#define E_EWS_CERT_KIND_MSEX "MSExchangeCertificate"
#define EWS_MAX_FETCH_COUNT 500
@@ -69,7 +73,19 @@
/* passing field uris for PhysicalAddress, PhoneNumbers causes error, so we
* use Default view to fetch them. Thus the summary props just have attachments
* and some additional properties that are not return with Default view */
-#define CONTACT_ITEM_PROPS "item:Attachments item:HasAttachments item:Body item:LastModifiedTime contacts:Manager contacts:Department contacts:SpouseName contacts:AssistantName contacts:BusinessHomePage contacts:Birthday"
+#define CONTACT_ITEM_PROPS "item:Attachments "\
+ "item:HasAttachments "\
+ "item:Body "\
+ "item:LastModifiedTime "\
+ "contacts:Manager "\
+ "contacts:Department "\
+ "contacts:SpouseName "\
+ "contacts:AssistantName "\
+ "contacts:BusinessHomePage "\
+ "contacts:Birthday"
+#define CONTACT_ITEM_PROPS_10SP2 CONTACT_ITEM_PROPS " "\
+ "contacts:UserSMIMECertificate "\
+ "contacts:MSExchangeCertificate"
struct _EBookBackendEwsPrivate {
GRecMutex cnc_lock;
@@ -551,6 +567,238 @@ ebews_populate_photo (EBookBackendEws *bbews,
e_contact_photo_free (photo);
}
+static void
+ebews_populate_cert (EBookBackendEws *bbews,
+ EContact *contact,
+ EEwsItem *item,
+ const gchar *kind,
+ GCancellable *cancellable,
+ GError **error)
+{
+ EVCardAttribute *attr;
+ EContactCert cert;
+
+ g_return_if_fail (g_str_equal (kind, E_EWS_CERT_KIND_USER) || g_str_equal (kind, E_EWS_CERT_KIND_MSEX));
+
+ /* Support for certificates was added in Exchange 2010 SP2. */
+ if (!e_ews_connection_satisfies_server_version (bbews->priv->cnc, E_EWS_EXCHANGE_2010_SP2))
+ return;
+
+ if (g_str_equal (kind, E_EWS_CERT_KIND_USER))
+ cert.data = (gchar *) e_ews_item_get_user_certificate (item, );
+ else
+ cert.data = (gchar *) e_ews_item_get_msexchange_certificate (item, );
+
+ if (!cert.data || !cert.length)
+ return;
+
+ attr = e_vcard_attribute_new (NULL, EVC_KEY);
+
+ e_vcard_append_attribute (E_VCARD (contact), attr);
+
+ e_vcard_attribute_add_param_with_value (
+ attr,
+ e_vcard_attribute_param_new (EVC_TYPE),
+ "X509");
+
+ e_vcard_attribute_add_param_with_value (
+ attr,
+ e_vcard_attribute_param_new (EVC_ENCODING),
+ "b");
+
+ e_vcard_attribute_add_param_with_value (
+ attr,
+ e_vcard_attribute_param_new (X_EWS_CERT_KIND),
+ kind);
+
+ e_vcard_attribute_add_value_decoded (attr, cert.data, cert.length);
+}
+
+static void
+ebews_populate_user_cert (EBookBackendEws *bbews,
+ EContact *contact,
+ EEwsItem *item,
+ GCancellable *cancellable,
+ GError **error)
+{
+ ebews_populate_cert (bbews, contact, item, E_EWS_CERT_KIND_USER, cancellable, error);
+}
+
+static void
+ebews_populate_msex_cert (EBookBackendEws *bbews,
+ EContact *contact,
+ EEwsItem *item,
+ GCancellable *cancellable,
+ GError **error)
+{
+ ebews_populate_cert (bbews, contact, item, E_EWS_CERT_KIND_MSEX, cancellable, error);
+}
+
+static EVCardAttribute *
+ebews_find_cert_attribute (EContact *contact,
+ const gchar *kind,
+ gint fallback_index)
+{
+ GList *link;
+ EVCardAttribute *fallback_attr = NULL;
+
+ for (link = e_vcard_get_attributes (E_VCARD (contact)); link; link = g_list_next (link)) {
+ EVCardAttribute *attr = link->data;
+ const gchar *attr_name;
+
+ attr_name = e_vcard_attribute_get_name (attr);
+
+ if (attr_name && g_ascii_strcasecmp (attr_name, EVC_KEY) == 0) {
+ GList *
Bug#1021531: Contacts: retrieve user S/MIME certificates patch was not applied on stable
Package: evolution-ews Version: 3.38.3-1 Followup-For: Bug #994252 X-Debbugs-Cc: r.me...@siemens.com Dear Maintainer, On Debian stable the S/MIME certificates can not be retrieved. This has been fixed for testing and unstable as they ship a more recent version of evolution-ews. However, the patch is not yet applied as suggested within #994252 It would be awesome if that patch could be applied for the stable package as well. Further Information: - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994252 - https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3 -- System Information: Debian Release: 11.5 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-18-amd64 (SMP w/8 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages evolution-ews depends on: ii evolution3.38.3-1 ii evolution-data-server3.38.3-1 ii libc62.31-13+deb11u4 ii libcamel-1.2-62 3.38.3-1 ii libebackend-1.2-10 3.38.3-1 ii libebook-1.2-20 3.38.3-1 ii libebook-contacts-1.2-3 3.38.3-1 ii libecal-2.0-13.38.3-1 ii libedata-book-1.2-26 3.38.3-1 ii libedata-cal-2.0-1 3.38.3-1 ii libedataserver-1.2-253.38.3-1 ii libedataserverui-1.2-2 3.38.3-1 ii libevolution 3.38.3-1 ii libglib2.0-0 2.66.8-1 ii libgtk-3-0 3.24.24-4+deb11u2 ii libical3 3.0.9-2 ii libjson-glib-1.0-0 1.6.2-1 ii libmspack0 0.10.1-2 ii libpango-1.0-0 1.46.2-3 ii libsoup2.4-1 2.72.0-2 ii libxml2 2.9.10+dfsg-6.7+deb11u2 evolution-ews recommends no packages. evolution-ews suggests no packages. -- no debconf information
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#1011228: Questions hold up upgrades.
Package: apt Version: apt 2.4.5 (amd64) Severity: wishlist I was upgrading my system and expected the upgrade to take about an hour. So after the initial questions at the start I went off to do other things. When I came back there was a new question about some file I had modified. IMHO it should be easy to make a dependency graph of the upgrade. Need to fetch packageX before I can unpack packageX and need to unpack packageX before I can run the install scripts for packageX. And: dependencies dictate that packageX is installed for packageY. So we better finish installing packageX before we (unpack or run the install script. Some thought will need to go into which one is required) pacakgeY. (maybe unpacking can already be done before we've run the install script). Now things are possible, like "start installing when the download of "later" packages is still in progress. And: move the questions all to the end instead of having them happen somewhere in the middle of a long install/upgraded. That more-or-less automatically happens if you continue to install unrelated stuff should a question be asked. Possibly: for testing: you might write out the dependency tree as a Makefile. all: installed_packageX installed_packageX: unpacked_packageX run_installscript packageX unpacked_packageX: fetched_packageX unpacack packageX fetched_packageX: fetch packageX installed_packageY: installed_packageX unpacked_packageY run_installscript packageY unpacked_packageY: fetched_packageY unpacack packageY fetched_packageY: fetch packageY Running make will now intermixing fetching and installing whatever can be installed. Adding -j 5 will allow overlap between the different tasks, but fetching multiple packages at once may be counter-productive (although... from different sites, that is already done atm, right?) But if one task gets "stuck" asking for a question, 4 other threads can continue to fetch, unpack and install packages that are not related. For final version. I do think that you need to handle the dependencies and parallelism inside apt. There should be a single "asking questions" thread, and I don't know a good way to teach that to Make wile still allowing parallelism on other stuff.
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#1009911: RM: elog -- ROM; No active maintainership, insecure version in Debian
Package:ftp.debian.org Severity: normal I think elog should be removed from Debian. There are several open CVEs for the elog package in Debian. These are resolved in the most recent upstream version of elog. But since there is no active maintainership, it is better to remove the outdated and insecure version of elog from Debian.
Bug#1008708: pysolfc: After installing python3.10, pysolfc cannot start
Package: pysolfc Version: 2.6.4-3 Severity: grave Tags: newcomer Justification: renders package unusable Dear Maintainer, 1. Attempted to start pysolfc through the menus; it failed to start. 2. Attempted to start from the command line; it failed to start with the following messaging: $ pysolfc Traceback (most recent call last): File "/usr/games/pysolfc", line 36, in from pysollib.main import main # noqa: E402,I202 File "/usr/share/games/pysolfc/pysollib/main.py", line 30, in from pysollib.app import Application File "/usr/share/games/pysolfc/pysollib/app.py", line 32, in from pysollib.images import Images, SubsampledImages File "/usr/share/games/pysolfc/pysollib/images.py", line 28, in from pysollib.pysoltk import copyImage, createBottom, createImage, loadImage File "/usr/share/games/pysolfc/pysollib/pysoltk.py", line 35, in from pysollib.tile.tkhtml import * # noqa: F401,F403 File "/usr/share/games/pysolfc/pysollib/tile/tkhtml.py", line 29, in from pysollib.ui.tktile.tkhtml import Base_HTMLViewer File "/usr/share/games/pysolfc/pysollib/ui/tktile/tkhtml.py", line 24, in import formatter ModuleNotFoundError: No module named 'formatter' $ Expected result is that the game starts. After researching, I came across https://github.com/shlomif/PySolFC/issues/217 and https://github.com/shlomif/PySolFC/pull/218, which: a) explained that the formatter module was deprecated in Python 3.4 and removed in 3.10, and b) fixed the issue upstream in PySolFC version 2.14, released September 9, 2021. I believe the best fix is to import the newest version of pysolfc to the Debian ecosystem. -- System Information: Debian Release: bookworm/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages pysolfc depends on: ii python33.10.4-1 ii python3-configobj 5.0.6-5 ii python3-pygame 2.1.2+dfsg-3 ii python3-random21.0.1-2.1 ii python3-six1.16.0-3 ii python3-tk 3.9.12-1 Versions of packages pysolfc recommends: ii python3-pil.imagetk 9.0.1-1 Versions of packages pysolfc suggests: ii freecell-solver-bin 5.0.0-2+b1 ii pysolfc-cardsets 2.0+dfsg2-2.1 -- no debconf information
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#994582: deluge-gtk: Deluge-GTK will only start in Thin mode
Package: deluge-common Version: 2.0.3-3.1 Followup-For: Bug #994582 X-Debbugs-Cc: gulien.ro...@gmail.com Dear Maintainer, It seems that this bug is due to an incompatibility with deluge 2.0.3 and python3.8 and newer. This bug is already "fixed" in deluge git since 2019. It would be nice to cherry pick this commit in order to have a working deluge in bullseye. https://git.deluge- torrent.org/deluge/commit/?h=develop=351664ec071daa04161577c6a1c949ed0f2c3206 Thanks's -- System Information: Debian Release: 11.1 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable'), (100, 'bullseye-fasttrack') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-9-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_FR.UTF8, LC_CTYPE=fr_FR.UTF8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages deluge-common depends on: ii python3 3.9.2-3 ii python3-chardet 4.0.0-1 ii python3-mako1.1.3+ds1-2 ii python3-openssl 20.0.1-1 ii python3-pil 8.1.2+dfsg-0.3 ii python3-pkg-resources 52.0.0-4 ii python3-pyasn1 0.4.8-1 ii python3-rencode 1.0.6-1+b3 ii python3-setproctitle1.2.1-1+b1 ii python3-six 1.16.0-2 ii python3-twisted 20.3.0-7 ii python3-xdg 0.27-2 ii python3-zope.interface 5.2.0-1 Versions of packages deluge-common recommends: ii geoip-database 20191224-3 ii python3-dbus1.2.16-5 pn python3-geoip deluge-common suggests no packages.
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#947771: unbound: cannot restart daemon under sysvinit-core when apparmor is enforced
Followup-For: Bug #947771 Package: unbound Version: 1.13.1-1 On Fri, 03 Jul 2020 19:27:17 +0900 Stephane Lapie wrote: I worked around this issue by adding --remove-pidfile to the "start-stop-daemon --stop" commands. On Thu, 28 Jan 2021 02:19:05 +0800 Gedalya wrote: - if start-stop-daemon --stop --quiet --oknodo --pidfile $PIDFILE --name $NAME --retry 5; then + if start-stop-daemon --stop --quiet --oknodo --remove-pidfile --pidfile $PIDFILE --name $NAME --retry 5; then Thank you, this fixed it for me. This bug would appear to be related to that described at https://github.com/NLnetLabs/unbound/issues/303 but that was apparently fixed in 1.13.0. Regards, Roger
Bug#994252: Acknowledgement (Contacts: Retrieve user S/MIME certificate does not work)
Sorry, I was using an Ubuntu system to report the bug. Nevertheless, this report is for Debian stable and unstable, the provided patch is backported and tested on Debian stable using evolution-ews 3.38.3-1 The patch for evolution-ews on Ubuntu has been submitted here: https://bugs.launchpad.net/ubuntu/+source/evolution-ews/+bug/1943450 best! roger On Tue, 2021-09-14 at 18:09 +, Debian Bug Tracking System wrote: > Thank you for filing a new Bug report with Debian. > > You can follow progress on this Bug here: 994252: > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994252. > > This is an automatically generated reply to let you know your message > has been received. > > Your message is being forwarded to the package maintainers and other > interested parties for their attention; they will reply in due > course. > > As you requested using X-Debbugs-CC, your message was also forwarded > to > r.me...@siemens.com > (after having been given a Bug report number, if it did not have > one). > > Your message has been sent to the package maintainer(s): > Debian GNOME Maintainers < > pkg-gnome-maintain...@lists.alioth.debian.org> > > If you wish to submit further information on this problem, please > send it to 994...@bugs.debian.org. > > Please do not send mail to ow...@bugs.debian.org unless you wish > to report a problem with the Bug-tracking system. > smime.p7s Description: S/MIME cryptographic signature
Bug#994252: Contacts: Retrieve user S/MIME certificate does not work
Package: evolution-ews
Version: 3.36.5-0ubuntu1
Severity: normal
Tags: patch
It's currently not possible to retrieve encryption certificates from GAL when
connecting to o365.
upstream:
- issue: https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3
- patch: https://gitlab.gnome.org/GNOME/evolution-
ews/uploads/ffa7d7a4934cd6bd8b0f44d8c5a47f8f/ews.patch
The patch has not yet been merged upstream due to hard code freeze.
I've back-ported the patch to evolution-ews 3.38 so it could be shipped with
Debian stable. Would be great if you could integrate that and ship it with
latest Debian stable, so people could benefit already today.
-- System Information:
Debian Release: bullseye/sid
APT prefers focal-updates
APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'),
(100, 'focal-backports')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.4.0-84-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages evolution-ews depends on:
ii evolution3.36.5-0ubuntu1
ii evolution-data-server3.36.5-0ubuntu1
ii libc62.31-0ubuntu9.2
ii libcamel-1.2-62 3.36.5-0ubuntu1
ii libebackend-1.2-10 3.36.5-0ubuntu1
ii libebook-1.2-20 3.36.5-0ubuntu1
ii libebook-contacts-1.2-3 3.36.5-0ubuntu1
ii libecal-2.0-13.36.5-0ubuntu1
ii libedata-book-1.2-26 3.36.5-0ubuntu1
ii libedata-cal-2.0-1 3.36.5-0ubuntu1
ii libedataserver-1.2-243.36.5-0ubuntu1
ii libedataserverui-1.2-2 3.36.5-0ubuntu1
ii libevolution 3.36.5-0ubuntu1
ii libglib2.0-0 2.64.6-1~ubuntu20.04.4
ii libgtk-3-0 3.24.20-0ubuntu1
ii libical3 3.0.8-1
ii libmspack0 0.10.1-2
ii libpango-1.0-0 1.44.7-2ubuntu4
ii libsoup2.4-1 2.70.0-1
ii libxml2 2.9.10+dfsg-5ubuntu0.20.04.1
evolution-ews recommends no packages.
evolution-ews suggests no packages.
-- no debconf information
>From b1ef96f7daee840c4695a3ffccb3ea843cbd8068 Mon Sep 17 00:00:00 2001
From: Roger Meier
Date: Mon, 13 Sep 2021 16:32:02 +0200
Subject: [PATCH] Contacts: Retrieve user S/MIME certificate
see https://gitlab.gnome.org/GNOME/evolution-ews/-/issues/3
---
src/EWS/addressbook/e-book-backend-ews.c | 335 +--
src/EWS/addressbook/ews-oab-decoder.c| 54 +++-
src/EWS/common/e-ews-connection.c| 8 +-
src/EWS/common/e-ews-item.c | 65 +
src/EWS/common/e-ews-item.h | 5 +
5 files changed, 431 insertions(+), 36 deletions(-)
diff --git a/src/EWS/addressbook/e-book-backend-ews.c
b/src/EWS/addressbook/e-book-backend-ews.c
index 197d49fd..9bf75100 100644
--- a/src/EWS/addressbook/e-book-backend-ews.c
+++ b/src/EWS/addressbook/e-book-backend-ews.c
@@ -60,6 +60,10 @@
#define X_EWS_CHANGEKEY "X-EWS-CHANGEKEY"
#define X_EWS_GAL_SHA1 "X-EWS-GAL-SHA1"
#define X_EWS_PHOTO_CHECK_DATE "X-EWS-PHOTO-CHECK-DATE" /* MMDD of the
last check for photo */
+#define X_EWS_CERT_KIND "X-EWS-CERT-KIND"
+
+#define E_EWS_CERT_KIND_USER "UserSMIMECertificate"
+#define E_EWS_CERT_KIND_MSEX "MSExchangeCertificate"
#define EWS_MAX_FETCH_COUNT 500
@@ -69,7 +73,19 @@
/* passing field uris for PhysicalAddress, PhoneNumbers causes error, so we
* use Default view to fetch them. Thus the summary props just have attachments
* and some additional properties that are not return with Default view */
-#define CONTACT_ITEM_PROPS "item:Attachments item:HasAttachments item:Body
item:LastModifiedTime contacts:Manager contacts:Department contacts:SpouseName
contacts:AssistantName contacts:BusinessHomePage contacts:Birthday"
+#define CONTACT_ITEM_PROPS "item:Attachments "\
+ "item:HasAttachments "\
+ "item:Body "\
+ "item:LastModifiedTime "\
+ "contacts:Manager "\
+ "contacts:Department "\
+ "contacts:SpouseName "\
+ "contacts:AssistantName "\
+ "contacts:BusinessHomePage "\
+ "contacts:Birthday"
+#define CONTACT_ITEM_PROPS_10SP2 CONTACT_ITEM_PROPS " "\
+ "contacts:UserSMIMECertificate "\
+ "contacts:MSExchangeCertificate"
struct _EBookBackendEwsPrivate {
GRecMutex cnc_lock;
@@ -551,6 +567,238 @@ ebews_populate_photo (EBookBackendEws *bbews,
e_contact_photo_free (photo);
}
+stati
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
On 05/09/2021 09:07, Salvatore Bonaccorso wrote: On Wed, Sep 01, 2021 at 10:59:19PM +0100, Roger Lynn wrote: On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit wrote: > A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in the PHY > reporting an invalid PHY ID. Realtek / Gigabyte don't release errata information, > therefore there's not much that can be done. In bugzilla.kernel.org you can find > workarounds that helped for some users, else use the r8168 driver. In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. Neither of these worked for me. Fortunately the r8168-dkms package does work. Thank you for the suggestion, as I was not aware of this driver. According to the discussion, there is not something to patch on the kernel side and rather likely a BIOS bug. So closing the bug. The r8168-dkms package asks for bugs to be filed when it works but the in-kernel driver doesn't. I guess this bug already counts for that.
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
On 06/09/2021 11:05, Didier 'OdyX' Raboud wrote: CUPS appears to already have access to everything in /etc/ssl/ on all systems, which is where I used to keep my CAcert certificates. This doesn't feel any different. You're absolutely right; that's convincing to me! Reopening, and will fix in the next upload. Excellent! Thank you.
Bug#993819: release-notes: Please document the removal of wicd
Package: release-notes Severity: important Hi, Please document the removal of wicd in Bullseye. This seems particularly dangerous if the upgrade is being done over a network connection being managed by wicd as it seems likely that the connection will be lost when wicd is removed (due to dependency problems). It would also be helpful if alternatives could be suggested. Thanks, Roger
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
On Wed, 25 Aug 2021 08:07:48 +0200 Heiner Kallweit wrote: A number of Gigabyte boards from ~2009 have broken BIOS support, resulting in the PHY reporting an invalid PHY ID. Realtek / Gigabyte don't release errata information, therefore there's not much that can be done. In bugzilla.kernel.org you can find workarounds that helped for some users, else use the r8168 driver. In https://bugzilla.kernel.org/show_bug.cgi?id=207203 it was suggested to enable the boot ROM in the BIOS and/or reinsert the r8169 kernel module. Neither of these worked for me. Fortunately the r8168-dkms package does work. Thank you for the suggestion, as I was not aware of this driver. Roger
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
On 27/08/2021 14:33, Didier 'OdyX' Raboud wrote:> Control: tags -1 +wontfix Using Let's Encrypt is fine, allowed, and (apparently) working with CUPS, but as that's clearly not a default way of working for CUPS, I'd be _very_ reluctant to allow CUPS to access "all the Let's Encrypt certificates" on all systems it gets installed to. Furthermore, /etc/apparmor.d/usr.sbin.cupsd is a configuration file, freely modifiable by the local system administrator. In other words, imposing that a local system administrator needs to update that file to enable a specific type of certificates is reasonable. CUPS appears to already have access to everything in /etc/ssl/ on all systems, which is where I used to keep my CAcert certificates. This doesn't feel any different. On 29/08/2021 08:31, Didier 'OdyX' Raboud wrote: Le vendredi, 27 août 2021, 18.31:17 h CEST Roger Lynn a écrit : The documentation is definitely lacking - I've been trying to work out why my configuration broke since upgrading to Buster 3 months ago! Even with the loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is the most popular source of signed certificates and the upstream documentation at https://www.cups.org/doc/encryption.html explicitly says: "CUPS also supports certificates created and managed by the popular Let's Encrypt certificate service, which are stored in the /etc/letsencrypt/live directory." Right. Where do you suggest this needed apparmor edition should be documented? README.Debian or cups-files.conf(5) seem appropriate. A mention in NEWS.Debian would have been useful, but it's probably a bit late for that now. Thanks, Roger
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
The documentation is definitely lacking - I've been trying to work out why my configuration broke since upgrading to Buster 3 months ago! Even with the loglevel set to "debug", the logs were utterly unhelpful. Let's Encrypt is the most popular source of signed certificates and the upstream documentation at https://www.cups.org/doc/encryption.html explicitly says: "CUPS also supports certificates created and managed by the popular Let's Encrypt certificate service, which are stored in the /etc/letsencrypt/live directory."
Bug#992886: r8169: no dedicated PHY driver found for PHY ID 0xc1071002
Package: src:linux Version: 5.10.46-4 Severity: normal File: /lib/modules/5.10.0-8-amd64/kernel/drivers/net/ethernet/realtek/r8169.ko I've just upgraded this machine to Bullseye and it seems unable to load the ethernet driver: [6.548031] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [6.566607] libphy: r8169: probed [6.566613] r8169 :02:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.590372] r8169: probe of :02:00.0 failed with error -49 [6.590412] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [6.592984] libphy: r8169: probed [6.592987] r8169 :03:00.0: no dedicated PHY driver found for PHY ID 0xc1071002, maybe realtek.ko needs to be added to initramfs? [6.626342] r8169: probe of :03:00.0 failed with error -49 This is long after the filesystem has been mounted, so the initramfs should be irrelevant, but I tried adding the realtek and r8169 modules to the initramfs and the only difference was that the error was earlier in the boot sequence. The machine is 12 years old and has worked with every stable Debian release in that time. The old Buster kernel, 4.19.0-17-amd64, running with Bullseye reports: [ 10.604259] r8169 :02:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.616071] libphy: r8169: probed [ 10.616222] r8169 :02:00.0 eth0: RTL8168d/8111d, 00:24:1d:1e:99:33, XID 281000c0, IRQ 25 [ 10.616223] r8169 :02:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko] [ 10.616921] r8169 :03:00.0: can't disable ASPM; OS doesn't have ASPM control [ 10.619251] libphy: r8169: probed [ 10.619384] r8169 :03:00.0 eth1: RTL8168d/8111d, 00:24:1d:1e:99:31, XID 281000c0, IRQ 26 [ 10.619385] r8169 :03:00.0 eth1: jumbo features [frames: 9200 bytes, tx checksumming: ko] ... [ 17.134036] r8169 :02:00.0: firmware: direct-loading firmware rtl_nic/rtl8168d-1.fw [ 17.134559] Generic PHY r8169-200:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-200:00, irq=IGNORE) [ 17.285430] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 17.286173] Generic PHY r8169-300:00: attached PHY driver [Generic PHY] (mii_bus:phy_addr=r8169-300:00, irq=IGNORE) [ 17.437417] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready [ 20.009162] r8169 :02:00.0 eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 20.009180] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Thanks, Roger -- Package-specific info: ** Version: Linux version 5.10.0-8-amd64 (debian-ker...@lists.debian.org) (gcc-10 (Debian 10.2.1-6) 10.2.1 20210110, GNU ld (GNU Binutils for Debian) 2.35.2) #1 SMP Debian 5.10.46-4 (2021-08-03) ** Command line: BOOT_IMAGE=/boot/vmlinuz-5.10.0-8-amd64 root=UUID=cc5ea548-3370-40b7-b244-7fb88e5b310e ro radeon.dpm=1 quiet ** Not tainted ** Kernel log: Unable to read kernel log; any relevant messages should be attached ** Model information sys_vendor: Gigabyte Technology Co., Ltd. product_name: GA-MA790FXT-UD5P product_version: chassis_vendor: Gigabyte Technology Co., Ltd. chassis_version: bios_vendor: Award Software International, Inc. bios_version: F8n board_vendor: Gigabyte Technology Co., Ltd. board_name: GA-MA790FXT-UD5P board_version: ** Loaded modules: udp_diag tcp_diag inet_diag cpufreq_userspace cpufreq_powersave cpufreq_conservative cpufreq_ondemand uinput it87 hwmon_vid loop msr i2c_dev snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio ax88179_178a usbnet snd_hda_codec_hdmi mii snd_hda_intel snd_intel_dspcfg soundwire_intel soundwire_generic_allocation snd_soc_core edac_mce_amd snd_compress soundwire_cadence kvm_amd snd_hda_codec ccp r8169 rng_core snd_hda_core kvm firewire_ohci firewire_core snd_hwdep wmi_bmof realtek soundwire_bus mdio_devres libphy sr_mod crc_itu_t irqbypass snd_pcm snd_timer cdrom pcspkr ohci_pci ohci_hcd ata_generic snd sg ehci_pci ehci_hcd sp5100_tco watchdog pata_atiixp usbcore acpi_cpufreq soundcore button usb_common wmi i2c_piix4 k10temp ext4 crc16 mbcache jbd2 crc32c_generic sd_mod t10_pi crc_t10dif crct10dif_generic crct10dif_common radeon i2c_algo_bit drm_kms_helper cec ahci ttm libahci libata drm evdev psmouse scsi_mod serio_raw ** Network interface configuration: *** /etc/network/interfaces: auto lo iface lo inet loopback allow-hotplug eth0 iface eth0 inet static address 192.168.0.3 netmask 255.255.255.0 network 192.168.0.0 broadcast 192.168.0.255 gateway 192.168.0.2 allow-hotplug eth1 iface eth1 inet static address 192.168.2.1 netmask 255.255.255.0 ** Network status: *** IP interfaces and addresses: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft
Bug#959949: sensord: not available in stable o testing
Package: sensord Version: 1:3.4.0-3+b1 Followup-For: Bug #959949 Hi, The last version of sensord still seems to work perfectly for logging temperatures. Is there any other package that will do this instead? Thanks, Roger -- System Information: Debian Release: 9.13 APT prefers oldoldstable APT policy: (500, 'oldoldstable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.0-16-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages sensord depends on: ii libc62.24-11+deb9u4 ii librrd8 1.6.0-1+b2 ii libsensors4 1:3.4.0-4 ii lm-sensors 1:3.4.0-4 ii lsb-base 9.20161125 sensord recommends no packages. Versions of packages sensord suggests: pn rrdtool -- no debconf information
Bug#992430: schroot: user password does not match
Hi, I'm not personally familiar with the changes in the latest Debian release, but please check that all the password, shadow password files etc. are all copied into the chroot and are self-consistent with one another. Are the host files using a hash type not supported by the chroot environment? Regards, Roger On 18/08/2021, 14:54, "Sergey Vlasov" wrote: Package: schroot Version: 1.6.10-12 Severity: important X-Debbugs-Cc: ser...@vlasov.me Dear Maintainer, When doing schroot into a buster chroot environment, sudo commands fail due to password not matching the current user password. There is no such problem for bullseye chroot environment.
Bug#992378: /etc/apparmor.d/usr.sbin.cupsd: Prevents Let's Encrypt certificates from being used
Package: cups-daemon Version: 2.3.3op2-3+deb11u1 Severity: normal File: /etc/apparmor.d/usr.sbin.cupsd Adding /etc/letsencrypt/archive/** r, seems to fix this. I only discovered what was causing the problem when I stumbled across https://askubuntu.com/questions/1079957 Thanks, Roger -- System Information: Debian Release: 11.0 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) LSM: AppArmor: enabled Versions of packages cups-daemon depends on: ii adduser3.118 ii bc 1.07.1-2+b2 ii init-system-helpers1.60 ii libavahi-client3 0.8-5 ii libavahi-common3 0.8-5 ii libc6 2.31-13 ii libcups2 2.3.3op2-3+deb11u1 ii libdbus-1-31.12.20-2 ii libelogind0 [libsystemd0] 246.9.1-1+debian1 ii libgssapi-krb5-2 1.18.3-6 ii libpam0g 1.4.0-9 ii libpaper1 1.1.28+b1 ii lsb-base 11.1.0 ii procps 2:3.3.17-5 ii ssl-cert 1.1.0+nmu1 Versions of packages cups-daemon recommends: pn avahi-daemon pn colord pn cups-browsed pn ipp-usb Versions of packages cups-daemon suggests: ii cups 2.3.3op2-3+deb11u1 ii cups-bsd 2.3.3op2-3+deb11u1 ii cups-client2.3.3op2-3+deb11u1 ii cups-common2.3.3op2-3+deb11u1 ii cups-filters 1.28.7-1 pn cups-pdf ii cups-ppdc 2.3.3op2-3+deb11u1 ii cups-server-common 2.3.3op2-3+deb11u1 ii foomatic-db-compressed-ppds [foomatic-db] 20200820-1 ii ghostscript9.53.3~dfsg-7 ii poppler-utils 20.09.0-3.1 pn smbclient ii udev 247.3-6 -- Configuration Files: /etc/cups/cups-files.conf changed: CreateSelfSignedCerts no SystemGroup lpadmin LogFileGroup adm AccessLog /var/log/cups/access_log ErrorLog /var/log/cups/error_log PageLog /var/log/cups/page_log -- no debconf information
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#989320: apt-file search
$ apt-file find libwine.so libwine: /usr/lib/x86_64-linux-gnu/wine/libwine.so.1 libwine: /usr/lib/x86_64-linux-gnu/wine/libwine.so.1.0 libwine-dev: /usr/lib/x86_64-linux-gnu/wine/libwine.so libwine-development: /usr/lib/x86_64-linux-gnu/wine-development/libwine.so <--- libwine-development: /usr/lib/x86_64-linux-gnu/wine-development/libwine.so.1 libwine-development: /usr/lib/x86_64-linux-gnu/wine-development/libwine.so.1.0 libwine-development-dev: /usr/lib/x86_64-linux-gnu/wine-development/libwine.so <--- $
Bug#989320: libwine-development-dev: libwine-development and libwine-development-dev both supply libwine.so
Package: libwine-development-dev Version: 5.22+repack-1 Severity: normal Dear Maintainer, I was attempting to upgrade all installed packages. libwine-development was to be upgraded from 5.19+repack-1 to 5.22+repack-1, as well as libwine-development-dev from 5.19+repack-1 to 5.22+repack-1. libwine-development-dev upgraded successfully, but libwine-development did not: roger@rogerhp:~$ sudo apt-get full-upgrade Reading package lists... Done Building dependency tree... Done Reading state information... Done You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: libwine-development : Breaks: libwine-development:i386 (!= 5.19+repack-1) but 5.22+repack-1 is installed libwine-development:i386 : Recommends: libodbc1:i386 (>= 2.3.1) but it is not installed Recommends: gstreamer1.0-plugins-good:i386 but it is not installed Breaks: libwine-development (!= 5.22+repack-1) but 5.19+repack-1 is installed libwine-development-dev : Depends: libwine-development (= 5.22+repack-1) but 5.19+repack-1 is installed wine64-development : Depends: libwine-development (= 5.22+repack-1) but 5.19+repack-1 is installed E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). $ $ $ sudo apt-get --fix-broken install Reading package lists... Done Building dependency tree... Done Reading state information... Done Correcting dependencies... Done The following additional packages will be installed: libwine-development The following packages will be upgraded: libwine-development 1 upgraded, 0 newly installed, 0 to remove and 20 not upgraded. 9 not fully installed or removed. Need to get 0 B/76.9 MB of archives. After this operation, 36.1 MB of additional disk space will be used. Do you want to continue? [Y/n] y Retrieving bug reports... Done Parsing Found/Fixed information... Done Reading changelogs... Done (Reading database ... 778201 files and directories currently installed.) Preparing to unpack .../libwine-development_5.22+repack-1_amd64.deb ... Unpacking libwine-development:amd64 (5.22+repack-1) over (5.19+repack-1) ... dpkg: error processing archive /var/cache/apt/archives/libwine-development_5.22+repack-1_amd64.deb (--unpack): trying to overwrite '/usr/lib/x86_64-linux-gnu/wine-development/libwine.so', which is also in package libwine-development-dev 5.22+repack-1 Errors were encountered while processing: /var/cache/apt/archives/libwine-development_5.22+repack-1_amd64.deb needrestart is being skipped since dpkg has failed E: Sub-process /usr/bin/dpkg returned an error code (1) $ Expected result: Successful upgrade of both packages. -- Package-specific info: /usr/bin/wine points to /usr/bin/wine-stable. -- System Information: Debian Release: 11.0 APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-7-amd64 (SMP w/4 CPU threads) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libwine-development-dev depends on: ii libc6-dev [libc-dev] 2.31-12 ii libwine-development 5.19+repack-1 Versions of packages libwine-development-dev recommends: iu wine64-development-tools 5.22+repack-1 libwine-development-dev suggests no packages. Versions of packages wine-development depends on: iu wine32-development 5.22+repack-1 iu wine64-development 5.22+repack-1 Versions of packages wine-development suggests: pn dosbox pn exe-thumbnailer | kio-extras pn playonlinux pn q4wine pn winbind pn wine-binfmt ii winetricks0.0+20210206-2 Versions of packages libwine-development depends on: ii libasound2 1.2.4-1.1 ii libc62.31-12 ii libfaudio0 21.02-1 ii libfontconfig1 2.13.1-4.2 ii libfreetype6 2.10.4+dfsg-1 ii libgcc-s110.2.1-6 ii libglib2.0-0 2.66.8-1 ii libgphoto2-6 2.5.27-1 ii libgphoto2-port122.5.27-1 ii libgstreamer-plugins-base1.0-0 1.18.4-dmo1 ii libgstreamer1.0-01.18.4-2 ii liblcms2-2 2.12~rc1-2 ii libldap-2.4-22.4.57+dfsg-3 ii libmpg123-0 1.26.4-1 ii libopenal1 1:1.19.1-2 ii libpcap0.8 1.10.0-2 ii libpulse014.2-2 ii libudev1 247.3-5 ii libunwind8 1.3.2-2 ii libvkd3d11.1-5 ii libx11-6 2:1.7.1-1 ii libxext6 2:1.3.3-1.1 ii libx
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
