Bug#1070784: birdfont: unable to run
severity -1 normal tags -1 +unreproducible thanks On Thu, 09 May 2024 06:19:47 +0200 Janusz S. Bień wrote: > Package: birdfont > Version: 2.32.3-2 > I get > > birdfont: symbol lookup error: /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37: > undefined symbol: gst_transcoder_get_sync_signal_adapter I've tested it with freshly-installed Debian12.5 VM on gnome-boxes and birdfont works fine, so tagged this bug as unreproducible and severity as normal. > ii libwebkit2gtk-4.0-37 2.42.5-1~deb12u1 Could you check its files with "LANG=C ls -l /lib/x86_64-linux-gnu/libwebkit2gtk-4.1.so*" and update its package with newest libwebkit2gtk-4.0-37 package, please? It was updated as https://lists.debian.org/debian-security-announce/2024/msg00095.html -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#1064345: gnome-settings-daemon: Cannot input Japanese on some apps with wayland
Hi Jeremy, On Tue, 20 Feb 2024 07:27:40 -0500 =?UTF-8?Q?Jeremy_B=C3=ADcha?= wrote: > Does this happen every time? Yes, at least on my laptop for work (Debian testing). Not depend on users, I've tested it on my laptop with two users, and it happens for those two. > There should not have been any input related changes in > gnome-settings-daemon 46 Beta: > https://gitlab.gnome.org/GNOME/gnome-settings-daemon/-/compare/45.1...46.beta > > Maybe something else changed on your system instead? No, just downgrading gnome-settings-daemon (as below) solves this problem. > > Start-Date: 2024-02-20 20:03:40 > > Commandline: apt install ./gnome-settings-daemon-common_45.1-1_all.deb > > ./gnome-settings-daemon_45.1-1_amd64.deb > > Requested-By: henrich (1000) > > Downgrade: gnome-settings-daemon-common:amd64 (46~beta-1, 45.1-1), > > gnome-settings-daemon:amd64 (46~beta-1, 45.1-1) > > End-Date: 2024-02-20 20:03:44 And here is reproduce step) 1. upgrade gnome-settings-daemon to 46~beta-1 2. logout from gnome 3. re-login (to use updated gnome-settings-daemon) 4. try to input Japanese on firefox-esr and could not do it 5. downgrade gnome-settings-daemon to 45.1-1 6. switch to second user 7. try to input Japanese on firefox-esr and it works 8. logout and switch back to first user 9. logout (first user) and re-login 10. try to input Japanese on firefox-esr and it works I'm not sure how to debug it and get some logs... -- Hideki Yamane
Bug#1064345: gnome-settings-daemon: Cannot input Japanese on some apps with wayland
On Tue, 20 Feb 2024 22:59:33 +0900 Hideki Yamane wrote: > > Does this happen every time? > > Yes, at least on my laptop for work (Debian testing). I've reproduced it with https://cdimage.debian.org/mirror/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-gnome.iso -- Hideki Yamane
Bug#1064345: gnome-settings-daemon: Cannot input Japanese on some apps with wayland
Package: gnome-settings-daemon Version: 46~beta-1 Severity: important X-Debbugs-Cc: henr...@debian.org Dear Maintainer, Recently I've updated my Debian testing box and rebooted it, then I could not input Japanese with IME (ibus + mozc) on some applications e.g. firefox-esr, google-chrome, slack, etc. After some investigations, I can input Japanese on Xorg session, instead of wayland. However, it misses some input on Xorg, so it is not a solution for me. And after more investigations, I've found that downgrade gnome-settings-daemon to 45.1-1 solves this problem. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.6.15-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 gnome-settings-daemon depends on: ii gnome-settings-daemon-common 45.1-1 ii gsettings-desktop-schemas 45.0-2 ii libasound21.2.10-3 ii libc6 2.37-15 ii libcairo2 1.18.0-1+b1 ii libcanberra-gtk3-00.30-11 ii libcanberra0 0.30-11 ii libcolord21.4.7-1 ii libcups2 2.4.7-1+b1 ii libfontconfig12.14.2-6+b1 ii libgck-1-03.41.1-4 ii libgcr-base-3-1 3.41.1-4 ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1 ii libgeoclue-2-02.7.1-2 ii libgeocode-glib-2-0 3.26.3-6+b1 ii libglib2.0-0 2.78.4-1 ii libgnome-desktop-3-20 44.0-2+b1 ii libgtk-3-03.24.41-1 ii libgudev-1.0-0238-3 ii libgweather-4-0 4.4.0-1 ii libmm-glib0 1.22.0-3 ii libnm01.44.2-7 ii libnotify40.8.3-1 ii libp11-kit0 0.25.3-4 ii libpam-systemd [logind] 255.3-2 ii libpango-1.0-01.51.0+ds-4 ii libpangocairo-1.0-0 1.51.0+ds-4 ii libpolkit-gobject-1-0 124-1 ii libpulse-mainloop-glib0 16.1+dfsg1-3 ii libpulse0 16.1+dfsg1-3 ii libspa-0.2-bluetooth 1.0.3-1 ii libupower-glib3 1.90.2-8 ii libwacom9 2.9.0-2 ii libwayland-client01.22.0-2.1+b1 ii libx11-6 2:1.8.7-1 ii libxext6 2:1.3.4-1+b1 ii libxfixes31:6.0.0-2 ii libxi62:1.8.1-1 ii pipewire-audio1.0.3-1 Versions of packages gnome-settings-daemon recommends: ii iio-sensor-proxy 3.5-1+b1 ii pipewire-audio 1.0.3-1 ii pkexec 124-1 ii x11-xserver-utils 7.7+10 Versions of packages gnome-settings-daemon suggests: pn usbguard -- no debconf information
Bug#1053417: debian-mirror.sakura.ne.jp: want to make it "Hub" mirror in JP region
Package: mirrors Severity: wishlist X-Debbugs-Cc: henr...@debian.org Dear mirror admins, I'm admin of debian-mirror.sakura.ne.jp. Until June, hanzubon.jp pushed repository changes to it, but unfortunately with some reasons hanzubon.jp was terminated and there's no upstream mirror in JP region. So, I want to step up to it. Could you help me to set up, please? -- Regards, Hideki Yamane
Bug#1052585: libc++1: Smooth upgrade with proper breaks version (-11 -> -14)
Package: libc++1 Version: 1:14.0-55.7 Severity: normal X-Debbugs-Cc: henr...@debian.org Dear Maintainer, It seems that libc++ package should change its dependency version for smoooth upgrade. --- control.old 2023-09-13 22:35:38.0 +0900 +++ control 2023-09-25 08:44:39.012538283 +0900 @@ -5,7 +5,7 @@ Maintainer: LLVM Packaging Team Installed-Size: 14 Depends: libc++1-16 (>= 16~) -Breaks: libc++1-11, libc++abi1-11 +Breaks: libc++1-14, libc++abi1-14 Section: libs Priority: optional Multi-Arch: same With above changes, apt upgrade works smoothly :) -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 6.4.0-4-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libc++1 depends on: ii libc++1-14 1:14.0.6-16 libc++1 recommends no packages. libc++1 suggests no packages. -- no debconf information --- control.old 2023-09-13 22:35:38.0 +0900 +++ control 2023-09-25 08:44:39.012538283 +0900 @@ -5,7 +5,7 @@ Maintainer: LLVM Packaging Team Installed-Size: 14 Depends: libc++1-16 (>= 16~) -Breaks: libc++1-11, libc++abi1-11 +Breaks: libc++1-14, libc++abi1-14 Section: libs Priority: optional Multi-Arch: same
Bug#885698: What licenses should be included in /usr/share/common-licenses?
Hi, On Sun, 10 Sep 2023 18:29:36 +0200 Bill Allombert wrote: > Or we could generate DEBIAN/copyright from debian/copyright using data in > license-common-list at build time. So maintainers would not need to manage > the copying > themselves. One problem is, that some software declares that they use some licenses (e.g. MIT), but sometimes they modify the license term itself a bit. So, there's a difference between words in the license list and some words in the included license in such software. It'd be better to find such software and ask upstream to fix it to use proper license terms, by tagging it at BTS. And, it's NOT Debian specific issues, so it may be better to ask folks to join such a movement then, IMHO. -- Hideki Yamane
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Sat, 09 Sep 2023 20:35:27 -0700 Russ Allbery wrote: > Licenses will be included in common-licenses if they meet all of the > following criteria: How about just pointing SPDX licenses URL for whole license text and lists DFSG-free licenses from that? (but yes, we should adjust short name of licenses for DEP-5 and SPDX for it). -- Hideki Yamane
Bug#885698: What licenses should be included in /usr/share/common-licenses?
On Sat, 09 Sep 2023 22:41:48 -0700 Russ Allbery wrote: > > How about just pointing SPDX licenses URL for whole license text and > > lists DFSG-free licenses from that? (but yes, we should adjust short > > name of licenses for DEP-5 and SPDX for it). > > Can we do this legally? If we can, it certainly has substantial merits, > but I'm not sure that this satisfies the requirement in a lot of licenses > to distribute a copy of the license along with the work. Some licenses > may allow that to be provided as a URL, but I don't think they all do > (which makes sense since people may receive Debian on physical media and > not have Internet access). Hmm, how about providing license-common package and that depends on "license-common-list", and ISO image provides both, then? It would be no regressions. I expect license-common-list data as below license-short-name: URL GPL-2: file:///usr/share/common-licenses/GPL-2 Boost-1.0: https://spdx.org/licenses/BSL-1.0.html -- Hideki Yamane
Bug#1035612: Acknowledgement (unblock: birdfont/2.32.3-2)
Oh, reportbug ;) > unblock birdfont/2.32.3-1 It should be unblock birdfont/2.32.3-2
Bug#1035616: release-notes: Duplicate paragraph
Package: release-notes Severity: normal Dear Maintainer, In en/issues.dbk, below paragraphs seem to be duplicated. Not all the same, but mostly. Things to do post upgrade before rebooting When apt full-upgrade has finished, the formal upgrade is complete. For the upgrade to , there are no special actions needed before performing a reboot. When apt full-upgrade has finished, the formal upgrade is complete, but there are some other things that should be taken care of before the next reboot.
Bug#1035613: release-notes: Maybe typo? "`arch`-based" in 5.3.3
Package: release-notes Severity: normal Dear Maintainer, In 5.3.3, en/issues.dbk says No-longer-supported hardware For a number of `arch`-based devices that were supported in , it is no longer viable for Debian to build the required Linux kernel, due to hardware limitations. The unsupported devices are: `arch`-based? It may be something other like $arch (and would be limited to its architecture's release notes).
Bug#1035612: unblock: birdfont/2.32.3-2
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
X-Debbugs-Cc: birdf...@packages.debian.org
Control: affects -1 + src:birdfont
Please unblock package birdfont
[ Reason ]
Ensure smooth upgrade birdfont package from bullseye
[ Impact ]
Upgrade failure from bullseye to bookworm
[ Tests ]
piuparts shows no error with this upgrade
(as $ sudo piuparts -e /var/cache/pbuilder/bullseye.cow/ -d stable -d sid
--apt birdfont=2.32.3-2 -l piuparts.log)
[ Risks ]
Well, I have not found it yet :)
[ 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
unblock birdfont/2.32.3-1
diff -Nru birdfont-2.32.3/debian/changelog birdfont-2.32.3/debian/changelog
--- birdfont-2.32.3/debian/changelog2022-09-25 21:02:39.0 +0900
+++ birdfont-2.32.3/debian/changelog2023-05-06 13:39:25.0 +0900
@@ -1,3 +1,11 @@
+birdfont (2.32.3-2) unstable; urgency=medium
+
+ * debian/control
+- Declare Repalces: to avoid upgrade problem (Closes: #1034968)
+ Thanks to Helmut Grohne for the report
+
+ -- Hideki Yamane Sat, 06 May 2023 13:39:25 +0900
+
birdfont (2.32.3-1) unstable; urgency=medium
* New upstream release
diff -Nru birdfont-2.32.3/debian/control birdfont-2.32.3/debian/control
--- birdfont-2.32.3/debian/control 2022-09-25 21:02:39.0 +0900
+++ birdfont-2.32.3/debian/control 2023-05-06 13:39:25.0 +0900
@@ -27,6 +27,7 @@
Depends: ${misc:Depends},
fonts-roboto-unhinted,
Breaks: birdfont (<< 2.29.4-1)
+Replaces: birdfont (<< 2.29.4-1)
Description: arch-independent data for birdfont package
Birdfont is a free, open source font editor that lets you create outline
vector graphics and export ttf, eot & svg fonts.
Bug#1033833: unknown-horizons: Fails to start Couldn't open
content/fonts/Unifont.ttf Message-Id: <20230404093247.b65a8493b462bfa1d06d3...@iijmio-mail.jp> In-Reply-To: X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi Tobias, On Mon, 3 Apr 2023 19:29:24 +0200 Tobias Frost wrote: > thanks for your feedback and the hint to look into otf. > It seems that the fife engine of unknown-horizons can read otf fonts as well, > so redirecting the symlink to that version works \o/ Good! :) > PS: Long description of the fonts-unifont package is still mentioning > truetype fonts$B!D(B > Maybe that needs s/truetype/opentype/ ? Ouch, now fixed it in git... will be updated as package with unifont 16.0 release. Thanks! -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#1033833: unknown-horizons: Fails to start Couldn't open content/fonts/Unifont.ttf
On Sun, 2 Apr 2023 18:33:34 +0200 Tobias Frost wrote: > it seems so that the fonts package unifont dropped unifont.ttf in > 1:15.0.01-1: Yes, and upstream plans to drop ttf. So I do not want to revert this change in Debian package. > Unifont 15.0.01 installs OpenType fonts alongside the TrueType fonts > that are installed in Unifont 14.0.x and previous releases. > The current plan is for Unifont 16.0.01 to no longer install TrueType > fonts that have OpenType equivalents. This will allow a period of > approximately one year for Unifont users to switch from TrueType to > OpenType files. -- Hideki Yamane
Bug#1032884: Acknowledgement (amanda-client: Amanda is unusable)
control: tags -1 +pending On Wed, 15 Mar 2023 18:39:47 + Jose M Calhariz wrote: > Thank you, your problem is known and will be fixed on the next upload. -- Hideki Yamane
Bug#987008: grub2: diff for NMU version 2.06-8.1
Control: tags -1 +pending Hi from RC bugs digger, It's better to show this issue is going to be solved, add "pending" is good to avoid duplicate efforts :) -- Hideki Yamane
Bug#1029821: change gnome-desktop's default choice of Japanese input methods for Debian
On Thu, 2 Mar 2023 09:42:36 + Simon McVittie wrote: > Is there consensus among Japanese-speaking users of Debian that mozc is > a better default for all Japanese speakers, including new users who are > not familiar with GNOME or Debian? anthy vs mozc : mozc is better to default now - As a user, I prefer mozc than anthy. When I used anthy on Debian long ago, its hiragana-kanji conversion quality did not satisfy me, lower than IM on Windows. However, mozc is good - almost same quality as Google Japanese Input Method on Windows since its code base is same one. - Upsteam: anthy development is not active, almost dead since years. Original author says "This is unmaintained ancient stuff and not for general use." in his repo [1] and now I found some other staff tries to restart it as anthy-unicode [2] While mozc is still alive [3]. mozc did not accept patches from outside of Google in early days, but it seems that they relax their policies [4]. 1) https://github.com/yt76/anthy/blob/master/README 2) https://github.com/fujiwarat/anthy-unicode 3) https://github.com/google/mozc/commits/master 4) https://github.com/google/mozc/blob/master/PULL_REQUEST_TEMPLATE.md > Looking at #984875 and #983653, I also see a mention of mozc only being > available on certain architectures: it's available on x86, ARM and riscv64, > but not on mips*el, ppc64el or s390x. Well, it's better to be on every archs, but we can ignore them since nearly 100% Japanese desktop users use it on i386, amd64 and arm[hf|64]. > I'm also concerned that mozc still depends on GTK 2 (a switch to GTK > 3 was tried and then reverted, see #967641). This is OK for bookworm, > but will probably not be supportable in Debian 13. It should be reported to mozc upstream, they don't aware of it now, I guess. > > Upstream prefers ibus-anthy for Japanese input > > Please talk to upstream about this: if mozc is a better default for Debian, > then it's probably also a better default for upstream. Okay, I'll do. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#1027448: Bug#1027446: console-setup-l
=?utf-8?Q?inux=3A_Super-Ugly_glyphs_inside_Greek-Fixed16=2Epsf=2Egz_for_c?= =?utf-8?B?aGFyYWN0ZXJzIM6zIM68IM62IM6+?= (with solution) Message-Id: <20230131231024.f1526c8797f5f69ed3ea6...@iijmio-mail.jp> In-Reply-To: <20221231163959.j2pufq32lwlvbysm@begin> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Hi, On Sat, 31 Dec 2022 17:39:59 +0100 Samuel Thibault wrote: > Pavlos Gkesos, le sam. 31 déc. 2022 18:06:20 +0200, a ecrit: > > Greek characters μ ξ ζ γ appears UGLY. > > I fix them and I provide the new Greek-Fixed16.psf.gz > > These are coming from unifont, so that's where we should be fixing it. Well, Samuel, let me confirm with it. You said those glphs comes from unifont, do those glphs in "Fonts/bdf/unifont.bdf"? If so, it is very different from unifont package one, can we sync those unifont.bdf? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#741268: pristine-bz2: fails to reproduce build of openclonk-5.4.1-src.tar.bz2
Hi, I've proposed a merge request to support 7zip as https://bugs.debian.org//714698, and it may be able to solve this #741268 issue, but not sure. Do you still have openclonk-5.4.1-src.tar.bz2? I cannot find it from the web. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#714698: pristine-tar: pristine-bz2 failed to reproduce build of r8168-8.036.00.tar.bz2
contorl: tags -1 +patch Hi, I've got the same issue with r8125 tarball from Realtek, and fixed it with 7zip support. I guess Realtek people use 7zip for bzip2 compression. MR is https://salsa.debian.org/debian/pristine-tar/-/merge_requests/10 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#1027450: unifont: Glyphs for greek characters γ μ ζ ξ appear UGLY
On Tue, 10 Jan 2023 11:29:49 +0200 Παύλος Γκέσος wrote: > Any updates? Please do NOT rush :( It is only 1 week or so. I have my family (my wife and little son) and my day job. Those are important, especially doing some Japanese traditions during 1/1-1/3, and traveling with my family is very important to me. I can do some package maintenance work during my spare time, and I do it for 200 and more packages. -- Hideki Yamane
Bug#1027628: snapper: FTBFS: regex_compiler.tcc:179:19: error: expected unqualified-id before ‘=’ token
control: tags -1 +confirmed
control: tags -1 +forwarded https://github.com/openSUSE/snapper/issues/762
control: tags -1 +upstream
It was introduced with a change in libbtrfs-dev_6.1-1,
/usr/include/btrfs/kerncompat.h.
https://github.com/kdave/btrfs-progs/commit/788a71c16a917f8357784571106537a1d42012e8
> typedef struct wait_queue_head_s {
> } wait_queue_head_t;
>
> #define __init
> #define __cold
>
> #endif
Just commented out "#define __init", it can be compiled.
--
Regards,
Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#1023492: linux-signed-amd64: Cannot boot with message "cryptsetup: Waiting for encrypted source device UUID=xxxx..."
Source: linux-signed-amd64 Version: 6.0.6+2 Severity: important Dear Maintainer, I cannot boot my amd64 PC with linux-image-6.0.0-2-amd64, it just shows "cryptsetup: Waiting for encrypted source device UUID=" again and again, then falled down to busybox shell. With 6.0.0-1 works, 6.1~rc3+1~exp1 in experimental also does not work. $ LANG=C df -h -x tmpfs Filesystem Size Used Avail Use% Mounted on udev 15G 0 15G 0% /dev /dev/mapper/tiny--vg-system 328G 224G 104G 69% / /dev/sda2235M 221M 1.8M 100% /boot /dev/mapper/tiny--vg-home559G 391G 168G 70% /home /dev/nvme0n1p1 256M 34M 223M 14% /boot/efi $ mount|grep mapper /dev/mapper/tiny--vg-system on / type btrfs (rw,relatime,ssd,space_cache,subvolid=5,subvol=/) /dev/mapper/tiny--vg-home on /home type btrfs (rw,relatime,compress=zstd:3,ssd,space_cache,subvolid=5,subvol=/) -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.0.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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
Bug#1022566: fonts-mplus: upgrade of mplus leaves an old /usr/share/fonts/truetype/mplus behind
control: reassign -1 fontconfig control: forcemerge -1 897040 Hi, On Mon, 24 Oct 2022 05:27:14 +0200 Alexandre Detiste wrote: > After upgrade of mplus, I still have got old loose dir and cache file > from previous version: > > /usr/share/fonts/truetype/mplus > /usr/share/fonts/truetype/mplus/.uuid > > Please remove these files on upgrade. It was not created by fonts packages, but by fontconfig. And, it seemed to be fixed in upstream now. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040 -- Hideki Yamane
Bug#1022702: gnupg: Migrating packaging from 2.2.x to "stable" 2.3.x
Package: gnupg Severity: wishlist Dear Maintainer, I've noticed that now upstream says 2.3 branch is "stable" series, not development ones since 2.3.5. https://lists.gnupg.org/pipermail/gnupg-announce/2022q2/000472.html (2.3.5) https://lists.gnupg.org/pipermail/gnupg-announce/2021q4/000468.html (2.3.4) So, it may be better to migrate 2.3.x before releasing bookworm since it needs to be maintained long term. And last, thank you for your maintainance this quite important package :) -- Regards, Hideki Yamane
Bug#1021434: gnome-initial-setup: No current input method settings (ibus-mozc) in list (then default choise deletes current sources)
Package: gnome-initial-setup
Version: 43.0-1
Severity: important
X-Debbugs-Cc: henr...@debian.org
Dear Maintainer,
After upgrading packages, gnome-initial-setup windows popped up
and I chose default choise "日本語", then I cannot input Japanese
with ibus since ibus indicator was disappeared on my desktop and
could not kick it.
With investigation, I've found that ~/.config/dconf/user data was
changed.
$ dconf dump /org/gnome/desktop/input-sources/
[/]
dmru-sources=[('ibus', 'mozc-jp'), ('xkb', 'jp')]
sources=[('ibus', 'mozc-jp'), ('xkb', 'jp')]
xkb-options=['lv3:ralt_switch']
was changed to
[/]
dmru-sources=[('xkb', 'jp')]
sources=[('xkb', 'jp')]
xkb-options=['lv3:ralt_switch']
sources=[('ibus', 'mozc-jp')] was disappeared. I've manually put it
via dconf and it works again.
So, why there is no input method source as ibus-mozc on gnome-initial-setup?
-- System Information:
Debian Release: bookworm/sid
APT prefers testing
APT policy: (500, 'testing')
Architecture: amd64 (x86_64)
Kernel: Linux 5.19.0-2-amd64 (SMP w/4 CPU threads; PREEMPT)
Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 gnome-initial-setup depends on:
ii adduser3.129
ii desktop-base 11.0.3
ii gnome-settings-daemon 43.0-2
ii libaccountsservice022.08.8-1
ii libadwaita-1-0 1.2.0-1
ii libc6 2.35-2
ii libcairo2 1.16.0-6
ii libfontconfig1 2.13.1-4.5
ii libgdk-pixbuf-2.0-02.42.9+dfsg-1
ii libgdm143.0-1
ii libgeoclue-2-0 2.6.0-2
ii libgeocode-glib-2-03.26.3-3
ii libglib2.0-0 2.74.0-2
ii libgnome-desktop-4-2 43-2
ii libgoa-1.0-0b 3.46.0-1
ii libgoa-backend-1.0-1 3.46.0-1
ii libgtk-3-0 3.24.34-3
ii libgtk-4-1 4.8.1+ds-1
ii libgweather-4-04.2.0-1
ii libibus-1.0-5 1.5.27-2
ii libjson-glib-1.0-0 1.6.6-1
ii libkrb5-3 1.20-1
ii libmalcontent-0-0 0.11.0-3
ii libmalcontent-ui-1-1 0.11.0-3
ii libnm0 1.40.0-1
ii libnma-gtk4-0 1.10.2-1
ii libpango-1.0-0 1.50.10+ds-1
ii libpangocairo-1.0-01.50.10+ds-1
ii libpolkit-gobject-1-0 0.105-33
ii libpwquality1 1.4.4-1+b1
ii librest-1.0-0 0.9.1-2
ii libsecret-1-0 0.20.5-3
ii libwebkit2gtk-5.0-02.38.0-3
ii policykit-10.105-33
Versions of packages gnome-initial-setup recommends:
ii accountsservice 22.08.8-1
ii geoclue-2.0 2.6.0-2
ii gnome-keyring42.1-1
ii malcontent 0.11.0-3
Versions of packages gnome-initial-setup suggests:
ii gdm3 43.0-1
-- no debconf information
Bug#1020609: lintian: unknown-field Autobuild
Package: lintian Version: 2.115.3 Severity: minor Dear Maintainer, Checked non-free package r8125, lintian reports "unknown-field Autobuild" that is set in debian/control file as below. >> XS-Autobuild: yes It would be better to not report as "unknown-field".
Bug#1020070: ITP: ruby-traces -- Application instrumentation and tracing
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ruby-traces Version : 0.7.0 Upstream Author : Samuel G. D. Williams (http://www.codeotaku.com/) * URL : https://github.com/socketry/traces * License : MIT Programming Lang: Ruby Description : Application instrumentation and tracing Traces captures nested traces during code execution in a vendor agnostic way. This package is needed by another ruby package (ruby-async-http) update.
Bug#984102: > libfm-qt: ftbfs with GCC-11
As 0.16.0-3.2 changelog, it seems to be okay to close this bug > libfm-qt (0.16.0-3.2) unstable; urgency=high > . > * Non-maintainer upload. > * debian/*.symbols*: Dropped, unmaintainable for c++ library. Could you check it, please? -- Hideki Yamane
Bug#1012055: FTBFS: build failure with libbtrfs-dev 5.18
Package: snapper
Version: 0.9.1-1
Severity: normal
Tags: ftbfs upstream
With libbtrfs-dev 5.18 (and above, I guess), snapper fails to be built
from source. Newer upstream version 0.10.2 fails, too.
Errors are below.
/usr/include/btrfs/list.h:78:9: error: expected primary-expression before
'volatile'
78 | WRITE_ONCE(list->next, list);
| ^~
/usr/include/btrfs/list.h:78:9: error: expected ')' before 'volatile'
78 | WRITE_ONCE(list->next, list);
| ^~
/usr/include/btrfs/list.h: In function 'void __list_add(list_head*, list_head*,
list_head*)':
/usr/include/btrfs/list.h:116:9: error: expected primary-expression before
'volatile'
116 | WRITE_ONCE(prev->next, xnew);
| ^~
/usr/include/btrfs/list.h:116:9: error: expected ')' before 'volatile'
116 | WRITE_ONCE(prev->next, xnew);
| ^~
/usr/include/btrfs/list.h: In function 'void __list_del(list_head*,
list_head*)':
/usr/include/btrfs/list.h:156:9: error: expected primary-expression before
'volatile'
156 | WRITE_ONCE(prev->next, next);
| ^~
/usr/include/btrfs/list.h:156:9: error: expected ')' before 'volatile'
156 | WRITE_ONCE(prev->next, next);
| ^~
In file included from /usr/include/btrfs/ctree.h:31,
from /usr/include/btrfs/send-utils.h:28,
from BtrfsUtils.cc:36:
/usr/include/btrfs/list.h: In function 'void list_del(list_head*)':
/usr/include/btrfs/list.h:190:23: error: invalid conversion from 'void*' to
'list_head*' [-fpermissive]
190 | entry->next = LIST_POISON1;
| ^~~~
| |
| void*
/usr/include/btrfs/list.h:191:23: error: invalid conversion from 'void*' to
'list_head*' [-fpermissive]
191 | entry->prev = LIST_POISON2;
| ^~~~
| |
| void*
In file included from /usr/include/btrfs/send-utils.h:27,
from BtrfsUtils.cc:36:
/usr/include/btrfs/list.h: In function 'int list_empty(const list_head*)':
/usr/include/btrfs/list.h:333:16: error: expected primary-expression before
'const'
333 | return READ_ONCE(head->next) == head;
|^
/usr/include/btrfs/list.h:333:16: error: expected ')' before 'const'
333 | return READ_ONCE(head->next) == head;
|^
/usr/include/btrfs/list.h:333:16: error: expected ')' before ';' token
333 | return READ_ONCE(head->next) == head;
|^
/usr/include/btrfs/list.h:333:16: note: to match this '('
333 | return READ_ONCE(head->next) == head;
|^
In file included from /usr/include/btrfs/ctree.h:31,
from /usr/include/btrfs/send-utils.h:28,
from BtrfsUtils.cc:36:
/usr/include/btrfs/list.h:333:38: error: invalid operands of types 'void' and
'const list_head*' to binary 'operator=='
333 | return READ_ONCE(head->next) == head;
| ^~
| |
| const list_head*
In file included from /usr/include/btrfs/send-utils.h:27,
from BtrfsUtils.cc:36:
/usr/include/btrfs/list.h: In function 'void list_del_init_careful(list_head*)':
/usr/include/btrfs/list.h:351:9: error: expected primary-expression before
'volatile'
351 | smp_store_release(>next, entry);
| ^
/usr/include/btrfs/list.h:351:9: error: expected ')' before 'volatile'
351 | smp_store_release(>next, entry);
| ^
/usr/include/btrfs/list.h: In function 'int list_empty_careful(const
list_head*)':
/usr/include/btrfs/list.h:369:34: error: expected primary-expression before
'const'
369 | struct list_head *next = smp_load_acquire(>next);
| ^~~~
/usr/include/btrfs/list.h:369:34: error: expected ')' before 'const'
369 | struct list_head *next = smp_load_acquire(>next);
| ^~~~
/usr/include/btrfs/list.h:369:34: error: expected ')' before ';' token
369 | struct list_head *next = smp_load_acquire(>next);
| ^~~~
/usr/include/btrfs/list.h:369:34: note: to match this '('
369 | struct list_head *next = smp_load_acquire(>next);
| ^~~~
/usr/include/btrfs/list.h:369:34: error: void value not ignored as it ought to
be
369 | struct list_head *next = smp_load_acquire(>next);
| ^~~~
/usr/include/btrfs/list.h: In function 'int hlist_unhashed_lockless(const
Bug#1009691: libusb-1.0-0: Some USB microphone takes sounds as very low volume
Package: libusb-1.0-0 Version: 2:1.0.26-1 Severity: normal X-Debbugs-Cc: henr...@debian.org Dear Maintainer, With upgrading libusb-1.0-0 package from 2:1.0.25-1 to 2:1.0.26-1, my USB microphone (marantz PROFESSIONAL pod pack1, "C-Media Electronics, Inc. Blue Snowball" with lsusb) just takes sounds as very low volume. However, Other USB mic (logicool webcam) just works fine with both versions. Downgrading to 2:1.0.25-1 solves this problem. USB microphone's info via lsusb is attached. Please let me know if you need more information to investigate this issue. Thanks. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-5-amd64 (SMP w/4 CPU threads; PREEMPT) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 libusb-1.0-0 depends on: ii libc6 2.33-7 ii libudev1 250.4-1 libusb-1.0-0 recommends no packages. libusb-1.0-0 suggests no packages. -- no debconf information Bus 003 Device 014: ID 0d8c:0005 C-Media Electronics, Inc. Blue Snowball Device Descriptor: bLength18 bDescriptorType 1 bcdUSB 1.10 bDeviceClass0 bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize016 idVendor 0x0d8c C-Media Electronics, Inc. idProduct 0x0005 Blue Snowball bcdDevice1.00 iManufacturer 1 MICE MICROPHONE iProduct2 USB MICROPHONE iSerial 3 201308 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 0x009f bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 0x002e bInCollection 1 baInterfaceNr(0)1 AudioControl Interface Descriptor: bLength12 bDescriptorType36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 2 wTerminalType 0x0201 Microphone bAssocTerminal 0 bNrChannels 1 wChannelConfig 0x0001 Left Front (L) iChannelNames 0 iTerminal 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 3 (OUTPUT_TERMINAL) bTerminalID 7 wTerminalType 0x0101 USB Streaming bAssocTerminal 0 bSourceID 8 iTerminal 0 AudioControl Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 5 (SELECTOR_UNIT) bUnitID 8 bNrInPins 1 baSourceID(0) 10 iSelector 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType36 bDescriptorSubtype 6 (FEATURE_UNIT) bUnitID10 bSourceID 2 bControlSize1 bmaControls(0) 0x03 Mute Control Volume Control bmaControls(1) 0x00 iFeature0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 1 Audio bInterfaceSubClass 2 Streaming bInterfaceProtocol 0 iInterface 0 AudioStreaming Interface Descriptor: bLength 7 bDescriptorType36 bDescriptorSubtype 1 (AS_GENERAL) bTerminalLink 7 bDelay
Bug#1003945: manpages-ja: shutdown is now provided by systemd
Package: manpages-ja Version: 0.5.0.0.20210215+dfsg-1 Severity: minor X-Debbugs-Cc: henr...@debian.org Dear Maintainer, Now "shutdown" command in Debian is provided by systemd, so /usr/share/man/ja/man8/shutdown.8.gz seems to be outdated. -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.15.0-2-amd64 (SMP w/4 CPU threads) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled manpages-ja depends on no packages. manpages-ja recommends no packages. Versions of packages manpages-ja suggests: ii man-db [man-browser] 2.9.4-4 -- no debconf information
Bug#1002611: ITP: r8125 -- dkms source for the r8125 network driver
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, henr...@debian.org, a...@debian.org * Package name: r8125 Version : 9.007.01 Upstream Author : Realtek NIC software team * URL : https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-pci-express-software * License : GPL-2 (but goes into non-free, see below) Programming Lang: C Description : dkms source for the r8125 network driver r8125 is the Linux 2.5G Ethernet device driver released by RealTek for their network controller. . This package provides the dkms source code for the r8125 kernel modules. Kernel source or headers are required to compile these modules. As same as r8168-dkms, it overwrites firmware running in microcontrollers on the network controllers, then goes into non-free. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=777257
Bug#996029: firmware-iwlwifi: Filter bogus warning with "firmware: failed to load iwl-debug-yoyo.bin"
Package: firmware-iwlwifi Severity: minor Hi, During looking logs, I've found that iwlwifi puts warning as below. > 7月 09 21:04:01 elitebook830 kernel: iwlwifi :01:00.0: firmware: failed to > load iwl-debug-yoyo.bin (-2) > 7月 09 21:04:01 elitebook830 kernel: firmware_class: See > https://wiki.debian.org/Firmware for information about missing firmware But my college says iwl-debug-yoyo.bin is for debugging used by Intel, so users don't need it (we're not sure why debug output is enabled by default...) How about putting "options iwlwifi enable_ini=0" in /etc/modprobe.d/iwlwifi.conf to ignore this bogus warning?
Bug#954315: rastertopwg segfault
On Thu, 9 Sep 2021 10:51:32 +0100 Brian Potkin wrote: > How are you progressing with this issue using the present cups in > unstable? Well, I can have some time for Debian in next week, so will check later. Thanks for head up! :) -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#993328: openscap: FTBFS with Perl 5.34: hardcodes Perl version 5.32
On Mon, 30 Aug 2021 23:50:41 +0300 Niko Tyni wrote: > This package fails to build from source with Perl 5.34 (currently in > experimental). This is because debian/rules hardcodes Perl version > 5.32.0. It was dealt with as below, but in NEW queue now... commit c1060eee08d477cbc59426dbf6b38886fae3441b Author: Hideki Yamane Date: Sun Jul 4 03:41:48 2021 +0900 Do not specify specific version number to deal with changes Perl5 transition would break build without this commit. And it is expected to change soname in the future. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#992692: general: Use https for {deb,security}.debian.org by default
On Thu, 2 Sep 2021 21:26:11 +0200 Simon Richter wrote: > The TLS layer is not part of the security model, so we'd be teaching > users to look for the wrong thing, kind of like the "encrypted with SSL" > badges on web pages in the 90ies. Is there any strong reason to use HTTP than HTTPS now? Should we teach all our users (including non-tech) about "Secure APT" mechanism? And I said about only deb.debian.org and security.debian.org, and just "default" - it means it does provide http access too. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#993683: debhelper: dh_missing wrongly reports
Package: debhelper Version: 13.5.1 Severity: normal Dear Maintainer, During build tomoyo-tools package with dh13, it fails with below. dh_missing: warning: sbin/tomoyo-init exists in debian/tmp but is not installed to anywhere (related file: "sbin/tomoyo-init") dh_missing: error: missing files, aborting While detecting missing files, dh_missing noted some files with a similar name to those that were missing. This error /might/ be resolved by replacing references to the missing files with the similarly named ones that dh_missing found - assuming the content is identical. As an example, you might want to replace: * sbin/tomoyo-init with: * sbin/tomoyo-init in a file in debian/ or as argument to one of the dh_* tools called from debian/rules. (Note it is possible the paths are not used verbatim but instead directories containing or globs matching them are used instead) Alternatively, add the missing file to debian/not-installed if it cannot and should not be used. The following debhelper tools have reported what they installed (with files per package) * dh_install: libtomoyotools3 (2), tomoyo-tools (22) * dh_installdocs: libtomoyotools3 (0), tomoyo-tools (1) * dh_installman: libtomoyotools3 (0), tomoyo-tools (19) If the missing files are installed by another tool, please file a bug against it. When filing the report, if the tool is not part of debhelper itself, please reference the "Logging helpers and dh_missing" section from the "PROGRAMMING" guide for debhelper (10.6.3+). (in the debhelper package: /usr/share/doc/debhelper/PROGRAMMING.gz) Be sure to test with dpkg-buildpackage -A/-B as the results may vary when only a subset is built If the omission is intentional or no other helper can take care of this consider adding the paths to debian/not-installed. However, sbin/tomoyo-init file was installed properly. # find . -name tomoyo-init -print ./sbin/tomoyo-init ./debian/tomoyo-tools/sbin/tomoyo-init ./debian/tmp/sbin/tomoyo-init So I guess it is a bug in debhelper. -- System Information: Debian Release: bookworm/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-8-amd64 (SMP w/8 CPU threads) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 debhelper depends on: ii autotools-dev20180224.1+nmu1 ii dh-autoreconf20 ii dh-strip-nondeterminism 1.12.0-1 ii dpkg 1.20.9 ii dpkg-dev 1.20.9 ii dwz 0.14-1 ii file 1:5.39-3 ii libdebhelper-perl13.5.1 ii libdpkg-perl 1.20.9 ii man-db 2.9.4-2 ii perl 5.32.1-5 ii po-debconf 1.0.21+nmu1 debhelper recommends no packages. Versions of packages debhelper suggests: ii dh-make 2.202101 -- no debconf information
Bug#992692: general: Use https for {deb,security}.debian.org by default
Hi,
On Wed, 01 Sep 2021 07:46:07 -0700
Russ Allbery wrote:
> >> I believe that the discussion has later identified that doing so would
> >> break squid-deb-proxy-client and auto-apt-proxy. Given that the
> >> security benefits are not strong (beyond embracing good habits), I
> >> think the reasonable thing to do is keep preferring http.
>
> > That is an opt-in choice which likely only a small number of users use.
> > People wanting to use a caching proxy can just switch to http as part of
> > this choice; it doesn't seem a good reason to not use https by default
> > for all other users.
>
> Completely agreed.
Providing "default secure setting" is good message to users.
Some users want proxy but they can configure their settings.
So just change "default setting for {deb,security}.debian.org"
is not so harmful, IMO.
- Users can choose other mirror than https://deb.debian.org
- Caching .debs from security.debian.org is not so huge, I guess
(maybe except linux-image).
--
Hideki Yamane
Bug#993218: ITP: ruby-localhost -- Manage a local certificate authority for self-signed localhost
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ruby-localhost Version : 1.1.8 Upstream Author : 2018-2021 Samuel G. D. Williams * URL : https://github.com/socketry/localhost * License : MIT Programming Lang: Ruby Description : Manage a local certificate authority for self-signed localhost This provides a convenient API for generating per-user self-signed root certificates, is useful for development. 1. Introduce ruby-async-rspec (ITPed) 2. Introduce ruby-async-process (ITPed) 3. Introduce ruby-localhost <-- here 4. Update ruby-async-http
Bug#993215: ITP: ruby-async-process -- asynchronous process spawning in Ruby
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ruby-async-process Version : 1.3.1 Upstream Author : Samuel G. D. Williams * URL : https://github.com/socketry/async-process * License : MIT Programming Lang: Ruby Description : asynchronous process spawning in Ruby Implements Process.spawn and Process.capture for async. 1. Introduce ruby-async-rspec (ITPed) 2. Introduce ruby-async-process <-- here 3. Introduce ruby-localhost 4. Update ruby-async-http
Bug#993212: ITP: ruby-async-rspec -- helpers for writing specs against the async gem
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: ruby-async-rspec Version : 1.6.1 Upstream Author : Samuel G. D. Williams * URL : https://github.com/socketry/async-rspec * License : MIT Programming Lang: Ruby Description : helpers for writing specs against the async gem Provides useful RSpec.shared_contexts for testing code that builds on top of async. This package is needed to update other gem - ruby-async-http. ruby-async-rspec is necessary to introduce ruby-async-process, it is used to introduce ruby-localhost, and ruby-localhost is dependency for ruby-async-http update. 1. Introduce ruby-async-rspec <-- here 2. Introduce ruby-async-process 3. Introduce ruby-localhost 4. Update ruby-async-http
Bug#992692: general: Use https for {deb,security}.debian.org by default
Package: general
Severity: wishlist
Dear developers,
As we discussed on -devel(*), it seems that we can enable https for
{deb,security}.debian.org by default. With this bug report, I'll
collect related things and fix it.
- Update mirror list (how?)
- Update security mirror setting in d-i (how?)
- https://www.debian.org/mirror/list.en.html points http""://deb.debian.org,
it should be https.
- deb.debian.org says "deb http://;, it should be "deb https://;
- In release notes, it should be https://security.debian.org, at least
See
https://www.debian.org/releases/stable/amd64/release-notes/ch-information.html#security-archive
*) https://lists.debian.org/debian-devel/2021/08/msg00269.html
Bug#992664: ITP: ruby-parser -- Ruby parser written in pure Ruby
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, pkg-ruby-extras-maintain...@lists.alioth.debian.org * Package name: ruby-parser Version : 3.0.2.0 * URL : https://github.com/whitequark/parser * License : MIT Programming Lang: Ruby Description : Ruby parser written in pure Ruby Parser is a production-ready Ruby parser written in pure Ruby. It recognizes as much or more code than Ripper, Melbourne, JRubyParser or ruby_parser, and is vastly more convenient to use.
Bug#992185: release-notes: Confusion with "apt full-upgrade" and "apt-get dist-upgrade"
Package: release-notes Severity: minor X-Debbugs-Cc: henr...@debian.org Hi, In en/upgrading.dbk, one of its section title says about "Dist-upgrade", so it's about "apt-get dist-upgrade" > >Dist-upgrade fails with Could not perform immediate > configuration However, paragraphs continue as > > In some cases the apt full-upgrade step can fail after > downloading packages with: "apt full-upgrade", not apt-get. We should choose one to avoid confusion.
Bug#992020: ITP: scap-workbench -- Scanning and tailoring tool for SCAP content
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, he...@nerv.fi, k...@debian.org * Package name: scap-workbench Version : 1.2.1 Upstream Author : Red Hat * URL : https://www.open-scap.org/tools/scap-workbench/ * License : GPL-3+ Programming Lang: C++ Description : Scanning and tailoring tool for SCAP content SCAP is a line of standards managed by NIST with the goal of providing a standard language for the expression of Computer Network Defense related information. . The main goal of this application is to lower the initial barrier of using SCAP. Therefore, the scope of very narrow - scap-workbench only scans a single machine and only with XCCDF/SDS (no direct OVAL evaluation). The assumption is that this is enough for users who want to scan a few machines and users with huge amount of machines to scan will just use scap-workbench to test or hand-tune their content before deploying it with more advanced (and harder to use) tools like spacewalk. . Feature highlights: * XCCDF 1.1 and 1.2 support * Source Data Stream 1.2 support * XCCDF 1.2 Tailoring file support * Evaluation of local machine * Evaluation of remote machine (using ssh) * Limited tailoring support - selection and unselection * Saving results as XCCDF 1.1 or 1.2 (depending on input) or ARF 1.1 Note: this package was removed once from archive sicne it depended on deprecated Qt4, see https://tracker.debian.org/news/1106349/removed-115-1-from-unstable/ But new upstream version is successfully migrated to Qt5, so push it again.
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
Hi, I've restructured openscap pacakge to fix Bug#990183 and make it better, upload to https://salsa.debian.org/henrich/openscap I'll upload it to experimental with delay-10, if you want to cancel it, don't hestitate. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#990881: ITP: gn -- meta-build system that generates build files for Ninja
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org * Package name: gn Upstream Author : The Chromium Authors * URL : https://gn.googlesource.com/gn * License : BSD-3-Clause Programming Lang: C++ Description : meta-build system that generates build files for Ninja It can generate Ninja build files for C, C++, Rust, Objective C, and Swift source on most popular platforms. Other languages can be compiled using the general “action” rules which are executed by Python or another scripting language (Google does this to compile Java and Go). But because this is not as clean, generally GN is only used when the bulk of the build is in one of the main built-in languages.
Bug#990412: pam: Regression - it won't search /lib/security
Hi Sam, On Tue, 06 Jul 2021 08:46:30 -0600 Sam Hartman wrote: > This many years after multiarch, I think it is entirely reasonable for > PAM to drop support for non-multiarch paths at the transition between > buster and bullseye. It was NOT raised as a goal of bullseye for libpam-* packages those are not multiarch-ed, IMO. And at this time, last minutes for release, we should ensure "it works" as previously to deliver values for users. Breaking several libpam-* packages is not. Is there any *strong* reason to not deffer make libpam-* packages multiarch-ed to bookworm release? > I think Steve is quite familiar with multiarch and while he hasn't > commented yet I'm assuming he dropped those patch lines as part of > removing unnecessary upstream deltas. I want his comment, too. git log in his repo just says "refresh patches" for this change, and debian/patches-applied/lib_security_multiarch_compat is the patch for non-multiarch pam modules and still remains. If it was intended, it should be removed, I suppose. > I think you failed to read my comments in the 990412 bug log before > Merging and reassigning. Okay, will read again. Thanks! -- Hideki Yamane
Bug#990412: pam: Regression - it won't search /lib/security
control: tags -1 +patch +pending
Hi,
I've found the root cause of this bug, and fixed it.
On my local sid machine, I've tested it with edit /etc/pam.d/su
as search pam_yubico.so, exec su and it searchs /lib/security/pam_yubico.so :)
See below debdiff. If it seems to be okay, I'll put it into sid
and request unblock.
diff -Nru pam-1.4.0/debian/changelog pam-1.4.0/debian/changelog
--- pam-1.4.0/debian/changelog 2021-03-16 04:01:55.0 +0900
+++ pam-1.4.0/debian/changelog 2021-07-06 22:09:15.0 +0900
@@ -1,3 +1,13 @@
+pam (1.4.0-7.1) unstable; urgency=high
+
+ * Non-maintainer upload.
+ * debian/patches-applied/lib_security_multiarch_compat
+- Fix regression that was introduced in 1.4.0-1, some lines were not
+ applied during refresh patch and it doesn't work.
+ (Closes: #979973, #990412)
+
+ -- Hideki Yamane Tue, 06 Jul 2021 22:09:15 +0900
+
pam (1.4.0-7) unstable; urgency=medium
* Updated portuguese debconf translation, thanks Pedro Ribeiro, Closes:
diff -Nru pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
--- pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
2021-01-31 07:09:52.0 +0900
+++ pam-1.4.0/debian/patches-applied/lib_security_multiarch_compat
2021-07-06 22:09:15.0 +0900
@@ -11,11 +11,11 @@
order to get everything installed where we want it and get absolute paths
the way we want them.
-Index: pam/libpam/pam_handlers.c
+Index: pam-1.4.0/libpam/pam_handlers.c
===
pam.orig/libpam/pam_handlers.c
-+++ pam/libpam/pam_handlers.c
-@@ -735,7 +735,18 @@
+--- pam-1.4.0.orig/libpam/pam_handlers.c
pam-1.4.0/libpam/pam_handlers.c
+@@ -735,7 +735,27 @@ _pam_load_module(pam_handle_t *pamh, con
success = PAM_ABORT;
D(("_pam_load_module: _pam_dlopen(%s)", mod_path));
@@ -31,11 +31,20 @@
+ } else {
+ pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
+ }
++ if (!mod->dl_handle) {
++ if (asprintf(_full_path, "%s/%s",
++_PAM_ISA, mod_path) >= 0) {
++ mod->dl_handle = _pam_dlopen(mod_full_path);
++ _pam_drop(mod_full_path);
++ } else {
++ pam_syslog(pamh, LOG_CRIT, "cannot malloc full mod path");
++ }
++ }
+ }
D(("_pam_load_module: _pam_dlopen'ed"));
D(("_pam_load_module: dlopen'ed"));
if (mod->dl_handle == NULL) {
-@@ -812,7 +823,6 @@
+@@ -812,7 +832,6 @@ int _pam_add_handler(pam_handle_t *pamh
struct handler **handler_p2;
struct handlers *the_handlers;
const char *sym, *sym2;
@@ -43,7 +52,7 @@
servicefn func, func2;
int mod_type = PAM_MT_FAULTY_MOD;
-@@ -824,16 +834,7 @@
+@@ -824,16 +843,7 @@ int _pam_add_handler(pam_handle_t *pamh
if ((handler_type == PAM_HT_MODULE || handler_type ==
PAM_HT_SILENT_MODULE) &&
mod_path != NULL) {
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
On Sat, 3 Jul 2021 21:36:53 +0900
Hideki Yamane wrote:
> Mostly done, still have an error with autopkgtest for python3-openscap
Updated. Passed all salsa-ci test as below, and eliminate most of
lintian warning/info.
https://salsa.debian.org/henrich/openscap/-/pipelines/265972
diff -Nru openscap-1.3.4/debian/changelog openscap-1.3.4/debian/changelog
--- openscap-1.3.4/debian/changelog 2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/changelog 2021-06-30 16:33:53.0 +0900
@@ -1,3 +1,37 @@
+openscap (1.3.4-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ * Package structure changes
+- Apply soname change (libopenscap8 -> 25)
+- Split libopenscap25 to openscap-scanner, openscap-utils and
+ openscap-common
+- Drop -dbg package and unnecessary lintian-overrides
+ * debian/control
+- Specify https for upstream URL
+- Use debhelper-compat (= 13) to not forget to install necessary files
+ with dh_missing
+- Add missing dependencies: libacl1-dev, libblkid-dev, libglib2.0-dev,
+ libyaml-dev, librpm-dev, libpopt-dev, libprocps-dev, libopendbx1-dev,
+ libxmlsec1-dev, doxygen, graphviz, asciidoc,
+ * Drop unnecessary debian/compat
+ * debian/rules
+- Enable documentation build
+- Enable hardening
+ * Add openscap-common.docs to install HTML docs
+ * debian/openscap-scanner.install
+- Install bash-completion
+ * openscap-utils.install
+- Install autotailor and scap-as-rpm
+ * Add debian/openscap-{scanner,utils}.manpages
+
+ * Trim trailing whitespace.
+ * Update watch file format version to 4.
+ * Set upstream metadata fields: Bug-Database, Bug-Submit.
+ * Drop unnecessary dependency on dh-autoreconf.
+
+ -- Hideki Yamane Wed, 30 Jun 2021 16:33:53 +0900
+
openscap (1.3.4-1) unstable; urgency=medium
* New upstream version 1.3.4
diff -Nru openscap-1.3.4/debian/compat openscap-1.3.4/debian/compat
--- openscap-1.3.4/debian/compat2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/compat1970-01-01 09:00:00.0 +0900
@@ -1 +0,0 @@
-11
diff -Nru openscap-1.3.4/debian/control openscap-1.3.4/debian/control
--- openscap-1.3.4/debian/control 2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/control 2021-06-30 16:33:53.0 +0900
@@ -2,7 +2,7 @@
Priority: optional
Maintainer: Pierre Chifflier
Uploaders: Philippe Thierry
-Build-Depends: debhelper (>= 13),
+Build-Depends: debhelper-compat (= 13),
cmake,
libpcre3-dev,
libxml2-dev,
@@ -18,19 +18,30 @@
libattr1-dev,
libldap2-dev,
libbz2-dev,
+libacl1-dev,
+libblkid-dev,
+libglib2.0-dev,
+libyaml-dev,
+librpm-dev,
+libpopt-dev,
+libprocps-dev,
+libopendbx1-dev,
+libxmlsec1-dev,
+doxygen, graphviz,
+asciidoc,
pkg-config,
dh-python,
chrpath,
libdbus-1-dev
+Section: admin
X-Python3-Version: >= 3.9
Standards-Version: 4.5.1
-Section: libs
-Homepage: http://www.open-scap.org/
+Homepage: https://www.open-scap.org/
Package: libopenscap-dev
Section: libdevel
Architecture: linux-any
-Depends: libopenscap8 (= ${binary:Version}), ${misc:Depends},
${python3:Depends}, libjs-jquery
+Depends: libopenscap25 (= ${binary:Version}), ${misc:Depends},
${python3:Depends}, libjs-jquery
Description: Set of libraries enabling integration of the SCAP line of
standards
OpenSCAP is a set of open source libraries providing an easier path
for integration of the SCAP line of standards. SCAP is a line of
@@ -48,13 +59,13 @@
.
This package contains the development files for OpenSCAP.
-Package: libopenscap8
+Package: libopenscap25
Section: libs
Architecture: linux-any
-Conflicts: libopenscap0, libopenscap1, libopenscap3
-Replaces: libopenscap0, libopenscap1, libopenscap3
+Conflicts: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
+Replaces: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
Description: Set of libraries enabling integration of the SCAP line of
standards
OpenSCAP is a set of open source libraries providing an easier path
for integration of the SCAP line of standards. SCAP is a line of
@@ -69,11 +80,13 @@
* Common Vulnerability Scoring System (CVSS)
* Extensible Configuration Checklist Description Format (XCCDF)
* Open Vulnerability and Assessment Language (OVAL)
+ .
+ This package contains libraries for OpenSCAP.
Package: python3-openscap
Section: python
Architecture: linux-any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libopenscap8
(= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libopenscap25
(= ${binary:Version})
X-Python3-Version: ${python3:Versions}
Provides: ${python3:Provides}
Description: Set of libraries enabling integration of t
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
On Fri, 2 Jul 2021 00:43:02 +0200
Sebastian Ramacher wrote:
> Yes, but note that this needs to happen soon as it has to pass NEW.
Mostly done, still have an error with autopkgtest for python3-openscap
https://salsa.debian.org/henrich/openscap/-/pipelines/265919
(It doesn't have git repo, so I pushed it under my user at salsa).
It includes fixes a *lot* (sorry at this freeze time, but...), if it should
be shrunk, we can rebase it.
diff -Nru openscap-1.3.4/debian/changelog openscap-1.3.4/debian/changelog
--- openscap-1.3.4/debian/changelog 2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/changelog 2021-06-30 16:33:53.0 +0900
@@ -1,3 +1,37 @@
+openscap (1.3.4-1.1) UNRELEASED; urgency=medium
+
+ * Non-maintainer upload.
+
+ * Package structure changes
+- Apply soname change (libopenscap8 -> 25)
+- Split libopenscap25 to openscap-scanner, openscap-utils and
+ openscap-common
+- Drop -dbg package and unnecessary lintian-overrides
+ * debian/control
+- Specify https for upstream URL
+- Use debhelper-compat (= 13) to not forget to install necessary files
+ with dh_missing
+- Add missing dependencies: libacl1-dev, libblkid-dev, libglib2.0-dev,
+ libyaml-dev, librpm-dev, libpopt-dev, libprocps-dev, libopendbx1-dev,
+ libxmlsec1-dev, doxygen, graphviz, asciidoc,
+ * Drop unnecessary debian/compat
+ * debian/rules
+- Enable documantation build
+- Enable hardening
+ * Add openscap-common.docs to install HTML docs
+ * debian/openscap-scanner.install
+- Install bash-completion
+ * openscap-utils.install
+- Install autotailor and scap-as-rpm
+ * Add debian/openscap-{scanner,utils}.manpages
+
+ * Trim trailing whitespace.
+ * Update watch file format version to 4.
+ * Set upstream metadata fields: Bug-Database, Bug-Submit.
+ * Drop unnecessary dependency on dh-autoreconf.
+
+ -- Hideki Yamane Wed, 30 Jun 2021 16:33:53 +0900
+
openscap (1.3.4-1) unstable; urgency=medium
* New upstream version 1.3.4
diff -Nru openscap-1.3.4/debian/compat openscap-1.3.4/debian/compat
--- openscap-1.3.4/debian/compat2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/compat1970-01-01 09:00:00.0 +0900
@@ -1 +0,0 @@
-11
diff -Nru openscap-1.3.4/debian/control openscap-1.3.4/debian/control
--- openscap-1.3.4/debian/control 2021-02-02 00:22:30.0 +0900
+++ openscap-1.3.4/debian/control 2021-06-30 16:33:53.0 +0900
@@ -2,7 +2,7 @@
Priority: optional
Maintainer: Pierre Chifflier
Uploaders: Philippe Thierry
-Build-Depends: debhelper (>= 13),
+Build-Depends: debhelper-compat (= 13),
cmake,
libpcre3-dev,
libxml2-dev,
@@ -18,19 +18,30 @@
libattr1-dev,
libldap2-dev,
libbz2-dev,
+libacl1-dev,
+libblkid-dev,
+libglib2.0-dev,
+libyaml-dev,
+librpm-dev,
+libpopt-dev,
+libprocps-dev,
+libopendbx1-dev,
+libxmlsec1-dev,
+doxygen, graphviz,
+asciidoc,
pkg-config,
dh-python,
chrpath,
libdbus-1-dev
+Section: admin
X-Python3-Version: >= 3.9
Standards-Version: 4.5.1
-Section: libs
-Homepage: http://www.open-scap.org/
+Homepage: https://www.open-scap.org/
Package: libopenscap-dev
Section: libdevel
Architecture: linux-any
-Depends: libopenscap8 (= ${binary:Version}), ${misc:Depends},
${python3:Depends}, libjs-jquery
+Depends: libopenscap25 (= ${binary:Version}), ${misc:Depends},
${python3:Depends}, libjs-jquery
Description: Set of libraries enabling integration of the SCAP line of
standards
OpenSCAP is a set of open source libraries providing an easier path
for integration of the SCAP line of standards. SCAP is a line of
@@ -48,13 +59,13 @@
.
This package contains the development files for OpenSCAP.
-Package: libopenscap8
+Package: libopenscap25
Section: libs
Architecture: linux-any
-Conflicts: libopenscap0, libopenscap1, libopenscap3
-Replaces: libopenscap0, libopenscap1, libopenscap3
+Conflicts: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
+Replaces: libopenscap0, libopenscap1, libopenscap3, libopenscap8,
Pre-Depends: ${misc:Pre-Depends}
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}
+Depends: ${shlibs:Depends}, ${misc:Depends},
Description: Set of libraries enabling integration of the SCAP line of
standards
OpenSCAP is a set of open source libraries providing an easier path
for integration of the SCAP line of standards. SCAP is a line of
@@ -69,11 +80,13 @@
* Common Vulnerability Scoring System (CVSS)
* Extensible Configuration Checklist Description Format (XCCDF)
* Open Vulnerability and Assessment Language (OVAL)
+ .
+ This package contains libraries for OpenSCAP.
Package: python3-openscap
Section: python
Architecture: linux-any
-Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, libopenscap8
(= ${binary:Version})
+Depends: ${shlibs:Depends}, ${misc:Depends}, ${python3:Depends}, l
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
On Fri, 2 Jul 2021 00:43:02 +0200 Sebastian Ramacher wrote: > Yes, but note that this needs to happen soon as it has to pass NEW. Thanks, I'll try it. -- Hideki Yamane
Bug#989799: psmisc: Undeclared file conflict with manpages-de
Hi Helge, On Fri, 2 Jul 2021 10:29:53 +0900 Hideki Yamane wrote: > We can close it via mail, but should investigate its reason, IMO. Note it as https://bugs.debian.org/990557 Let's close Bug#989799 via hand. -- Hideki Yamane
Bug#990557: bugs.debian.org: Not automatically close Bug#989799 for buster-backports
Package: bugs.debian.org Severity: important Dear Maintainer, As https://tracker.debian.org/news/1243791/accepted-manpages-l10n-4100-1bpo101-source-into-buster-backports-backports-policy-buster-backports/ Bug#989799 was noted as "Closes" but not done automatically. We expect that is closed, is it BTS system side issue or not?
Bug#989799: psmisc: Undeclared file conflict with manpages-de
On Thu, 1 Jul 2021 21:07:03 +0200 Helge Kreutzmann wrote: > It now has. So this bug is closed, if users upgrade to the latestes > backport version. Hmm, however, this bug is not closed automatically. Weird. https://tracker.debian.org/news/1243791/accepted-manpages-l10n-4100-1bpo101-source-into-buster-backports-backports-policy-buster-backports/ We can close it via mail, but should investigate its reason, IMO. -- Hideki Yamane
Bug#990183: libopenscap8: libopenscap.so.8 is missing from libopenscap8 and is expected by scap-workbench
Hi, On Tue, 22 Jun 2021 11:23:51 +0200 Sebastian Ramacher wrote: > 1.3.4-1 would have needed to rename the package to libopenscap25 and > start a library transition. The library package also contains a bunch of > binaries and other files that do not look like the should be part of a > library package. In any case, raising the severity to serious is the > current packaging of the library is broken. Can we have a chance to put splitted packages (openscap-scanner as tools binary as other distros do and openscap-common for /usr/share files) for bullseye release? If so, I'll try to do so. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#989799: psmisc: Undeclared file conflict with manpages-de
from buster-backports Message-Id: <20210630134637.d8e6f92027ef11aeb9a09...@iijmio-mail.jp> In-Reply-To: <20210627060424.GA7522@Debian-50-lenny-64-minimal> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Sun, 27 Jun 2021 08:04:24 +0200 Helge Kreutzmann wrote: > manpages-l10n (4.10.0-1~bpo10+1) buster-backports; urgency=medium > > * Rebuild for buster-backports. > * Properly conflict with future versions of psmisc and procps so that > upgrades to bullseye will work without file conflicts. Closes: #989799 > > -- Helge Kreutzmann Sun, 20 Jun 2021 10:27:10 +0200 > > Also tracker.debian.org does not show (yet), that it has been accepted. Have it reached to buster-backports repo? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#990263: podman sets oom_score_adj to -1000 for processes inside the
container so the system breaks in OOM situations Message-Id: <20210629000848.a3125fe89a9984a780074...@iijmio-mail.jp> In-Reply-To: <502056d5848360369973f2c96882ff37ad42bb4f.ca...@doo.shop> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Hi, On Thu, 24 Jun 2021 11:37:35 +0200 Max Bruckner wrote: > How to reproduce: > > ``` > # podman run -it --rm debian sh > # cat /proc/$$/oom_score_adj > -1000 > ``` Well, I've tested it too with bullseye on KVM and reproduced it, however, it's only under root privilege. Just run "$ podman run -it --rm debian sh" via normal user and it returns 0. And also tested with my daily driver unstable system I cannot reproduce it. (But sid on KVM can reproduce it, hmm...) It may be better to downgrade as important if it's only root privilege, IMO. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#934713: os-prober: missing dependency on mount
control: tags -1 +patch On Thu, 15 Aug 2019 16:49:46 +0200 Johannes Schauer wrote: > > > https://lists.debian.org/20170726081846.ga22...@fatal.se > > > > Well, debian-devel@ isn't where one files bug reports against packages that > > suddenly need a dependency? > > I was not trying to justify or excuse the omission of the src:util-linux > maintainers. I can only imagine that os-prober somehow slipped through the > cracks when the src:util-linux maintainers filed bugs against all packages > that > need the mount utilities during the buster release cycle. > > I agree that the situation now is unfortunate but I only reported this problem > once I stumbled across it. I was not involved in the decision two years ago. Anyway, here's a tiny MR https://salsa.debian.org/installer-team/os-prober/-/merge_requests/9 If it would be a wrong way to deal with this bug, then close above MR and remove Tags: patch, please. If not - just merge it and push the package :D -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#239449: xfonts-scalable-nonfree doesn't set up type 1 fonts
control: reassign -1 t1-xfree86-nonfree control: tags -1 +confirmed On Mon, 22 Mar 2004 20:47:01 +0100 Daniel Skorka wrote: > This package contains some type 1 fonts that aren't set up for use by > X11. There is a file called > '/etc/X11/fonts/Type1/xfonts-scalable-nonfree.scale', but it is empty. Type 1 fonts are provided as t1-xfree86-nonfree, so reassign it. As https://docs.freebsd.org/en/articles/fonts/#type1-fonts-x11, it seems that we can setup its /etc/X11/fonts/Type1/t1-xfree86-nonfree.scale file but now it contains just "0". $ cat /etc/X11/fonts/Type1/t1-xfree86-nonfree.scale 0 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#989255: qbittorrent-nox web UI fails after qt5 upgrade
control: reassign -1 libqt5core5a control: affects -1 qbittorrent-nox control: tags -1 -unreproducible control: block -1 by 989744 On Sun, 27 Jun 2021 12:03:15 +0200 Hovno Cuc wrote: > Hello, > I think the issue for me is, that with libqt5core5a 5.15.2+dfsg-5 the > qbittorrent-nox reports this content type: > > content-type: text/html > > while with version 5.15.2+dfsg-7 it reports the following content type: > > content-type: application/x-extension-html > > and firefox instead of displaying the web page, it offers to download it. Okay, it's libqt5core5a's issue, thus reassign to it. -- Hideki Yamane
Bug#989255: qbittorrent-nox web UI fails after qt5 upgrade
control: tags -1 +unreproducible control: severity -1 important On Sun, 30 May 2021 09:09:27 -0500 allan grossman wrote: > Ran aptitude safe-upgrade this morning which updated qt5 libraries. > After reboot, qbittorrent-nox web UI is inaccessible. > Tried opening web UI in Chrome and Firefox and both browsers download > the page instead of opening it. Backend works just > fine as radarr and sonarr are both communicating with it just fine but > web UI is broken. I've tested that with those environment but couldn't reproduce it, Web UI works fine. - sid - bullseye on docker - fresh install bullseye on KVM So, once tags it as unreproducible and downgrade severity. Could you install qbittorrent-dbg and run it with strace as "strace qbittorrent-nox --skipdialog=true" and send debug log, please? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#988358: bucardo: please use versioned Depends: libpod-parser-perl (>= 1.63)
control: tags -1 +patch Hi, Here's a tiny MR for it. https://salsa.debian.org/postgresql/bucardo/-/merge_requests/2 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#987461: libuima-adapter-soap-java is empty
On Mon, 21 Jun 2021 16:47:49 -0700 tony mancill wrote: > My apologies if using Breaks in this way is a common pattern. I am > simply not familiar with it. If you have used the pattern before, I > will upgrade the package as-is, since your way is cleaner. Otherwise, I > will remove the Breaks. Not so much common, "Breaks: + Replaces: + Provides:" pattern is the common case for package replacement. I cannot remember whether I used it before... Please remove Breaks: since ftpmasters would be happy with more simple debdiff :) -- Hideki Yamane
Bug#987461: libuima-adapter-soap-java is empty
Hi, On Mon, 21 Jun 2021 11:52:14 -0700 tony mancill wrote: > I saw the note in the changelog that Breaks is in fact there to remove > the empty package, but it's not happening for me when I try to upgrade > locally. My test case is to install uima-utils (which will install > libuima-adapter-soap-java via Recommends) and then try to upgrade the > binaries to 2.10.2-4 using dpkg. Well, it would remove libuima-adapter-soap-java if I've tested it on chroot env as below. # apt install /tmp/libuima-core-java_2.10.2-4_all.deb (snip) The following packages will be REMOVED: libuima-adapter-soap-java The following packages will be upgraded: libuima-core-java 1 upgraded, 0 newly installed, 1 to remove and 0 not upgraded. Need to get 0 B/1513 kB of archives. After this operation, 12.3 kB disk space will be freed. > The only way I can make this work is remove libuima-adapter-soap-java > manually. Are you sure that Breaks is necessary? apt-get autoremove > will clean up libuima-adapter-soap-java at some point. Okay, libuima-adapter-soap-java is empty now, just manual autoremove is fine. > I took a look at policy to see if Breaks + Replaces should be used in > this situation, but I'm not sure it really applies (although I think it > would work better than just Breaks). Still, I'm unsure about the need > for Breaks for this empty package clean-up use case. I don't think "Replaces" to be used in this situation since it does not provide any fuctions as same as previous one. > Any concerns if I drop the Breaks before the upload? None, please go ahead for bullseye :) -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#989103: pulseaudio crashes on startup
control: tags -1 -moreinfo
control: tags -1 -unreproducible
control: tags -1 +patch
Hi,
On Mon, 7 Jun 2021 22:37:11 +0300 Igor Kovalenko
wrote:
> I confirm this is a regression in pulseaudio-14.0, fixed in pulseaudio
> master now.
>
> https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/merge_requests/576
Thank you, let's patch for debian package, then.
I've attached patches not MR, since some commits were already done
in master branch.
--
Regards,
Hideki Yamane henrich @ debian.org/iijmio-mail.jp
>From 7b3a5ada2664e16a44edec2f0abe65f5a12f4fc1 Mon Sep 17 00:00:00 2001
From: Hideki Yamane
Date: Mon, 21 Jun 2021 02:32:42 +0900
Subject: [PATCH 2/2] note to changelog
---
debian/changelog | 9 +
1 file changed, 9 insertions(+)
diff --git a/debian/changelog b/debian/changelog
index dffa6bc8..5ede7839 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,12 @@
+pulseaudio (14.2-2.1) unstable; urgency=medium
+
+ * NMU.
+ * debian/patches
+- Add: 0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
+ (Closes: #989103)
+
+ -- Hideki Yamane Mon, 21 Jun 2021 02:31:10 +0900
+
pulseaudio (14.2-2) unstable; urgency=medium
* Stop installing the console kit module.
--
2.32.0
>From fef59ed6742bdec063267122fdb360826adaed18 Mon Sep 17 00:00:00 2001
From: Hideki Yamane
Date: Mon, 21 Jun 2021 02:27:34 +0900
Subject: [PATCH 1/2] Add
0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
---
...mixer-check-if-mapping-is-NULL-befor.patch | 39 +++
debian/patches/series | 1 +
2 files changed, 40 insertions(+)
create mode 100644 debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
diff --git a/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch b/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
new file mode 100644
index ..c9f84b66
--- /dev/null
+++ b/debian/patches/0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
@@ -0,0 +1,39 @@
+From: Hideki Yamane
+Date: Mon, 21 Jun 2021 02:25:34 +0900
+Subject: Bug#989103 alsa-mixer: check if mapping is NULL before using it
+
+Taken from upstream git, see
+https://gitlab.freedesktop.org/pulseaudio/pulseaudio/-/commit/79cb1369fc4d22966cb65253e9da2ccda2f25b45?merge_request_iid=576
+---
+ src/modules/alsa/alsa-sink.c | 3 ++-
+ src/modules/alsa/alsa-source.c | 3 ++-
+ 2 files changed, 4 insertions(+), 2 deletions(-)
+
+diff --git a/src/modules/alsa/alsa-sink.c b/src/modules/alsa/alsa-sink.c
+index f7fef8a..84cdb15 100644
+--- a/src/modules/alsa/alsa-sink.c
b/src/modules/alsa/alsa-sink.c
+@@ -2107,7 +2107,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, true);
+ } else {
+diff --git a/src/modules/alsa/alsa-source.c b/src/modules/alsa/alsa-source.c
+index 76370f8..083f928 100644
+--- a/src/modules/alsa/alsa-source.c
b/src/modules/alsa/alsa-source.c
+@@ -1813,7 +1813,8 @@ static void find_mixer(struct userdata *u, pa_alsa_mapping *mapping, const char
+ u->mixers = pa_hashmap_new_full(pa_idxset_string_hash_func, pa_idxset_string_compare_func,
+ NULL, (pa_free_cb_t) pa_alsa_mixer_free);
+
+-mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
++if (mapping)
++mdev = pa_proplist_gets(mapping->proplist, "alsa.mixer_device");
+ if (mdev) {
+ u->mixer_handle = pa_alsa_open_mixer_by_name(u->mixers, mdev, false);
+ } else {
diff --git a/debian/patches/series b/debian/patches/series
index 54c06fdd..fe50543a 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -1,2 +1,3 @@
disable-autospawn.patch
tests-fix-use-of-uninitialized-variable-cpu_info.patch
+0003-Bug-989103-alsa-mixer-check-if-mapping-is-NULL-befor.patch
--
2.32.0
Bug#987461: libuima-adapter-soap-java is empty
control: tags -1 +patch On Sat, 24 Apr 2021 18:40:31 +0200 Chris Hofstaedtler wrote: > It appears the change itself was intentional: > > > uimaj (2.10.2-2) unstable; urgency=medium > > > > * No longer build the uimaj-adapter-soap module > > > > -- Emmanuel Bourg Fri, 30 Nov 2018 09:07:17 +0100 > > However, the binary package should probably also have been removed. > > Maintainers, please come to a conclusion regarding the now empty binary > package. Okay, libuima-adapter-soap-java has no reverse dependency. $ apt-rdepends -r libuima-adapter-soap-java Reading package lists... Done Building dependency tree... Done Reading state information... Done libuima-adapter-soap-java So let's remove its binary package and add Breaks: to it. MR is here, could someone review it, please? https://salsa.debian.org/java-team/uimaj/-/merge_requests/1 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#990065: unblock: squid-deb-proxy/0.8.15+nmu1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package squid-deb-proxy [ Reason ] squid-deb-proxy needs its apparmor profile to work. [ Impact ] squid-deb-proxy does not work on bullseye (There's a alternative, so not grave for all users). [ Tests ] Tested on KVM bullseye environment, it does not work well without this changes as the bug report says, and patched system works fine. [ Risks ] None, IMHO. - It's leaf package - Its change does not affect its behavior, it's just for apparmor and does not affect other package, too. - Code is trivial one [ 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 unblock squid-deb-proxy/0.8.15+nmu1 diff -Nru squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy --- squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 1970-01-01 09:00:00.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy 2021-06-14 23:38:09.0 +0900 @@ -0,0 +1,6 @@ +# vim:syntax=apparmor + +/etc/squid-deb-proxy/** r, +/var/log/squid-deb-proxy/* rw, +/run/squid-deb-proxy.pid rwk, +/var/cache/squid-deb-proxy/** rw, diff -Nru squid-deb-proxy-0.8.15/debian/changelog squid-deb-proxy-0.8.15+nmu1/debian/changelog --- squid-deb-proxy-0.8.15/debian/changelog 2020-01-19 03:00:55.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/changelog2021-06-14 23:41:11.0 +0900 @@ -1,3 +1,10 @@ +squid-deb-proxy (0.8.15+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Add apparmor profiles to work (Closes: #932501) + + -- Hideki Yamane Mon, 14 Jun 2021 23:41:11 +0900 + squid-deb-proxy (0.8.15) unstable; urgency=medium [ Graham Cantin ] diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs 2020-01-10 19:02:40.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs 2021-06-14 23:40:40.0 +0900 @@ -1,2 +1,3 @@ etc/resolvconf/update-libc.d +etc/apparmor.d/abstractions/squid-deb-proxy var/log/squid-deb-proxy diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 2020-01-10 19:02:40.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install 2021-06-14 23:40:21.0 +0900 @@ -1,3 +1,4 @@ ../update-libc.d etc/resolvconf/ etc/squid-deb-proxy init-common.sh usr/share/squid-deb-proxy/ +../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/
Bug#989491: libxstream-java: CVE-2021-29505
On Sat, 05 Jun 2021 09:29:20 +0200 Salvatore Bonaccorso wrote: > Source: libxstream-java > Version: 1.4.15-2 Let's check it with buster version, then. Here's a patch for it, it lacks some blacklist items from current unstable version but it should be so if sticks to a minimum. Anyway, could you review it, please libstream-java.debdiff Description: Binary data
Bug#989080: cifs-utils: Fix for CVE-2021-20208 breaks cifs.upcall
control: tags -1 +patch Here's MR https://salsa.debian.org/samba-team/cifs-utils/-/merge_requests/8
Bug#989438: CVE-2021-31855
control: tags -1 +patch Merge Request was prepared as https://salsa.debian.org/qt-kde-team/kde/messagelib/-/commit/30133062524fefeafd0784837d868b603f0797f1 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#980466: cervisia: missing dependency on kinit package
control: tags -1 +confirmed +patch
Hi,
I'd prepare tiny patch for this issue as below.
diff --git a/debian/changelog b/debian/changelog
index cbd284c..7fde2e5 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,10 @@
+cervisia (4:20.12.0-1.1) unstable; urgency=medium
+
+ * Non-maintainer upload.
+ * Fix dependency to exec without whole KDE environment (Closes: #980466)
+
+ -- Hideki Yamane Tue, 15 Jun 2021 01:08:14 +0900
+
cervisia (4:20.12.0-1) unstable; urgency=medium
* Team upload.
diff --git a/debian/control b/debian/control
index 44c6731..9da63c4 100644
--- a/debian/control
+++ b/debian/control
@@ -29,7 +29,8 @@ Rules-Requires-Root: no
Package: cervisia
Architecture: any
Section: devel
-Depends: cvsservice (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends}
+Depends: cvsservice (= ${binary:Version}), ${misc:Depends}, ${shlibs:Depends},
+ kinit,
Suggests: khelpcenter
Description: graphical CVS client
Cervisia is a front-end for the CVS version control system client.
Bug#932501: problem still present in 0.8.15
On Tue, 13 Apr 2021 20:13:59 +0200 =?UTF-8?B?SsOpcsOpbXkgVmnDqHM=?= wrote: > Just to confirm the issue is still present in bullseye current release. > I had to add the following lines to apparmor configuration to make it work. > > /etc/squid-deb-proxy/** r, > /var/log/squid-deb-proxy/* rw, > /run/squid-deb-proxy.pid rwk, > /var/cache/squid-deb-proxy/** rw, Thank you, put it to debdiff now. diff -Nru squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy --- squid-deb-proxy-0.8.15/debian/apparmor-profiles/squid-deb-proxy 1970-01-01 09:00:00.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/apparmor-profiles/squid-deb-proxy 2021-06-14 23:38:09.0 +0900 @@ -0,0 +1,6 @@ +# vim:syntax=apparmor + +/etc/squid-deb-proxy/** r, +/var/log/squid-deb-proxy/* rw, +/run/squid-deb-proxy.pid rwk, +/var/cache/squid-deb-proxy/** rw, diff -Nru squid-deb-proxy-0.8.15/debian/changelog squid-deb-proxy-0.8.15+nmu1/debian/changelog --- squid-deb-proxy-0.8.15/debian/changelog 2020-01-19 03:00:55.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/changelog2021-06-14 23:41:11.0 +0900 @@ -1,3 +1,10 @@ +squid-deb-proxy (0.8.15+nmu1) unstable; urgency=medium + + * Non-maintainer upload. + * Add apparmor profiles to work (Closes: #932501) + + -- Hideki Yamane Mon, 14 Jun 2021 23:41:11 +0900 + squid-deb-proxy (0.8.15) unstable; urgency=medium [ Graham Cantin ] diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.dirs 2020-01-10 19:02:40.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.dirs 2021-06-14 23:40:40.0 +0900 @@ -1,2 +1,3 @@ etc/resolvconf/update-libc.d +etc/apparmor.d/abstractions/squid-deb-proxy var/log/squid-deb-proxy diff -Nru squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install --- squid-deb-proxy-0.8.15/debian/squid-deb-proxy.install 2020-01-10 19:02:40.0 +0900 +++ squid-deb-proxy-0.8.15+nmu1/debian/squid-deb-proxy.install 2021-06-14 23:40:21.0 +0900 @@ -1,3 +1,4 @@ ../update-libc.d etc/resolvconf/ etc/squid-deb-proxy init-common.sh usr/share/squid-deb-proxy/ +../apparmor-profiles/* etc/apparmor.d/abstractions/squid-deb-proxy/
Bug#968897: src:pylint should provide a pylint3 transitional package
control: tags -1 +patch On Tue, 1 Jun 2021 22:49:18 +0300 Adrian Bunk wrote: > Provides is good for fulfilling dependencies, but won't for an upgrade > to the renamed package. Okay, then add transitional dummy package for it as below. If anything goes wrong, I'll upload it to delay-5 queue later. >From 2e52e9170265d4eb8160f813b07e34aa41b97521 Mon Sep 17 00:00:00 2001 From: Hideki Yamane Date: Mon, 14 Jun 2021 21:51:09 +0900 Subject: [PATCH 1/2] Add Transitional dummy package pylint3 (Closes: #968897) --- debian/control | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/debian/control b/debian/control index a60b507..cca8351 100644 --- a/debian/control +++ b/debian/control @@ -58,7 +58,7 @@ Depends: python3-astroid (>= 2.4.0), Recommends: python3-tk, Suggests: pylint-doc, python3-mccabe, -Breaks: pylint3, +Breaks: pylint3 (<< 2.7.2-2), python3-pylint-django (<< 2.0), python3-pylint-plugin-utils (<< 0.4), python3-pytest-pylint (<< 0.10), @@ -83,3 +83,9 @@ Description: Python 3 code static checker and UML diagram generator * pyreverse3: an UML diagram generator * symilar3: an independent similarities checker * epylint3: Emacs and Flymake compatible Pylint + +Package: pylint3 +Architecture: all +Depends: pylint +Description: Transitional dummy package + This is transitional dummy package for pylint, you can safely remove it. -- 2.32.0 >From 4d18a26c96b9a0b449a01efe198f8aa46ddc046d Mon Sep 17 00:00:00 2001 From: Hideki Yamane Date: Mon, 14 Jun 2021 22:04:59 +0900 Subject: [PATCH 2/2] note to changelog --- debian/changelog | 8 1 file changed, 8 insertions(+) diff --git a/debian/changelog b/debian/changelog index bae2d32..37bdddb 100644 --- a/debian/changelog +++ b/debian/changelog @@ -1,3 +1,11 @@ +pylint (2.7.2-2) unstable; urgency=medium + + * Team upload + * debian/control +- Introduce pylint3 trantional package for smooth upgrade (Closes: #968897) + + -- Hideki Yamane Mon, 14 Jun 2021 23:03:38 +0900 + pylint (2.7.2-1) unstable; urgency=medium * New upstream release -- 2.32.0
Bug#989554: Add argyll dependency
Hi, On Mon, 07 Jun 2021 13:36:17 + Age Bosma wrote: > The colour calibration functionality gnome-control-center will happily start > the lengthy process of colour testing, only the fail at the end with the > error: > > "Tools required for calibration are not installed" > > This without specifying which tools exactly. > > Installing the argyll package solves the issue. It seems that we can pull it via Recommends is enough as below. But its git repo is a bit confusing, should I patch it to 3.38.4-1 in unstable or more updated version 3.38.6-1 in repo? >From 9eaa7e05e3279637667b5aad6cc2555906c6ae6a Mon Sep 17 00:00:00 2001 From: Hideki Yamane Date: Mon, 14 Jun 2021 21:38:24 +0900 Subject: [PATCH] Add Recommends: argyll to provide color management feature (Closes: #989554) --- debian/control.in | 1 + 1 file changed, 1 insertion(+) diff --git a/debian/control.in b/debian/control.in index 7c106ecb3..4e02f278a 100644 --- a/debian/control.in +++ b/debian/control.in @@ -92,6 +92,7 @@ Recommends: cups-pk-helper, libnss-myhostname, cracklib-runtime, pulseaudio-module-bluetooth, +argyll, realmd Suggests: gnome-software | gnome-packagekit, gstreamer1.0-pulseaudio, -- 2.32.0
Bug#982723: ruby-rails-html-sanitizer: FTBFS: ERROR: Test "ruby2.7" failed.
Hi, It seems that is caused with latest ruby-loofah and it was fixed in upstream git repo. https://github.com/rails/rails-html-sanitizer.git I'll check it later, and push it if it works. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#989173: libuninameslist: FTBFS with -O0: nameslist.c:216: undefined reference to uniNamesList_NamesListVersionFR
Source: libuninameslist Severity: important Tags: patch ftbfs Justification: fails to build from source (but built successfully in the past) Hi, As gentoo developer Naohiro Aota has told me that they got a FTBFS issue with -O0 and solved it. See https://bugs.gentoo.org/781716 Well, we do not build it with -O0 but it's worth to take a look into it, IMHO.
Bug#988599: ITP: kata-containers -- secure container runtime with lightweight virtual machines
On Mon, 17 May 2021 00:28:51 +0800 Shengjing Zhu wrote: > * Package name: kata-containers I'm also interested in making its deb package. Can I join it? -- Hideki Yamane
Bug#987850: .uuid file stuck there
On Sat, 01 May 2021 04:44:27 +0800 積丹尼 Dan Jacobson wrote: > Package: ttf-xfree86-nonfree-syriac > > dpkg: warning: unable to delete old directory > '/usr/share/fonts/truetype/ttf-xfree86-nonfree-syriac': Directory not empty > stuck there: /usr/share/fonts/truetype/ttf-xfree86-nonfree-syriac/.uuid > It's not font package issue, fontconfig issue. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=897040 -- Hideki Yamane
Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?
Hi Andreas, Thanks for your suggestion. On Sun, 7 Mar 2021 08:47:05 +0100 Andreas Metzler wrote: > I think that might be a dh_installdeb error, it seems to check whether > the first character is a '/', and does not account for possible quoting > characters. > > This might work around this > rm_conffile /etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg,\ \* Well, * is considered as [prior-version], then. > BTW you should really specify [prior-version and [package]. Yes, but above problem prevent me to solve issue... -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#985192: unblock: libonig/6.9.6-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Please unblock package libonig [ Reason ] Current testing version 6.9.6-1 is not compatible with previous version 6.9.5-2. [ Impact ] If current testing version 6.9.6-1 would be shipped, it breaks some applications (e.g. sylfilter, etc). [ Tests ] Just manually checked for 6.9.6-1.1 works with sylfilter. [ Risks ] Changes are very minimal and easily reverted. [ 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 unblock libonig/6.9.6-1.1 diff -Nru libonig-6.9.6/debian/changelog libonig-6.9.6/debian/changelog --- libonig-6.9.6/debian/changelog 2020-11-08 21:08:04.0 +0900 +++ libonig-6.9.6/debian/changelog 2021-02-24 02:25:03.0 +0900 @@ -1,3 +1,12 @@ +libonig (6.9.6-1.1) unstable; urgency=high + + * Non-maintainer upload. + * debian/rules +- As upstream change, set "--enable-binary-compatible-posix-api=yes", + instead of "--enable-posix-api" (Closes: #983406) + + -- Hideki Yamane Wed, 24 Feb 2021 02:25:03 +0900 + libonig (6.9.6-1) unstable; urgency=medium * New upstream release. diff -Nru libonig-6.9.6/debian/rules libonig-6.9.6/debian/rules --- libonig-6.9.6/debian/rules 2020-11-08 19:46:09.0 +0900 +++ libonig-6.9.6/debian/rules 2021-02-24 02:24:56.0 +0900 @@ -17,7 +17,7 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- --enable-posix-api + dh_auto_configure -- --enable-binary-compatible-posix-api=yes override_dh_install: $(RM) debian/tmp/usr/bin/onig-config
Bug#929165: How to use rm_conffile to remove files that contain empty " ", comma "," and wildcard "*"?
X-debbugs-CC: debian-de...@lists.debian.org Hi, I've tried to remove files that was accidentally containts empty " ", comma "," and wildcard "*" via rm_conffile from dpkg-maintscript-helper. However, it returns an error like below. > dh_installdeb: error: The current conffile path for rm_conffile must be > present and absolute, got > '/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg, I've specified it like below. > # cat debian/ubuntu-dbgsym-keyring.maintscript > rm_conffile '/etc/apt/trusted.gpg.d/ubuntu-keyring-2016-dbgsym.gpg, *' > rm_conffile '/etc/apt/trusted.gpg.d/ubuntu-dbgsym-removed-keys.gpg, *' How to use rm_conffile to remove such files that contains empty, comma and * in its filenames? -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#983406: libonig: Upstream changes POSIX API configure option as --enable-binary-compatible-posix-api=yes
Source: libonig Version: 6.9.6-1 Severity: important Tags: patch Dear Maintainer, Bug#958467 strike back again, it's because the change in upstream. See README.md. > Version 6.9.6 > - > * When using configure script, if you have the POSIX API enabled in an earlier > version (disabled by default in 6.9.5) and you need application binary > compatibility > with the POSIX API, specify "--enable-binary-compatible-posix-api=yes" > instead of > "--enable-posix-api=yes". Starting in 6.9.6, "--enable-posix-api=yes" only > supports > source-level compatibility for 6.9.5 and earlier about POSIX API. (Issue #210) Just replace its option solves problem. -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.10.0-3-amd64 (SMP w/8 CPU threads) Locale: LANG=ja_JP.UTF-8, LC_CTYPE=ja_JP.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 diff -Nru libonig-6.9.6/debian/changelog libonig-6.9.6/debian/changelog --- libonig-6.9.6/debian/changelog 2020-11-08 21:08:04.0 +0900 +++ libonig-6.9.6/debian/changelog 2021-02-24 02:25:03.0 +0900 @@ -1,3 +1,12 @@ +libonig (6.9.6-1.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * debian/rules +- As upstream change, set "--enable-binary-compatible-posix-api=yes", + instead of "--enable-posix-api" + + -- Hideki Yamane Wed, 24 Feb 2021 02:25:03 +0900 + libonig (6.9.6-1) unstable; urgency=medium * New upstream release. diff -Nru libonig-6.9.6/debian/rules libonig-6.9.6/debian/rules --- libonig-6.9.6/debian/rules 2020-11-08 19:46:09.0 +0900 +++ libonig-6.9.6/debian/rules 2021-02-24 02:24:56.0 +0900 @@ -17,7 +17,7 @@ dh $@ override_dh_auto_configure: - dh_auto_configure -- --enable-posix-api + dh_auto_configure -- --enable-binary-compatible-posix-api=yes override_dh_install: $(RM) debian/tmp/usr/bin/onig-config
Bug#948876: fontforge: Segmentation fault, making kodi FTBFS
control: severity -1 important control: retitle -1 fontforge: memory leak issue Hi, > fontforge: Segmentation fault, making kodi FTBFS fontforge has still memory leak issues that are able to detect with sanitize DEB_BUILD_OPTION in debian/rules, however, kodi build can be without fontforge's segmentation fault now. So, downgrade severity and retitle it. -- Hideki Yamane
Bug#982284: fonts-yuseki-magic: wrong long description: identical to that of fonts-yusei-magic
control: reassign -1 ftp.debian.org control: retitle -1 RoM: fonts-yuseki-magic uploader's mistake Hi, I'm really sorry that it was mistake by me, just typo of fonts-yusei-magic... Could you remove it from experimental repo, please? -- Hideki Yamane
Bug#981426: RM: cu2qu -- ROM; merged to fonttools
Hi Yao, On Fri, 12 Feb 2021 10:49:57 +0800 Yao Wei wrote: > > And Yao, please push your changes for ufo2ft to salsa repo. > > Done! I forgot to push branch again :/ Thanks! pushed. -- Hideki Yamane
Bug#981426: RM: cu2qu -- ROM; merged to fonttools
Hi Paul, On Thu, 11 Feb 2021 21:32:54 +0100 Paul Gevers wrote: > So, Yao, what's the way forward for python3-fontmake and python3-ufo2ft? > Will fonttools provide python3-cu2qu? I've done with python3-ufo2ft, and just now done for python3-fontmake :) > > Date: Thu, 11 Feb 2021 14:49:37 +0900 > > Source: ufo2ft > > Architecture: source > > Version: 2.19.1-2 > > Distribution: unstable > > Urgency: medium > > Maintainer: Debian Fonts Task Force > > Changed-By: Hideki Yamane > > Changes: > > ufo2ft (2.19.1-2) unstable; urgency=medium > > . > >* Team upload > > . > >* debian/control > > - Set Build-Depends: python3-fonttools (>= 4.19.1) and drop > > python3-cu2qu > >* debian/patches > > - Add cu2qu_moved_to_fonttools.patch for above change And Yao, please push your changes for ufo2ft to salsa repo. -- Hideki Yamane
Bug#982079: ITP: fonts-yusei-magic -- handwritten letters written with permanent marker
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 control: retitle -1 ITP: fonts-yusei-magic -- handwritten letters written with permanent marker On Sat, 06 Feb 2021 22:01:09 +0900 (JST) Tatsuya Kinoshita wrote: > On 2021-02-06 at 19:04, Hideki Yamane wrote: > > * Package name: fonts-yuseki-magic > > * URL : https://github.com/tanukifont/YuseiMagic > > Typo? It should be fonts-yusei-magic. Ouch! Thanks for catching! - -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp http://wiki.debian.org/HidekiYamane -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEQZYJUbYxgXxV33EdBBJ4KqpAHFMFAmAf2YYACgkQBBJ4KqpA HFNEABAAsRA85RKzOYzKvNAnGNRmyCeXSihhOBYYN0rZPPeBAhnvGzE3pGcGUV1H bP3gxBcS/ta2GeM7ytAQxgOfRh/qxJBz9Iebotouive+dpddlIX+xWWTwum7z628 8t9tgB20wv7GwQ+TqnHpvNpqhjDmHjkpg1hUJJVBGF405sEniqldAOHg9VbrLfap SIkOxYYP4KMjxS4Eb/SS6UxZQWZKJuW4saKpm1to3ablsQ14V9tW5FvbSuNpIWNg dNV/445JLx77HHm+1pzSmBI2zeJha5v3nJvHhzafXSF2AfKkKTIk9nHF9c8AI3ui VET7dG2Vuh/E88LWWFYBwp4710V/6b+83ejzy9zvEZxzG9mfRpJyLdpkvuroW4fj 5jGfFmlSeKSCh4j7V+M6UrR7N9Q/bJ11RP8VhhLNiS7kWop0nGA3Rtwqox1ZFPxK SCOTe+o/OrWyaUa6K1b+lzS/TV3EdRltQlHBaP0SmldrbYbkdVUxnyYwrc2Jd3ex EUX1fKUKxHi5aH3VZp/A4V4dD+uQpqmKoU5/9Gh/TloIHdjSQWX601T5TOx41YjM NfCPW0dPjK/uVQYWHORJ/a6aXt7ebD6zOpwTZJpEGoc0BmeyKCM2RbjI2BcUaZug Qd6+e3YDjePf5Iz1aZAPqHw7aSQwbUUHzEYCYEZOkqUDBW03U+k= =8EZe -END PGP SIGNATURE-
Bug#982079: ITP: fonts-yuseki-magic -- handwritten letters written with permanent marker
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-yuseki-magic Version : 1.000 Upstream Author : Tanukizamurai (Kumiko Yoshida) * URL : https://github.com/tanukifont/YuseiMagic * License : OFL-1.1 Programming Lang: python Description : handwritten letters written with permanent marker Yusei Magic is a font based on handwritten letters written with permanent marker. It has thick vertical strokes and thin horizontal strokes, so it is highly visible. The design of the letters has both the strength of bold lines and the softness of spaciousness. Highly recommended for handwriting on blackboards and pop art designs. . This font includes Google Latin Core, Hiragana, Katakana, JIS level 1, level 2 and IBM Extended Kanji (Han) glyphs. . See https://github.com/tanukifont/YuseiMagic
Bug#981955: ITP: fonts-train -- gothic-style typeface made with an outer and inner line
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-train Version : 1.000 Upstream Author : The Train Project Authors * URL : https://github.com/fontworks-fonts/Train * License : OFL-1.1 Programming Lang: Python Description : gothic-style typeface made with an outer and inner line Train (distributed as "Railway" in Japan by Fontworks) is a gothic-style typeface made with an outer and inner line. It is open and vibrant, and its strong first impression makes it suitable for logos and titles. . See https://fontworks.co.jp/fontsearch/RailwayStd-B/
Bug#981950: ITP: fonts-stick -- font designed with straight lines, wide versatility for use
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-stick Version : 1.000 Upstream Author : The Stick Project Authors * URL : https://github.com/fontworks-fonts/Stick * License : OFL-1.1 Programming Lang: Python Description : font designed with straight lines, wide versatility for use True to its name, Stick is designed with straight lines that create a cute and playful feel. The pastoral ambience also gives this font wide versatility for use in both paper mediums and digital content. . See https://fontworks.co.jp/fontsearch/stickstd-b/
Bug#981939: ITP: fonts-reggae -- display font often used in Japanese boys' magazines and digital content
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-reggae Version : 1.000 Upstream Author : The Reggae Project Authors * URL : https://github.com/fontworks-fonts/Reggae * License : OFL-1.1 Programming Lang: python Description : display font often used in Japanese boys' magazines and digital content Reggae is a very popular display font often used in Japanese boys' magazines and digital content. The sharpened ends give off a dynamic pulse, making this font ideal to express rhythm, movement and energy, or for emphasis. . See https://fontworks.co.jp/fontsearch/ReggaeStd-B/
Bug#981832: ITP: fonts-rocknroll -- pop-style font
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-rocknroll Version : 1.0.0 Upstream Author : The RocknRoll Project Authors * URL : https://github.com/fontworks-fonts/rocknroll * License : OFL-1.1 Programming Lang: Python Description : pop-style font RocknRoll is an original pop-style font. The strokes of varying intensity add momentum and the rounded dots create a lively and dynamic feel.
Bug#981740: ITP: fonts-klee -- script font handwritten by pencil or pen
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-klee Version : 1.0.0 Upstream Author : The Klee Project Authors * URL : https://github.com/fontworks-fonts/klee * License : OFL-1.1 Programming Lang: Python Description : script font handwritten by pencil or pen Klee is a script font handwritten by pencil or pen. It's quiet design has an elegant look that sets itself apart from traditional script and textbook fonts. Ideal for body text. . This package containts two fonts: - Klee One Regular - Klee One SemiBold . For more detail, see https://github.com/fontworks-fonts/klee
Bug#981463: ITP: fonts-rampart -- unique outline shadow font made in the image of 3-D blocks
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-rampart Version : 1.0.0 Upstream Author : The Rampart Project Authors (https://github.com/fontworks-fonts/Rampart/) * URL : https://github.com/fontworks-fonts/Rampart * License : OFL-1.1 Programming Lang: python Description : unique outline shadow font made in the image of 3-D blocks Rampart is a unique outline shadow font made in the image of 3-D blocks. It is best used for added impact or to demonstrate strength and stability. . See https://fontworks.co.jp/fontsearch/RampartStd-EB/
Bug#981455: ITP: fonts-dotgothic16 -- TrueType font based on the old 16x16 Gothic bitmap
Package: wnpp Severity: wishlist Owner: Hideki Yamane X-Debbugs-Cc: debian-de...@lists.debian.org, debian-fo...@lists.debian.org * Package name: fonts-dotgothic16 Version : 1.0.0 Upstream Author : The DotGothic16 Project Authors (https://github.com/fontworks-fonts/DotGothic16/) * URL : https://github.com/fontworks-fonts/DotGothic16 * License : OFL-1.1 Programming Lang: python Description : TrueType font based on the old 16x16 Gothic bitmap Dotgothic 16 is based on the old 16x16 Gothic bitmap font that can best recreate the feel of pixel fonts from old video games, cell phones and computer screens on print. With its high readability, this font has become more popular in recent years due to the growing popularity of pixel art. . See https://fontworks.co.jp/fontsearch/dotgothic16std-m/
Bug#976054: initramfs-tools: [RFC] Compress initramfs file with zstd
Hi, On Wed, 2 Dec 2020 11:28:06 +0100 Michael Prokop wrote: > Do we have any numbers for where xz resides in terms of > decompression speed? As I've posted at salsa, its decompression is so slow. Its CPU is AMD Ryzen 5 PRO 3400GE (3.3GHz) but it takes 3 seconds. Older i686 CPUs would take more... but xz shrinks just 3 or 4MB. https://salsa.debian.org/kernel-team/initramfs-tools/-/merge_requests/37#note_211939 -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
Bug#976261: tomoyo-tools: Consider not adding security=tomoyo to the kernel command line
control: tags -1 +confirmed Hi, On Wed, 02 Dec 2020 13:21:59 +0100 Alois Wohlschlager wrote: > Linux supports LSM stacking now, and Debian's kernel in bullseye (and > unstable) > is configured in a way that AppArmor and TOMOYO are enabled by default. So > "security=tomoyo" is not necessary to enable TOMOYO any more, it just disables > AppArmor needlessly. Okay, since 5.1. https://kernelnewbies.org/Linux_5.1#Security > Hence it's probably a good idea for tomoyo-tools not to add this option any > more. Only disadvantage I can think of is that if running on unsupported > kernels (e.g. from buster), TOMOYO is silently disabled instead of a kernel > panic. Yes. > (NB: The system I am writing this from was booted without security=tomoyo and > has both TOMOYO and AppArmor enabled.) Confirmed with VMs. -- Regards, Hideki Yamane henrich @ debian.org/iijmio-mail.jp
