Re: Bug#900912: "AtkWrapper not found" error impacting JOSM on Ubuntu/Mint
Hi On 06-04-2019 08:55, Samuel Thibault wrote: >> please don't NMU. In the past the atk patches broke the non-atk use case way >> too >> often. Maybe you want to upload to a PPA or to experimental to give this a >> little bit more testing. > > Can we then at least upload all changes except enabling atk, i.e. > the attached patch which just fixes loading atk without enabling it > by default? So that there is even no need for any external PPA or > experimental (which would be quite involved for people to configure), > instead people can just enable from the configuration file, as expected > and documented. With my release team member hat on: we want accessibility enabled by default. We're late already, I would want this rather sooner than latter in buster, such that there is some real live testing before we release. Sure, there are chances for bugs, but if that's the case, let's find them and fix them. Paul signature.asc Description: OpenPGP digital signature
Re: Enabling jaw (Java-atk-wrapper) by default ? (Bug#900912)
Hi doko, On 07-04-2019 12:08, Samuel Thibault wrote: >> I disagree. I'll do the next upload with Samuel's proposed patches, not >> enabling that by default, together with the planned security update. Then >> people can start testing if the wrapper works. > > Well, I'm afraid that what will happen is that the people who will > test will simply find out that it just works for them (just like it > does already for them with openjdk-8) ; will we then conclude near the > release that it should be enabled by default for Buster, and then be hit > by the much wider exposition to jaw? > > If on the contrary we enable it by default during the freeze, we will > have *way* more testing coverage, and thus be much more confident with > keeping it enabled by default in Buster if we don't see bug reports. Although I agree with Samuel here, can we please-pretty-please get an upload even if you don't enable it, such that we can get this story into buster? Paul signature.asc Description: OpenPGP digital signature
Re: Usage of language specific profiles in build dependencies
Hi, On 11-02-2021 10:16, Matthias Klose wrote: > These dependencies should look like: > > default-jdk [!hppa !hurd-i386 !kfreebsd-any] > > or > > default-jdk [alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel > powerpc ppc64 ppc64el riscv64 s390x sh4 sparc64 x32] > > It's also ok to use something like > > default-jdk [!hppa !hurd-i386 !kfreebsd-any] > > to be able to build with the nojava profile. I also see this used in many > mono > related build dependencies. > > Having such build dependencies in a package that is a required package for > almost everything isn't helpful. Maybe a very stupid solution would be to have default-jdk be available on all architectures, but just not pull in anything? IIUC that would lead to build failures (because code that really needs the jdk will FTBFS) but it avoids busywork for maintainers that are not involved in bootstrapping java. Machine time is cheap, volunteer time is not. Just my 2 cents. Paul OpenPGP_signature Description: OpenPGP digital signature
Re: Bug#1093787: New version of maven-resolver causes failures in autopkgtests and builds
Hi, On 23-01-2025 09:26, Julien Plissonneau Duquène wrote: These issues are currently being discussed on debian-java [1]. Would a britney hint or something be appropriate here? We believe that these reverse dependencies should not block these migrations. If RC bugs have been filed for all regressions, I'm OK with adding a hint to ignore the autopkgtest regressions, provided they are not also build test errors in key packages. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
