Bug#1056140: marked as pending in debos
Control: tag -1 pending Hello, Bug #1056140 in debos reported by you has been fixed in the Git repository and is awaiting an upload. You can see the commit message below and you can check the diff of the fix at: https://salsa.debian.org/go-team/packages/debos/-/commit/0fd286374379752f86726b536d1135a45d9db4f5 Add golang-github-alessio-shellescape-dev to Build-Depends. Closes: #1056140 Signed-off-by: Christopher Obbard (this message was generated automatically) -- Greetings https://bugs.debian.org/1056140
Bug#1035436: rkdeveloptool: diff for NMU version 1.32+git20210408.46bb4c0-2.1
Hi Andreas, I uploaded a new version this morning with the fix; it has a -3 suffix so it should reject your NMU which had a -2.1 suffix. As I am fairly new to Debian processes, it is great you have walked me through it. Thank you! On 20 May 2023 12:07:03 BST, Andreas Metzler wrote: >On 2023-05-20 Christopher Obbard wrote: >[...] >> > I've prepared an NMU for rkdeveloptool (versioned as >> > 1.32+git20210408.46bb4c0-2.1) and uploaded it to DELAYED/1. >[...] >> Thank you for your contribution, but it seems like there is some >> parallel work (this morning in fact). > >> I am currently in the process of uploading and the fixes for this >> package. Is it possible to skip this delayed version in favour of the >> version I am about to upload ? > >Hello Christopher, > >if you upload before the NMU is accepted the NMU will simply be >rejected because there is already a higher numbered version of the >package in the archive. I can also simply cancel the NMU or bump the >delay if you want me to. - Just tell me what your preference is. > >cu Andreas >-- >`What a good friend you are to him, Dr. Maturin. His other friends are >so grateful to you.' >`I sew his ears on from time to time, sure'
Bug#1035436: rkdeveloptool: diff for NMU version 1.32+git20210408.46bb4c0-2.1
Hi, On Sat, 2023-05-20 at 11:07 +0200, Andreas Metzler wrote: > Control: tags 1035436 + patch > Control: tags 1035436 + pending > > Dear maintainer, > > I've prepared an NMU for rkdeveloptool (versioned as > 1.32+git20210408.46bb4c0-2.1) and uploaded it to DELAYED/1. Please feel > free to tell me if I should delay it longer. Thank you for your contribution, but it seems like there is some parallel work (this morning in fact). I am currently in the process of uploading and the fixes for this package. Is it possible to skip this delayed version in favour of the version I am about to upload ? > > kind regards > > Andreas
Bug#1031640: Bug#1030940: e2fsprogs: generates filesystems that grub-install doesn't recognize
Control: severity -1 important Control: retitle -1 e2fsprogs generates filesystems which cannot be mounted on systems with older e2fsprogs It turns out for debos the situation is a bit different. Since debos uses packages on the host to prepare the partitions, new features in e2fsprogs from unstable which are unsupported in the target suite causes the built system to not boot. One such failure at boot-time of a Debian testing system is when systemd-fsck tries to check a filesystem, it fails to mount the device: /dev/mmcblk0p5 has unsupported feature(s): FEATURE_C12 So, in short we cannot run images built for suites with older e2fsprogs on a host system which has e2fsprogs >=1.47.0-1. Fixing grub2 will not fix the issue for debos, so I have retitled the bug. In debos with newer e2fsprogs, we can set the following flag on a partition to disable the feature which allows the system running older e2fsprogs to boot, but older e2fsprogs doesn't allow us to set this flag: features: [ "^orphan_file" ] So to my mind, the bug is in e2fsprogs as it doesn't maintain backwards compatibility. I have reduced the severity of the bug since a workaround for debos does exist. I wonder whether the bug should be reassigned to e2fsprogs ?
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
On Thu, 2023-01-05 at 13:21 -0300, Walter Lozano wrote: > Hi Christopher and Vagrant > > On 1/5/23 12:10, Christopher Obbard wrote: > > On Wed, 2022-12-28 at 15:53 -0800, Vagrant Cascadian wrote: > > > On 2022-12-28, Vagrant Cascadian wrote: > > > > On 2022-12-22, Vagrant Cascadian wrote: > > > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > > > This bug is just to delay migration to testing while more > > > > > > > platforms get > > > > > > > tested. If you have a relevent board, please consider > > > > > > > testing > > > > > > > and > > > > > > > reporting the status: > > > > > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > > > > > I have not received many test results for current or even > > > > remotely > > > > recent u-boot platforms in Debian, and u-boot has been blocked > > > > from > > > > migration to testing partly because of this. > > > > > > > > As the bookworm freeze approaches, this is getting to be... > > > > worrysome! > > > > > > > > If you have access to any of these boards, please consider > > > > testing > > > > u-boot versions as packaged in debian for versions from debian > > > > stable > > > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > > > experimental > > > > (2023.01-rc*) and updating the wiki page if successful and/or > > > > replying > > > > to 1016...@bugs.debian.org with a positive confirmation... > > > > > > > > ...and if not successful, filing bugs against the relevent u- > > > > boot-* > > > > packages and marking them as blocking 1016963. > > > > > > rock-pi-4-rk3399 > > > > Hi Walter, Hi Vagrant, > > > > > > I tested this board and updated the wiki. All looks fine to me. > > > > - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from > > experimental > > - SD boot: works > > - MAC address: correctly derived from serial number > > > > > > - rock-pi-4-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable > > - SD boot: works > > - MAC address: correctly derived from serial number > > > > Thank you for your help here! I also did some testing, and everything > looks OK. The only thing to mention is that the the script > u-boot-install-rockchip does not auto detect my board. > > The case statement is > ``` > "Radxa ROCK Pi 4") > TARGET="/usr/lib/u-boot/rock-pi-4-rk3399" > ``` Ah, good catch! For compatiblity with mainline (debian) kernel, that line should probably be updated to: "Radxa ROCK Pi 4A"|"Radxa ROCK Pi 4A+"|"Radxa ROCK Pi 4B"|"Radxa ROCK Pi 4B+") The Radxa kernel[1] 4.14 branches use "ROCK PI 4A" and "ROCK PI 4B", we could add those in if we really wanted to. The 5.10 based kernels use devicetrees based on mainline, so are unaffected. Thanks! Chris [1]: https://github.com/radxa/kernel/blob/stable-4.4-rockpi4/arch/arm64/boot/dts/rockchip/rk3399-rock-pi-4a.dts > > fails since the string in my case is only "ROCK Pi 4". Of course, by > setting TARGET variable I can upgrade it without problems. I don't > consider this an issue and it is probably related to the kernel I am > using, since I have used as starting point the images from Radxa [1]. > > Regards, > > Walter > > [1] https://wiki.radxa.com/Rockpi4/downloads >
Bug#1016963: Please test u-boot for rock-pi-4-rk3399
On Wed, 2022-12-28 at 15:53 -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > This bug is just to delay migration to testing while more > > > > > platforms get > > > > > tested. If you have a relevent board, please consider testing > > > > > and > > > > > reporting the status: > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... > > worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian > > stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > experimental > > (2023.01-rc*) and updating the wiki page if successful and/or > > replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > rock-pi-4-rk3399 Hi Walter, Hi Vagrant, I tested this board and updated the wiki. All looks fine to me. - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number
Bug#1016963: please test u-boot for roc-pc-rk3399 rock-pi-e-rk3328
Hi Vagrant, On Wed, 2022-12-28 at 15:51 -0800, Vagrant Cascadian wrote: > On 2022-12-28, Vagrant Cascadian wrote: > > On 2022-12-22, Vagrant Cascadian wrote: > > > On 2022-08-20, Vagrant Cascadian wrote: > > > > On 2022-08-10, Vagrant Cascadian wrote: > > > > > This bug is just to delay migration to testing while more > > > > > platforms get > > > > > tested. If you have a relevent board, please consider testing > > > > > and > > > > > reporting the status: > > > > > > > > > > https://wiki.debian.org/U-boot/Status > > > > I have not received many test results for current or even remotely > > recent u-boot platforms in Debian, and u-boot has been blocked from > > migration to testing partly because of this. > > > > As the bookworm freeze approaches, this is getting to be... > > worrysome! > > > > If you have access to any of these boards, please consider testing > > u-boot versions as packaged in debian for versions from debian > > stable > > (2021.01*), testing (2022.04*), unstable (2022.10*) and > > experimental > > (2023.01-rc*) and updating the wiki page if successful and/or > > replying > > to 1016...@bugs.debian.org with a positive confirmation... > > > > ...and if not successful, filing bugs against the relevent u-boot-* > > packages and marking them as blocking 1016963. > > roc-pc-rk3399 > rock-pi-e-rk3328 Sorry for the delay, I've been catching up after the Christmas break ;- ) I've tested the following platforms and updated the wiki with my results: - roc-pc-rk3399, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - roc-pc-rk3399, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: random on each boot, patch needs backporting from experimental - rock-pi-e-rk3328, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-e-rk3328, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4-rk3399, on rock-pi-4b, 2023.01-rc4+dfsg-1 from experimental - SD boot: works - MAC address: correctly derived from serial number - rock-pi-4b-rk3399, on rock-pi-4b, 2022.10+dfsg-2 from unstable - SD boot: works - MAC address: correctly derived from serial number @Vagrant, about roc-pc-rk3399, can you please backport debian/patches/rockchip/rockchip-roc-pc-rk3399-Enable-rockchip-efuse- support.patch to the next unstable release ? If you prefer, I could create another bug about that. Thanks! Chris
Bug#1012786: libcamera: Fails to build from source
On 14/06/2022 15:35, Lisandro Damián Nicanor Pérez Meyer wrote: Hi! On Tue, 14 Jun 2022 at 05:26, Christopher Obbard wrote: Hi! I propose a patch to potentially fix this: https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6 The use of the depreciated function could even be fixed in upstream, it could be worth updating the package from upstream? No, upstream is doing the right thing. Their builds ought to fail in this case. We are the ones that should disable this flag, as done. What you really need to do is take this issue to upstream so they use the newer interfaces if possible (ie, avoid the deprecation warning). Right, what I originally meant was: "perhaps upstream have fixed this by using the correct gstreamer function instead of a depreciated one, maybe we should check if upstream have done that". For the record, it turns out that upstream have: https://git.libcamera.org/libcamera/libcamera.git/commit/test/gstreamer/gstreamer_multi_stream_test.cpp?id=4085372c517e1527114dc4098194c3ae3b973ba0 So, if we update to the latest version of libcamera, everything is fine again for future :-). I don't mind doing an update to libcamera HEAD, if Andrew would like some help. Cheers! Chris
Bug#1012786: libcamera: Fails to build from source
Hi! I propose a patch to potentially fix this: https://salsa.debian.org/multimedia-team/libcamera/-/merge_requests/6 The use of the depreciated function could even be fixed in upstream, it could be worth updating the package from upstream? @Andrew: can you review the patch above? Also, I can help with updating from upstream if you would like. Chris On 14/06/2022 03:02, Lisandro Damián Nicanor Pérez Meyer wrote: Source: libcamera Version: 0~git20200629+e7aa92a-8 Severity: serious Justification: Fails to build form source X-Debbugs-Cc: lisan...@debian.org Trying to fix a bug in libcamera I found it's currently failing to build from source. Seems it's taking deprecation warnings as errors. Log follows. Kinds regards, Lisandro. ../test/gstreamer/gstreamer_multi_stream_test.cpp: In member function ‘virtual int GstreamerMultiStreamTest::run()’: ../test/gstreamer/gstreamer_multi_stream_test.cpp:90:76: error: ‘GstPad* gst_element_get_request_pad(GstElement*, const gchar*)’ is deprecated: Use 'gst_element_request_pad_simple' instead [-Werror=deprecated-declarations] 90 | g_autoptr(GstPad) request_pad = gst_element_get_request_pad(libcameraSrc_, "src_%u"); | ~~~^ In file included from /usr/include/gstreamer-1.0/gst/gstbin.h:27, from /usr/include/gstreamer-1.0/gst/gst.h:35, from ../test/gstreamer/gstreamer_multi_stream_test.cpp:13: /usr/include/gstreamer-1.0/gst/gstelement.h:1042:25: note: declared here 1042 | GstPad* gst_element_get_request_pad (GstElement *element, const gchar *name); | ^~~ cc1plus: all warnings being treated as errors [246/390] /usr/bin/meson --internal symbolextractor '/<>/obj-x86_64-linux-gnu' src/libcamera/base/libcamera-base.so.0.0.0 src/libcamera/base/libcamera-base.so.0.0.0 src/libcamera/base/libcamera-base.so.0.0.0.p/libcamera-base.so.0.0.0.symbols [247/390] ccache c++ -Itest/stream/stream_formats.p -Itest/stream -I../test/stream -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -MD -MQ test/stream/stream_formats.p/stream_formats.cpp.o -MF test/stream/stream_formats.p/stream_formats.cpp.o.d -o test/stream/stream_formats.p/stream_formats.cpp.o -c ../test/stream/stream_formats.cpp [248/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/control_serialization.p/serialization_test.cpp.o -MF test/serialization/control_serialization.p/serialization_test.cpp.o.d -o test/serialization/control_serialization.p/serialization_test.cpp.o -c ../test/serialization/serialization_test.cpp [249/390] ccache c++ -Itest/serialization/ipa_data_serializer_test.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -MF test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o.d -o test/serialization/ipa_data_serializer_test.p/serialization_test.cpp.o -c ../test/serialization/serialization_test.cpp [250/390] ccache c++ -Itest/serialization/control_serialization.p -Itest/serialization -I../test/serialization -Itest/libtest -I../test/libtest -Iinclude -I../include -Iinclude/libcamera/ipa -Iinclude/libcamera -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -Wnon-virtual-dtor -Wextra -Werror -std=c++17 -O0 -Wshadow -include config.h -g -O2 '-ffile-prefix-map=/<>=.' -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -DLIBCAMERA_BASE_PRIVATE -MD -MQ test/serialization/control_serialization.p/control_serialization.cpp.o -MF test/serialization/control_serialization.p/control_serialization.cpp.o.d -o
Bug#1001766: oomd: ships both ./lib/systemd/system/oomd.service & ./usr/lib/systemd/system/oomd.service
Hi! Got a different error (with the same cause) when installing 0.5.0-1 using apt: Unpacking oomd (0.5.0-1+b1) ... dpkg: error processing archive /tmp/apt-dpkg-install-46e3FG/48-oomd_0.5.0-1+b1_amd64.deb (--unpack): unable to open '/usr/lib/systemd/system/oomd.service.dpkg-new': No such file or directory Looks like the package builds OK, but lintian fails: $ gbp clone https://salsa.debian.org/yangfl-guest/oomd.git $ cd oomd $ gbp buildpackage -uc -us ... Now running lintian oomd_0.5.0-1_amd64.changes ... E: oomd: file-in-root-and-usr lib/systemd/system/oomd.service usr/lib/systemd/system/oomd.service ... This is probably due to both oomd and the package shipping a (different!) service file: src/oomd/etc/oomd.service.in debian/oomd.service I've prepared a merge request to drop the upstream service (since the package's version is better) at: https://salsa.debian.org/yangfl-guest/oomd/-/merge_requests/3 Thank you! Christopher Obbard
Bug#981840: libslirp-helper crashes a few seconds after connection
Package: libslirp-helper Version: 4.3.0-2 Severity: grave Justification: renders package unusable Dear Maintainer, libslirp-helper crashes a few seconds after connection without any explanation on stdout or stderr, even with --debug flag set and RUST_BACKTRACE enabled. Debos and Fakemachine use libslirp-helper under the hood for networking, to create a bridge network for the inner virtual machine to the outside world. This can be tested by installing the fakemachine package and running fakemachine using the uml backend, then trying to connect to the network: $ fakemachine --backend uml wget http://google.com As you can see, the libslirp-helper process which is started by fakemachine quits. >From investigation, I think this is because libslirp-helper was patched to be compiled with an older version of the mio crate (0.6.16) while the libslirp-helper Cargo.toml requires a newer version of mio (0.6.19). These dependencies for this package were relaxed since mio version 0.6.16 was already packaged for debian. When manually building the package with mio version 0.6.16, I get the same error described above. So I am pretty sure that bumping mio will sort this out. -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-1-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages libslirp-helper depends on: ii libc6 2.31-9 ii libgcc-s1 10.2.1-3 ii libslirp0 4.4.0-1 libslirp-helper recommends no packages. libslirp-helper suggests no packages. -- no debconf information
Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java
Hi, On Fri, 3 Jan 2020 at 17:52, Rene Engelhard wrote: > > Hi, > > On Fri, Jan 03, 2020 at 06:36:56PM +0100, Rene Engelhard wrote: > > > The following additional packages will be installed: > > >libjuh-java libjurt-java libridl-java libunoloader-java > > > The following NEW packages will be installed: > > >libjuh-java libjurt-java libridl-java libunoloader-java > [...] > > I wonder how you got into this. Looks you didn't upgrade to 6.4 yet > before so that it does flag libjuh-java libjurt-java libridl-java > libunoloader-java as *additional* packages? those four depends appear to be coming from the upgrade of libreoffice-java-common libreoffice has been upgraded to the latest version > > I am not sure what a dist-upgrade will do here and Replaces: vice-versa > > might be problematic, so it might be you need to upgrade ure when it is > > available and then continue with a normal upgrade (maybe it even works > > in one -f or dist-upgrade, but not sure). > > Actually #debian-devel says it should work, so let's test... the dist-upgrade won't work until the four packages are installed, which won't happen because they conflict with ure... which is required by most of the libreoffice suite :-) thanks Chris > > Regards, > > Rene
Bug#947907: trying to overwrite '/usr/share/java/juh.jar', which is also in package libjuh-java
On Fri, 3 Jan 2020 17:07:33 +0100 Rene Engelhard wrote: > On Fri, Jan 03, 2020 at 04:49:23PM +0100, Thorsten Glaser wrote: > > Package: ure > > Version: 6.4.0~rc1-5 > > Followup-For: Bug #947907 > > > > It’s more than just libjuh-java: > > Yes. > > As was already said in > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=947907#34 (this bug!) > and the bugs merged with it (and the corresponding commit.) oooh dear, just has this one myself. $ sudo apt --fix-broken install Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: coinor-libcbc3 coinor-libcgl1 coinor-libclp1 coinor-libcoinmp1v5 coinor-libcoinutils3v5 coinor-libosi1v5 Use 'sudo apt autoremove' to remove them. The following additional packages will be installed: libjuh-java libjurt-java libridl-java libunoloader-java The following NEW packages will be installed: libjuh-java libjurt-java libridl-java libunoloader-java 0 upgraded, 4 newly installed, 0 to remove and 123 not upgraded. 37 not fully installed or removed. Need to get 0 B/1,138 kB of archives. After this operation, 1,351 kB of additional disk space will be used. Do you want to continue? [Y/n] (Reading database ... 124615 files and directories currently installed.) Preparing to unpack .../libjuh-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libjuh-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/juh.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libjurt-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libjurt-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/jurt.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libridl-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libridl-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/ridl.jar', which is also in package ure 6.4.0~rc1-5 Preparing to unpack .../libunoloader-java_1%3a6.4.0~rc1-5_all.deb ... Unpacking libunoloader-java (1:6.4.0~rc1-5) ... dpkg: error processing archive /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb (--unpack): trying to overwrite '/usr/share/java/unoloader.jar', which is also in package ure 6.4.0~rc1-5 Errors were encountered while processing: /var/cache/apt/archives/libjuh-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libjurt-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libridl-java_1%3a6.4.0~rc1-5_all.deb /var/cache/apt/archives/libunoloader-java_1%3a6.4.0~rc1-5_all.deb E: Sub-process /usr/bin/dpkg returned an error code (1) > > Regards, > > Rene > >
Bug#945920: Random Chromium crashes
Hi, This is also occurring on two machines for me. The crashes are random but will happen after about 10 minutes of use, quite annoying... Thanks! Chris On Tue, 31 Dec 2019 18:27:13 +0100 (CET) Thorsten Bonow wrote: > On Mon, 30 Dec 2019 13:50:36 -0800 Eloston > wrote: > > [...] > > > $ ./debian/rules get-orig-source > > Hi, > > this fails for me: > > [...] > test ! -e debian || rm -rf debian > cp -r ../debian ./ > cp: cannot stat '../debian': No such file or directory > make: *** [debian/rules:212: get-orig-source] Error 1 > ./debian/rules get-orig-source 441.08s user 24.95s system 92% cpu > 8:25.08 total > > Files and directories: > $ ll > total 12K > drwxr-sr-x 50 toto staff 4.0K Dec 31 14:40 chromium-79.0.3945.79 > -rw-r--r-- 1 toto staff 2.9K Dec 31 14:30 > chromium-build-deps_79.0.3945.79-1_all.deb > -rw-r--r-- 1 toto staff 3.6K Dec 31 12:28 enable-tracing.patch > $ pwd > /usr/local/src/chromium/chromium-c88b97a6dc183a6a7f8a05aee9e99957285a9371 > > > Regards, > Toto > > -- > Sent from my GNU Emacs running on GNU/Linux > >
Bug#902185:
this has happened to me on both my laptop and pc when doing an upgrade. A reinstall of Debian on my main PC seemed to fix it. My laptop boots to the WM but with no keyboard/mouse. This is a grave bug.
