Bug#1073535: soundcraft-utils: Properly manage dbus service
Source: soundcraft-utils Version: 0.4.0-2 Severity: normal X-Debbugs-Cc: ti...@debian.org Upstream manages dbus in it's own way. The package in its currently state won't manage it properly, and won't remove the service file after a purge. Needs a patch. -- System Information: Debian Release: trixie/sid APT prefers testing APT policy: (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 6.5.0-5-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#1072061: RFP: soundcraft-utils -- Linux Utilities for Soundcraft Mixers
Package: wnpp Severity: wishlist X-Debbugs-Cc: ti...@debian.org * Package name: soundcraft-utils Version : 0.4.0 Upstream Contact: Jim Ramsay * URL : https://github.com/lack/soundcraft-utils * License : MIT Programming Lang: Python Description : Linux Utilities for Soundcraft Mixers Soundcraft Notepad mixers are pretty nice small-sized mixer boards with Harmon USB I/O built-in. While the USB audio works great in alsa without any additional configuration needed, there are some advanced features available to the Windows driver that have no Linux equivalent. Most importantly, the USB routing for the capture channels is software-controlled, and requires an additional utility. For example, by default the Notepad-12FX sends the Master L outputs to USB capture channels 3 and 4, but this routing can be changed to input 3&4, input 5&6, or input 7&8. This tool aims to give this same software control of the USB capture channel routing to Linux users.
Bug#985442: Fix
Control: severity 985442 wishlist Hi, Thanks for reporting and sorry for the long delay. This is indeed an important issue and I have fixed it in a quick way. I like your suggestion but I'll need some time to make it work without breaking users installations. I'll keep this bug open as wishlist. Bests, -- Tiago Vaz https://tvaz.cc
Bug#871768: (no subject)
tags #871768 patch thanks See MR at https://salsa.debian.org/nm-team/nm-templates/-/merge_requests/23 -- Tiago Bortoletto Vaz
Bug#1037914: cloud-initramfs-growroot: missing dependencies in initramfs
Control: tags -1 patch Hi, I've managed to reproduce the original report after adding 'debug' to the kernel command line and checking "/run/initramfs/initramfs.debug"[1]. A patch was sent to the "cloud-team/cloud-initramfs-tools" Salsa repository[2]. Regards, Tiago. [1]: https://wiki.debian.org/InitramfsDebug#Saving_debug_information [2]: https://salsa.debian.org/cloud-team/cloud-initramfs-tools/-/merge_requests/8 -- Tiago "Myhro" Ilieve Blog: https://blog.myhro.info/ GitHub: https://github.com/myhro LinkedIn: https://www.linkedin.com/in/myhro/ Montes Claros, Brazil
Bug#1055019: RM: ffmpeg2theora -- RoQA; dead upstream, missed bookworm, RC buggy
Ack. -- Tiago Vaz https://tvaz.cc On Sun, Oct 29, 2023 at 12:51:17PM +0100, Sebastian Ramacher wrote: > Package: ftp.debian.org > Severity: normal > User: ftp.debian@packages.debian.org > Usertags: remove > X-Debbugs-Cc: ffmpeg2the...@packages.debian.org, sramac...@debian.org > Control: affects -1 + src:ffmpeg2theora > > ffmpeg2theora is RC buggy (see #1013423) and thus missed the bookworm > release. As it's also dead upstream (homepage is 404), please remove it > from unstable. > > Cheers > -- > Sebastian Ramacher
Bug#1052516: apticron man page doesn't say how to configure, doesn't refer user to the file that does
Hi, On Sat, Sep 23, 2023 at 12:31:15PM -0400, Jonathan Kamens wrote: > Package: apticron > Version: 1.2.7 > Severity: minor > > Both the README.Debian file for apticron and the man page say that it > is configurable but don't say how. > > Ideally the man page would document the configuration options, but at > the very least it should reference /usr/lib/apticron/apticron.conf in > the FILES section and mention that configuration settings are > documented there. /etc/apticron/apticron.conf is the right place for custom settings. The values set in /etc/apticron/apticron.conf will override the settings in /usr/lib/apticron/apticron.conf, as it's stated in the file header. The configuration options are documented in the configuration file itself. Thanks for reporting, I'll make it clearer in the manpage. Bests, > -- 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/8 CPU threads; PREEMPT) > Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.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 apticron depends on: > ii apt 2.7.3 > ii bzip2 1.0.8-5+b1 > ii cron [cron-daemon] 3.0pl1-175 > ii dpkg1.22.0 > ii mailutils [mailx] 1:3.16-1+b1 > ii ucf 3.0043+nmu1 > > Versions of packages apticron recommends: > ii apt-listchanges 3.27 > ii gpg 2.2.40-1.1 > ii iproute2 6.5.0-4 > > apticron suggests no packages. > > -- no debconf information
Bug#795967: (no subject)
tags #795967 patch thanks See MR https://salsa.debian.org/nm-team/contributors.debian.org/-/merge_requests/17 -- Tiago Vaz https://tvaz.cc
Bug#972439: (no subject)
retitle 972439 RFP: tailscale -- wireguard overlay network manager (client) thanks I'm refraining from packaging tailscale for Debian. I ITP'ed without looking further, as I was excited to hack it during the going on Debconf. Status: - Among its direct dependencies, 39 will need to be packaged. - I had a quick look at them, and many will have extra dependencies to be packaged as well. - Then I looked at the upstream view on a official Debian package for tailscale and got some extra discouragement: https://github.com/tailscale/tailscale/issues/7847#issuecomment-1503731931 All in all, I wish good luck to the brave one who takes on this job.
Bug#1051657: fatal: 'upstream/.orig' is not a valid tag name.
Package: dh-make-golang
Version: 0.6.0-2+b5
Severity: normal
X-Debbugs-Cc: ti...@debian.org
Dear Maintainer,
Please have a look at the git import, which somewhat won't find a proper
version and try to tag an invalid name ".orig". The following was my attempt of
creating a salsa repo for tailscale:
$ dh-make-golang github.com/tailscale/tailscale
2023/09/10 20:37:02 Starting "dh-make-golang v0.6.0 linux/amd64"
2023/09/10 20:37:02 Downloading "github.com/tailscale/tailscale/..."
2023/09/10 20:37:12 Determining upstream version number
2023/09/10 20:37:12 Found latest tag "coral-gitops"
2023/09/10 20:37:12 WARNING: Latest tag "coral-gitops" is not a valid SemVer
version
2023/09/10 20:37:12 INFO: master is ahead of "coral-gitops" by 1158 commits
2023/09/10 20:37:12 Package version is ""
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/atomicfile
expects import "tailscale.com/atomicfile"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/derper
expects import "tailscale.com/cmd/derper"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/hello
expects import "tailscale.com/cmd/hello"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tailscale
expects import "tailscale.com/cmd/tailscale"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tailscaled
expects import "tailscale.com/cmd/tailscaled"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tsconnect
expects import "tailscale.com/cmd/tsconnect"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/util/singleflight
expects import "tailscale.com/util/singleflight"
2023/09/10 20:37:13 WARNING: In findMains: ["go" "list" "-f" "{{.ImportPath}}
{{.Name}}" "github.com/tailscale/tailscale/..."]: exit status 1
2023/09/10 20:37:13 Retrying without appending "/..." to repo
2023/09/10 20:37:13 Determining dependencies
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/atomicfile
expects import "tailscale.com/atomicfile"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/derper
expects import "tailscale.com/cmd/derper"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/hello
expects import "tailscale.com/cmd/hello"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tailscale
expects import "tailscale.com/cmd/tailscale"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tailscaled
expects import "tailscale.com/cmd/tailscaled"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/cmd/tsconnect
expects import "tailscale.com/cmd/tsconnect"
code in directory
/tmp/dh-make-golang2735977206/src/github.com/tailscale/tailscale/util/singleflight
expects import "tailscale.com/util/singleflight"
2023/09/10 20:37:14 WARNING: In findDependencies: ["go" "list" "-f" "{{join
.Imports \"\\n\"}}\n{{join .TestImports \"\\n\"}}\n{{join .XTestImports
\"\\n\"}}" "github.com/tailscale/tailscale/..."]: exit status 1
2023/09/10 20:37:14 Retrying without appending "/..." to repo
2023/09/10 20:37:14 Downloading
https://github.com/tailscale/tailscale/archive/coral-gitops.tar.gz
2023/09/10 20:37:16 Moving tempfile to
"golang-github-tailscale-tailscale_.orig.tar.gz"
hint: Using 'master' as the name for the initial branch. This default branch
name
hint: is subject to change. To configure the initial branch name to use in all
hint: of your new repositories, which will suppress this warning, call:
hint:
hint: git config --global init.defaultBranch
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this command:
hint:
hint: git branch -m
2023/09/10 20:37:16 Adding remote "origin" with URL
"g...@salsa.debian.org:go-team/packages/golang-github-tailscale-tailscale.git"
2023/09/10 20:37:16 Adding remote "github" with URL
"https://github.com/tailscale/tailscale;
2023/09/10 20:37:16 Running "git fetch github"
remote: Enumerating objects: 55925, done.
remote: Counting objects: 100% (1718/1718), done.
remote: Compressing objects: 100% (408/408), done.
remote: Total 55925 (delta 1363), reused 1499 (delta 1307), pack-reused 54207
Receiving objects: 100% (55925/55925), 21.87 MiB | 3.40 MiB/s, done.
Resolving deltas: 100% (38285/38285), done.
>From https://github.com/tailscale/tailscale
* [new branch]Aadi/speedtest-tailscaled ->
github/Aadi/speedtest-tailscaled
* [new branch]Xe/TS-envvar-name -> github/Xe/TS-envvar-name
* [new branch]Xe/debug-nixos-build-> github/Xe/debug-nixos-build
* [new branch]Xe/derphttp-panic-fix -> github/Xe/derphttp-panic-fix
* [new branch]
Bug#994442: (no subject)
Hi, I tried to reproduce this issue without success. Please note that 1.0.5 has been released. Can you give me exact steps to reproduce it in 1.0.5 using the current version of chainsaw? Thanks. -- Tiago Bortoletto Vaz
Bug#1013351: (no subject)
Hi, thanks for reporting. I'll see how it can grab this info from lsb-release. Now it could get such info from /etc/lsb-release: # Source lsb-release so we know what distribution we are DISTRIB_ID="Debian"# Default to Debian [ -e /etc/lsb-release ] && . /etc/lsb-release ...however current lsb-release uses "/etc/os-release" instead. I'll fix that in the next days. For now, a workaround for you would be having a "/etc/lsb-release" with the DISTRIB_ID var set as you wish. In the future versions this will be probably taken from lsb-release PRETTY_NAME var instead: $ cat /usr/lib/os-release PRETTY_NAME="Debian GNU/Linux bookworm/sid" NAME="Debian GNU/Linux" ID=debian HOME_URL="https://www.debian.org/; SUPPORT_URL="https://www.debian.org/support; BUG_REPORT_URL="https://bugs.debian.org/; Bests, -- Tiago
Bug#952898: (no subject)
Hi, thanks for reporting that, it's indeed an issue that should be fixed. I think this would be better addressed by apt-listchanges itself, and I filed a report for that: #1020858 Bests, -- Tiago
Bug#1020858: apt-listchanges: Please consider line breaking
Package: apt-listchanges X-Debbugs-Cc: ti...@debian.org Version: 3.24 Severity: minor Dear Maintainer, In some situations, the "Changes for: ..." line becomes way too long and can break functionalities such as reported in #952898. For this specific case, I could certainly workaround apticron directly, but I think this issue would be better addressed in apt-listchanges, avoiding future issues in other tools and usage. Thanks for maintaining apt-listchanges. Bests, -- Tiago
Bug#1008877: ITA
retitle 1008877 ITA: screen-message -- Displays a short text fullscreen owner 1008877 ! thanks! On Sun, Apr 03, 2022 at 06:07:52PM +, Joachim Breitner wrote: > > 03.04.2022 19:53:37 Tiago Bortoletto Vaz : > > > Hi nomeata, > > > > I use screen-message in a few projects and I'd like to adopt it. If you're > > ok > > with that I can rename this bug to ITA and get the ownership. > > > > Thanks a lot for this nice tool and for your many years of contributions to > > Debian! > > > > Bests, > > > > -- > > Tiago > Yes, please do! > > Let me know if you want anything from me as upstream. > > Thanks, > Joachim
Bug#1008877: ITA
Hi nomeata, I use screen-message in a few projects and I'd like to adopt it. If you're ok with that I can rename this bug to ITA and get the ownership. Thanks a lot for this nice tool and for your many years of contributions to Debian! Bests, -- Tiago
Bug#1006017: playitslowly - PLEASE DON'T REMOVE FROM STABLE
Hi,
I've double-checked playitslowly in a clean stable system and indeed it
works. Thanks Chris for avoiding the removal in time. I'm not sure why
it hadn't work in my previous system.
Andreas, I had already tried 1.5.1 release and it presents the very same
issues on unstable. If the upstream or someone else decides to fix it
I'll be happy to upload it back to Debian. I just don't have the time to
make it myself atm.
Bests,
--
Tiago
On 2022-03-11 12:09 p.m., Andreas Beckmann wrote:
> On 11/03/2022 16.39, Tiago Bortoletto Vaz wrote:
>> Andreas Beckmann also confirmed it doesn't work for him.
>
> Digging a bit further into the problem ...
> https://stackoverflow.com/questions/55670051/python3-gtk-program-throws-introspection-typelib-error
>
> ... installing gir1.2-gtk-3.0 makes it no longer crash
> immediately at startup. It's noisy, though.
> But I have no idea if it is usable with this dependency added.;-)
>
> Btw, there seems to be a 1.5.1 upstream release available while
> Debian has 1.5.0.
>
> In a minimal pbuilder chroot with build-essential, playitslowly,
> xvfb, xauth, gir1.2-gtk-3.0 installed (and --install-recommends
> disabled):
>
> # xvfb-run playitslowly
> /usr/lib/python3/dist-packages/playitslowly/app.py:36: PyGIWarning: Gtk
> was imported without specifying a version first. Use
> gi.require_version('Gtk', '3.0') before import to ensure that the right
> version gets loaded.
> from gi.repository import Gtk, GObject, Gst, Gio, Gdk
> /usr/lib/python3/dist-packages/playitslowly/app.py:38:
> PyGIDeprecationWarning: Since version 3.11, calling threads_init is no
> longer needed. See: https://wiki.gnome.org/PyGObject/Threading
> GObject.threads_init()
> /usr/lib/python3/dist-packages/playitslowly/app.py:44:
> DeprecationWarning: Gtk.Settings.set_long_property is deprecated
> Gtk.Settings.get_default().set_long_property("gtk-button-images", True,
> "main")
> /usr/lib/python3/dist-packages/playitslowly/app.py:92:
> PyGTKDeprecationWarning: Using positional arguments with the GObject
> constructor has been deprecated. Please specify keyword(s) for "type" or
> use a class specific constructor. See:
> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> Gtk.Window.__init__(self, Gtk.WindowType.TOPLEVEL)
> /usr/lib/python3/dist-packages/playitslowly/app.py:117:
> PyGTKDeprecationWarning: Using positional arguments with the GObject
> constructor has been deprecated. Please specify keyword(s) for "label"
> or use a class specific constructor. See:
> https://wiki.gnome.org/PyGObject/InitializerDeprecations
> self.recentbutton = Gtk.Button(_("Recent"))
> /usr/lib/python3/dist-packages/playitslowly/app.py:164:
> PyGTKDeprecationWarning: Stock items are deprecated. Please use:
> Gtk.Button.new_with_mnemonic(label)
> self.play_button = Gtk.ToggleButton(stock=Gtk.STOCK_MEDIA_PLAY)
> /usr/lib/python3/dist-packages/playitslowly/app.py:166:
> DeprecationWarning: Gtk.Button.set_use_stock is deprecated
> self.play_button.set_use_stock(True)
> /usr/lib/python3/dist-packages/playitslowly/app.py:171:
> DeprecationWarning: Gtk.Button.new_from_stock is deprecated
> self.back_button = Gtk.Button.new_from_stock(Gtk.STOCK_MEDIA_REWIND)
>
> (app.py:1180): Gtk-WARNING **: 17:49:08.459: Error loading theme icon
> 'media-playback-start' for stock:
>
> (app.py:1180): Gtk-WARNING **: 17:49:08.460: Error loading theme icon
> 'media-seek-backward' for stock:
>
> (app.py:1180): Gtk-WARNING **: 17:49:08.460: Error loading theme icon
> 'document-save-as' for stock: Icon 'document-save-as' not present in
> theme Adwaita
>
> (app.py:1180): Gtk-WARNING **: 17:49:08.460: Error loading theme icon
> 'help-about' for stock: Icon 'help-about' not present in theme Adwaita
>
> ^C
>
>
> Andreas
>
Bug#1006017: playitslowly - PLEASE DON'T REMOVE FROM STABLE
Hi Chris, I've tested it here and got the same error as we have in unstable. Andreas Beckmann also confirmed it doesn't work for him. Are you sure you're testing it in a clean Bullseye system? Anyway, I'm dropping my request to removal from stable/old-stable for now: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006879 Bests, -- Tiago On 2022-03-10 6:32 p.m., Chris Guiver wrote: > I just tested `playitslowly` on a Debian 11/Bullseye box & it works for me. > > It worked for me in (Debian) `testing` ~until I filed the Ubuntu bug > report (or a few days before hand; Nov-2021) > > Yes loads of messages appear if you run it at terminal; but it starts > and runs on Debian Bullseye, Ubuntu impish correctly and earlier > systems in my experience (despite messages on screen). > > I use it mostly to loop music when I need to concentrate and don't > want any distractions; using it on a semi-regular basis (on different > Debian & Ubuntu systems) & only noticed issues Nov-21 in day(s) before > I filed bug report first on launchpad; being after the python3.10 > change. > > I'd request it NOT be removed from Debian stable. > > (I can test a debian old-stable too if helpful; but I tend to use it > on testing in Debian & development on Ubuntu & not older systems) >
Bug#1006879: RM: playitslowly/1.5.0-1.1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm X-Debbugs-Cc: ti...@debian.org Hi, I'm requesting the removal of playitslowly package from stable and oldstable due to an old RC bug as described in #1006017. A RM for unstable has been requested as well in #1006761. Thanks, -- Tiago
Bug#1006017: playitslowly doesn't start (hasn't for awhile)
On Sat, Mar 05, 2022 at 11:16:44AM +0100, Andreas Beckmann wrote: > On 04/03/2022 13.15, Tiago Bortoletto Vaz wrote: > > This package has indeed been broken for a long time already. Upstream is > > inactive since 2015 and I'm not willing to do all the fixes it would > > need. Therefore I requested its removal from Debian archive. > > Then we should probably get it removed from stable and and oldstable as > well, since it it not usable there either. > Can you file the corresponding bugs, too? Sure, I'll proceed with the requests. Bests, -- Tiago
Bug#1006017: playitslowly doesn't start (hasn't for awhile)
This package has indeed been broken for a long time already. Upstream is inactive since 2015 and I'm not willing to do all the fixes it would need. Therefore I requested its removal from Debian archive. Other tools present in Debian can perform the same task. For instance soundstretch (command line) and audacity (gui). Thanks for reporting, -- Tiago On 2022-02-19 4:50 p.m., Andreas Beckmann wrote: > Followup-For: Bug #1006017 > Control: found -1 1.5.0-1 > > This seems to go back to stretch: > > # xvfb-run playitslowly > Traceback (most recent call last): > File "", line 890, in _find_spec > AttributeError: 'DynamicImporter' object has no attribute 'find_spec' > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "/usr/lib/python3.5/runpy.py", line 193, in _run_module_as_main > "__main__", mod_spec) > File "/usr/lib/python3.5/runpy.py", line 85, in _run_code > exec(code, run_globals) > File "/usr/lib/python3/dist-packages/playitslowly/app.py", line 36, in > > from gi.repository import Gtk, GObject, Gst, Gio, Gdk > File "/usr/lib/python3/dist-packages/gi/importer.py", line 127, in > find_module > 'introspection typelib not found' % namespace) > ImportError: cannot import name Gtk, introspection typelib not found > > > Andreas >
Bug#1006761: RM: playitslowly -- ROM; RC-buggy; abandoned upstream
Package: ftp.debian.org Severity: normal X-Debbugs-Cc: ti...@debian.org Hi, this package has been broken for a long time already. Upstream is inactive since 2015 and I'm not willing to do all the fixes it would need. Other tools present in Debian can perform the same task. For instance soundstretch (command line) and audacity (gui). RC bug is #1006017. Thanks, -- Tiago
Bug#996910: linphone: Segmentation fault when registering a sip account
On Tue, Dec 28, 2021 at 06:21:56PM +0100, Dennis Filder wrote: > X-Debbugs-CC: Tiago Bortoletto Vaz > > On Tue, Dec 28, 2021 at 09:45:04AM -0500, Tiago Bortoletto Vaz wrote: > > gdb log attached. I hope that can be useful :\ > > That stacktrace looks very similar to the ones from #983597 which > already has 3 entries in the Qt bugtracker[0] one of which has an > Orca-less reproducer. Thus I'm inclined to mark this as a duplicate. That's fine. I'll keep an eye and try to provide them with some info if needed. By the way, it doesn't depend on the domain, neither it gets to the auth step. > Unfortunately, tracking this down would probably require unoptimized > debug builds of most of the involved libraries, so that's something > the Qt devs have to solve. Sure, thanks for the investigation. Bests,
Bug#996910: linphone: Segmentation fault when registering a sip account
> > What domain name are you using? Also are you doing this from the same > dialog as before? Because from the log output I would guess you are > using the settings menu instead of the account registering dialog. > Whether a crash happens from within the settings menu that would also > be important to know. Also, are you running Orca by any chance? I've tried available subdomains from voip.ms provider. For instance, vancouver1.voip.ms. I'm entering the registration data via the registering dialog, the one which appears once we open Linphone for the first time. I've also tried using the Preferences -> SIP accounts menu and get this segfault. I'm not running Orca. [...] > That was not as illuminating as I had hoped. If you can, download the > debug symbols package for linphone-desktop (or wherever the segfault > happens) from > http://debug.mirrors.debian.org/debian-debug/pool/main/l/linphone-desktop/ > and run it under gdb to get a stack trace. gdb log attached. I hope that can be useful :\ Bests, -- Tiago Starting program: /usr/bin/linphone [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffea9e4640 (LWP 932883)] [New Thread 0x7fffe932c640 (LWP 932884)] [New Thread 0x7fffe8b17640 (LWP 932886)] [New Thread 0x7fffdbfff640 (LWP 932892)] [New Thread 0x7fffcef01640 (LWP 932894)] [New Thread 0x7fffce700640 (LWP 932895)] [New Thread 0x7fffcdeff640 (LWP 932896)] [New Thread 0x7fffcd6fe640 (LWP 932897)] [New Thread 0x7fffccaed640 (LWP 932898)] [New Thread 0x7fffb7fff640 (LWP 932899)] [New Thread 0x7fffaf7fe640 (LWP 932900)] [New Thread 0x7fffb77fe640 (LWP 932901)] [New Thread 0x7fffb6c32640 (LWP 932902)] [New Thread 0x7fffb5bf1640 (LWP 932903)] [New Thread 0x7fffb53f0640 (LWP 932904)] [Thread 0x7fffb53f0640 (LWP 932904) exited] [New Thread 0x7fffb53f0640 (LWP 932905)] [Thread 0x7fffb53f0640 (LWP 932905) exited] [New Thread 0x7fffb53f0640 (LWP 932908)] [New Thread 0x7fffa640 (LWP 932920)] [Thread 0x7fffb77fe640 (LWP 932901) exited] [Thread 0x7fffaf7fe640 (LWP 932900) exited] [Thread 0x7fffb7fff640 (LWP 932899) exited] [Thread 0x7fffccaed640 (LWP 932898) exited] Thread 1 "linphone" received signal SIGSEGV, Segmentation fault. 0x in ?? () #0 0x in () #1 0x7745d9b7 in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #2 0x7745d9f9 in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #3 0x775d5a03 in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #4 0x7fffeaf8f8ca in () at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #5 0x7fffeaf91a84 in () at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #6 0x7fffeaf93120 in () at /lib/x86_64-linux-gnu/libQt5XcbQpa.so.5 #7 0x7746f9e8 in QQuickItemPrivate::setEffectiveVisibleRecur(bool) () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #8 0x77473259 in QQuickItem::setParentItem(QQuickItem*) () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #9 0x77473736 in QQuickItem::~QQuickItem() () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #10 0x7fffcc180615 in () at /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Templates.2/libqtquicktemplates2plugin.so #11 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x775e5315 in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #14 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #15 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x775e609e in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #17 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x775e614e in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #20 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #22 0x775e614e in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #23 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #24 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #25 0x775e5625 in () at /lib/x86_64-linux-gnu/libQt5Quick.so.5 #26 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #27 0x75c907b4 in QObject::~QObject() () at /lib/x86_64-linux-gnu/libQt5Core.so.5 #28 0x7fffcc180145 in () at /usr/lib/x86_64-linux-gnu/qt5/qml/QtQuick/Templates.2/libqtquicktemplates2plugin.so #29 0x75c85bde in QObjectPrivate::deleteChildren() () at /lib/x86_64-linux-gnu/lib
Bug#996910: linphone: Segmentation fault when registering a sip account
Package: linphone
Version: 4.2.5-3
Severity: important
X-Debbugs-Cc: ti...@debian.org
Dear Maintainer,
I'm getting a segmentation fault every time I try to registar a regular UDP
account from my SIP provider:
[...]
: Implicitly defined onFoo properties in Connections are deprecated. Use this
syntax instead: function onFoo() { ... }
[11:59:09:441][0x55a449eb92b0][Info]app/App.cpp:225: "Creating subwindow:
`qrc:/ui/views/App/Settings/SettingsWindow.qml`."
[11:59:09:506][0x55a449eb92b0][Info]app/App.cpp:232: "Subwindow status: `1`."
[11:59:09:682][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:
qrc:/ui/views/App/Settings/SettingsAdvanced.qml:91:7: QML Connections:
Implicitly defined onFoo properties in Connections are deprecated. Use this
syntax instead: function onFoo() { ... }
[11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:149:
qrc:/ui/views/App/Settings/SettingsVideo.qml:149:7: QML Connections:
Implicitly defined onFoo properties in Connections are deprecated. Use this
syntax instead: function onFoo() { ... }
[11:59:09:911][0x55a449eb92b0][Warning]qrc:/ui/views/App/Settings/SettingsVideo.qml:142:
qrc:/ui/views/App/Settings/SettingsVideo.qml:142:7: QML Connections:
Implicitly defined onFoo properties in Connections are deprecated. Use this
syntax instead: function onFoo() { ... }
[11:59:10:027][0x55a449eb92b0][Warning]app/App.cpp:802: System tray not found
on this system.
[11:59:10:062][0x55a449eb92b0][Warning]qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:
qrc:/ui/views/App/Main/Assistant/AssistantHome.qml:132:5: QML Connections:
Implicitly defined onFoo properties in Connections are deprecated. Use this
syntax instead: function onFoo() { ... }
[11:59:10:236][0x55a449eb92b0][Info]components/core/event-count-notifier/AbstractEventCountNotifier.cpp:71:
"Notify event count: 0."
[11:59:20:311][0x55a449eb92b0][Info]components/assistant/AssistantModel.cpp:416:
"Set config on assistant:
`/usr/share/linphone/assistant/use-other-sip-account.rc`."
Segmentation fault
Thanks,
-- System Information:
Debian Release: 11.0
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 5.10.0-8-amd64 (SMP w/4 CPU threads)
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8),
LANGUAGE=en_CA:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linphone depends on:
ii linphone-desktop 4.2.5-3
linphone recommends no packages.
linphone suggests no packages.
-- no debconf information
Bug#992957: Solved, i guess - Re: apticron: Wrong path of binary "hostname" inside /usr/sbin/apticron
Hi Tim, thanks for the follow-up, glad you found the issue at your side! I'm close this bug then. Bests, -- Tiago On Wed, Sep 15, 2021 at 12:00:54PM +0200, Tim Boneko wrote: > Hello! > Never mind about this, it seems to have been a DNS issue. My router > couldn't resolve its own ip address. After fixing this, apticron > started working again. > Cheers, > > tim
Bug#962921: Please fix spam for bullseye
Hi Romain, thanks for poking me on that. I've just uploaded a source-only version (1.2.5) with the same changes applied to 1.2.4. Bests, On 2021-03-28 7:29 a.m., Romain Francoise wrote: > Hi Tiago, > > apticron is scheduled for automatic removal on 04/12 and the fixed > package will not migrate because you included an arch-all binary in your > upload. Please upload a source-only version. > > Thanks. >
Bug#985606: Acknowledgement (unblock: apticron/1.2.4)
Attaching debdiff!
On Sat, Mar 20, 2021 at 04:30:04PM +, Debian Bug Tracking System wrote:
> Thank you for filing a new Bug report with Debian.
>
> You can follow progress on this Bug here: 985606:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985606.
>
> This is an automatically generated reply to let you know your message
> has been received.
>
> Your message is being forwarded to the package maintainers and other
> interested parties for their attention; they will reply in due course.
>
> As you requested using X-Debbugs-CC, your message was also forwarded to
> ti...@debian.org
> (after having been given a Bug report number, if it did not have one).
>
> Your message has been sent to the package maintainer(s):
> Debian Release Team
>
> If you wish to submit further information on this problem, please
> send it to 985...@bugs.debian.org.
>
> Please do not send mail to ow...@bugs.debian.org unless you wish
> to report a problem with the Bug-tracking system.
>
> --
> 985606: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=985606
> Debian Bug Tracking System
> Contact ow...@bugs.debian.org with problems
diff -Nru apticron-1.2.3+nmu1/apticron apticron-1.2.4/apticron
--- apticron-1.2.3+nmu1/apticron 2019-10-29 14:00:18.0 -0400
+++ apticron-1.2.4/apticron 2021-03-20 11:35:29.0 -0400
@@ -4,10 +4,10 @@
# implementations in Debian. Make sure we send proper headers, and a
# text/plain content type.
Mailx() {
-MAIL_BODY_FILE=$(tempfile)
+MAIL_BODY_FILE=$(mktemp)
cat > "$MAIL_BODY_FILE"
if [ "x$GPG_ENCRYPT" = "x1" ] && gpg --list-public-keys "$EMAIL" > /dev/null 2>&1; then
-MAIL_ENC_FILE=$(tempfile)
+MAIL_ENC_FILE=$(mktemp)
gpg --trust-model always --batch --armor --encrypt --recipient "$EMAIL" < "$MAIL_BODY_FILE" > "$MAIL_ENC_FILE"
mv "$MAIL_ENC_FILE" "$MAIL_BODY_FILE"
fi
diff -Nru apticron-1.2.3+nmu1/debian/changelog apticron-1.2.4/debian/changelog
--- apticron-1.2.3+nmu1/debian/changelog 2019-10-29 14:00:18.0 -0400
+++ apticron-1.2.4/debian/changelog 2021-03-20 11:45:39.0 -0400
@@ -1,3 +1,9 @@
+apticron (1.2.4) unstable; urgency=medium
+
+ * Fix tempfile warning message. (Closes: #962921)
+
+ -- Tiago Bortoletto Vaz Sat, 20 Mar 2021 11:45:39 -0400
+
apticron (1.2.3+nmu1) unstable; urgency=medium
* Non-maintainer upload.
Bug#985606: unblock: apticron/1.2.4
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock X-Debbugs-Cc: ti...@debian.org Please unblock package apticron. The only change is using `mktemp` instead of deprecated `tempfile` command in two lines of apticron's code. [ Reason ] Depecration warning produces an email every time apticron runs, see #962921 [ Impact ] Daily useless emails [ Tests ] Manual test [ Risks ] I can't see any risk [ 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 [ Other info ] The reporter has kindly contacted the release team before proposing the patch, according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962921#17 unblock apticron/1.2.4 Bests, -- Tiago
Bug#962921: (no subject)
user debian-rele...@lists.debian.org usertags 962921 + bsp-2021-03-ca-montreal tags 962921 + fixed pending thank you
Bug#962921: Please fix spam for bullseye
Hi again, I just noticed I had said I'd be working on it 'this weekend', but in fact I meant the next one, during our local sprint session from Debian-quebec. Bests, On Tue, Mar 09, 2021 at 09:30:27AM -0800, Felix Lechner wrote: > Dear maintainer, > > The release team will accept this patch for bullseye. They raised the > bug status to "serious" after I asked on your behalf. Please upload a > patched version and ask for unblocking in a bug against release.d.o. > > Thanks for your contributions to Debian! > > Kind regards > Felix Lechner
Bug#962921: Please fix spam for bullseye
Hi, I'll have it done this weekend, thanks for reporting! Bests, On Tue, Mar 09, 2021 at 09:30:27AM -0800, Felix Lechner wrote: > Dear maintainer, > > The release team will accept this patch for bullseye. They raised the > bug status to "serious" after I asked on your behalf. Please upload a > patched version and ask for unblocking in a bug against release.d.o. > > Thanks for your contributions to Debian! > > Kind regards > Felix Lechner
Bug#980017: argus-clients FTBFS due to missing link and includes for tirpc library
Source: argus-clients Version: 3.0.8.2-6 Severity: important Dear Maintainer, This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h". Sun RPC used to be included in glibc and now it must be added from TI-RPC library (libtirpc-dev). To fix it a simple change was needed: configure.ac: +AC_CHECK_LIB([tirpc],[rpc_call],, + [AC_MSG_ERROR([no tirpc library, exiting...!])]) +V_INCLS="$V_INCLS -I/usr/include/tirpc" AC_CHECK_FUNCS(xdrmem_create) The full debdiff is available at: https://launchpadlibrarian.net/516883019/argus-clients_1%3A3.0.8.2-6ubuntu1_1%3A3.0.8.2-6ubuntu2.diff.gz Best regards, Tiago -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980016: argus FTBFS due to missing link and includes for tirpc library
Source: argus Version: 2:3.0.8.2-2 Severity: important Dear Maintainer, This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h". Sun RPC used to be included in glibc and now it must be added from TI-RPC library (libtirpc-dev). To fix it 3 changes were required: configure.ac: +AC_CHECK_LIB([tirpc],[rpc_call],, + [AC_MSG_ERROR([no tirpc library, exiting...!])]) AC_CHECK_FUNCS(xdrmem_create) reordering library inclusion in argus/Makefile.in: -LIB = @LIBS@ @V_THREADS@ $(WRAPLIBS) $(SASLLIBS) $(COMPATLIB) ../lib/argus_common.a -lm +LIB = ../lib/argus_common.a -lm @LIBS@ @V_THREADS@ $(WRAPLIBS) $(SASLLIBS) $(COMPATLIB) and finally the header include in debian/rules +export DEB_CFLAGS_MAINT_APPEND = -I/usr/include/tirpc I tried the header inclusion through V_INCLS but it was being overriden by the wrap macro, and this quick workaround was fine. The full debdiff is available at: https://launchpad.net/ubuntu/+archive/primary/+files/argus_2%3A3.0.8.2-2_2%3A3.0.8.2-2ubuntu1.diff.gz Best regards, Tiago -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#980015: alberta: FTBFS due to missing link and include for tirpc library
Source: alberta Version: 3.0.1-2 Severity: important Dear Maintainer, This package failed to rebuild in Ubuntu with "fatal error: rpc/type.h". Sun RPC used to be included in glibc and now it must be added from TI-RPC library (libtirpc-dev). I was able to build it after adding a check lib in configure.ac right before check headers for rpc/types.h +AC_CHECK_LIB([tirpc],[rpc_call],, + [AC_MSG_ERROR([no tirpc library, exiting...!])]) and including the library in debian/rules +export DEB_CFLAGS_MAINT_APPEND = -I/usr/include/tirpc There might a better way to include that library directly in configure.ac, but this is what worked for me. Regards, Tiago -- System Information: Debian Release: bullseye/sid APT prefers focal-updates APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, 'focal'), (400, 'focal-proposed'), (100, 'focal-backports') Architecture: amd64 (x86_64) Kernel: Linux 5.8.0-36-generic (SMP w/12 CPU cores) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#972137: SSL certificate problem (Was: Bug#972137: r-bioc-tcgabiolinks: autopkgtest regression)
Hi Andreas, The software access an external database to retrieve the genome information. The database has experienced problems in the last days and it has not been fixed yet. I am trying to save the genome information inside the package so it does not depends on the database anymore. I'll let you know when I fix it. Best regards, Tiago Chedraoui Silva On Tue, Oct 13, 2020 at 6:04 AM Andreas Tille wrote: > Control: tags -1 upstream > Control: tags -1 help > Control: forwarded -1 Antonio Colaprico , Tiago > Chedraoui Silva > > > Hi Antonio and Tiago, > > the Debian packaged version of TCGAbiolinks received a bug report about > a failure in its test suite. I have the impression that the SSL > certificate of a site where data are downloaded from is not correct. > Could you please verify the test suite and let me know whether you > might also get > > ── 1. Error: Preparing HT_HG-U133A as SE works > (@test-prepare-download.R#193) ─ > > failed to get URL after 3 tries: > > >error: SSL certificate problem: unable to get local issuer certificate > > > > Kind regards > >Andreas. > > On Tue, Oct 13, 2020 at 08:36:21AM +0200, Graham Inggs wrote: > > Source: r-bioc-tcgabiolinks > > Version: 2.16.4+dfsg-1 > > Severity: serious > > Tags: sid bullseye > > X-Debbugs-CC: debian...@lists.debian.org > > User: debian...@lists.debian.org > > Usertags: regression > > > > Hi Maintainer > > > > Since 2020-10-08, the autopkgtest of r-bioc-tcgabiolinks has been > failing [1]. > > > > I've copied what I hope is the relevant part of the log below. > > > > Does this autopkgtest download data? If so, please add the > > 'needs-internet' [2] restriction to debian/tests/control, or even skip > > that particular test. > > > > Regards > > Graham > > > > > > [1] https://ci.debian.net/packages/r/r-bioc-tcgabiolinks/testing/amd64/ > > [2] > https://salsa.debian.org/ci-team/autopkgtest/raw/master/doc/README.package-tests.rst > > > > > > ── 1. Error: Preparing HT_HG-U133A as SE works > (@test-prepare-download.R#193) ─ > > failed to get URL after 3 tries: > > error: SSL certificate problem: unable to get local issuer certificate > > Backtrace: > > 1. TCGAbiolinks::GDCprepare(query, summarizedExperiment = TRUE) > > 2. TCGAbiolinks:::readGeneExpressionQuantification(...) > > 3. TCGAbiolinks:::makeSEfromGeneExpressionQuantification(...) > > 4. TCGAbiolinks::get.GRCh.bioMart(genome) > > > > ___ > > R-pkg-team mailing list > > r-pkg-t...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/r-pkg-team > > -- > http://fam-tille.de >
Bug#944738: [Openjdk] Bug#944738: openjdk-11: diff for NMU version 11.0.8+10-1.1
On Mon, Sep 28, 2020 at 12:24 PM tony mancill wrote: > > On Mon, Sep 28, 2020 at 02:05:24PM +0200, Matthias Klose wrote: > > On 9/24/20 7:47 PM, tony mancill wrote: > > > Control: tags 944738 + pending > > > > > > Hello Matthias, > > > > > > I've prepared an NMU for openjdk-11 (versioned as 11.0.8+10-1.1) and > > > uploaded it to DELAYED/15. Please feel free to tell me if I should delay > > > it longer or remove the upload from the queue. > > > > please could you stop doing these NMUs? There's no reason to fast-track > > those > > before the next regular updates. Disappointed about that communication > > style, > > after your words at FOSDEM, nothing happened and then suddenly you start > > NMUing. > > Hi Matthias, > > Yes, I will both cease and also remove these NMUs from the upload queue > if you would prefer that. Regarding communication, we have been > discussing the bug in the BTS since September 18th and I announced my > intention to NMU on September 20th: > > > Once the upload is ready (see below), I will upload it as an NMU to > > the delayed queue if we haven't heard back from Matthias. > > (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944738#79) > > I assumed that you saw the traffic - after all, you did see the nmudiff > email - but would you prefer a direct cc: in the future? > > Regarding the sudden activity - in my opinion, the jlink bug is serious. > Part of the functionality of the JDK was broken in order to support > reproducible builds - and so I was trying to help address that. I'm > grateful that Julian discovered the root cause. Disclaimer: I am not involved in Debian and not very familiar with how NMUs are done and how they affect the package/distro, I'm just stating my opinion as an Ubuntu maintainer for the OpenJDK security releases regarding the patch itself. I agree with Tony's statement that this is a serious issue - and I'm also very glad that Julian found the root cause. The next security update comes out on Oct 20th and we should have it packaged in the same week, so while waiting until then seems ok, I believe it could be very useful to have the jlink patch out now so users can report back if they see any issues on the current fix. cheers! -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#944738: [Openjdk] Bug#944738: jlink: Hash of module differs to expected hash recorded in java.base
Hi Tony, Matthias is the actual Debian Maintainer, but in my opinion the patch is great and should be ok to go do an upload including it. Thanks Julian for the investigation and figuring out how to fix this problem, I really appreciate it. =) Best regards, Tiago On Fri, Sep 18, 2020 at 11:12 AM tony mancill wrote: > > On Fri, Sep 18, 2020 at 11:15:13AM +0100, Julian Gilbey wrote: > > tags 944738 patch > > thanks > > > > On Thu, Sep 17, 2020 at 06:45:39PM +0100, Julian Gilbey wrote: > > > affects 944738 openjdk-14-jdk > > > thanks > > > > > > The same problem is still present in openjdk-14 - see > > > https://bugs.debian.org/968991 > > > > I have located the source of the bug and have a patch to fix it. > > > > The cause is the use of dh_strip_nondeterminism late in the build > > process. This reorganises the jmod files, which in turn changes their > > SHA256 checksums. This would not be a problem, except that the > > checksums are saved in java.base.jmod *before* the use of > > dh_strip_nondeterminism. Performing this stripping immediately after > > each jmod file is created results in the checksums being consistent > > throughout. > > Thank you for digging into this bug Julian! > > Matthias or Tiago, any concerns with me preparing an upload that > includes this patch? > > Thank you, > tony > ___ > Mailing list: https://launchpad.net/~openjdk > Post to : open...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openjdk > More help : https://help.launchpad.net/ListHelp -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#965047: jtreg won't run as it can't locate its own jar file
Please consider the attached debdiff to fix this issue. jtreg-5.1-b01-1_5.1-b01-2.debdiff Description: Binary data
Bug#965047: jtreg won't run as it can't locate its own jar file
Package: jtreg
Version: 5.1-b01-1
Severity: important
Dear Maintainer,
Since jtreg 5.1-b01-1 it will no longer run without having JTREG_HOME (or
JT_HOME) explicitly set on the environment, previous versions worked ok.
It will exit 1 when trying to run it:
$ jtreg
Cannot determine JTREG_HOME; please set it explicitly
The reason is a change in debian/patches/launcher.patch that adds the check
if [ -z "${JTREG_HOME}" ]; then
JTREG_HOME="/usr/share/jtreg"
fi
too further down compared to the previous jtreg version. This causes the code
to search for lib/jtreg.jar in the script's path (/usr/bin) first, which does
not work and then calls exit 1.
That check is added exclusively for Debian/Ubuntu by d/p/launcher.patch and
should come before jtreg will try to look for lib/jtreg.jar by itself.
This also affects openjdk autopkgtests, which don't get run becuse jtreg
fails to start.
Thanks!
-- System Information:
Debian Release: bullseye/sid
APT prefers focal
APT policy: (500, 'focal'), (400, 'focal-proposed')
Architecture: amd64 (x86_64)
Kernel: Linux 5.4.0-26-generic (SMP w/8 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE,
TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#807648: your mail
#963550 Thanks, On Tue, Jun 23, 2020 at 08:54:46AM -0400, Tiago Bortoletto Vaz wrote: > Yes, please. And sorry for the MIA on this. > > I'm doing the RFP later today. > > Bests, > > On Sat, Jun 13, 2020 at 11:09:27PM +0200, Moritz Mühlenhoff wrote: > > On Mon, Sep 03, 2018 at 11:25:07PM -0400, Tiago Bortoletto Vaz wrote: > > > Hi, sorry for the long delay. > > > > > > I'm doing a (late) cleanup in my packages and will update Zyne to the new > > > upstream version, which now runs with python3 and python-wxgtk4.0. I'll > > > have > > > to package a new dependency as well: > > > https://github.com/belangeo/pyo-tools. > > > It will take some time, anyway just for the record that I didn't give up > > > about this nice synth in Debian. > > > > There hasn't been any further update, let's remove zyne? > > > > Cheers, > > Moritz
Bug#963550: RM: zyne -- ROM; missing dependency
Package: ftp.debian.org Severity: normal Current packaged version depends on obsolete wxPython. New upstream version depends on (at least one) unpackaged library pyo-tools. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=807648 Not impossible to repackage it in the future if anyone is interested on rechecking all the new required dependencies. Thanks,
Bug#807648: your mail
> I'm doing the RFP later today. Request for Removal I meant. Bests, > Bests, > > On Sat, Jun 13, 2020 at 11:09:27PM +0200, Moritz Mühlenhoff wrote: > > On Mon, Sep 03, 2018 at 11:25:07PM -0400, Tiago Bortoletto Vaz wrote: > > > Hi, sorry for the long delay. > > > > > > I'm doing a (late) cleanup in my packages and will update Zyne to the new > > > upstream version, which now runs with python3 and python-wxgtk4.0. I'll > > > have > > > to package a new dependency as well: > > > https://github.com/belangeo/pyo-tools. > > > It will take some time, anyway just for the record that I didn't give up > > > about this nice synth in Debian. > > > > There hasn't been any further update, let's remove zyne? > > > > Cheers, > > Moritz
Bug#807648: your mail
Yes, please. And sorry for the MIA on this. I'm doing the RFP later today. Bests, On Sat, Jun 13, 2020 at 11:09:27PM +0200, Moritz Mühlenhoff wrote: > On Mon, Sep 03, 2018 at 11:25:07PM -0400, Tiago Bortoletto Vaz wrote: > > Hi, sorry for the long delay. > > > > I'm doing a (late) cleanup in my packages and will update Zyne to the new > > upstream version, which now runs with python3 and python-wxgtk4.0. I'll have > > to package a new dependency as well: https://github.com/belangeo/pyo-tools. > > It will take some time, anyway just for the record that I didn't give up > > about this nice synth in Debian. > > There hasn't been any further update, let's remove zyne? > > Cheers, > Moritz
Bug#945961: xz-utils: FTBFS: cannot stat 'debian/tmp/usr/lib/x86_64-linux-gnu/liblzma.so.*'
On Thu, 9 Apr 2020 16:35:13 +0200 Sebastian Andrzej Siewior wrote: > I suggested already something in [0]. Back then we were hoping for some > feedback from the debhelper team. > Now I was just asking if Jonathan is handling this and/or if we could > also bump to current upstream version while at it. > > [0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945961#10 As Dimitri pointed out we have also been affected by this but in Ubuntu - we found it out recently when doing archive rebuilds on Focal. The proposed fix in #10 does workaround the issue and it is not necessary to change the build-arch rules as Dimitri suggested. I do wonder if this is in fact a regression in debhelper. I tracked it down to debhelper 12.4 to 12.5 and while I haven't been able to pinpoint exactly what particular change there is causing it I believe it is in how double colon rules are being interpreted. It seems the debhelper changes somehow fail to detect the build-arch rules. Unless someone knows enough perl to dig into debhelper changes between 12.4 and 12.5 and check if that is in fact a regression, I would suggest to simply apply the proposed change in comment #10. Thanks for your help =) Tiago Daitx
Bug#956676: firmware-iwlwifi: Can't get device info: No such device
Package: firmware-iwlwifi Version: 20190114-2 Severity: normal Dear Maintainer, * What led up to the situation? fresh install. * What exactly did you do (or not do) that was effective (or ineffective)? downloaded and tested kernel and firwmare from backports, reinstalled firmware and kernel from statble buster. * What was the outcome of this action? None, same, no efect what's so ever. * What outcome did you expect instead? The bluetooth interface to show up! -- System Information: Debian Release: 10.3 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-8-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8) Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled firmware-iwlwifi depends on no packages. firmware-iwlwifi recommends no packages. Versions of packages firmware-iwlwifi suggests: ii initramfs-tools 0.133+deb10u1 4.19.0-8-amd64 #1 SMP Debian 4.19.98-1 (2020-01-26) x86_64 GNU/Linux lspci|grep -i wire 03:00.0 Network controller: Intel Corporation Wireless 7265 (rev 59) dmesg |grep -i blue [ 2402.044618] Bluetooth: Core ver 2.22 [ 2402.044637] Bluetooth: HCI device and connection manager initialized [ 2402.044641] Bluetooth: HCI socket layer initialized [ 2402.044646] Bluetooth: L2CAP socket layer initialized [ 2402.044651] Bluetooth: SCO socket layer initialized -- no debconf information
Bug#951979: Anything related to recent patch from Ubuntu?
Hi Håvard, This FTBFS might have something to do with the recent added patch by you on last upload, and so far I can't find where is exactly the issue. Could you help? Thanks, -- Tiago
Bug#953379: gnome-subtitles: Please make another source-only upload to allow testing migration
Hi Boyuan, I've uploaded a 1.6-2 source-only version, thanks for reporting. Pedro, can you consider this issue for next gnomesubititles release? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948437 Let me know if you open an issue for that on gnomesubititles gitlab, then I add a proper tag at Debian BTS. Bests, On Sun, Mar 08, 2020 at 02:54:10PM -0400, Boyuan Yang wrote: > Source: gnome-subtitles > Version: 1.6-1 > Severity: important > X-Debbugs-CC: ti...@debian.org > > Hi Tiago, > > Thanks for updating gnome-subtitles to the new release. However, the latest > upload of gnome-subtitles was not a source-only upload; this means that the > new version will not be able to migrate to Testing. > > Please make another source-only upload to allow testing migration. For > details, please see https://wiki.debian.org/SourceOnlyUpload . > > Also I would be very much appreciated if https://bugs.debian.org/948437 can be > solved soon. > > -- > Best Regards, > Boyuan Yang
Bug#951604: gnome-subtitle: Please package the new upstream release (1.6)
Hi, I've just uploaded version 1.6. Thanks for reporting. Pedro, sorry for the loong delay. Bests, On Tue, Feb 18, 2020 at 01:42:30PM -0500, Boyuan Yang wrote: > Source: gnome-subtitles > Severity: normal > Version: 1.4.2-1 > X-Debbugs-CC: ti...@debian.org mee...@debian.org > > Dear gnome-subtitle maintainers, > > The upstream of gnome-subtitle has release v1.6 according to > http://gnomesubtitles.org/gnome-subtitles-release-1.6 . Please consider > packaging it in Debian. Thanks! > > -- > Best, > Boyuan Yang
Bug#936488: epylog: Python2 removal in sid/bullseye
On 2020-01-14 10:13, Stuart Prescott wrote: > This package appears to be dead upstream (upstream URL doesn't work and I > can't find it anywhere else). > > With a low popcon (inst: 9), perhaps it's time to remove this package. Indeed. I've asked for removal: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948896 Bests, -- tiago
Bug#948896: RM: epylog -- ROM; Python2; abandoned upstream; low popcon
Package: ftp.debian.org Severity: normal Please see #936488. Thanks. -- tiago
Bug#947326: antimony: diff for NMU version 0.9.3-1.1
Hi, I'm fine with the NMU, thanks. Bests, On 2020-01-06 06:26, Håvard Flaget Aasen wrote: > Control: tags 947326 + patch > Control: tags 947326 + pending > Control: tags 947479 + patch > Control: tags 947479 + pending > > > Dear maintainer, > > I've prepared an NMU for antimony (versioned as 0.9.3-1.1) and > uploaded it to DELAYED/XX. Please feel free to tell me if I > should delay it longer. > > Not sure how long it will be delayed > > Regards. > Håvard -- tiago
Bug#938969: python-packaging: test failures due to wrong arch check
Please consider the following debdiff to fix this issue.
diff -Nru python-packaging-19.1/debian/changelog python-packaging-19.1/debian/changelog
--- python-packaging-19.1/debian/changelog 2019-08-17 08:49:26.0 -0300
+++ python-packaging-19.1/debian/changelog 2019-08-29 18:58:34.0 -0300
@@ -1,3 +1,11 @@
+python-packaging (19.1-2) unstable; urgency=medium
+
+ * debian/patches/update-platform-for-pybuild.patch: use amd64 instead
+of x86_64 during the build as pybuild forcefully sets get_platform()
+to return linux-amd64.
+
+ -- Tiago Stürmer Daitx Thu, 29 Aug 2019 21:58:34 +
+
python-packaging (19.1-1) unstable; urgency=medium
* New upstream version.
diff -Nru python-packaging-19.1/debian/patches/series python-packaging-19.1/debian/patches/series
--- python-packaging-19.1/debian/patches/series 2015-10-28 11:18:13.0 -0200
+++ python-packaging-19.1/debian/patches/series 2019-08-29 18:58:34.0 -0300
@@ -1 +1,2 @@
# empty
+update-platform-for-pybuild.patch
diff -Nru python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch
--- python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch 1969-12-31 21:00:00.0 -0300
+++ python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch 2019-08-29 18:58:34.0 -0300
@@ -0,0 +1,84 @@
+Description: update x86_64 references to amd64
+ pybuild sets the _PYTHON_HOST_PLATFORM environment variable which
+ causes distutils.util.get_platform() to return linux-amd64 instead
+ of linux-x86_64. This causes 2 tests in test/test_tags.py to fail.
+ This patch updates the test_tags.py file to expect amd64 instead
+ of x86_64. Meanwhile packaging/tags.py needs to be updated to
+ support both linux-x86_64 (for runtime) and linux-amd64 (for build
+ time).
+Author: Tiago Stürmer Daitx
+Bug-Debian: http://bugs.debian.org/938969
+Forwarded: not-needed
+Last-Update: 2019-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/test_tags.py
b/tests/test_tags.py
+@@ -487,18 +487,18 @@ def test_have_compatible_glibc(monkeypat
+
+
+ def test_linux_platforms_64bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=False)[-1]
+-assert linux_platform == "linux_x86_64"
++assert linux_platform == "linux_amd64"
+
+
+ def test_linux_platforms_32bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=True)[-1]
+ assert linux_platform == "linux_i686"
+@@ -509,9 +509,9 @@ def test_linux_platforms_manylinux1(monk
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux1"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-assert platforms == ["manylinux1_x86_64", "linux_x86_64"]
++assert platforms == ["manylinux1_amd64", "linux_amd64"]
+
+
+ def test_linux_platforms_manylinux2010(monkeypatch):
+@@ -519,9 +519,9 @@ def test_linux_platforms_manylinux2010(m
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux2010"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-expected = ["manylinux2010_x86_64", "manylinux1_x86_64", "linux_x86_64"]
Bug#938969: python-packaging: test failures due to wrong arch check
Please consider the following debdiff to fix this issue.
diff -Nru python-packaging-19.1/debian/changelog python-packaging-19.1/debian/changelog
--- python-packaging-19.1/debian/changelog 2019-08-17 08:49:26.0 -0300
+++ python-packaging-19.1/debian/changelog 2019-08-29 18:58:34.0 -0300
@@ -1,3 +1,11 @@
+python-packaging (19.1-2) unstable; urgency=medium
+
+ * debian/patches/update-platform-for-pybuild.patch: use amd64 instead
+of x86_64 during the build as pybuild forcefully sets get_platform()
+to return linux-amd64.
+
+ -- Tiago Stürmer Daitx Thu, 29 Aug 2019 21:58:34 +
+
python-packaging (19.1-1) unstable; urgency=medium
* New upstream version.
diff -Nru python-packaging-19.1/debian/patches/series python-packaging-19.1/debian/patches/series
--- python-packaging-19.1/debian/patches/series 2015-10-28 11:18:13.0 -0200
+++ python-packaging-19.1/debian/patches/series 2019-08-29 18:58:34.0 -0300
@@ -1 +1,2 @@
# empty
+update-platform-for-pybuild.patch
diff -Nru python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch
--- python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch 1969-12-31 21:00:00.0 -0300
+++ python-packaging-19.1/debian/patches/update-platform-for-pybuild.patch 2019-08-29 18:58:34.0 -0300
@@ -0,0 +1,84 @@
+Description: update x86_64 references to amd64
+ pybuild sets the _PYTHON_HOST_PLATFORM environment variable which
+ causes distutils.util.get_platform() to return linux-amd64 instead
+ of linux-x86_64. This causes 2 tests in test/test_tags.py to fail.
+ This patch updates the test_tags.py file to expect amd64 instead
+ of x86_64. Meanwhile packaging/tags.py needs to be updated to
+ support both linux-x86_64 (for runtime) and linux-amd64 (for build
+ time).
+Author: Tiago Stürmer Daitx
+Bug-Debian: http://bugs.debian.org/938969
+Forwarded: not-needed
+Last-Update: 2019-08-30
+---
+This patch header follows DEP-3: http://dep.debian.net/deps/dep3/
+--- a/tests/test_tags.py
b/tests/test_tags.py
+@@ -487,18 +487,18 @@ def test_have_compatible_glibc(monkeypat
+
+
+ def test_linux_platforms_64bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=False)[-1]
+-assert linux_platform == "linux_x86_64"
++assert linux_platform == "linux_amd64"
+
+
+ def test_linux_platforms_32bit_on_64bit_os(monkeypatch):
+-is_64bit_os = distutils.util.get_platform().endswith("_x86_64")
++is_64bit_os = distutils.util.get_platform().endswith("_amd64")
+ if platform.system() != "Linux" or not is_64bit_os:
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ monkeypatch.setattr(tags, "_is_manylinux_compatible", lambda *args: False)
+ linux_platform = tags._linux_platforms(is_32bit=True)[-1]
+ assert linux_platform == "linux_i686"
+@@ -509,9 +509,9 @@ def test_linux_platforms_manylinux1(monk
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux1"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-assert platforms == ["manylinux1_x86_64", "linux_x86_64"]
++assert platforms == ["manylinux1_amd64", "linux_amd64"]
+
+
+ def test_linux_platforms_manylinux2010(monkeypatch):
+@@ -519,9 +519,9 @@ def test_linux_platforms_manylinux2010(m
+ tags, "_is_manylinux_compatible", lambda name, _: name == "manylinux2010"
+ )
+ if platform.system() != "Linux":
+-monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_x86_64")
++monkeypatch.setattr(distutils.util, "get_platform", lambda: "linux_amd64")
+ platforms = tags._linux_platforms(is_32bit=False)
+-expected = ["manylinux2010_x86_64", "manylinux1_x86_64", "linux_x86_64"]
Bug#938969: python-packaging: test failures due to wrong arch check
Package: python-packaging Version: 19.0-1 Severity: important Dear Maintainer, Since 19.1-1 python-packaging introduced a Tags class that has methods that depend upon distutils.util.get_platform(). The problem is that the behavior of get_platform() changes during build time, as pybuild sets _PYTHON_HOST_PLATFORM which overrides the default output of get_platform(). This causes linux-x86_64 to be changed to linux-amd64, leading to 2 test failures and some if clauses to run amok as they expect the string x86_64. Both tests/test_tags.py and packaging/tags.py require updates to deal with the build time get_platform changes. Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers eoan APT policy: (500, 'eoan'), (400, 'eoan-proposed') Architecture: amd64 (x86_64) Kernel: Linux 5.0.0-20-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=pt_BR.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages python-packaging depends on: ii python2.7.16-1 ii python-pyparsing 2.2.0+dfsg1-2 ii python-six1.12.0-1build1 python-packaging recommends no packages. python-packaging suggests no packages. -- no debconf information
Bug#926180: scilab: FTBFS on all - New trouble
On Tue, 14 May 2019 00:39:07 +0200 Alexis Murzeau wrote: > Le 13/05/2019 à 08:08, Sylvestre Ledru a écrit : > > > > On 12/05/2019 22:10, Julien Puydt wrote: > >> Hi, > >> > >> On 12/05/2019 11:46, Alexis Murzeau wrote: > >> > >>> I saw that there is a bugfix release 6.0.2 with many fixes [0]. > >> I had started to package 6.0.2 on salsa already in february. I removed > >> the patch about Linenum as that was supposed to have been reworked and > >> fixed, and it now fails with : > >> > >> ocamlopt -o XML2Modelica -I ./src/modelica_compiler -I > >> ./src/xml2modelica nums.cmxa ./src/xml2modelica/xMLTree.ml > >> ./src/xml2modelica/linenum.ml ./src/xml2modelica/stringParser.ml > >> ./src/xml2modelica/stringLexer.ml ./src/xml2modelica/xMLParser.ml > >> ./src/xml2modelica/xMLLexer.ml > >> ./src/xml2modelica/modelicaCodeGenerator.ml > >> ./src/xml2modelica/xML2Modelica.ml > >> File "./src/xml2modelica/xML2Modelica.ml", line 1: > >> Error: Files ./src/xml2modelica/xMLParser.cmx > >>and ./src/xml2modelica/linenum.cmx > >>make inconsistent assumptions over implementation Linenum > >> > >> ie : it looks like upstream's fix isn't correct. > > > > + upstream > > > > S > > > > > > Reversing the order of the includes parameters when compiling > XML2Modelica fix the build for me, ie. including xml2modelica first: > `-I ./src/xml2modelica -I ./src/modelica_compiler` > > I think ocamlopt prefer to use a part of Linenum from > ./src/modelica_compiler and the other one from ./src/xml2modelica which > lead to the error. > > But I'm not sure this is the way to handle it cleanly. > The files "linenum.mll" are almost the same between both directories. > The only difference is the comment at the beginning of the file. > > Maybe some of these "linenum.mll" file can be removed to keep only one ? Ubuntu has packaged 6.0.2 for Disco and Eoan, please see https://launchpad.net/ubuntu/+source/scilab or fetch the DSC directly from https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/scilab/6.0.2-0ubuntu2/scilab_6.0.2-0ubuntu2.dsc > > -- > Alexis Murzeau > PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F > >
Bug#928098: debdiff attached
--
tiago
diff -Nru sox-14.4.2/debian/changelog sox-14.4.2+git20190427/debian/changelog
--- sox-14.4.2/debian/changelog 2017-12-18 08:55:07.0 -0500
+++ sox-14.4.2+git20190427/debian/changelog 2019-04-27 15:57:59.0 -0400
@@ -1,3 +1,10 @@
+sox (14.4.2+git20190427-1) unstable; urgency=medium
+
+ * Add patches to fix CVE-2019-8354, CVE-2019-8355, CVE-2019-8356 and
+CVE-2019-8357. Thanks to Moritz Muehlenhoff. (Closes: #927906)
+
+ -- Tiago Bortoletto Vaz Sat, 27 Apr 2019 15:57:59 -0400
+
sox (14.4.2-3) unstable; urgency=medium
* Patch 0005 refreshed. (Closes: #882599)
diff -Nru sox-14.4.2/debian/control sox-14.4.2+git20190427/debian/control
--- sox-14.4.2/debian/control 2017-12-18 08:32:12.0 -0500
+++ sox-14.4.2+git20190427/debian/control 2019-04-27 15:52:25.0 -0400
@@ -1,7 +1,7 @@
Source: sox
Section: sound
Priority: optional
-Maintainer: Debian Multimedia Maintainers
+Maintainer: Debian Multimedia Maintainers
Uploaders: Jaromír Mikeš
Build-Depends: debhelper (>= 10~),
ladspa-sdk,
@@ -23,8 +23,8 @@
libvorbis-dev,
libwavpack-dev
Standards-Version: 4.1.2
-Vcs-Git: https://anonscm.debian.org/git/pkg-multimedia/sox.git
-Vcs-Browser: https://anonscm.debian.org/git/pkg-multimedia/sox.git
+Vcs-Git: https://salsa.debian.org/multimedia-team/sox.git
+Vcs-Browser: https://salsa.debian.org/multimedia-team/sox
Homepage: https://sox.sourceforge.io/
Package: sox
diff -Nru sox-14.4.2/debian/libsox3.symbols sox-14.4.2+git20190427/debian/libsox3.symbols
--- sox-14.4.2/debian/libsox3.symbols 2017-11-07 04:32:40.0 -0500
+++ sox-14.4.2+git20190427/debian/libsox3.symbols 2019-04-27 15:57:59.0 -0400
@@ -26,6 +26,7 @@
lsx_readbuf@Base 14.4.2~
lsx_readchars@Base 14.4.2~
lsx_realloc@Base 14.4.2~
+ lsx_realloc_array@Base 14.4.2~
lsx_report_impl@Base 14.4.2~
lsx_rewind@Base 14.4.2~
lsx_seeki@Base 14.4.2~
diff -Nru sox-14.4.2/debian/patches/0016-CVE-2019-8354.patch sox-14.4.2+git20190427/debian/patches/0016-CVE-2019-8354.patch
--- sox-14.4.2/debian/patches/0016-CVE-2019-8354.patch 1969-12-31 19:00:00.0 -0500
+++ sox-14.4.2+git20190427/debian/patches/0016-CVE-2019-8354.patch 2019-04-27 15:57:59.0 -0400
@@ -0,0 +1,11 @@
+--- a/src/effects_i_dsp.c
b/src/effects_i_dsp.c
+@@ -357,7 +357,7 @@
+ double scale, sox_bool dc_norm)
+ {
+ int i, m = num_taps - 1;
+- double * h = malloc(num_taps * sizeof(*h)), sum = 0;
++ double * h = calloc(num_taps, sizeof(*h)), sum = 0;
+ double mult = scale / lsx_bessel_I_0(beta), mult1 = 1 / (.5 * m + rho);
+ assert(Fc >= 0 && Fc <= 1);
+ lsx_debug("make_lpf(n=%i Fc=%.7g β=%g ρ=%g dc-norm=%i scale=%g)", num_taps, Fc, beta, rho, dc_norm, scale);
diff -Nru sox-14.4.2/debian/patches/0017-CVE-2019-8355.patch sox-14.4.2+git20190427/debian/patches/0017-CVE-2019-8355.patch
--- sox-14.4.2/debian/patches/0017-CVE-2019-8355.patch 1969-12-31 19:00:00.0 -0500
+++ sox-14.4.2+git20190427/debian/patches/0017-CVE-2019-8355.patch 2019-04-27 15:57:59.0 -0400
@@ -0,0 +1,46 @@
+--- a/src/Makefile.am
b/src/Makefile.am
+@@ -95,7 +95,7 @@
+
+ libsox_la_CFLAGS = @WARN_CFLAGS@
+ libsox_la_LDFLAGS = @APP_LDFLAGS@ -version-info @SHLIB_VERSION@ \
+- -export-symbols-regex '^(sox_.*|lsx_(([cm]|re)alloc|check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|error|fail_errno|filelength|find_(enum_(text|value)|file_extension)|flush|getopt(_init)?|id3_read_tag|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|rewind|seeki|sigfigs3p?|strcasecmp|strdup|tell|unreadb|write(b|_b_buf|buf|s)))$$'
++ -export-symbols-regex '^(sox_.*|lsx_(([cm]|re)alloc.*|check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|error|fail_errno|filelength|find_(enum_(text|value)|file_extension)|flush|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|rewind|seeki|sigfigs3p?|strcasecmp|strdup|tell|unreadb|write(b|_b_buf|buf|s)))$$'
+
+ if HAVE_WIN32_LTDL
+ libsox_la_SOURCES += win32-ltdl.c win32-ltdl.h
+--- a/src/xmalloc.c
b/src/xmalloc.c
+@@ -41,3 +41,13 @@
+
+ return ptr;
+ }
++
++void *lsx_realloc_array(void *p, size_t n, size_t size)
++{
++ if (n > (size_t)-1 / size) {
++lsx_fail("malloc size overflow");
++exit(2);
++ }
++
++ return lsx_realloc(p, n * size);
++}
+--- a/src/xmalloc.h
b/src/xmalloc.h
+@@ -23,12 +23,14 @@
+ #include
+ #include
+
++LSX_RETURN_VALID void *lsx_realloc_array(void *p, size_t n, size_t size);
++
+ #define lsx_malloc(size) lsx_realloc(NULL, (size))
+ #define lsx_calloc(n,s) (((n)*(s))? memset(lsx_malloc((n)*(s)),0,(n)*(s)) : NULL)
+ #define lsx_Calloc(v,n) v = lsx_calloc(n,sizeof(*(v)))
+ #define lsx_strdup(p) ((p)? strcpy((char *)lsx_malloc(strlen(p) + 1), p) : NULL)
+ #define lsx_memdup(p,s) ((p)? memcpy(lsx_malloc(s), p, s) : NULL)
+
Bug#928098: unblock: sox/4.4.2+git20190427-1
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: unblock Dear Release Team, Please unblock package sox. I've pushed the recent upstream commits for the following security fixes: CVE-2019-8354: https://sourceforge.net/p/sox/code/ci/f70911261a84333b077c29908e1242f69d7439eb/ CVE-2019-8355: https://sourceforge.net/p/sox/code/ci/f8587e2d50dad72d40453ac1191c539ee9e50381/ CVE-2019-8356: https://sourceforge.net/p/sox/code/ci/b7883ae1398499daaa926ae6621f088f0f531ed8/ CVE-2019-8357: https://sourceforge.net/p/sox/code/ci/2ce02fea7b350de9ddfbcf542ba4dd59a8ab255b/ Each fix is provided in a patch file: 0016-CVE-2019-8354.patch 0017-CVE-2019-8355.patch 0018-CVE-2019-8356.patch 0019-CVE-2019-8357.patch You might notice that I had to make a few modifications to avoid major changes in the current source. Diff is attached. unblock sox/4.4.2+git20190427-1 Thanks, -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#918826: (no subject)
control: user debian-rele...@lists.debian.org control: usertags -1 + bsp-2019-04-ca-toronto control: thanks -- tiago
Bug#925320: [Android-tools-devel] Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)
On Thu, Mar 28, 2019 at 7:24 AM Hans-Christoph Steiner wrote: > > > The "--release 8" fix seems fine, my only concern is that someone needs > to test this, since it is different than what upstream does. I suppose > that the autopkgtest is complete enough to test this. I'm not really > aware of whether there are security concerns of compiling with different > source/target/release versions. Do you know? > > .hc I am also not aware of any security issues related to providing backwards compatibility for compiled java classes. The --release flag (and the -source/-target pair) is and has been used on other packages for quite some time so there are no known drawbacks of using it, on the contrary, they are required so we can provide java 8 bytecode when compiling with a java 9+ compiler. Regards, Tiago
Bug#925320: [Android-tools-devel] Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)
Indeed, openjdk-8 is planned to be removed from buster, but any user that tries to run apksigner with a java 8 level binary (from openjdk, oracle, or other vendors) will be unable to do so. In addition to that Debian derivatives might be affected: Ubuntu is keeping openjdk-8 available for users and to avoid such simply delta I am proposing the patch to Debian. The early changelog entry related to the "-source 8" change stated that this was done to support java 8 level, but it missed the fact that it should actually have added "-target 8" at the least. I am aiming to fix that with the "--release 8" flag which is the proper way to set source/target since OpenJDK 9. Please note that the jh_build tool from javatools package has a bug that causes this package to currently FTBFS (with or without my change as the bug forces -source 7 -target 7 to be used which is incompatible with the level 8 source code): https://bugs.debian.org/925617 Regards, Tiago On Mon, Mar 25, 2019 at 4:52 PM Hans-Christoph Steiner wrote: > > > Can you tell me more about the use case for this? my understanding is > that openjdk-8 will not be supported in buster. > > .hc > > Tiago Daitx: > > Hi, > > > > Please consider my upload to mentors as a fix for this issue > > https://mentors.debian.net/package/android-platform-tools-apksig > > https://mentors.debian.net/debian/pool/main/a/android-platform-tools-apksig/android-platform-tools-apksig_0.8-3.dsc > > > > Regards, > > Tiago > > > > ___ > > Android-tools-devel mailing list > > android-tools-de...@alioth-lists.debian.net > > https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/android-tools-devel > > -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#925320: Acknowledgement (android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError)
Hi, Please consider my upload to mentors as a fix for this issue https://mentors.debian.net/package/android-platform-tools-apksig https://mentors.debian.net/debian/pool/main/a/android-platform-tools-apksig/android-platform-tools-apksig_0.8-3.dsc Regards, Tiago
Bug#925320: android-platform-tools-apksig: apksigner fails to run on OpenJDK 8 due to UnsupportedClassVersionError
Package: android-platform-tools-apksig Version: 0.8-2 Severity: important Dear Maintainer, The apksigner binary from android-platform-tools-apksig 0.8-2 fails to run under OpenJDK 8 because it is not being targetted to java 8 level. Please note that if OpenJDK 11 is installed it will be used instead even if the system is set to use OpenJDK 8 binaries by default, so if trying to reproduce this make sure that *only* OpenJDK 8 runtime is installed. The error is: $ apksigner Error: A JNI error has occurred, please check your installation and try again Exception in thread "main" java.lang.UnsupportedClassVersionError: com/android/apksigner/ApkSignerTool has been compiled by a more recent version of the Java Runtime (class file version 55.0), this version of the Java Runtime only recognizes class file versions up to 52.0 at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClass(ClassLoader.java:763) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142) at java.net.URLClassLoader.defineClass(URLClassLoader.java:468) at java.net.URLClassLoader.access$100(URLClassLoader.java:74) at java.net.URLClassLoader$1.run(URLClassLoader.java:369) at java.net.URLClassLoader$1.run(URLClassLoader.java:363) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:362) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:349) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:495) The fix is to replace the '-source 8' entry with '--release 8' in the rules file. While adding '-target 8' would also work, using '--release' is better as it also sets the right '-bootclasspath' without much fuzz. Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers disco APT policy: (500, 'disco'), (400, 'disco-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#925225: gradle: Fix gradle compatibility with OpenJDK 8
I uploaded a proposed solution to mentors, it is available at https://mentors.debian.net/package/gradle and dsc at https://mentors.debian.net/debian/pool/main/g/gradle/gradle_4.4.1-6.dsc That one involves using the actual upstream patch for https://github.com/gradle/gradle/commit/028548460bd929fd034a552704798ad7f689493a Regards, Tiago
Bug#925225: gradle: Fix gradle compatibility with OpenJDK 8
Package: gradle Version: 4.4.1-5 Severity: normal Dear Maintainer, Since the fix for bug #909905 in gradle 4.4.1-1 it has been not possible to run the generated binaries with OpenJDK 8. The patch introduced in 4.4.1-1 was loosely based on the actual upstream patch and - differently from upstream - it replaced OpenJDK 8 classloading with OpenJDK 9+ classloading scheme. The upstream patch modified classloading to _add_ OpenJDK 11 support. The 4.4.1-1 also modified gradle's Depends: to java 9. gradle 4.4.1 in itself is actually compatible with OpenJDK 8 and the packaging just added the minimum support to build and run it with OpenJDK 11. Still, that shouldn't be done in a way to remove the possibility of running gradle with OpenJDK 8. Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers disco APT policy: (500, 'disco'), (400, 'disco-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#923800: mapsforge: please include minimum versions in build-depends
Package: mapsforge Version: 0.10.0+dfsg.1-1 Severity: normal Dear Maintainer, mapsforge version 0.10.0+dfsg.1-1 does declare runtime version dependency but does not explicitly declares the required build time dependency versions. This would better show what is required for build and would help any future backports. I have run into this issue while backporting this package into Ubuntu Bionic (as part of the OpenJDK 11 transition). --- mapsforge-0.10.0+dfsg.1/debian/control 2018-10-25 20:30:27.0 + +++ mapsforge-0.10.0+dfsg.1/debian/control 2019-03-05 08:43:02.0 + @@ -1,12 +1,12 @@ gradle-debian-helper, javahelper (>= 0.70), junit4, - libjaxb-java, - libjts-java, - libkxml2-java, + libjaxb-java (>= 2.3.0.1), + libjts-java (>= 1.15.0), + libkxml2-java (>= 2.3.0), libsvgsalamander-java, - libtrove3-java, + libtrove3-java (>= 3.0.3), maven-repo-helper, - osmosis + osmosis (>= 0.46) Standards-Version: 4.1.2 Homepage: https://wiki.openstreetmap.org/wiki/Mapsforge Regards, Tiago Daitx -- System Information: Debian Release: buster/sid APT prefers disco APT policy: (500, 'disco'), (400, 'disco-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.19.0-13-generic (SMP w/4 CPU cores) Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#920534: openjdk-11: jlink creates very large runtime images
There is an open bug report on the OpenJDK side about this issue: https://bugs.openjdk.java.net/browse/JDK-8214796 and discussions on the fix are on the way. When this get implemented it could be backported into opendk-11 to enable the stripping of debug symbols from the java.base.jmod files.
Bug#795442: (no subject)
tags 795442 + upstream forwarded 795442 https://musescore.org/en/node/14365#comment-888396 usertags 795442 + bsp-2019-01-ca-montreal thanks I was about to close this bug due to the comments on this bug report at upstream's side: https://musescore.org/en/node/14365 (commit: https://github.com/musescore/MuseScore/commit/e6a2034b84b05f29ffbaf2d01e1aaf2e7c0438ee#diff-92b9ba7ed35cb159d5dbf87c5c1b2b74R149) However, after some testing I see that it hasn't been fixed on Linux systems yet. So, waiting from upstream answer. Bests, -- tiago
Bug#919797: RM: RoM flickrbackup/0.2-3.1; ancient; abandoned upstream; deprecated;
Package: release.debian.org Severity: normal User: release.debian@packages.debian.org Usertags: rm I took this code a few years ago and became the packager & upstream. It uses an old API and I'm not willing to update it anymore, since there are other newer tools (already packaged in Debian) for the same purpose. This package has been removed from unstable already (#904925). Please remove it from stable and testing. Thanks. -- System Information: Debian Release: buster/sid APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'testing'), (500, 'stable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.18.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_CA:en (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#914424: openjdk-11: mismatched cacert format
ca-certificates-java needs to be backported to stretch as well. On Fri, Nov 23, 2018 at 7:33 AM Robert Lemmen wrote: > > Source: openjdk-11 > Severity: normal > > hi folks, > > I was using the brand new openjdk-11 packages in stretch-backports. > thanks for providing these! they generally seem to work for me, but I > found that I cannot make TS connections. some googling revealed that the > default format for the cacert files jdk reads changed from jks to pkcs12 > or so. there seem to be plenty of reports aboutthis problem e.g. [0]. > > I managed to work around it by doing this: > > +echo "javax.net.ssl.trustStorePassword=changeit" \ > +>> /etc/java-11-openjdk/management/management.properties && \ > +/usr/bin/printf > '\xfe\xed\xfe\xed\x00\x00\x00\x02\x00\x00\x00\x00\xe2\x68\x6e\x45\xfb\x43\xdf\xa4\xd9\x92\xdd\x41\xce\xb6\xb2\x1c\x63\x30\xd7\x92' > > /etc/ssl/certs/java/cacerts && \ > +/var/lib/dpkg/info/ca-certificates-java.postinst configure > > but I guess a better solution is needed > > regards robert > > > -- System Information: > Debian Release: buster/sid > APT prefers testing > APT policy: (500, 'testing') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-2-amd64 (SMP w/8 CPU cores) > Locale: LANG=en_GB.UTF-8, LC_CTYPE=de_DE@euro (charmap=ISO-8859-15), > LANGUAGE=en_GB:en (charmap=ISO-8859-15) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#912527: [Openjdk] Bug#912527: openjdk-8-jdk: please update to support class file version 64
On Wed, Oct 31, 2018 at 11:57 PM Norbert Preining wrote: > $ java -jar myprog.jar > Error: A JNI error has occurred, please check your installation and try again > Exception in thread "main" java.lang.UnsupportedClassVersionError: > javafx/event/EventTarget has been compiled by a more recent version of the > Java Runtime (class file version 54.0), this version of the Java Runtime only > recognizes class file versions up to 52.0 > ... Please note that differently from Oracle JDK the OpenJDK project does not contain any classes for javafx. In Debian these classes are provided by the openjfx package. In particular the class javafx/event/EventTarget can be found in the libopenjfx-java binary package inside the /usr/share/java/javafx-base-11.jar file. >From your system informaton I can see you are running sid. The openjfx version in sid is 11+26-5, which is not compatible with openjdk-8 [see https://github.com/javafxports/openjdk-jfx/blob/jfx-11/doc-files/release-notes-11.md]. It depends and is only usable with openjdk-10 or openjdk-11. > OTOH, if I use jdk8 from upstream: > $ which java > /home/norbert/Java/jdk1.8.0_192/bin/java > $ java -version > java version "1.8.0_192-ea" > Java(TM) SE Runtime Environment (build 1.8.0_192-ea-b04) > Java HotSpot(TM) 64-Bit Server VM (build 25.192-b04, mixed mode) > $ java -jar myprog.jar > ... > > There are no problems. This is because the Oracle JDK packages JavaFX in its binary, it is not using the openjfx package from Debian, thus it works. > > Would it be possible to update jdk8 in Debian to support that? The only way for Debian to support that would be for it to have something like a separated openjfx-8 package that was compiled with openjdk-8. Somebody would have to be willing to support that but I am not sure if openjdk-8 will even be included in buster. The openjfx maintainer can probably provide a more insights into that. -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#913853: jtreg fails to run under openjdk-8 due to api incompatibility with openjdk-9 or later
I have also proposed it as a merge request in salsa. The url is https://salsa.debian.org/java-team/jtreg/merge_requests/1 I am still getting used to salsa and packages in git, hopefully I got the merge request right. And let me know if the it is any better/easier for you if I do it through mentors.debian.net instead. ;-) On Thu, Nov 15, 2018 at 10:33 PM Tiago Daitx wrote: > > Please consider the following debdiff patch to fix this issue. -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#913853: jtreg fails to run under openjdk-8 due to api incompatibility with openjdk-9 or later
Please consider the following debdiff patch to fix this issue. diff -Nru jtreg-4.2-b13/debian/changelog jtreg-4.2-b13/debian/changelog --- jtreg-4.2-b13/debian/changelog 2018-08-02 04:16:44.0 -0300 +++ jtreg-4.2-b13/debian/changelog 2018-11-01 02:36:28.0 -0300 @@ -1,3 +1,9 @@ +jtreg (4.2-b13-2) UNRELEASED; urgency=medium + + * Use release instead of source/target. (Closes: #913853, LP: #1803628) + + -- Tiago Stürmer Daitx Thu, 01 Nov 2018 05:36:28 + + jtreg (4.2-b13-1) unstable; urgency=medium * Team upload. diff -Nru jtreg-4.2-b13/debian/patches/series jtreg-4.2-b13/debian/patches/series --- jtreg-4.2-b13/debian/patches/series 2018-08-02 04:06:17.0 -0300 +++ jtreg-4.2-b13/debian/patches/series 2018-11-01 02:35:53.0 -0300 @@ -1,2 +1,3 @@ launchers.patch add-jcommander-to-classpath.patch +use-release-instead-of-source-target.patch diff -Nru jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch --- jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch 1969-12-31 21:00:00.0 -0300 +++ jtreg-4.2-b13/debian/patches/use-release-instead-of-source-target.patch 2018-11-01 02:36:28.0 -0300 @@ -0,0 +1,22 @@ +Description: use 'release' instead of 'target' and 'source' + When running jtreg with openjdk-8 and the agentvm it will fail to run with + "java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer". + An easy fix is to replace "source=1.7 target=1.7" with "release=7" in the + ant build script. +Author: Tiago Stürmer Daitx +Bug-Debian: https://bugs.debian.org/913853 +Bug-Ubuntu: https://launchpad.net/bugs/1803628 +Last-Update: 2018-11-01 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ +--- a/make/build.xml b/make/build.xml +@@ -172,7 +172,7 @@ + + + +-
Bug#913853: jtreg fails to run under openjdk-8 due to api incompatibility with openjdk-9 or later
Package: jtreg
Version: 4.2-b13-1
Severity: important
Dear Maintainer,
openjdk-9 introduced a few api changes that result in runtime errors when
trying to run the java classes under openjdk 8 (or earlier) even when
-source/-target are properly set.
The fix is to build such code using the new openjdk-9 flag "--release" instead
of the "-source/-target" pair.
When running Cosmic's jtreg 4.2-b13-1 with agentvm under openjdk-8 it will fail
and output a few lines such as:
stderr: Exception: java.lang.NoSuchMethodError thrown from the
UncaughtExceptionHandler in thread "main"
The java.lang.NoSuchMethodError is actually caused by
"java.lang.NoSuchMethodError: java.nio.ByteBuffer.flip()Ljava/nio/ByteBuffer"
which can be easily solved by building jtreg with the "--release 7" argument.
[Test Case]
For this test case we need to create an empty TEST.ROOT file and a test class
to satisfy jtreg requirements of a minimum test. jtreg must also be forced to
use openjdk-8.
$ sudo apt install openjdk-8-jdk jtreg
$ touch TEST.ROOT
$ cat > Hello.java << EOF
/*
* @test
* @bug 2718282
* @summary Hello test
*/
public class Hello {
public static void main(String [] args) throws Exception {
if (true)
System.out.println("Hello World!");
else
throw new Exception("??");
}
}
EOF
$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64/ jtreg -va -agentvm Hello.java
[2018-11-15 23:42:34,720] Agent[0]: stderr:
[2018-11-15 23:42:34,721] Agent[0]: stderr: Exception:
java.lang.NoSuchMethodError thrown from the UncaughtExceptionHandler in thread
"main"
--
TEST: Hello.java
TEST JDK: /usr/lib/jvm/java-8-openjdk-amd64
[snipped]
Test results: error: 1
Report written to /tmp/JTreport/html/report.html
Results written to /tmp/JTwork
Error: Some tests failed or other problems occurred.
The expected response from jtreg does not contain the "stderr:" lines as in:
$ JT_JAVA=/usr/lib/jvm/java-8-openjdk-amd64/ jtreg -va -agentvm Hello.java
--
TEST: Hello.java
TEST JDK: /usr/lib/jvm/java-8-openjdk-amd64
[snipped]
Test results: passed: 1
Report written to /tmp/JTreport/html/report.html
Results written to /tmp/JTwork
Alternatively one can also check that openjdk-lts is not affected by the
change, it should output the same before and after the fix:
$ sudo apt install openjdk-11-jdk
$ JT_JAVA=/usr/lib/jvm/java-11-openjdk-amd64/ jtreg -va -agentvm Hello.java
--
TEST: Hello.java
TEST JDK: /usr/lib/jvm/java-11-openjdk-amd64
[snipped]
Test results: passed: 1
Report written to /tmp/JTreport/html/report.html
Results written to /tmp/JTwork
[Regression Potential]
1. The --release argument is jdk9+ only, if jtreg is ever build with an older
jdk it will FTBFS, so this change should only be backported on releases where
the default-jdk is 9+.
2. The --release N argument is equivalent to setting -source N/-target
N/-bootclasspath , which can cause issues if the compiled
classes use APIs that have been removed or are considered internal. The current
jtreg version does not rely on internal classes from jdk 8 (otherwise it would
FTBFS) but if a later version does that it will probably FTBFS - note that this
is very unlikely as it would mean that upstream decided to break building jtreg
with newer jdks.
[Other Info]
See https://github.com/apache/felix/pull/114 for a good overview on the methods
that changed on OpenJDK 9 and a better description on the cause. Note that they
propose patching the methods to cast ByteBuffer to Buffer when calling the
affected methods, but this can be easily prevented by using the --release
argument instead.
I will follow-up with a patch as soon as I have a bug # to put on the
changelog and the patch dep3 header.
Regards,
Tiago
-- System Information:
Debian Release: buster/sid
APT prefers disco
APT policy: (500, 'disco'), (400, 'disco-proposed')
Architecture: amd64 (x86_64)
Kernel: Linux 4.18.0-10-generic (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Bug#910773: clojure1.8: clojure fails to run with openjdk-11
Please consider the attached debdiff which basically applies the upstream fix and adds a dep3 header to it. diff -Nru clojure1.8-1.8.0/debian/changelog clojure1.8-1.8.0/debian/changelog --- clojure1.8-1.8.0/debian/changelog 2018-08-04 17:56:45.0 -0300 +++ clojure1.8-1.8.0/debian/changelog 2018-10-10 13:47:36.0 -0300 @@ -1,3 +1,11 @@ +clojure1.8 (1.8.0-8) cosmic; urgency=medium + + * debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch: +Add hint type to toArray method to resolve ambiguity introduced by +JDK 11. (Closes: #910773, LP: #1796985). + + -- Tiago Stürmer Daitx Wed, 11 Oct 2018 02:12:55 + + clojure1.8 (1.8.0-7) unstable; urgency=medium * Update Vcs-* links to point to the clojure-team repo. diff -Nru clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch --- clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch 1969-12-31 21:00:00.0 -0300 +++ clojure1.8-1.8.0/debian/patches/03-add-toarray-hint-type-68d8b83138437c18.patch 2018-10-10 13:45:50.0 -0300 @@ -0,0 +1,37 @@ +Description: Add hint to overloaded toArray method + OpenJDK 11 added a new overload to the toArray method that + causes a slight API breakage. This requires calls to toArray + to set a type hint in order to prevent the exception + java.lang.IllegalArgumentException. +Origin: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23 +Bug: https://dev.clojure.org/jira/browse/CLJ-2374 +Bug-Ubuntu: https://launchpad.net/bugs/1796985 +Applied-Upstream: https://github.com/clojure/clojure/commit/68d8b83138437c18f1d5cf9ba46c056aa2701d23 +Last-Update: 2018-10-10 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ + +From 68d8b83138437c18f1d5cf9ba46c056aa2701d23 Mon Sep 17 00:00:00 2001 +From: Alex Miller +Date: Mon, 1 Oct 2018 09:29:37 -0500 +Subject: [PATCH] CLJ-2374 Add type hint to toArray to resolve ambiguity in JDK + 11 + +Signed-off-by: Stuart Halloway +--- + src/clj/clojure/gvec.clj | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/src/clj/clojure/gvec.clj b/src/clj/clojure/gvec.clj +index 3c4007379..6208f5539 100644 +--- a/src/clj/clojure/gvec.clj b/src/clj/clojure/gvec.clj +@@ -397,7 +397,7 @@ + (containsAll [this c] (every? #(.contains this %) c)) + (isEmpty [_] (zero? cnt)) + (toArray [this] (into-array Object this)) +- (toArray [this arr] ++ (^objects toArray [this ^objects arr] + (if (>= (count arr) cnt) + (do + (dotimes [i cnt] diff -Nru clojure1.8-1.8.0/debian/patches/series clojure1.8-1.8.0/debian/patches/series --- clojure1.8-1.8.0/debian/patches/series 2018-03-19 16:31:31.0 -0300 +++ clojure1.8-1.8.0/debian/patches/series 2018-10-10 13:46:55.0 -0300 @@ -1 +1,2 @@ 02-modify-cli-usage.patch +03-add-toarray-hint-type-68d8b83138437c18.patch
Bug#910773: clojure1.8: clojure fails to run with openjdk-11
Package: clojure1.8 Version: 1.8.0-7 Severity: important Dear Maintainer, when trying to run clojure1.8 with openjdk-11 it fails with Exception in thread "main" java.lang.ExceptionInInitializerError at clojure.main.(main.java:20) Caused by: java.lang.IllegalArgumentException: Must hint overloaded method: toArray, compiling:(clojure/gvec.clj:131:1) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6875) at clojure.lang.Compiler.analyze(Compiler.java:6669) at clojure.lang.Compiler.analyze(Compiler.java:6625) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6003) at clojure.lang.Compiler$LetExpr$Parser.parse(Compiler.java:6319) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868) at clojure.lang.Compiler.analyze(Compiler.java:6669) at clojure.lang.Compiler.analyze(Compiler.java:6625) at clojure.lang.Compiler$BodyExpr$Parser.parse(Compiler.java:6005) at clojure.lang.Compiler$FnMethod.parse(Compiler.java:5380) at clojure.lang.Compiler$FnExpr.parse(Compiler.java:3972) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6866) at clojure.lang.Compiler.analyze(Compiler.java:6669) at clojure.lang.Compiler.eval(Compiler.java:6924) at clojure.lang.Compiler.load(Compiler.java:7379) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__1621.invoke(core.clj:5893) at clojure.core$load.invokeStatic(core.clj:5892) at clojure.core$load.doInvoke(core.clj:5876) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$eval3106.invokeStatic(core.clj:6523) at clojure.core$eval3106.invoke(core.clj:6523) at clojure.lang.Compiler.eval(Compiler.java:6927) at clojure.lang.Compiler.load(Compiler.java:7379) at clojure.lang.RT.loadResourceScript(RT.java:372) at clojure.lang.RT.loadResourceScript(RT.java:363) at clojure.lang.RT.load(RT.java:453) at clojure.lang.RT.load(RT.java:419) at clojure.lang.RT.doInit(RT.java:461) at clojure.lang.RT.(RT.java:331) ... 1 more Caused by: java.lang.IllegalArgumentException: Must hint overloaded method: toArray at clojure.lang.Compiler$NewInstanceMethod.parse(Compiler.java:8206) at clojure.lang.Compiler$NewInstanceExpr.build(Compiler.java:7798) at clojure.lang.Compiler$NewInstanceExpr$DeftypeParser.parse(Compiler.java:7678) at clojure.lang.Compiler.analyzeSeq(Compiler.java:6868) ... 33 more This is related to https://dev.clojure.org/jira/browse/CLJ-2374 and the proposed fix upstream is available at https://github.com/tirkarthi/clojure/commit/63dab8e6cb702a6b0c5b279721bee7eff0aba44f.patch Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#910246: [ebo...@apache.org: Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro]
On Wed, Oct 3, 2018 at 11:57 PM Bruno Haible wrote: > Then, please apply the 2 patches from September 2018: > > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=bd09403f71a792b4e5c482c7ebb29d26c129dbe6 > https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=0782fa4dc036a709d5501a8712c5331489c28be9 I just saw this now, so someone might want to review/rework my patch in light of that. It's late and I will only review this tomorrow, but on a quick look they had a better and shorter conftest/conftestfail implementation. I also didn't add any support for openjdk 12+. cheers! -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#910246: gettext: FTBFS with Java 11: unknown target-version 11, please update gt_JAVACOMP macro
I updated the existing debian/patches/06-java9-support.patch to include support for openjdk 11, please see the attached debdiff. On Wed, Oct 3, 2018 at 9:45 PM Emmanuel Bourg wrote: > > Package: gettext > Version: 0.19.8.1-7 > Severity: important > Tags: sid buster > User: debian-j...@lists.debian.org > Usertags: default-java11 > > gettext fails to build with Java 11 because the configuration script > doesn't recognize the new version. During the build the following warning > can be seen: > > configure: WARNING: unknown target-version 11, please update gt_JAVACOMP > macro > checking for Java compiler... no > > The build later fails with: > > rm -f debian/gettext/usr/share/gettext/libintl.jar > mv debian/gettext/usr/share/gettext/gettext.jar > debian/gettext/usr/share/java > mv: cannot stat 'debian/gettext/usr/share/gettext/gettext.jar': No such > file or directory > make[1]: *** [debian/rules:139: gettext] Error 1 > -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE diff -Nru gettext-0.19.8.1/debian/changelog gettext-0.19.8.1/debian/changelog --- gettext-0.19.8.1/debian/changelog 2018-08-12 21:00:10.0 +0100 +++ gettext-0.19.8.1/debian/changelog 2018-10-04 00:10:11.0 +0100 @@ -1,3 +1,10 @@ +gettext (0.19.8.1-8) UNRELEASED; urgency=medium + + * debian/patches/06-java9-support.patch: update to support +openjdk 11. Closes: #910246. + + -- Tiago Stürmer Daitx Wed, 03 Oct 2018 23:10:11 + + gettext (0.19.8.1-7) unstable; urgency=medium * Use dh_autoreconf to regenerate autoconf stuff. New automake diff -Nru gettext-0.19.8.1/debian/patches/06-java9-support.patch gettext-0.19.8.1/debian/patches/06-java9-support.patch --- gettext-0.19.8.1/debian/patches/06-java9-support.patch 2018-08-12 20:06:00.0 +0100 +++ gettext-0.19.8.1/debian/patches/06-java9-support.patch 2018-10-04 00:10:11.0 +0100 @@ -29,7 +29,7 @@ dnl Copyright (C) 2001-2003, 2006-2007, 2009-2016 Free Software Foundation, dnl Inc. dnl This file is free software; the Free Software Foundation -@@ -15,7 +15,14 @@ +@@ -15,7 +15,15 @@ # 1.3 inner classes # 1.4 assert keyword # 1.5 generic classes and methods @@ -39,13 +39,14 @@ +# 1.8 lambdas +# 9 private interface methods +# 10 type inference for local variables ++# 11 type inference for lambda parameters +# Instead of source-version 1.6, use 1.5, since Java 6 did not introduce any +# language changes. See +# http://docs.oracle.com/javase/8/docs/technotes/guides/language/enhancements.html # # target-version can be: classfile version: # 1.1 45.3 -@@ -24,6 +31,10 @@ +@@ -24,6 +31,11 @@ # 1.4 48.0 # 1.5 49.0 # 1.6 50.0 @@ -53,10 +54,11 @@ +# 1.8 52.0 +# 9 53.0 +# 10 54.0 ++# 11 55.0 # The classfile version of a .class file can be determined through the "file" # command. More portably, the classfile major version can be determined through # "od -A n -t d1 -j 7 -N 1 classfile". -@@ -33,12 +44,18 @@ +@@ -33,12 +44,19 @@ # 1.1 JDK 1.1, jview # 1.2 JDK/JRE 1.2 # 1.3 JDK/JRE 1.3, gij 3.3, 3.4 @@ -70,6 +72,7 @@ +# 1.8 JDK/JRE 8 +# 9 JDK/JRE 9 +# 10 JDK/JRE 10 ++# 11 JDK/JRE 11 # Note: gij >= 3.3 can in some cases handle classes compiled with -target 1.4, # and gij >= 4.1 can in some cases partially handle classes compiled with -# -target 1.5, but I have no idea how complete this support is. @@ -79,7 +82,7 @@ # # Specifying target-version is useful when building a library (.jar) that is # useful outside the given package. Omitting target-version is useful when -@@ -47,14 +64,20 @@ +@@ -47,14 +64,21 @@ # It is unreasonable to ask for: # - target-version < 1.4 with source-version >= 1.4, or # - target-version < 1.5 with source-version >= 1.5, or @@ -90,6 +93,7 @@ +# - target_version < 1.8 with source_version >= 1.8, or +# - target_version < 9 with source_version >= 9, or +# - target_version < 10 with source_version >= 10, ++# - target_version < 11 with source_version >= 11, +# because even Sun's/Oracle's javac doesn't support these combinations. # # It is redundant to ask for a target-version > source-version, since the @@ -110,11 +114,11 @@ }` case "$target_version" in - 1.
Bug#910098: groovy: improve doc linking and add missing dependencies
Please consider this patch and disregard the old one.
I have dropped the ignore rule - it does not even use the
debian/docs.gradle file - and replaced the default-jdk-doc/api with
default-jdk/api as previously discussed in bug #896439 (ie. do not use
the -doc paths according to Debian Policy 3.9.7).
On Tue, Oct 2, 2018 at 6:41 PM Tiago Daitx wrote:
>
> Please consider the attached patch.
>
> It includes one additional "fix" from the Ubuntu delta to get
> groovydoc to ignore a file which was causing groovydoc to output a NUL
> char to stdout, that in turn caused the archive builders to fail -
> something about the python script giving up due to the output. I
> believe the debian builders are not affected, but in case you see any
> value on it, please use it. And if you really don't care about this
> patch let me know and I will send another debdiff without it.
>
> Note: for the Ubuntu side we have discussed cleaning up the output
> from sbuild, it's on my todo list, I consider the exclude list to be a
> temporary fix.
--
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com
PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
diff -Nru groovy-2.4.15/debian/changelog groovy-2.4.15/debian/changelog
--- groovy-2.4.15/debian/changelog 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/changelog 2018-09-27 18:46:07.0 +0100
@@ -1,3 +1,14 @@
+groovy (2.4.15-4) cosmic; urgency=medium
+
+ * Replace HTTP URLs with local files: (Closes: #910098)
+- debian/control: build depends on -doc packages so javadoc can
+ properly link the apis.
+- debian/patches/10_fix_javadoc_links.patch: include javadoc apis
+ locally, since openjdk 10 any invalid, unreacheable, or
+ nonexistent doc link causes the build to fail.
+
+ -- Tiago Stürmer Daitx Mon, 24 Sep 2018 12:19:05 +
+
groovy (2.4.15-3) unstable; urgency=medium
* Team upload.
diff -Nru groovy-2.4.15/debian/control groovy-2.4.15/debian/control
--- groovy-2.4.15/debian/control 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/control 2018-09-24 13:33:43.0 +0100
@@ -1,6 +1,7 @@
Uploaders: Felix Natter
Build-Depends:
ant,
+ ant-doc,
ant-optional,
antlr,
bnd (>= 2.1.0),
@@ -14,6 +16,7 @@
gradle-debian-helper,
ivy,
junit4,
+ junit4-doc,
libasm-java (>= 6.0~alpha-2~),
libbsf-java,
libcommons-cli-java,
@@ -24,6 +27,7 @@
libjline2-java,
libqdox-java,
libservlet3.1-java,
+ libservlet3.1-java-doc,
libxstream-java,
locales-all | language-pack-en,
maven-repo-helper,
@@ -75,7 +79,7 @@
Section: doc
Architecture: all
Depends: ${misc:Depends}
-Recommends: default-jdk-doc
+Recommends: default-jdk-doc, juni4-doc, libservlet3.1-java-doc
Suggests: groovy
Description: Agile dynamic language for the Java Virtual Machine (documentation)
Groovy is an agile dynamic language for the JVM combining lots of great
diff -Nru groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch
--- groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch 2018-09-24 13:32:01.0 +0100
@@ -3,18 +3,20 @@
Forwarded: not-needed
--- a/gradle/docs.gradle
+++ b/gradle/docs.gradle
-@@ -33,9 +33,7 @@
+@@ -33,9 +33,9 @@ def javadocSpec = {
overview = rootProject.file('src/main/overviewj.html')
footer = doc.footer
source = rootProject.useIndy()?'1.7':'1.6'
-links('http://docs.oracle.com/javase/8/docs/api/', 'http://docs.oracle.com/javaee/7/api/',
-'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'http://junit.org/junit4/javadoc/latest/',
-'http://docs.oracle.com/javaee/6/api/', 'http://www.antlr2.org/javadoc/')
-+links('file:/usr/share/doc/default-jre/api/')
++links('file:///usr/share/doc/ant/api/', 'file:///usr/share/doc/default-jdk/api/',
++ 'file:///usr/share/doc/libservlet3.1-java-doc/api',
++ 'file:///usr/share/doc/junit4/api/')
}
}
-@@ -53,12 +51,7 @@
+@@ -53,12 +53,10 @@ def groovydocSpec = {
overviewText = resources.text.fromFile(rootProject.file('src/main/overview.html'))
}
includePrivate = false
@@ -24,7 +26,10 @@
-link 'http://junit.org/junit4/javadoc/latest/', 'org.junit.', 'junit.'
-link 'http://www.antlr2.org/javadoc/', 'antlr.'
-link 'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'org.apache.commons.cli.'
-+link 'file:/usr/share/doc/default-jre/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/libservlet3.1-java-doc/api', 'javax.servlet.', 'javax.management.'
++link 'file:///usr/share/doc/default-jdk/api/', 'java.', 'org.xml.', 'jav
Bug#910098: groovy: improve doc linking and add missing dependencies
Please consider the attached patch.
It includes one additional "fix" from the Ubuntu delta to get
groovydoc to ignore a file which was causing groovydoc to output a NUL
char to stdout, that in turn caused the archive builders to fail -
something about the python script giving up due to the output. I
believe the debian builders are not affected, but in case you see any
value on it, please use it. And if you really don't care about this
patch let me know and I will send another debdiff without it.
Note: for the Ubuntu side we have discussed cleaning up the output
from sbuild, it's on my todo list, I consider the exclude list to be a
temporary fix.
diff -Nru groovy-2.4.15/debian/changelog groovy-2.4.15/debian/changelog
--- groovy-2.4.15/debian/changelog 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/changelog 2018-09-27 18:46:07.0 +0100
@@ -1,3 +1,18 @@
+groovy (2.4.15-4) cosmic; urgency=medium
+
+ * Replace HTTP URLs with local files: (Closes: #910098)
+- debian/control: build depends on -doc packages so javadoc can
+ properly link the apis.
+- debian/patches/10_fix_javadoc_links.patch: include javadoc apis
+ locally, since openjdk 10 any invalid, unreacheable, or
+ nonexistent doc link causes the build to fail.
+ * debian/patches/11_exclude_groovydoc.patch: exclude file
+org/codehaus/groovy/runtime/EncodingGroovyMethodsSupport.java from
+groovydoc because groovydoc complains about a NUL char and throws
+it to the build log, this causes the archive builders to fail.
+
+ -- Tiago Stürmer Daitx Mon, 24 Sep 2018 12:19:05 +
+
groovy (2.4.15-3) unstable; urgency=medium
* Team upload.
diff -Nru groovy-2.4.15/debian/control groovy-2.4.15/debian/control
--- groovy-2.4.15/debian/control 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/control 2018-09-24 13:33:43.0 +0100
@@ -1,6 +1,7 @@
Uploaders: Felix Natter
Build-Depends:
ant,
+ ant-doc,
ant-optional,
antlr,
bnd (>= 2.1.0),
@@ -14,6 +16,7 @@
gradle-debian-helper,
ivy,
junit4,
+ junit4-doc,
libasm-java (>= 6.0~alpha-2~),
libbsf-java,
libcommons-cli-java,
@@ -24,6 +27,7 @@
libjline2-java,
libqdox-java,
libservlet3.1-java,
+ libservlet3.1-java-doc,
libxstream-java,
locales-all | language-pack-en,
maven-repo-helper,
@@ -75,7 +79,7 @@
Section: doc
Architecture: all
Depends: ${misc:Depends}
-Recommends: default-jdk-doc
+Recommends: default-jdk-doc, juni4-doc, libservlet3.1-java-doc
Suggests: groovy
Description: Agile dynamic language for the Java Virtual Machine (documentation)
Groovy is an agile dynamic language for the JVM combining lots of great
diff -Nru groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch
--- groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch 2018-09-05 05:00:55.0 +0100
+++ groovy-2.4.15/debian/patches/10_fix_javadoc_links.patch 2018-09-24 13:32:01.0 +0100
@@ -3,18 +3,20 @@
Forwarded: not-needed
--- a/gradle/docs.gradle
+++ b/gradle/docs.gradle
-@@ -33,9 +33,7 @@
+@@ -33,9 +33,9 @@ def javadocSpec = {
overview = rootProject.file('src/main/overviewj.html')
footer = doc.footer
source = rootProject.useIndy()?'1.7':'1.6'
-links('http://docs.oracle.com/javase/8/docs/api/', 'http://docs.oracle.com/javaee/7/api/',
-'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'http://junit.org/junit4/javadoc/latest/',
-'http://docs.oracle.com/javaee/6/api/', 'http://www.antlr2.org/javadoc/')
-+links('file:/usr/share/doc/default-jre/api/')
++links('file:///usr/share/doc/ant/api/', 'file:///usr/share/doc/default-jdk-doc/api/',
++ 'file:///usr/share/doc/libservlet3.1-java-doc/api',
++ 'file:///usr/share/doc/junit4/api/')
}
}
-@@ -53,12 +51,7 @@
+@@ -53,12 +53,10 @@ def groovydocSpec = {
overviewText = resources.text.fromFile(rootProject.file('src/main/overview.html'))
}
includePrivate = false
@@ -24,7 +26,10 @@
-link 'http://junit.org/junit4/javadoc/latest/', 'org.junit.', 'junit.'
-link 'http://www.antlr2.org/javadoc/', 'antlr.'
-link 'http://commons.apache.org/proper/commons-cli/javadocs/api-release/', 'org.apache.commons.cli.'
-+link 'file:/usr/share/doc/default-jre/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/libservlet3.1-java-doc/api', 'javax.servlet.', 'javax.management.'
++link 'file:///usr/share/doc/default-jdk-doc/api/', 'java.', 'org.xml.', 'javax.', 'org.w3c.'
++link 'file:///usr/share/doc/ant/api/', 'org.apache.tools.ant.'
++link 'file:///usr/share/doc/junit4/api/', 'org.junit.'
}
allprojects {
diff -Nru groovy-2.4.15/debian/patches/11_exclude_groovydoc.patch groovy-2.4.15/debian/patches/11_exclude_groovydoc.patch
--- groovy-2.4.1
Bug#910098: groovy: improve doc linking and add missing dependencies
Package: groovy Version: 2.4.15-3 Severity: normal Dear Maintainer, The groovy doc linking can be improved by adding a few docs that have been packaged in Debian. Also, the previous fix for the jre doc link was using a URI with a single slash, which although works is not the standard. Additionally to that it was linking to default-jre/api, even though the actual doc apis files are in the default-jdk-doc package which is included in the b-deps. IMHO since the files and b-deps are from this package the hardcoded path should be enforced to use the same default-jdk-doc api path. I will attach the patch as soon as I have a bug number for the changelog entry. Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#910093: maven-compiler-plugin: tests fail due to hardcoded junit jar path and missing JAVA_HOME
Please consider the attached patch.
diff -Nru maven-compiler-plugin-3.8.0/debian/changelog maven-compiler-plugin-3.8.0/debian/changelog
--- maven-compiler-plugin-3.8.0/debian/changelog 2018-07-30 09:26:41.0 +0200
+++ maven-compiler-plugin-3.8.0/debian/changelog 2018-09-21 14:45:48.0 +0200
@@ -1,3 +1,12 @@
+maven-compiler-plugin (3.8.0-2) UNRELEASED; urgency=low
+
+ * Fix tests: (Closes: #910093)
+- debian/rules: set JAVA_HOME to prevent compiler test failure.
+- debian/patches/01-fix-wrong-junit-path.patch: patch wrong junit path in
+ compiler test.
+
+ -- Tiago Stürmer Daitx Fri, 21 Sep 2018 12:45:48 +
+
maven-compiler-plugin (3.8.0-1) unstable; urgency=medium
* Team upload.
diff -Nru maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch
--- maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch 1970-01-01 01:00:00.0 +0100
+++ maven-compiler-plugin-3.8.0/debian/patches/01-fix-wrong-junit-path.patch 2017-09-08 20:32:01.0 +0200
@@ -0,0 +1,21 @@
+Description: Fix wrong junit patch in Compiler test.
+ The compiler testcase sets an absolute path to junit's jar file
+ version 3.8.1 even though the pom.xml file now depends on 4.12
+ (4.x on Debian).
+ .
+ This patch fixes it and set the fixed path to a current junit jar
+ file.
+Author: Tiago Stürmer Daitx
+Last-Update: 2017-09-08
+
+--- maven-compiler-plugin-3.6.2.orig/src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java
maven-compiler-plugin-3.6.2/src/test/java/org/apache/maven/plugin/compiler/CompilerMojoTestCase.java
+@@ -397,7 +397,7 @@ public class CompilerMojoTestCase
+ String localRepository = System.getProperty( "localRepository" );
+ if ( localRepository != null )
+ {
+-artifactFile = new File( localRepository, "junit/junit/3.8.1/junit-3.8.1.jar" );
++artifactFile = new File( localRepository, "junit/junit/4.x/junit-4.x.jar" );
+ }
+ else
+ {
diff -Nru maven-compiler-plugin-3.8.0/debian/patches/series maven-compiler-plugin-3.8.0/debian/patches/series
--- maven-compiler-plugin-3.8.0/debian/patches/series 1970-01-01 01:00:00.0 +0100
+++ maven-compiler-plugin-3.8.0/debian/patches/series 2017-09-08 20:32:01.0 +0200
@@ -0,0 +1 @@
+01-fix-wrong-junit-path.patch
diff -Nru maven-compiler-plugin-3.8.0/debian/rules maven-compiler-plugin-3.8.0/debian/rules
--- maven-compiler-plugin-3.8.0/debian/rules 2018-07-30 01:26:57.0 +0200
+++ maven-compiler-plugin-3.8.0/debian/rules 2018-07-30 18:57:55.0 +0200
@@ -1,4 +1,5 @@
#!/usr/bin/make -f
+export JAVA_HOME=/usr/lib/jvm/default-java
%:
dh $@
Bug#910093: maven-compiler-plugin: tests fail due to hardcoded junit jar path and missing JAVA_HOME
Package: maven-compiler-plugin Version: 3.8.0-1 Severity: minor Dear Maintainer, Currently maven-compiler-plugin tests are failing due to 2 different reasons: 1. Some tests depend on JAVA_HOME being set 2. The junit jar file is hardcoded to version 3.8.1 Excerpt of the buildlog with the test failures: [ERROR] Tests run: 12, Failures: 0, Errors: 4, Skipped: 0, Time elapsed: 8.983 s <<< FAILURE! - in org.apache.maven.plugin.compiler.CompilerMojoTestCase [ERROR] testCompilerBasic(org.apache.maven.plugin.compiler.CompilerMojoTestCase) Time elapsed: 5.642 s <<< ERROR! org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerBasic(CompilerMojoTestCase.java:99) [ERROR] testCompilerIncludesExcludes(org.apache.maven.plugin.compiler.CompilerMojoTestCase) Time elapsed: 0.784 s <<< ERROR! org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerIncludesExcludes(CompilerMojoTestCase.java:190) [ERROR] testCompileSkipMain(org.apache.maven.plugin.compiler.CompilerMojoTestCase) Time elapsed: 0.369 s <<< ERROR! org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompileSkipMain(CompilerMojoTestCase.java:359) [ERROR] testCompilerFork(org.apache.maven.plugin.compiler.CompilerMojoTestCase) Time elapsed: 0.163 s <<< ERROR! org.apache.maven.plugin.MojoExecutionException: Fatal error compiling at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:215) Caused by: org.codehaus.plexus.compiler.CompilerException: Error while executing the external compiler. at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:215) Caused by: org.codehaus.plexus.util.cli.CommandLineException: Error while executing process. at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:215) Caused by: java.io.IOException: Cannot run program "bin/javac" (in directory "/<>"): error=2, No such file or directory at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:215) Caused by: java.io.IOException: error=2, No such file or directory at org.apache.maven.plugin.compiler.CompilerMojoTestCase.testCompilerFork(CompilerMojoTestCase.java:215) [INFO] [INFO] Results: [INFO] [ERROR] Errors: [ERROR] CompilerMojoTestCase.testCompileSkipMain:359 ? CompilationFailure Compilation ... [ERROR] CompilerMojoTestCase.testCompilerBasic:99 ? CompilationFailure Compilation fai... [ERROR] CompilerMojoTestCase.testCompilerFork:215 ? MojoExecution Fatal error compilin... [ERROR] CompilerMojoTestCase.testCompilerIncludesExcludes:190 ? CompilationFailure Com... [INFO] [ERROR] Tests run: 12, Failures: 0, Errors: 4, Skipped: 0 [INFO] [ERROR] There are test failures. Expected result with passing tests: [INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 51.216 s - in org.apache.maven.plugin.compiler.CompilerMojoTestCase [INFO] [INFO] Results: [INFO] [INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0 I will be attaching the debdiff with a fix as soon as I have a bug number to reference to in the changelog. Regards, Tiago -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)
Updated patch to include the missing DEP-3 headers and to remove the test files. On Mon, Oct 1, 2018 at 9:52 PM Tiago Daitx wrote: > > I have updated the patch to include 3 additional commits from > upstream, this fixes the build with openjdk-11 and stops gradle from > FTBFS. > > The last applied patch [1], which actually gets rid of the > "NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to > remove the kotlin classes and then put the new classes under > subprojets/base-services/ instead of subprojects/base-services-java9/ > in order to get them to compile - the logic of handling the > subprojects has been moved to kotlin and I didn't check if there was a > way to get it working with separated directories under gradle's 4.4 > build structure. > > For now I kept the openjdk-11 version check patch as it was > originally, having the full JEP-223 might actually be a good thing - I > will let the decision to someone who understands gradle better than I > do. > > Of course, always bootstrap with openjdk-10 first, after that the > generated binaries are good enough to get it to build with openjdk-11. > > [1] > debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch > > On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg wrote: > > > > Le 01/10/2018 à 19:37, shirish शिरीष a écrit : > > > > > So are we going to have gradle 4.8 in either experimental or unstable > > > soonish. > > > > Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and > > we are nowhere near having Kotlin in Debian. It's more likely we'll > > instead patch Gradle 4.4 and fix the Java 11 incompatibilities. > > > > > > > I'm sure you may have read the freeze time-table which was shared few > > > days ago. > > > > > > It would be nice to have all the components in debian tested etc. well > > > before freeze. > > > > Sure but this won't happen magically, we need more contributors. > > > > Emmanuel Bourg > > > > > -- > Tiago Stürmer Daitx > Software Engineer > tiago.da...@canonical.com > > PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) > Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog --- gradle-4.4/debian/changelog 2018-10-01 14:12:33.0 +0100 +++ gradle-4.4/debian/changelog 2018-10-01 20:05:23.0 +0100 @@ -1,3 +1,17 @@ +gradle (4.4-4) UNRELEASED; urgency=medium + + * Enable support for openjdk-11 (Closes: #909905) +- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch: + enable support for openjdk-11. +- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch: + Use Lookup to invoke defineClass on Java 9+. +- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch: + Don't use ClassLoader.getDefinedPackages() on Java 9. +- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path: + Use Lookup instead of reflection on Java 9+. + + -- Tiago Stürmer Daitx Mon, 01 Oct 2018 21:12:00 + + gradle (4.4-3) unstable; urgency=medium * Team upload. diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch --- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch 1970-01-01 01:00:00.0 +0100 +++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch 2018-10-01 20:05:23.0 +0100 @@ -0,0 +1,149 @@ +Description: Don't use ClassLoader.getDefinedPackages() on Java 9 + Prior to this change, FilteringClassLoader invokes + ClassLoader.getSystemClassLoader().getParent().getDefinedPackages() + to get all system packages on Java 9, which is not correct. + ClassLoader.getDefinedPackages() only fetches packages defined by + the ClassLoader itself, not including its parent's. The consequence is, + on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in + FilteringClassLoader.SYSTEM_PACKAGES. + + This PR fixes this problem by using ClassLoader.getPackages() all the time. +Origin: upstream, https://github.com/gradle/gradle/commit/50eababaa25230abc73899eda768dd0646ddcdb4 +Bug: https://github.com/gradle/gradle/pull/5477 +Bug-Debian: https://bugs.debian.org/909905 +Forwarded: not-needed +Applied-Upstream: 50eababaa25230abc73899eda768dd0646ddcdb4 +Last-Update: 2018-10-01 +--- +This patch
Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)
I have updated the patch to include 3 additional commits from upstream, this fixes the build with openjdk-11 and stops gradle from FTBFS. The last applied patch [1], which actually gets rid of the "NoSuchMethodError: sun.misc.Unsafe.defineClass" error, required me to remove the kotlin classes and then put the new classes under subprojets/base-services/ instead of subprojects/base-services-java9/ in order to get them to compile - the logic of handling the subprojects has been moved to kotlin and I didn't check if there was a way to get it working with separated directories under gradle's 4.4 build structure. For now I kept the openjdk-11 version check patch as it was originally, having the full JEP-223 might actually be a good thing - I will let the decision to someone who understands gradle better than I do. Of course, always bootstrap with openjdk-10 first, after that the generated binaries are good enough to get it to build with openjdk-11. [1] debian/patches/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.patch On Mon, Oct 1, 2018 at 8:39 PM Emmanuel Bourg wrote: > > Le 01/10/2018 à 19:37, shirish शिरीष a écrit : > > > So are we going to have gradle 4.8 in either experimental or unstable > > soonish. > > Unfortunately no. Starting with version 4.5 Gradle requires Kotlin, and > we are nowhere near having Kotlin in Debian. It's more likely we'll > instead patch Gradle 4.4 and fix the Java 11 incompatibilities. > > > > I'm sure you may have read the freeze time-table which was shared few days > > ago. > > > > It would be nice to have all the components in debian tested etc. well > > before freeze. > > Sure but this won't happen magically, we need more contributors. > > Emmanuel Bourg > -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog --- gradle-4.4/debian/changelog 2018-10-01 14:12:33.0 +0100 +++ gradle-4.4/debian/changelog 2018-10-01 20:05:23.0 +0100 @@ -1,3 +1,17 @@ +gradle (4.4-4) UNRELEASED; urgency=medium + + * Enable support for openjdk-11 (Closes: #909905) +- debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch: + enable support for openjdk-11. +- d/p/use-lookup-to-invoke-defineclass-java-9-028548460bd929fd.patch: + Use Lookup to invoke defineClass on Java 9+. +- d/p/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch: + Don't use ClassLoader.getDefinedPackages() on Java 9. +- d/p/use-lookup-instead-of-reflection-on-java-9-3db6e25698705317.path: + Use Lookup instead of reflection on Java 9+. + + -- Tiago Stürmer Daitx Mon, 01 Oct 2018 19:05:23 + + gradle (4.4-3) unstable; urgency=medium * Team upload. diff -Nru gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch --- gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch 1970-01-01 01:00:00.0 +0100 +++ gradle-4.4/debian/patches/do-not-use-classLoader-getdefinedpackages-on-java-9-50eababaa25230ab.patch 2018-09-29 21:25:43.0 +0100 @@ -0,0 +1,130 @@ +From 50eababaa25230abc73899eda768dd0646ddcdb4 Mon Sep 17 00:00:00 2001 +From: Bo Zhang +Date: Wed, 23 May 2018 16:24:05 +0800 +Subject: [PATCH] Don't use ClassLoader.getDefinedPackages() on Java 9 (#5477) + +Prior to this change, FilteringClassLoader invokes +ClassLoader.getSystemClassLoader().getParent().getDefinedPackages() +to get all system packages on Java 9, which is not correct. +ClassLoader.getDefinedPackages() only fetches packages defined by +the ClassLoader itself, not including its parent's. The consequence is, +on Java 9, most Java SE and JDK packages (e.g. java.lang) are not included in +FilteringClassLoader.SYSTEM_PACKAGES. + +This PR fixes this problem by using ClassLoader.getPackages() all the time. +--- + .../classloader/ClassLoaderUtils.java | 4 ++-- + .../classloader/FilteringClassLoader.java | 22 +-- + .../FilteringClassLoaderTest.groovy | 6 + + .../fixtures/executer/LogContent.java | 2 +- + ...ConsoleJvmTestLoggingFunctionalTest.groovy | 3 ++- + 5 files changed, 17 insertions(+), 20 deletions(-) + +diff --git a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java b/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java +index 3995ad38be55..cdd68af5f905 100644 +--- a/subprojects/base-services/src/main/java/org/gradle/internal/classloader/ClassLoaderUtils.java b/subprojects/base-services/src/main/java/org/gradle/internal/
Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)
Please consider the attached patch which applies the upstream patch [1]. References: [1] https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782 On Sat, Sep 29, 2018 at 8:33 PM Tiago Stürmer Daitx wrote: > > Package: gradle > Version: 4.4-2 > Severity: normal > > Dear Maintainer, > > gradle 4.4-2 currently FTBFS when build with openjdk-11. > > * Exception is: > java.lang.IllegalArgumentException: Could not determine java version from > '11'. > at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:72) > at org.gradle.api.JavaVersion.current(JavaVersion.java:82) > at > org.gradle.internal.jvm.UnsupportedJavaRuntimeException.assertUsingVersion(UnsupportedJavaRuntimeException.java:42) > at > org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:32) > at > org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) > at > org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) > at > org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) > at > org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:257) > at > org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:191) > at org.gradle.launcher.Main.doAction(Main.java:33) > at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:566) > at > org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60) > at > org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37) > at org.gradle.launcher.GradleMain.main(GradleMain.java:23) > > it needs either to be updated to 4.7 or have the upstream patch [1] > applied. > > References: > [1] > https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782#diff-1992c69962eb418e832c020dd61b2f1b.diff > > > -- System Information: > Debian Release: buster/sid > APT prefers cosmic > APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE diff -Nru gradle-4.4/debian/changelog gradle-4.4/debian/changelog --- gradle-4.4/debian/changelog 2018-09-17 10:15:05.0 +0100 +++ gradle-4.4/debian/changelog 2018-09-29 18:50:56.0 +0100 @@ -1,3 +1,10 @@ +gradle (4.4-3) UNRELEASED; urgency=medium + + * debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch: enable +support for openjdk-11. (Closes: #909905) + + -- Tiago Stürmer Daitx Sat, 29 Sep 2018 17:50:56 + + gradle (4.4-2) unstable; urgency=medium * Team upload. diff -Nru gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch --- gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch 1970-01-01 01:00:00.0 +0100 +++ gradle-4.4/debian/patches/enable-jdk-11-support-ac15612d41b43c39c.patch 2018-09-29 18:50:56.0 +0100 @@ -0,0 +1,560 @@ +Description: make JavaVersion support JDK 11 and JEP-223 + Add JavaVersion.VERSION_11 and support JEP223 +Origin: upstream, https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782 +Bug-Debian: http://bugs.debian.org/909905 +Forwarded: not-needed +Applied-Upstream: ac15612d41b43c39c8e39d12fdd6621589b0f782 +Last-Update: 2018-09-29 +--- +This patch header follows DEP-3: http://dep.debian.net/deps/dep3/ + +From ac15612d41b43c39c8e39d12fdd6621589b0f782 Mon Sep 17 00:00:00 2001 +From: Bo Zhang +Date: Wed, 21 Mar 2018 16:08:44 +0800 +Subject: [PATCH] Make JavaVersion support JDK 11 and JEP-223 (#4759) + +Add JavaVersion.VERSION_11 and support JEP223 +--- + .../main/java/org/gradle/api/JavaVersion.java | 123 ++ + .../org/gradle/api/JavaVersionSpec.groovy | 212 --
Bug#909905: gradle FTBFS when building with openjdk-11 (needs update to 4.7.0 or upstream patch)
Package: gradle Version: 4.4-2 Severity: normal Dear Maintainer, gradle 4.4-2 currently FTBFS when build with openjdk-11. * Exception is: java.lang.IllegalArgumentException: Could not determine java version from '11'. at org.gradle.api.JavaVersion.toVersion(JavaVersion.java:72) at org.gradle.api.JavaVersion.current(JavaVersion.java:82) at org.gradle.internal.jvm.UnsupportedJavaRuntimeException.assertUsingVersion(UnsupportedJavaRuntimeException.java:42) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:32) at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33) at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:257) at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:191) at org.gradle.launcher.Main.doAction(Main.java:33) at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:566) at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:60) at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:37) at org.gradle.launcher.GradleMain.main(GradleMain.java:23) it needs either to be updated to 4.7 or have the upstream patch [1] applied. References: [1] https://github.com/gradle/gradle/commit/ac15612d41b43c39c8e39d12fdd6621589b0f782#diff-1992c69962eb418e832c020dd61b2f1b.diff -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.18.0-7-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled
Bug#896990: (no subject)
Please note that flickrbackup is marked for removal already (#904925). Bests, -- tiago
Bug#909012: RM: lcrack -- ROM; Deprecated, no upstream activity since 2004, better options available
Package: ftp.debian.org Severity: normal Some better alternatives to it: hashcat and john.
Bug#807648: (no subject)
Hi, sorry for the long delay. I'm doing a (late) cleanup in my packages and will update Zyne to the new upstream version, which now runs with python3 and python-wxgtk4.0. I'll have to package a new dependency as well: https://github.com/belangeo/pyo-tools. It will take some time, anyway just for the record that I didn't give up about this nice synth in Debian. Bests,
Bug#907435: ITP: antimony -- Computer-aided design CAD tool
Package: wnpp Severity: wishlist Owner: Tiago Bortoletto Vaz * Package name: antimony Version : 0.9.3 Upstream Author : Matthew Keeter and other contributors * URL : http://www.mattkeeter.com/projects/antimony/3/ * License : MIT Programming Lang: C++ Description : Computer-aided design CAD tool Antimony is a computer-aided design (CAD) tool from a parallel universe in which CAD software evolved from Lisp machines rather than drafting tables. Antimony is built on three mostly-orthogonal axes: - A framework for tracking information flow through directed acyclic graphs - A geometry engine for doing CSG - A standard library of shapes and transforms
Bug#906411:
The underlying cause seems to be a fix in maven-shared-utils 3.2, which was uploaded recently. The fix MSHARED-610 [1] seems to have exposed IOException that were previously being ignored, so surefire now needs to be updated to handle those. I have opened a bug report upstream (SUREFIRE-1558 [2]) to let them know about it. References: [1] https://issues.apache.org/jira/browse/MSHARED-610 [2] https://issues.apache.org/jira/browse/SUREFIRE-1558 -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#845217: Merge requested
https://salsa.debian.org/ftp-team/dak/merge_requests/97 -- tiago
Bug#905675: testng missing dependency on guava causes tests to fails
Dear maintainer, Please consider the following patch which applies the PR 1096 [1] change. thanks On Tue, Aug 7, 2018 at 8:09 PM Tiago Stürmer Daitx wrote: > > Package: testng > Version: 6.9.12-3 > Severity: normal > > Dear Maintainer, > > While running OpenJDK 10 tests I noticed that quite a few tests that > depend on testng fail due to a missing guava class. > > The package libguava-java has the class but it is not declared as a > dependency. > > The bug has been reported upstream back in 2016 [1] and fixed a few days > after that [2]. The guava class import was replaced with a new internal > class [3]. > > testng should be updated to a newer version or that particular patch [3] > should be applied to the existing package. > > References: > [1] https://github.com/cbeust/testng/issues/1085 > [2] https://github.com/cbeust/testng/pull/1086 > [3] > https://github.com/cbeust/testng/pull/1086/commits/deeb5847282ae3b5b185c046a8146814bf98b124 > > > Error output example: > > java.lang.NoClassDefFoundError: com/google/common/primitives/Ints > at > org.testng.internal.annotations.JDK15TagFactory.createDataProviderTag(JDK15TagFactory.java:335) > at > org.testng.internal.annotations.JDK15TagFactory.createTag(JDK15TagFactory.java:59) > at > org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:217) > at > org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:111) > at > org.testng.internal.Parameters.findDataProvider(Parameters.java:326) > at > org.testng.internal.Parameters.findDataProvider(Parameters.java:261) > at > org.testng.internal.Parameters.handleParameters(Parameters.java:418) > at org.testng.internal.Invoker.handleParameters(Invoker.java:1240) > at org.testng.internal.Invoker.createParameters(Invoker.java:980) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1070) > at > org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. > > Regards, > Tiago Daitx > > -- System Information: > Debian Release: buster/sid > APT prefers cosmic > APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') > Architecture: amd64 (x86_64) > > Kernel: Linux 4.15.0-23-generic (SMP w/4 CPU cores) > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), > LANGUAGE=en_US (charmap=UTF-8) > Shell: /bin/sh linked to /bin/dash > Init: systemd (via /run/systemd/system) > LSM: AppArmor: enabled > > Versions of packages testng depends on: > ii libbsh-java 2.0b4-19 > pn libjcommander-java > > Versions of packages testng recommends: > ii ant 1.10.4-2 > ii junit4 4.12-7 > pn libyaml-snake-java > > testng suggests no packages. -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE diff -Nru testng-6.9.12/debian/changelog testng-6.9.12/debian/changelog --- testng-6.9.12/debian/changelog 2018-07-30 12:53:55.0 -0300 +++ testng-6.9.12/debian/changelog 2018-08-07 20:16:34.0 -0300 @@ -1,3 +1,10 @@ +testng (6.9.12-4) UNRELEASED; urgency=medium + + * d/p/remove-guava-dependency-pr1086.patch: apply upstream patch to +remove guava dependency (Closes: #905675, LP: #1785896) + + -- Tiago Stürmer Daitx Tue, 07 Aug 2018 23:16:34 + + testng (6.9.12-3) unstable; urgency=medium * Team upload. diff -Nru testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch --- testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch 1969-12-31 21:00:00.0 -0300 +++ testng-6.9.12/debian/patches/remove-guava-dependency-pr1086.patch 2018-08-07 20:16:34.0 -0300 @@ -0,0 +1,56 @@ +From deeb5847282ae3b5b185c046a8146814bf98b124 Mon Sep 17 00:00:00 2001 +From: Julien Herr +Date: Thu, 7 Jul 2016 23:04:24 +0200 +Subject: [PATCH] Fix #1085 Remove Guava dependency + +--- + .../internal/annotations/JDK15TagFactory.java | 2 +- + .../org/testng/internal/collections/Ints.java | 19 +++ + 2 files changed, 20 insertions(+), 1 deletion(-) + create mode 100644 src/main/java/org/testng/internal/collections/Ints.java + +diff --git a/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java b/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java +index 7e79166d1..7ed9cc19e 100755 +--- a/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java b/src/main/java/org/testng/internal/annotations/JDK15TagFactory.java +@@ -6,7 +6,6 @@ + import java.util.List; + import java.util.Set; + +-impo
Bug#905675: testng missing dependency on guava causes tests to fails
Package: testng Version: 6.9.12-3 Severity: normal Dear Maintainer, While running OpenJDK 10 tests I noticed that quite a few tests that depend on testng fail due to a missing guava class. The package libguava-java has the class but it is not declared as a dependency. The bug has been reported upstream back in 2016 [1] and fixed a few days after that [2]. The guava class import was replaced with a new internal class [3]. testng should be updated to a newer version or that particular patch [3] should be applied to the existing package. References: [1] https://github.com/cbeust/testng/issues/1085 [2] https://github.com/cbeust/testng/pull/1086 [3] https://github.com/cbeust/testng/pull/1086/commits/deeb5847282ae3b5b185c046a8146814bf98b124 Error output example: java.lang.NoClassDefFoundError: com/google/common/primitives/Ints at org.testng.internal.annotations.JDK15TagFactory.createDataProviderTag(JDK15TagFactory.java:335) at org.testng.internal.annotations.JDK15TagFactory.createTag(JDK15TagFactory.java:59) at org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:217) at org.testng.internal.annotations.JDK15AnnotationFinder.findAnnotation(JDK15AnnotationFinder.java:111) at org.testng.internal.Parameters.findDataProvider(Parameters.java:326) at org.testng.internal.Parameters.findDataProvider(Parameters.java:261) at org.testng.internal.Parameters.handleParameters(Parameters.java:418) at org.testng.internal.Invoker.handleParameters(Invoker.java:1240) at org.testng.internal.Invoker.createParameters(Invoker.java:980) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1070) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker. Regards, Tiago Daitx -- System Information: Debian Release: buster/sid APT prefers cosmic APT policy: (500, 'cosmic'), (400, 'cosmic-proposed') Architecture: amd64 (x86_64) Kernel: Linux 4.15.0-23-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages testng depends on: ii libbsh-java 2.0b4-19 pn libjcommander-java Versions of packages testng recommends: ii ant 1.10.4-2 ii junit4 4.12-7 pn libyaml-snake-java testng suggests no packages.
Bug#904925: RM: flickrbackup -- ROM; ancient; abandoned upstream; deprecated;
Package: ftp.debian.org Severity: normal I took this code a few years ago and became the packager & upstream. It uses an old API and I'm not willing to update it anymore, since there are other newer tools (already packaged in Debian) for the same purpose.
Bug#900912: Incident Report 9127367 : Java atk wrapper does not load any more
On Thu, Jul 19, 2018 at 6:22 PM Samuel Thibault wrote:
>
> Samuel Thibault, le jeu. 19 juil. 2018 23:13:26 +0200, a ecrit:
> > Samuel Thibault, le jeu. 19 juil. 2018 23:00:04 +0200, a ecrit:
> > > What I think is still missing is "to be loaded by
> > > java.util.ServiceLoader". How is that supposed to happen?
> > >
> > > To make it work, Fridrich Strba says in
> > > http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html
> > > that he is apparently relinking jdk itself to include
> > > java-atk-wrapper.jar as a module. Are we really supposed to be doing
> > > that in Debian? That's mean a circular dependency between openjdk
> > > and java-atk-wrapper... But otherwise, how are we supposed to make
> > > the jvm know that for that accessibility provider it should load
> > > java-atk-wrapper.jar?
> >
> > Or put another way: how are we supposed to make the
> > module contained in java-atk-wrapper.jar ("provides
> > javax.accessibility.AccessibilityProvider with
> > org.GNOME.Accessibility.AtkProvider;") visible to the JVM? Is there a
> > directory where it looks for them?
>
> Of course there is the -p option and alike, but the goal is that it just
> works without the user having to specify anything. Or should Debian
> define a module path were the java-atk-wrapper package should put its
> module? I'd be surprised that openjdk doesn't already define one, just
> like it used to define the ext/ directory for the older mechanism.
>
> Samuel
Hi Samuel,
Thanks for the quick work on this! I have seen the changes in the git
repo [1] and will build the package to see if I can get it to work
with openjdk like it used to with older ext mechanism - for now all
module examples I have seem need to be directly loaded with -p as you
stated.
It is just a guess at this time, but we might need to patch openjdk to
load mods from other locations so debian packages can use that. I
report back after doing some testing.
I'm still working on the openjdk security updates, so might take a
while to get my hands down on this.
Regards,
Tiago
[1] https://salsa.debian.org/a11y-team/java-atk-wrapper/commits/master
--
Tiago Stürmer Daitx
Software Engineer
tiago.da...@canonical.com
PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com)
Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#900912: [Openjdk] Bug#900912: openjdk-10: Accessibility does not get loaded
The ATK was updated to use the new interface last year by Fridrich Strba [1,2], but it seems that upstream never updated it to include those patches - the bugs he reported and attached patches remain open. Might be worth to check if we can apply these to our packages. [1] http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2017-November/038927.html [2] http://mail.openjdk.java.net/pipermail/awt-dev/2017-November/013344.html On Mon, Jul 16, 2018 at 10:15 AM Matthias Klose wrote: > > On 13.07.2018 12:39, Samuel Thibault wrote: > > Hello, > > > > Matthias Klose, le ven. 13 juil. 2018 12:04:42 +0200, a ecrit: > >> this issue now has two patches, one to install the properties file, and the > >> other to extend the class path. Are both needed? > > > > Yes. > > > >> Can you see any compatibility issues when the accessibility stuff > >> isn't used? > > > > I didn't see any. > > hmm, I'm not sure. the upstream issue asks instead about > > """ > This is a consequence of the JPMS. ATK will need to be reimplemented as a > Service Provider, to be > loaded by java.util.ServiceLoader. In order to do this it must provide an SPI > which extends > javax.accessibility.AccessibilityProvider > See > https://docs.oracle.com/javase/10/docs/api/java/awt/Toolkit.html#getDefaultToolkit() > and > https://docs.oracle.com/javase/10/docs/api/javax/accessibility/AccessibilityProvider.html > """ > > ___ > Mailing list: https://launchpad.net/~openjdk > Post to : open...@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openjdk > More help : https://help.launchpad.net/ListHelp -- Tiago Stürmer Daitx Software Engineer tiago.da...@canonical.com PGP Key: 4096R/F5B213BE (hkp://keyserver.ubuntu.com) Fingerprint = 45D0 FE5A 8109 1E91 866E 8CA4 1931 8D5E F5B2 13BE
Bug#896768: playitslowly: diff for NMU version 1.5.0-1.1
Hi Adrian, Thanks for the NMU, feel free to reschedule it for a immediate upload. Bests, On Sun, Jun 03, 2018 at 10:04:59PM +0300, Adrian Bunk wrote: > Control: tags 896768 + patch > Control: tags 896768 + pending > > Dear maintainer, > > I've prepared an NMU for playitslowly (versioned as 1.5.0-1.1) and > uploaded it to DELAYED/14. Please feel free to tell me if I should > cancel it. > > cu > Adrian > > -- > >"Is there not promise of rain?" Ling Tan asked suddenly out > of the darkness. There had been need of rain for many days. >"Only a promise," Lao Er said. > Pearl S. Buck - Dragon Seed > -- tiago
Bug#898678: ca-certificates-java: convert PKCS12 cacerts keystore to JKS
Package: ca-certificates-java
Version: 20180413
Severity: important
Dear Maintainer,
The fix for bug #894979 which updated ca-certificates-java to generate
JKS keystores by default - instead OpenJDK's 9+ default of PKCS12 - only
fixes new installs.
Any user already affected by that issue won't benefit from the fix, as
the file /etc/ssl/certs/java/cacerts is at most updated by the
jks-keystore hook. The only way to actually change it from the PKCS12
to the JKS format is to remove the cacerts file and then calling
'update-ca-certificates -f' - which is also accomplished by removing and
then reinstalling the ca-certificates-java package.
The attached patch fixes this behavior by:
1) Detecting if a PKCS12 cacert exists
2) Converting it to JKS and saving it to cacerts.dpkg-new
Finally, if, and only if, 'cacerts_updates' is set to 'yes':
3) Moving the old PKCS12 cacerts to a cacerts.dpkg-old and the dpkg-new
into /etc/ssl/certs/java/cacerts.
Additionally, a few other fixes are also addressed in the debdiff:
1) Only set JAVA_HOME if a jvm is found. Previously if none of the the
jvms in the list were found the last one jvm was used - although that
didn't cause any unexpected errors, it was wrong.
2) Avoid generating a jvm.cfg as openjdk has it's own logic for
providing a well defined default jvm.cfg in such scenarios.
3) On Ubuntu it should depend on openjdk-11-jre-headless instead
of openjdk-8.
Please review and consider applying the provided debdiff.
Regards,
Tiago Daitx
-- System Information:
Debian Release: buster/sid
APT prefers cosmic
APT policy: (500, 'cosmic'), (400, 'cosmic-proposed')
Architecture: amd64 (x86_64)
Kernel: Linux 4.15.0-20-lowlatency (SMP w/8 CPU cores; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
diff -Nru ca-certificates-java-20180413/debian/changelog
ca-certificates-java-20180413.1/debian/changelog
--- ca-certificates-java-20180413/debian/changelog 2018-04-13
09:15:39.0 -0300
+++ ca-certificates-java-20180413.1/debian/changelog2018-05-14
23:16:43.0 -0300
@@ -1,3 +1,18 @@
+ca-certificates-java (20180413.1) unstable; urgency=medium
+
+ [ Tiago Stürmer Daitx ]
+ * debian/jks-keystore.hook.in: Don't create a jvm-*.cfg file, a default file
+with the right configuration is already supplied by the openjdk packages.
+ * debian/jks-keystore.hook.in, debian/postinst.in: Only export JAVA_HOME
+and update PATH if a known jvm was found.
+ * debian/postinst.in: Detect PKCS12 cacert keystore generated by
+previous ca-certificates-java and convert them to JKS.
+
+ [ Matthias Klose ]
+ * Explicitly depend on openjdk-11-jre-headless, needed to configure.
+
+ -- Tiago Stürmer Daitx <tiago.da...@ubuntu.com> Tue, 15 May 2018 02:16:43
+
+
ca-certificates-java (20180413) unstable; urgency=medium
* Team upload.
diff -Nru ca-certificates-java-20180413/debian/jks-keystore.hook.in
ca-certificates-java-20180413.1/debian/jks-keystore.hook.in
--- ca-certificates-java-20180413/debian/jks-keystore.hook.in 2018-04-13
09:02:14.0 -0300
+++ ca-certificates-java-20180413.1/debian/jks-keystore.hook.in 2018-05-14
23:16:43.0 -0300
@@ -45,20 +45,12 @@
oracle-java10-jre-$arch oracle-java10-server-jre-$arch
oracle-java10-jdk-$arch \
java-11-openjdk-$arch java-11-openjdk \
oracle-java11-jre-$arch oracle-java11-server-jre-$arch
oracle-java11-jdk-$arch; do
-if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+export JAVA_HOME=/usr/lib/jvm/$jvm
+PATH=$JAVA_HOME/bin:$PATH
break
-fi
+fi
done
-export JAVA_HOME=/usr/lib/jvm/$jvm
-PATH=$JAVA_HOME/bin:$PATH
-
-temp_jvm_cfg=
-if [ ! -f /etc/${jvm%-$arch}/jvm-$arch.cfg ]; then
-# the jre is not yet configured, but jvm.cfg is needed to run it
-temp_jvm_cfg=/etc/${jvm%-$arch}/jvm-$arch.cfg
-mkdir -p /etc/${jvm%-$arch}
-printf -- "-server KNOWN\n" > $temp_jvm_cfg
-fi
if dpkg-query --version >/dev/null; then
nsspkg=$(dpkg-query -L "$(nsslib_name)" | sed -n
's,\(.*\)/libnss3\.so$,\1,p'|head -n 1)
diff -Nru ca-certificates-java-20180413/debian/postinst.in
ca-certificates-java-20180413.1/debian/postinst.in
--- ca-certificates-java-20180413/debian/postinst.in2018-04-13
09:03:15.0 -0300
+++ ca-certificates-java-20180413.1/debian/postinst.in 2018-05-14
23:16:43.0 -0300
@@ -35,12 +35,50 @@
oracle-java10-jre-$arch oracle-java10-server-jre-$arch
oracle-java10-jdk-$arch \
java-11-openjdk-$arch java-11-openjdk \
oracle-java11-jre-$arch oracle-java11-server-jre-$arch
oracle-java11-jdk-$arch; do
-if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
-break
+if [ -x /usr/lib/jvm/$jvm/bin/java ]; then
+ex
