Processed: php-geos: FTBFS with php8.0
Processing control commands: > block 976811 by -1 Bug #976811 [release.debian.org] transition: php8.0 976811 was not blocked by any bugs. 976811 was not blocking any bugs. Added blocking bug(s) of 976811: 977186 > forwarded -1 https://git.osgeo.org/gitea/geos/php-geos/issues/26 Bug #977186 [src:php-geos] php-geos: FTBFS with php8.0 Set Bug forwarded-to-address to 'https://git.osgeo.org/gitea/geos/php-geos/issues/26'. -- 976811: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976811 977186: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977186 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#976880: transition: dtkcore
Package: release.debian.org Followup-For: Bug #976880 Dear Release Team, Following packages need to have a sourceful upload: dtkcore dtkgui dtkwidget dtkwm dde-qt-dbus-factory dde-qt5integration dde-calendar deepin-deb-installer deepin-menu deepin-movie-reborn deepin-music deepin-screen-recorder deepin-voice-recorder deepin-calculator deepin-image-viewer And the following packages need binNMU: deepin-shortcut-viewer deepin-picker deepin-notifications deepin-screenshot -- Arun Kumar Pariyar OpenPGP_signature Description: OpenPGP digital signature
Bug#977201: transition: glade
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition Hello, I would like to upload glade 3.38 in unstable, but this requires a transiton (libgladeui-2-6 -> libgladeui-2-13) I tried to rebuild all the rdeps and they all build fine except libhandy and libgtkdatabox For libhandy I opened #977187 (with a patch). For libgtkdatabox I opened #977184 but I'm not really sure that can be fixed easily (at all?) as it seems there is a mismatch between gtk2 and gtk3 in the source. IMVHO, the only option is to remove the glade plugin. AFAICS, there is not rdeps in the archive, I've also a patch for that. Kind regards, Laurent Bigonville Ben file: title = "glade"; is_affected = .depends ~ "libgladeui-2-6" | .depends ~ "libgladeui-2-13"; is_good = .depends ~ "libgladeui-2-13"; is_bad = .depends ~ "libgladeui-2-6"; -- System Information: Debian Release: bullseye/sid APT prefers unstable-debug APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/8 CPU threads) Kernel taint flags: TAINT_WARN Locale: LANG=fr_BE.UTF-8, LC_CTYPE=fr_BE.UTF-8 (charmap=UTF-8), LANGUAGE=fr_BE:fr Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: SELinux: enabled - Mode: Permissive - Policy name: refpolicy
Processed: block 977201 with 977184 977187
Processing commands for cont...@bugs.debian.org: > block 977201 with 977184 977187 Bug #977201 [release.debian.org] transition: glade 977201 was not blocked by any bugs. 977201 was not blocking any bugs. Added blocking bug(s) of 977201: 977187 and 977184 > thanks Stopping processing here. Please contact me if you need assistance. -- 977201: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977201 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#976811: transition: php8.0
On Sat, Dec 12, 2020 at 08:05:19AM +0100, Ondřej Surý wrote: > And let me restate that it’s not my intent to make anyone’s life hell and > I am willing to help with any package (as usual). I am just trying to do > the most sane thing to do security and maintainer wise. oh sure, I never expected anything else, on the contrary. many thanks for very nicely caring about php! (and other packages too! :) signature.asc Description: PGP signature
Bug#977207: nmu: avldrums.lv2_0.4.1-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: d_br...@kabelmail.de nmu avldrums.lv2_0.4.1-1 . ANY . bullseye . -m "Upload to bullseye" -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash
Bug#977209: transition: proftpd-dfsg
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: transition This transition was already started by the recent proftpd upload, but is not caught caught automatically since it is a virtual package name that has changed. Ben file: title = "proftpd-dfsg"; is_affected = .depends ~ /proftpd-abi-/; is_good = .depends ~ /proftpd-abi-1.3.7a+dfsg/; is_bad = .depends ~ /proftpd-abi-1.3.7a/; Thanks! -- System Information: Debian Release: bullseye/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 5.9.0-4-686-pae (SMP w/2 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_GB.UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#977207: marked as done (nmu: avldrums.lv2_0.4.1-1)
Your message dated Sat, 12 Dec 2020 17:07:28 +0100 with message-id and subject line Re: Bug#977207: nmu: avldrums.lv2_0.4.1-1 has caused the Debian Bug report #977207, regarding nmu: avldrums.lv2_0.4.1-1 to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 977207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977207 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: binnmu X-Debbugs-Cc: d_br...@kabelmail.de nmu avldrums.lv2_0.4.1-1 . ANY . bullseye . -m "Upload to bullseye" -- System Information: Debian Release: bullseye/sid APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash --- End Message --- --- Begin Message --- On 2020-12-12 15:58:45 +0100, Dennis Braun wrote: > Package: release.debian.org > Severity: normal > User: release.debian@packages.debian.org > Usertags: binnmu > X-Debbugs-Cc: d_br...@kabelmail.de > > nmu avldrums.lv2_0.4.1-1 . ANY . bullseye . -m "Upload to bullseye" avldrums.lv2 needs a source only upload due to the arch: all binary. I will take care of that. Cheers > > -- System Information: > Debian Release: bullseye/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.9.0-4-amd64 (SMP w/4 CPU threads) > Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8), LANGUAGE not > set > Shell: /bin/sh linked to /bin/dash > -- Sebastian Ramacher signature.asc Description: PGP signature --- End Message ---
Processed: your mail
Processing commands for cont...@bugs.debian.org: > summary 977207 nmu avldrums.lv2_0.4.1-1 . amd64 . unstable . -m "Rebuild on > buildd" Summary recorded from message bug 977207 message > End of message, stopping processing here. Please contact me if you need assistance. -- 977207: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977207 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Tue, Dec 08, 2020 at 05:46:26PM +, Simon McVittie wrote: >... > I think it's necessary to consider what the purpose of the i386 port is, > and set expectations and an appropriate baseline based on that. > > I see two possible use-cases for i386: > > 1. It's a compatibility layer for legacy 32-bit binaries on x86_64 CPUs: >in particular, proprietary 32-bit binaries that we cannot recompile, >32-bit builds of Wine, and the dependency stacks for those > > 2. It's something you can genuinely run on older (or more-embedded) >32-bit x86 CPUs that do not support x86_64 (down to some arbitrary >baseline, currently i686 without MMX or SSE) There are at least two more: 3. Computers that do support MMX and SSE2, but do not support 64bit. AFAIR the last 32bit-only CPU from Intel was released in 2007.[1] Then there was the short netbook boom, but AFAIR some early ones had 64bit CPUs but 32bit-only firmware. Surprisingly many netbooks are still in use even in first-world countries.[2] 4. People who wrongly installed i386 on amd64-capable hardware. The existing userbase with this setup is large, and even though crossgrades are now finally possible it is better to wait until there are fewer users in this setup and more potential crossgrade issues resolved. > Ubuntu have chosen to support the first use-case, and only the first > use-case. They longer ship a complete, bootable i386 operating system; > instead, they have an i386 second-class-citizen architecture that > is sufficient to provide graphics drivers and other shared libraries > for legacy 32-bit proprietary binaries. >... Ubuntu has a business-minded focus, which is fair enough. But Debian should not blindly follow whatever Canonical does with Ubuntu for business reasons.[3] It does make sense for Debian to differenciate by providing support for communities whose hardware is not or no longer supported by Ubuntu. >... > we could raise the > baseline to include those and stop patching packages to avoid using them, > which would remove i386's major oddity when compared with other > architectures (i387 extended-precision floating point). While this specific oddity is unique to the i386 port, it is worth mentioning that every port has its own oddities. > Also, if we are only supporting i386 for my first use-case, then I think > we should seriously consider waiving the archive-completeness metric > for i386: if big packages like web browsers and Libreoffice can't be > compiled on 32-bit, then so be it. We only need to be able to compile > a library stack, plus enough programs to be able to build and test that > library stack on virtual or real hardware. There is also a cost associated with having to modify packages for handling such port-specific omissions. One current example for missing archive-completeness would be s390x, and I guess you are aware how much pain its headless nature has caused in some places. > If the second use-case is supported, then we are going to need an i386 > porter team analogous to any other architecture porting team, that can > take responsibility for choosing an achievable baseline for the oldest > i386 CPU that they intend to test and support, triaging i386-specific > bugs, and providing patches where necessary to keep packages below that > baseline (which will require an increasing amount of work over time if > they choose a baseline that is suitable for historical x86 CPUs, since > increasingly many upstreams refuse to support the i387 FPU). I don't > think it's reasonable any more to expect individual package maintainers > to understand the finer points of the historical x86 instruction set. This is correct. This is exactly porter work, and this is what I have already been doing for years for i386. A large part of porter work is being a one-trick pony, often submitting the same fix for many packages. For i386 this is usually some variant of ifneq (,$(filter $(DEB_HOST_ARCH), i386)) export DEB_CXXFLAGS_MAINT_APPEND += -ffloat-store endif > One factor that makes the second use-case difficult to support is > that even if developers still have old 32-bit x86 hardware, it's very > likely to be considerably newer than our current baseline. For example, > mainstream Intel and AMD 32-bit CPUs gained SSE support around 20 years > ago (Pentium III and Athlon XP). I know there are somewhat newer x86 > embedded CPUs with lesser capabilities, but most developers would have > to have deliberately chosen to obtain those, rather than having access > to old machines just because they haven't disposed of them yet. It is not realistic to expect porters to have hardware matching exactly the port baseline. How many people do have hardware matching exactly our amd64 baseline? Does hardware matching exactly our amd64 baseline even exist? > I don't think it's realistic to drop i386 completely, and I want to > be able to continue to run legacy 32-bit games; so if an i386 porter >
Re: Porter roll call for Debian Bullseye
Hi, sorry for the late reply and thanks a lot Graham for pinging me directly. I didn't monitor -devel closely lately, but I am an active porter for the following architecture and I intend to continue this for the lifetime of the Bullseye release (est. end of 2024): For ppc64el, I - test most packages on this architecture - run a Debian testing or unstable system that I use regularly - fix ppc64el-related bugs, especially by following https://udd.debian.org/cgi-bin/ftbfs.cgi - test d-i on a daily basis with an homegrown automated iso (sid netboot/testing netinst/bullseye alphas) installer (vm and PowerVM) and moving to OpenQA now. - fix d-i bugs/issues I am a DD, Frédéric Bonnard signature.asc Description: PGP signature
NEW changes in stable-new
Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_amd64.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_arm64-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_armel-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_armhf-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_i386-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_mips-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_mips64el-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_mipsel-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_ppc64el-buildd.changes ACCEPT Processing changes file: minidlna_1.2.1+dfsg-2+deb10u1_s390x.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_source.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_all.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_amd64-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_arm64-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_armel-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_armhf-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_i386-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_mips-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_mips64el-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_mipsel-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_ppc64el-buildd.changes ACCEPT Processing changes file: openssl_1.1.1d-0+deb10u4_s390x.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_source.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_amd64-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_arm64-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_armhf-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_i386-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_mips-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_mips64el-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_mipsel-buildd.changes ACCEPT Processing changes file: trafficserver_8.0.2+ds-1+deb10u4_ppc64el-buildd.changes ACCEPT
Re: Release status of i386 for Bullseye and long term support for 3 years?
On Sat, 12 Dec 2020 at 18:09:02 +0200, Adrian Bunk wrote: > 3. Computers that do support MMX and SSE2, but do not support 64bit. Right, that's basically the second use-case I mentioned, but moving the boundary for what we do and don't support to be more modern. We could put the boundary anywhere we want, with higher baselines letting us make more assumptions but excluding more old hardware. > 4. People who wrongly installed i386 on amd64-capable hardware. You're right that this doesn't match either of the use-cases I gave. If this one is important to us, then that's a reason to keep a complete bootable i386 system (with bootloaders and kernels), but we could move its baseline as high as amd64's. > Ubuntu has a business-minded focus, which is fair enough. > But Debian should not blindly follow whatever Canonical > does with Ubuntu for business reasons.[3] > [3] neither should Debian blindly do the opposite I agree - we need to weigh up the same advantages and disadvantages that Canonical/Ubuntu did, but we might come to a different conclusion because our priorities (and infrastructure) are different. smcv
Bug#976397: transition: opencv
On Thu, Dec 10, 2020 at 10:17:06PM +0100, Sebastian Ramacher wrote: > What's the status wrt to reverse dependencies? Do they all build with > the new version? Only 4 of them FTBFS. 3 of them failed due to other reasons. OKactiona_3.10.1-1.dsc OKauto-multiple-choice_1.4.0-5.dsc OKcaffe_1.0.0+git20180821.99bd997-8.dsc OKcimg_2.8.4+dfsg-1.dsc OKdarknet_0.0.0+git20180914.61c9d02e-2.dsc OKdigikam_7.1.0-1.dsc OKeviacam_2.1.4-2.dsc OKfreecad_0.19~pre1+git20201123.8d73c8f0+dfsg1-1.dsc FAIL (already FTBFS against opencv 4.0.1) freeture_1.3.0-1.dsc OKgmic_2.4.5-1.1.dsc OKgst-plugins-bad1.0_1.18.2-1.dsc FAIL (already FTBFS against opencv 4.0.1) limereg_1.4.1-4.dsc FAIL (already FTBFS against opencv 3.4.4, 4.0.1) mldemos_0.5.1+git.1.ee5d11f-4.dsc OKmonado_0.3.0-3.dsc FTBFS (#977247) mrpt_2.1.5-1.dsc OKnode-opencv_7.0.0+git20200310.6c13234-1.dsc OKnomacs_3.12.0+dfsg-3.dsc OKopencfu_4.0.0-1.dsc OKopenimageio_2.2.9.0+dfsg-1.dsc OKos-autoinst_4.5.1527308405.8b586d5-4.2.dsc OKotb_7.2.0+dfsg-1.dsc FTBFS (#977248) (header path) php-facedetect_1.1.0-19-g135c72a-1.dsc OKpytorch_1.7.0-2.dsc OKqimgv_0.9.1-2.dsc FTBFS (#977249) ros-opencv-apps_2.0.2-1.dsc FTBFS (#977250) ros-vision-opencv_1.15.0+ds-2.dsc OKsiril_0.99.6-1.dsc OKslowmovideo_0.5+git20190116-3.dsc OKvisp_3.3.0-5.dsc
Re: Release status of i386 for Bullseye and long term support for 3 years?
Then there was the short netbook boom, but AFAIR some early ones had 64bit CPUs but 32bit-only firmware. My memory is that at the height of the boom the dominant processors were the N270 and N280, which are 32-bit only. By the time 64-bit netbook processors showed up the boom was on the decline. There are at least two more: 5. People running Debian on virtual machines. You can run an i386 VM with vmware or virtualbox with no special hardware support. An x86-64 VM on the other hand requires VT-x (or the AMD equivilent). While processor support for this is the norm nowadays it's still often disabled by default which can be a pain if you need to get IT support to access bios setup on a machine. i386 hardware is so numerous and widely spread, that every tiny fraction of i386 users might be more users than half of our release architectures combined. It is not even clear whether this is just an exaggeration or might be literally true: i386 still gives 17281 popcon submissions, that is about a tenth of amd64, but it's also over 10 times the next highest port Now that probably doesn't reflect true usage, in particular users who install using images tend to miss out on the popcon question, but I still suspect that i386 is up there in the top few most used architectures.
Re: Release status of i386 for Bullseye and long term support for 3 years?
Hi all, As someone who runs amd64/i386 multiarch, this statement from Adrian: > i386 hardware is so numerous and widely spread, that every tiny fraction > of i386 users might be more users than half of our release architectures > combined. It is not even clear whether this is just an exaggeration or > might be literally true: intrested me. I wondered just how many there were. Popcon lists 17281 people with i386 installations, but I bet that includes those who (like me) installed multiarch. So I grep'ed through the popcon output a bit, looking for kernel packages. I figure that, if you have an i386 kernel pacakge, you don't belong in the first group of people. Obviously you all can easily replicate this, and this only applies to users with popularity-contest installed, but here are my results: For a baseline, there are 181,863 amd64 users who are regularally sending popcon reports. Of those, 171,916 have the linux-image-amd64 package installed. I assume the remaining 5.4 percent are selecting what kernel package they are running manually, or perhaps are in a VM. The 13th most popular linux-image package is linux-image-686-pae, at 12,736 installs. It places ahead of every single 5.x kernel, indicating that there are more people running i386 (with some extensions) than there are running Testing or Unstable. Continuing down the list, the standard linux-image-686 package (no PAE) has 877 popcon installs. None of the other release archetecures have appeared yet: which isn't supprising, since every other popcon archetecure has a combined total of 1636 installs, the largest being armhf at 636 installs. I assume these people are the ones who would lose support: while some of them may have PAE capable computers, I don't think it's a significant fraction. Clearly, I have already proved Adrian's point: I can say, with certainty, that there are an order of magnitude more people with i386 kernels (and thus presumably i386 hardware) than there are for every other non-amd64 release archetecture combined. Further, there are more people with old i386 hardware than there are for any other arch. My point is that we would lose less people if we dropped all ARM support than if we dropped the oldest supported i386 kernel[1]. But lets keep going! See, we haven't seen any arm kernal images yet, so who knows if they even exist? Remember, the ARM archectures are the biggest ones after i386. Next up, we hit linux-image-586, with 403 installs. That means there are 403 people who were unable to upgrade to stretch, but are still running Debian and popcon. That's presumably the lower limit for the number Adrian referenced as people who were upset with the increase in baseline, since again, all of those 403 people have used their 586 machine in the past month. Continuing down, we see linux-image-486, 310 installs. That's still more installations than arm64's total popcon. It's also been unsupported since 2014, but hey. Then we hit linux-image-marvell, which (as I understand it) is one of the arm versions. At 225 installs, its not terribly impressive. Its also the first non-amd64/i386 kernel that I hit on this list, and where I stop. This is supported as a first-class Debian citizen: and yet, the now dropped 486 still has more installations. Of course, the pace of technology marches on, and the 586 is an ancient chip. We were right to end support for it: it's not like any modern software would run well on such a processor. But there is still a large section of the debian userbase using the older 686 versions. Adrian is right to say that ending support for them isn't right. Wall of text meticulously analyzing the output of two commands aside, this was a bit fun to make! Now I'm off to bed in my bed: thanks for reading! Calum M [1]: Okay, that's not strictly true: the total number of people reporting packages from each of the arm architectures is 1256. However, that involves three seperate sub-archetecures, and I am willing to bet there are a fair number of multi-arch arm users. But for strict correctness, pretend I said "all armhf and arm64 support", since those two total to only 10 more than the subset of i386 in question. signature.asc Description: This is a digitally signed message part
