Bug#894011: java-common: Please move ia64 to the list of Java 9 architectures
Source: java-common Version: 0.62 Severity: normal User: debian-i...@lists.debian.org Usertags: ia64 Hi! With OpenJDK9 bootstrapped for ia64, it's now possible to set it as the default JDK for ia64. Thus, please move ia64 from the list of Java 5 architectures to the list of Java 9 architectures. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#864768: Duplicate bug reports?
On Thu, Jun 15, 2017 at 06:57:25PM +0200, Emmanuel Bourg wrote: > That was intentional, that's two different packages with different fixes. Ah, I didn't look at the PTS pages. I thought that the binary package in the one bug report was build from the source package in the other bug report. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#864768: Duplicate bug reports?
Hi Emmanuel! Is there a reason why you filed the same bug report twice? One against src:libquartz-java (#864768) and one against libquartz-java (#864769)? Otherwise I'd suggest merging both bug reports. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#766977: elasticsearch not starting
Control: retitle -1 elasticsearch: Please provide a systemd service file > However the fact remains, systemd is confusingly reporting ES as > being started when it is not. IMHO, that's an issue. Not an issue here. Without START_DAEMON=true, systemd correctly reports the unit as run successfully and detects the daemon to have exited: root@vs84:~> systemctl status elasticsearch.service ● elasticsearch.service - LSB: Starts elasticsearch Loaded: loaded (/etc/init.d/elasticsearch) Active: active (exited) since Tue 2015-10-06 10:17:28 CEST; 1 weeks 1 days ago root@vs84:~> Enabling elasticsearch with START_DAEMON=true and systemd will also detect the process itself as running: root@vs84:~> systemctl status elasticsearch.service ● elasticsearch.service - LSB: Starts elasticsearch Loaded: loaded (/etc/init.d/elasticsearch) Active: active (running) since Wed 2015-10-14 10:51:31 CEST; 3s ago Process: 17109 ExecStop=/etc/init.d/elasticsearch stop (code=exited, status=0/SUCCESS) Process: 17149 ExecStart=/etc/init.d/elasticsearch start (code=exited, status=0/SUCCESS) CGroup: /system.slice/elasticsearch.service └─17203 /usr/lib/jvm/java-7-openjdk-amd64/bin/java -Xms256m -Xmx1g -Djava.awt.headless=true -XX:+UseParNewGC -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSIn... Oct 14 10:51:31 vs84 elasticsearch[17149]: Starting Elasticsearch Server:. root@vs84:~> systemd is behaving absolutely correctly and as expected. Without any systemd support from the elasticsearch service, systemd has to resort to using the LSB compatibility layer and has to evaluate the status codes of the SysV scripts provided by elasticsearch. If these scripts return with SUCCESS on "start", systemd has to assume the service was run successfully albeit it detects that the process associated with it has exited (which is what you can see above). There are cases where a unit is run and exits shortly after (so-called "oneshot" unit in systemd), so it's safe to assume for systemd to assume that the unit was run successfully as long as the exit code was zero. In order to properly fix this problem, the elasticsearch maintainers should add systemd support to their package by providing a service file. This is a good idea anyway since systemd is the default init system since Debian Jessie and SystemV scripts is something we would like to get rid of in Debian. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
Bug#700898: commons-daemon: FTBFS because it whitelists architectures*** Host support ***, checking for strip... strip, checking C flags dependant on host system type... failed, configure: error: Unsu
Hi Tony!
> According to the buildd logs [1], the package builds on every
> architecture except for hurd-i386.
No, you have to look at the ports architectures [1]. On sh4, for
example, I get:
*** Host support ***
checking for strip... strip
checking C flags dependant on host system type... failed
configure: error: Unsupported CPU architecture "sh4"
dh_auto_configure: ./configure --build=sh4-linux-gnu --prefix=/usr
--includedir=${prefix}/include --mandir=${prefix}/share/man
--infodir=${prefix}/share/info --sysconfdir=/etc --localstatedir=/var
--disable-silent-rules --libdir=${prefix}/lib/sh4-linux-gnu
--libexecdir=${prefix}/lib/sh4-linux-gnu --disable-maintainer-mode
--disable-dependency-tracking --with-java=/usr/lib/jvm/default-java
CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security
CPPFLAGS=-D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector-strong
-Wformat -Werror=format-security FCFLAGS=-g -O2 -fstack-protector-strong
FFLAGS=-g -O2 -fstack-protector-strong GCJFLAGS=-g -O2
-fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2
-fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g
-O2 -fstack-protector-strong -Wformat -Werror=format-security returned
exit code 1
make[1]: *** [override_dh_auto_configure] Error 2
debian/rules:19: recipe for target 'override_dh_auto_configure' failed
make[1]: Leaving directory '/«PKGBUILDDIR»'
debian/rules:16: recipe for target 'build-arch' failed
make: *** [build-arch] Error 2
So it's definitely a matter of architectures being white-listed.
Please add support for hppa, m68k, ppc64 and sh4.
Thanks,
Adrian
> [1]
http://buildd.debian-ports.org/status/package.php?p=commons-daemon&suite=sid
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaub...@debian.org
`. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
`-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
__
This is the maintainer address of Debian's Java team
<http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>.
Please use
debian-j...@lists.debian.org for discussions and questions.
Bug#719842: [pkg-db-devel] Bug#719842: db5.3: FTBFS: jh_linkjars: Invalid option: N
Hi Ondřej! Is there anything that speaks against applying Thorsten's patch to fix the FTBFS of db5.3 on m68k? If not, would you be so kind and apply his patch so that db5.3 is also built on this particular Debian port? I'd also be happy to do an NMU if necessary. The m68k port has lots of fans in the retro-computing scene (Apple, Atari and Amiga users) and we recently got some (small) funding from Debian approved by our DPL Lucas Nussbaum to support our work. I am fully aware of the fact that m68k machines are (currently) not something what most people would use for production. However, the port is now on a very good way and we have several people investing some time to revive the port and our users appreciate it. PS: Even Greg Kroah-Hartman likes the m68k port when I was asking him at LinuxTag and he said the code is there to stay in the kernel since the port helps finding compatibility regressions in the kernel which can also affect other, newer architectures. Thanks a lot! Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 __ This is the maintainer address of Debian's Java team <http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-java-maintainers>. Please use debian-j...@lists.debian.org for discussions and questions.
