[13:54] <sil2100> tdaitx, doko: ok, I see Steve (or someone) copied all of stage5 and antmaven already, right?
[13:55] <sil2100> Did sbeattie sign off on anything else since then?
[13:55] <doko> sil2100: yes. but the hints still need updating. could you do that?
[13:55] <tdaitx> sil2100: yeah, I asked steve to copy it if he had the time
[13:55] <doko> no, I'm building a few more packages, but these need review
[13:57] <tdaitx> doko: which ppa are/will you be using for those?
[14:01] <sil2100> doko: for which apps? All from antmaven?
[14:06] <doko> tdaitx: stage5
[14:07] <doko> tdaitx: can you look at the jabref crash?
[14:11] <doko> sil2100: look at http://people.canonical.com/~ubuntu-archive/proposed-migration/bionic/update_excuses.html for all these "Not touching" messages
[14:16] <doko> crap, virtualbox-hwe requires the hwe stack in -updates. sbeattie, how do you want to handle this?
[14:17] <tdaitx> doko: will do, just found the error report
[14:25] <sil2100> doko: ACK
[14:45] <sil2100> doko: think I pushed the right ones
[15:46] <sbeattie> doko: ugh, the xorg hwe stack? I guess we need no-change rebuilds for those, too.
[15:46] <sbeattie> not sure how many source packages that is.
[15:47] <doko> sbeattie: or having virtualbox-hwe in -updates? LocutusOfBord claims that this is only usable with the hwe
[15:48] <sbeattie> eh, I would be okay with that, I guess.
[15:49] <doko> ok
[15:52] <doko> sbeattie: stage5 has three more packages: virtualbox libpdfbox-java mongo-java-driver
[15:56] <sbeattie> okay
[17:11] <sbeattie> sil2100: +1 on virtualbox libpdfbox-java mongo-java-driver being binary copied to bionic-proposed from the stage5 ppa.
[17:20] <doko> sbeattie: one more in stage5: openhft-chronicle-threads
[17:20] <doko> and new ppa android-tools
[17:20]  * doko hides
[17:22]  * sbeattie sighs
[17:23] <sil2100> sbeattie: ok, thanks, will copy shortly (need to finish this DMB meeting)
[17:23] <huehner> doko: left you some comment here yesterday evening on my first tomcat testing
[17:25] <sbeattie> doko: openhft-chronicle-threads is depwait on debhelper 12.
[17:29] <doko> ouch
[17:36] <doko> sbeattie: openhft-chronicle-threads now built
[17:36] <sbeattie> thanks
[17:58] <doko> huehner: thanks. not sure what to do about the init files. if you leave them as init scripts for 8, then they are different for 9 ...
[18:11] <sbeattie> sil2100: +1 on openhft-chronicle-threads going to bionic-proposed from stage5
[18:37] <sil2100> Will copy those in a second, thanks o/
[18:49] <huehner> doko: for the init script, if you undo that change gets messy from maintenance as diverging
[18:50] <huehner> doko: when keeping best is probably to try to make it very visible for people on updating + help them to cope with it (i.e. example systemd service override file do undo access restrictions)
[18:51] <huehner> doko: for making visible not sure if you have something stronger than NEWS file entry available here?
[18:57] <doko> huehner: where is your draft for these notes? ;p
[18:57] <huehner> doko: in #debian-java chat with ebourgh some month ago ;) i raised those there for next debian stable
[18:58] <huehner> doko: that aside i can try to list up the possible problem i did/can think of as a start
[18:59] <doko> that would be nice
[19:00] <huehner> doko: that other topic (missing entropy causing 30s delay)
[19:00] <huehner> maybe there longer but i don;t remember ever noticing it
[19:00] <huehner> So not sure if its 'regressio' (as perceived by user) or not... maybe tomcat/java now trying harder to get entropy
[19:01] <sil2100> doko, sbeattie: ok, packages approved
[19:08] <doko> sbeattie: I probably will update a few more packages which had updates in disco, but that shouldn't be many
[19:11] <sbeattie> doko: okay, just ping me with a list. thanks.
[19:18] <doko> sbeattie: so looks like we want the android packages in -proposed as well. would be nice to have them reviewed tomorrow when the email is ready
[19:24] <tdaitx> doko: ok, found the issue with jabref, it is related to libjgoodies-looks-java (debian #898906), fortunately it is a runtime thing and just updating bionic to the cosmic version should fix it
[19:24] <doko> ta, just add it to stage5
[19:25] <tdaitx> sure, I will just wait for it to be published on the test ppa to test to be sure it fixes it
[19:47] <tdaitx> yeah, it is fixed with the update
[19:50] <tdaitx> doko: sbeattie: copied libjgoodies-looks-java to stage5, it fixes a runtime issue with java's Look&Feel in jabref (scilab and zeroc-ice also seemed to be affected)
[19:53] <sbeattie> okay, waiting for it to finish building.
[20:39] <sbeattie> tdaitx: and that change didn't require additional changes from jabref to no longer refer to  com.jgoodies.looks.windows.WindowsLookAndFeel ?
[20:40] <sbeattie> (dcs shows a few things referencing that class, but it's not clear to me whether there's runtime detection of whether that class exists or not)
[20:42] <tdaitx> sbeattie: no, the (previous) libjgoodies in bionic would actually cause java to throw a NoClassDefFoundError because it did _try_ to load the WindowsLookAndFeel regardless
[20:42] <tdaitx> with the fix it just throws a ClassNotFoundException that is catched by jabref
[20:43] <tdaitx> so there's no need to recompile reverse bdeps of libjgoodies-looks-java
[20:49] <sbeattie> tdaitx: okay, thanks.
[20:50] <sbeattie> sil2100: when you come back online, +1 on libjgoodies-looks-java being binary-copied from stage5 to bionic-proposed.
[21:23] <tdaitx> doko: as for sweethome3d, how did you run it? chroot, qemu, something else?
[21:23] <tdaitx> I tested it on a bionic chroot and when /dev/dri was not binded to the chroot I got a lot of weird errors: not only menus, the whole app would show black regions where it should be showing some content
[21:23] <tdaitx> after I binded /dev/dri to the chroot then I got the right app, menus were working just fine
[21:23] <tdaitx> I did find a weird bug (unrelated) about setting the Look&Feel: setting it on swing.properties does not work at all, I had to set it using the -D setting (either on command line or through _JAVA_OPTIONS)
[21:23] <tdaitx> also, from java UIManager code the swing.properties should be located in conf/ not lib/ as we have right now, still, copying the file into conf/swing.properties still does not work
[21:24] <tdaitx> anyway, I was unable to properly reproduce the menu bug on the chroot when /dev/dri is properly bind mounted
[23:45] <sbeattie> hrm android-platform-libnativehelper 8.1.0+r23-1~18.04 drops a bunch of JniConstants:: statics (like bigDecimalClass, constructorClass, deflaterClass) that it looks like android-framework-23 still references, is that okay?