#ubuntu-java 2006-04-12
<darksatanic> Can anyone shed some light on this problem for me, please? http://pastebin.com/646079
<darksatanic> Why is ant looking for a Java 1.4.2 GCJ, instead of using the default javac that I want it to?
<m_akys> hello
<m_akys> i installed java 1.5 in ubuntu, but i don't know where i must set the variable JAVA_HOME
<darksatanic> As far as I'm aware, you don't need to.
<m_akys> I want set JAVA_HOME for all users
<m_akys> I need it for Tomcat
<darksatanic> However, I asked a question relating to this very issue in here nearly 5 hours ago, and nobody's been able to give me an answer, 
<darksatanic> so I assume that there isn't anyone listening. :)
<m_akys> I could modify the startup.sh but is not elegant
<m_akys> oh :(
<m_akys> thank you anyway
#ubuntu-java 2006-04-15
<pip_> Hello?
<pip_> why there are so few people here ?
#ubuntu-java 2007-04-10
<vil> man-di_, ping
<man-di_> vil: pong
<man-di_> good morning
<vil> morning
<vil> I wanted to ask, if you found anything regarding the sparc build of eclipse.
<man-di_> I sent a patch to doko on thursday
<vil> You also mentioned that you could provide me access to some sparc machine, where I could play around... :)
<man-di_> the problem was that the eclipse execytable was not rebuilt and used from the upstream source tarball (which should not contain it)
<vil> ok, sounds good that doko will take care of this
<man-di_> vil: I havent setup the machine yet here
<vil> looks like I forgot to remove this binary. I removed all .so .dll .jar but forgot about this one
<vil> interesting that it did not cause any problems on the other builds...
<vil> any idea?
<man-di> and we copied the wrong one to /usr/lib/eclipse/eclipse
<man-di> yes, the problem was that we created the sparc (and other) arch packages on our own
<man-di> on archs where upstream provides an executable we used that
<vil> ok, do we want to change the sources, too, not to contain the prebuilt binary? I would say yes
<man-di> I'm undecided
<man-di> I delete the executables for now in the debian/rules file
<vil> ok, I'll wait to see the patch, sounds reasonable
<man-di> its not nice to have it in but its not so big (filesize) and should have no legal issues
<man-di> we should just take care to make it right the next time
<vil> lessons learnt :)
<man-di> hehe
<man-di> the old 3.2.1 tarball from me has the same problem
<vil> this should be covert by lintian
<vil> either I did not pay attention or it was not caught
<man-di> ;-)it cant be covert by lintian as the eclipse executable is hidden in a tar file
<doko> man-di: hmm, though I did send you two emails on Thursday/Friday ...
<man-di> doko: two? one about sinjdoc. and the other?
<man-di> sinjdoc is on people.d.o/~mkoch/java/
* Starting logfile irclogs/ubuntu-java.log
* Starting logfile irclogs/ubuntu-java.log
#ubuntu-java 2007-04-11
<johnn8> anyone in here?
<doko> man-di: https://launchpad.net/+builds/+build/317303
<man-di> doko: does this mean it worked?
<doko> man-di: sorry, cannot check
<man-di> I mean, it built?
<man-di> at least one improvement
<doko> man-di: yes, a sucessful build log
<man-di> cool
<man-di> this means we should be able to build on s390 now too :-)
<doko> man-di: http://people.ubuntu.com/~fabbione/1176276463665.log
<doko> will have to check sometime ...
<man-di> sparc64
<man-di> that explains
<man-di> I will try to solve this later
<man-di> should not be too difficult
<man-di> the problem is eclipse's preprocessing of SWT and platform sources
<doko> ok, should be the same then for s390 (where the kernel reports s390x)
<man-di> for s390 we explicitely build 32-bit afaik
<man-di> doko: which is the first Ubuntu release with glibc 2.4? feisty? edgy?
<doko> edgy
<man-di> doko: thx
<vil> man-di, troubles with wtk? :)
<man-di> vil: with stupid proprietary software creators
<Detox_on_Server> hello
<Detox_on_Server> anyone home?
#ubuntu-java 2007-04-13
<minus198> Hi, anyon here?
<minus198> anyone*
#ubuntu-java 2007-04-14
<doko> vil: good morning
<vil> hey doko
<doko> vil: your eclipse fixes should be in feisty; sparc builds but fails to run. didn't have time to investigate
<vil> doko, I saw you put it in
<vil> doko, any idea, where could I test the sparc problems?
<vil> actually, I can try on one of imbrandon machines. if I don't succed, I will come back to you
<doko> vil: man-di has an idea, apparently it doesn't get the distinction between 64bit kernel and 32bit userland
<vil> doko great
<vil> doko, pls, let me know if you find something
<vil> if not, I will try to look at it later today
<doko> vil: won't have time today, it's sunny outside :-)
<vil> doko, I fully understand, have a great time
<vil> man-di, ping
<man-di> pong
<vil> man-di, doko told me that you might know, how to heal eclipse on sparc
<vil> any progress?
<man-di> no, not yet
<man-di> i think the problem might be an 32 bit vs 64 bit issues
<man-di> but I have no 64 bit sparc I can access
<man-di> so I can only guess and look if I can see something in our build system
<man-di> vil: do you have a really error message on sparc64?
<vil> man-di, I don't know any about this arch, so I can barely help
<man-di> vil: do you have access to a sparc64?
<vil> i own just i386 and that's it
<man-di> vil: you said something about imbrandon machines earlier
<vil> man-di, cpu             : TI UltraSparc IIi (Sabre)
<vil> man-di, is that suitable?
<man-di> depends on the kernel, afaik
<man-di> I dont really know sparc that good
<vil> man-di, Linux sparky 2.6.17-11-sparc64 #2 Thu Feb 1 19:25:47 UTC 2007 sparc64 GNU/Linux
<man-di> yes, thats sparc64
<vil> man-di, ok, let me find out, if we can eclipse there
<man-di> thanks
<man-di> that would help a lot
<man-di> if you have an error message, please tell it to me
<vil> man-di, do you have a LP login?
<man-di> yes
<vil> man-di, imbrandon from ubuntu motu is hosting that sparc64 box, but I guess only for ubuntu motus
<vil> you can try ask him, if you would like to get access there
<vil> I am going to try eclipse there now
<man-di> one person trying it is enough
<man-di> I think
#ubuntu-java 2007-04-15
<man-di> vi1: good morning
<vi1> man-di, morning
<vi1> I am sorry, I wass
<vi1> was ko yesterday
* man-di too
<man-di> thats no problem at all
* vi1 still trying to run eclipse on that machine
<vi1> there is some pbuilder chroot that I can use for it
<vi1> man-di, the problem I was stuck yesterday is
<vi1> X11 connection rejected because of wrong authentication.
<vi1> when I try to run eclipse under the pbuilder chroot (root user)
<vi1> DIPLAY variable is set correctly (locahost:12) , but I guess the problem is different user than that who created the ssh connection.
<vi1> any hint?
<man-di> xauth
<man-di> the problem is that the MIT cookie does not match
<man-di> gone
* vi1 trying xauth
<man-di> the problem is that the MIT cookie does not match
<man-di> damn jsf
* man-di curses the inventors of jsf
<vi1> man-di, so here we go http://paste.ubuntu-nl.org/15750/
<man-di> huh
<man-di> Caused by: java.lang.ClassNotFoundException: org.eclipse.swt.SWTError
<man-di> can you check this swt is successfully installed?
<man-di> and includes the classes it should
<man-di> I guess there is no org.eclipse.swt.gtk.linux.sparc_3.2.2.R3_2_maintenance.jar but a org.eclipse.swt.gtk.linux.sparc64_3.2.2.R3_2_maintenance.jar
<man-di> ?
<man-di> thats the problem then if thats the case
<vi1> org.eclipse.swt.gtk.linux.sparc_3.2.2.R3_2_maintenance.jar is there
<man-di> hmmm
<vi1> swt looks ok so far
<man-di> !MESSAGE The following is a complete list of bundles which are not resolved, see the prior log entry for the root cause if it exists:
<man-di> !SUBENTRY 1 org.eclipse.osgi 2 0 2007-04-15 07:26:12.147
<man-di> !MESSAGE Bundle update@plugins/org.eclipse.swt.gtk.linux.sparc_3.2.2.R3_2_maintenance.jar [6]  was not resolved.
<man-di> !SUBENTRY 2 org.eclipse.swt.gtk.linux.sparc 2 0 2007-04-15 07:26:12.148
<man-di> !MESSAGE Platform filter did not match: (& (osgi.ws=gtk) (osgi.os=linux) (osgi.arch=sparc))
<man-di> !SUBENTRY 2 org.eclipse.swt.gtk.linux.sparc 2 0 2007-04-15 07:26:12.149
<man-di> !MESSAGE Missing Constraint: Fragment-Host: org.eclipse.swt; bundle-version="[3.0.0,4.0.0)"
<man-di> something is borked in SWT
<vi1> swt has jni bindings, maybe that thing
<man-di> can you paste the manifest of org.eclipse.swt.gtk.linux.sparc_3.2.2.R3_2_maintenance.jar please?
<vi1> sure
<vi1> http://paste.ubuntu-nl.org/15754/
<vi1> can the (osgi.arch=sparc) clause cause the troubles?
<man-di> and uname -m return sparc64?
<man-di> vi1: thats what I think: sparc vs sparc64
<man-di> from the first paste: BootLoader constants: OS=linux, ARCH=sparc64, WS=gtk, NL=en_US
<man-di> different archs
<vi1> Linux sparky 2.6.17-11-sparc64 #2 Thu Feb 1 19:25:47 UTC 2007 sparc64 GNU/Linux
<man-di> so what we need to know now: are all supported sparc sparc64 or do we need to care about sparc(32) too?
<man-di> vi1: is there a linux32 command on the sparc?
<vi1> man-di, just a sec, swt install does not look so good any more
<vi1> the swt.jar link is dead
<vi1> let me fix that and try again
<man-di> eclipse doest use the swt.jar link in /usr/share/java
<man-di> thats a different story
<man-di> thats only for 3rd party apps
<vi1> ok, now I see it
<vi1> there is also a slight difference between linux and sparc in the naming
<vi1> org.eclipse.swt.gtk.linux.sparc_3.2.2.R3_2_maintenance.jar
<vi1> org.eclipse.swt.gtk.linux.x86_3.2.2.v3236.jar
<vi1> i meant x86
<man-di> hmmm
<man-di> that is becuase we use SWT from ia64 for all officially-non-supported archs
* vi1 just installed linux32
<man-di> SWT versions are not all the same for the different archs
<man-di> vi1: when you exec linux32 and then run eclipse I really wonder if it works or if the error message is different
<vi1> man-di, linux32 eclipse makes a difference :)
<vi1> eclipse booting up
<man-di> hehehe
<vi1> you was right from the very beggining ;)
<man-di> thanks for the flowers
<man-di> now lets think how to solve that
<man-di> I dont know enough about sparc to decide what to do
<man-di> I think
<vi1> man-di, on the other hand, it crashed again ;)
<man-di> vi1: what does uname -m output under linux32?
<man-di> oh?
<man-di> error message?
<vi1> jvm crash
<man-di> uuffffff
<man-di> thats no bug in eclipse then ;-)
<vi1> i can send you a scrshot
<man-di> vi1: that would be great
<man-di> dcc doesnt work here
<man-di> I'm behind a firewall
<vi1> ok, mail
<man-di> there was some pasting service for images...
<man-di> if I would remember the url
<vi1> linux32 uname -m
<vi1> sparc
<man-di> okay, thats what I guessed
<man-di> perhaps we should patch eclipse's arch detection code
<man-di> you dont know if the userland of sparc is always 32 bit or sometimes 64 bit?
<man-di> sparc64 only means the kernel is 64bit
<vi1> no idea, i am old-school x86 guy
<man-di> we can ask doko
<man-di> nice screenshot
<vi1> nice screenshot not saying anything
<man-di> well, it says which arch, which runtime, etc.
<man-di> I should do a debian bts eclipse bug triaging
<Mammnon> hello everybody
<Mammnon> may I ask a question?
* man-di wonders why people are so impatient
#ubuntu-java 2008-04-07
<AnAnt> Hello, to run a java program I must do: -classpath <list of dependencies> even if these dependencies  are /usr/share/java ?
<AnAnt_> Hello, I imported from Debian new version of lucene2: http://launchpadlibrarian.net/13163284/lucene2_2.3.1+ds1-1ubuntu1~ppa1.dsc
#ubuntu-java 2008-04-09
<wxf6981> HALLO?
<jamesstansell> sun didn't include their javaplugin in openjdk-6, but they created javaplugin2 for 1.6u10 - does anyone know if they'll be releasing the code to javaplugin2 at some point?
#ubuntu-java 2008-04-10
<b0ef> ehlo
<b0ef> got an ubuntu box that I'm compiling some code that depends on javax.persistence. I'm not sure which package in ubuntu that ships these files; any idea?
#ubuntu-java 2009-04-06
<kia0gh> hi all
<kia0gh> '/ msg nickserv help register
<kia0gh> can someone help me with a java peoblem
<kia0gh> how do u set a double type to be less than a value cant find anything on api
<kia0gh> hi
<kia0gh> can someone help me please
<kia0gh> i cant coonect to ##java
<kia0gh> how do i register for ir
<sdfsdf> does anyone know how to setup an internet connection on ubuntu
#ubuntu-java 2009-04-07
<mpinto> hello, how do i get J2ME on ubunto?
<mpinto> i cant seam to find it in the package menager
<mpinto> nevermind, i found out
#ubuntu-java 2009-04-09
<IntuitiveNipple> doko: ping?
<ttx> team meeting in #ubuntu-meeting... now
#ubuntu-java 2010-04-13
<doko_> bdrung: are you able to reproduce 520515?
<bdrung> doko_: yes
<nthykier> bdrung: Hey - did you look at creating a reportbug script? If not I will give it a try
<bdrung> nthykier: i will create the apport hook first and then let's see if we can recycle it
<nthykier> bdrung: okay
<doko_> bdrung: works for me
<bdrung> doko_: sudo apt-get install wine1.2
<bdrung> nthykier: how can i detect the workspace directory?
<doko_> bdrung: can you recheck with openjdk-6 from https://edge.launchpad.net/~doko/+archive/toolchain
<bdrung> doko_: ok
<bdrung> doko_: is there an bug report that openjdk does not support tray icons?
<doko_> bdrung: are you running compiz?
<bdrung> s/an/a/
<bdrung> doko_: yes
<doko_> should be fixed in the ppa version. please check
<bdrung> k
<nthykier> bdrung: You can try  ~/.eclipse/org.eclipse.platform_*/configuration/.settings/org.eclipse.ui.ide.prefs - it contains a RECENT_WORKSPACES value
<bdrung> doko_: tray icon works
<nthykier> I think the average case will be ~/workspace/
<nthykier> I would be okay with just doing an if [ -e "$HOME/workspace/.metadata/.log" ] ; then dump_file "$HOME/workspace/.metadata/.log" ; done
<nthykier> s/done/fi/ - but anyway
<bdrung> doko_: the font bug is still there
<bdrung> doko_: TESTCASE: Install jdownloader and select a Synthetica theme
<doko_> bdrung: Synthetica Simple 2D is the theme in use.
<doko_> and works
<bdrung> doko_: do you have mscorefonts installed?
<doko_> bdrung: no
<doko_> bdrung: installed, still works
<bdrung> doko_: then install this
<bdrung> doko_: bug #520515
<ubottu> Launchpad bug 520515 in openjdk-6 "Fonts in Java application are distorted" [Undecided,Incomplete] https://launchpad.net/bugs/520515
<doko_> bdrung: why package the download script, what does it change?
<bdrung> it gives you a desktop file. but downloading it and running it would have the same results.
<bdrung> doko_: i just wanted to create a simple test case (to avoid a jd config trigger this behaviour)
<doko_> bdrung: I did ...
<bdrung> doko_: which arch?
<doko_> i386
<doko_> bdrung: please try to remove any extra fonts installed
<bdrung> doko_: mine is amd64
<bdrung> doko_: where are the extra fonts?
<doko_> ttf-* packages
<doko_> and you mscorefonts,
<bdrung> k, will test it in a kvm instance
<doko_> bdrung: any results?
#ubuntu-java 2010-04-14
<bdrung> doko_: yes: bug #520515
<ubottu> Launchpad bug 520515 in openjdk-6 "Fonts in Java application are distorted" [Undecided,Incomplete] https://launchpad.net/bugs/520515
<doko_> bdrung: not for me, sorry
<bdrung> doko_: you installed ttf-tahoma-replacement without any result?
<bdrung> doko_: btw, i am on amd64
<doko_> bdrung: ahh, didn't see this comment
<bdrung> doko_: i was able to reproduce this issue in kvm.
<doko_> bdrung: confirmed, reassigning to wine
<bdrung> great
<doko_> bdrung: I hope it's not sarcasm, but apparently there's something with the font
<bdrung> :)
<bdrung> good night
<KA1234> how do i get invite to #java?
<nthykier> you register your nick - see freenode's documentation
<KA1234> but they say my nick name is already registered and i still cant get into the channell
<nthykier> wow, they really restrict it to invites only
<nthykier> well, no clue how that works
<persia> Just worked for me, and I've no reason to have been invited there.  Dunno.
<nthykier> well, I get a "require invite"
<nthykier> not that I have much desire to join that channel :P
<persia> If I ask NickServ about you, it says you aren't registered.
<persia> Maybe unregistered folks need invites?
<nthykier> Truly I am not registered - but KA1234 claimed that he was
<nthykier> s@he@he/she@g
<persia> Right.  I'm wondering if the channel is set up to require invites for unregistered folks.
<persia> Anyway, doesn't matter.
<nthykier> Agreed - I am perfectly okay with not being able to enter #java :P
<persia> Oh, #java?  I've never tried there, only ##java.
#ubuntu-java 2010-04-15
<hazmat> is there a way to get the apt to use the 'real' java installed instead of trying to pull in a gcj stack?
<hazmat> ie. if i do update-java-alternatives and pick the sun or openjdk
<hazmat> and then try to install something like maven, apt still wants to pull down the entire gcj stack
<persia> hazmat: Yes, but not trivially, or client-side.
<persia> Essentially it requires investigating the dependency stacks,and ensuring that there exists a gcj-clean path.
<persia> Note that if any adjustments are required, it's important to *also* support the -gcj path for folks that want to run natively.
<hazmat> persia, so what would a gcj clean path look like.. let's take ant as an example (smaller transitive dep stack) i see default-jre-headless and libxerces2-java as the deps.. lbiexerces2-java also needs the same default-jre-headless and libjaxp which just needs a default-jre-headless
<hazmat> so afaics thats a gcj-clean path
<hazmat> yet attempting an installation will still pull in a gcj stack
<persia> I have ant installed on my workstation and no -gcj packages.
<persia> Could you paste the output of `apt-get install ant` in your target environment?
<hazmat> persia, http://gist.github.com/367258
<hazmat> and my java alternatives.. http://gist.github.com/367261
<hazmat> karmic fwiw
<persia> Ah, right.
<persia> So ant-gcj is a recomemndation, and you have recommends turned on by default.
<persia> You either need to use --no-install-recommends or use a more nuanced package manager.
#ubuntu-java 2010-04-16
<kobrien> hi, recommended packaging method for a program built with ant?
<thkoch> kobrien: debhelper
<kobrien> kk
<kobrien> ahoy. I get the error "dpkg-source: binary file contents changed" when packaging. how do I proceed?
<kobrien> the error occurs for all .jars in the dir
<persia> Firstly, you don't want to include jars in your packaging.
<persia> (ideally)
<persia> Secondly, you can work around that with source format 3.0 if you need.
<persia> But generally you should be able to just set the right build-depends to get all the jars you need.
<kobrien> the library jars are my own code
<persia> Then they deserve their own packages.
<kobrien> ah, ok, noted
#ubuntu-java 2010-04-18
<persia> Anyone use visualvm?
<ksemeks> Hi
<persia> Hey
<ksemeks> i have a question. how could i run my code from a folder, say i want to run 'java /path/to/file/file', how could i do it?
<persia> That doesn't just work?
<ksemeks> no, it gets me an error, that it cannot find the main method
<ksemeks> there are 3 files in the folder, but i only call 1
<persia> Adn the code is known to work?
<ksemeks> yes, the code works normally when i run it from the folder
<persia> What's different about "normally"?
<ksemeks> different is when i try to run it from without the folder, then i get the errror
<persia> Sounds like an issue with CLASSPATH to me.
<ksemeks> might be, but does this mean that every time i want to run a file from out the folder, i have to include the path to the folder ini the classpath?
<nthykier> ksemeks: you have to use "java -cp $dir classname" rather than java $dir/classname
<ksemeks> ty nthykier, it works fine now :)
<persia> nthykier: You don't happen to know where I might found the source download for visualvm, do you?  There's a new upstream bugfix, but I'm only finding binary downloads :(
<nthykier> persia: nope sorry - never heard of it
<persia> nthykier: OK.  Thanks.  ( https://visualvm.dev.java.net/ )
<doko_> nthykier, persia: are there any eclipse plugins/extensions already packaged?
<nthykier> doko_: We got eclipse-emf and eclipse-rse nearly ready
<persia> nthykier and you had some eclipse-helper scripts, right?
<nthykier> persia: yes
<doko_> nthykier: any guide how to do extension/plugin packaging? looking at pydev
<persia> doko_: IF you have time, could you give me some guidance on how to build the tarballs for visualvm?  I'd like to push the new upstream to lucid.
<nthykier> doko_: My helpers are geared towards buildless features
<nthykier> doko_: Not sure they are useful if upstream ships their own build
<doko_> persia: hahaha ... bulding the tarballs is the problem
<doko_> nthykier: I thought you did include the build bits from fedora?
<persia> I see :)  Do you happen to know where one might find the extra bit?  http://icedtea.classpath.org/visualvm/ seems stuck at 6.5
<nthykier> doko_: I do - my helpers wraps those
<nthykier> The Fedora helper is in /usr/lib/eclipse/buildscripts/pde-build
<doko_> persia: yes, look at the 500gb netbeans 6.8 checkout. it's on my radar, no need to do the work twice
<persia> Oh, if you7re doing it, I'll skip it.  Juli appears to have already uploaded NB6.8, so that's in place.
<persia> Thanks :)
<ksemeks> is stack in C the same stack of java?
<nthykier> ksemeks: The datatype ? They bear similarities - the call/value stack? No
<ksemeks> i meant the call/value one.. al right.. ty
<nthykier> ksemeks: You cannot access the call/value stack in java
<ksemeks> ok. and the constructor 'lives' in the stack too? or?
<persia> ksemeks: You may want to ask some of these questions in ##java : we tend to focus on packaging stuff in this channel.
<ksemeks> oh, ok. :)
#ubuntu-java 2011-04-13
<epenor> buenas noches
<epenor> quisiera saber como ajusto el tamaÃ±o de las fuentes de Java
<epenor> tengo una aplicacion que en windows se ve bien pero en ubuntu las letras se ven algo grande
<epenor> y algunas palabras no se ven completas
<raevol> hi, does anyone know if the javax.media library is provided in ubuntu?
<raevol> i see, it's out of development
#ubuntu-java 2011-04-14
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
<samrat37> hi .. are u software programmer or system admin?
#ubuntu-java 2011-04-17
<kamel__> hi sorry, for some reason ive been stuck for a hour now, i need to add a .jar file to my class path using command in linux, how can i do that?
#ubuntu-java 2012-04-10
<dzegcifuentes> wuzup!!! sorry for my bad english but!! im willing if someone of u can help me!!!!
<dzegcifuentes> Id like to do a printing monitor but the OS is windows 7 any idea?
<dzegcifuentes> obvious in java SE
#ubuntu-java 2016-04-15
<baci> hi there anyone work with nutch and solr before?
<baci> okay what projects are u guys working on at the moment?
<baci> anyways. im working on these projects and can always use help in configuration...
#ubuntu-java 2019-04-08
<asdfasdasd> asdf
<asdfasdasd> hello
<doko> sbeattie, tdaitx_, gaughen: updated the transition document with the two outstanding tomcat8/9 issues
<huehner> doko: what is the pending tomcat8? i assume the service file instead of redirect?
<huehner> doko: apart is there a new timing for the -proposed -> -security copy?
<tdaitx_> huehner: sorry, I missed your first question, it is related to LP: #1819721
<huehner> tdaitx: the use-case from #2 should be possible to support i think kind of easily (of course not 100% transparently)
<huehner> tdaitx: idea:
<huehner> /etc/systemd/system/tomcat.service.d# cat override.conf
<huehner> [Service]
<huehner> EnvironmentFile=/home/openbravo/tools/tomcat.prop
<huehner> then use that prop file similar to their tomcat8.local
<huehner> note: just idea did not test that exact scenario they explain
<huehner> away... now getting late here in europe (back tomorrow)
<tdaitx> huehner: yeah, I agree, I have tested that locally and it works, but hard to tell if it applies to whatever they are using, I will have to comment on the bug
#ubuntu-java 2019-04-09
<huehner> tdaitx: a month ago i did a review of old tomcat packaging vs new to think on potential issues and shared here: overview https://pastebin.com/tHwmMd0j
<huehner> tdaitx: the 3rd is a bit obscure but the 2nd i think somebody else out there might hit (could be 'solved'/reconfigured by override file
<huehner> tdaitx: plan B (not a good one, but possible) the old-style init-script does still work technically (we use tomcat8-user to create on separate instance and keep modified init-script for now in there) -> we tested and does still work for us
#ubuntu-java 2019-04-10
<gaughen> hey tdaitx - checking in on the open items for openjdk11 - what's left to do?
 * sbeattie was trying to figure out the same
<tdaitx> I was reviewing and testing the uploads we just did
<tdaitx> there was a small difference in tomcat8 that I hadn't realized before, but I believe I actually got it right
<tdaitx> the diff I had done when writing the document was based on the versions that balint used for the "bb to bb-proposed" u-u test
<tdaitx> but what we probably missed is that we actually cared about "bb-security to bb-proposed"
<tdaitx> so while the initial diff suggested that tomcat8 lacked proper support for openjdk 11 (and 10) in the init file, that was fixed on a security update
<tdaitx> fortunately I reverted tomcat8's initd script to the one from bionic-security, not bb, so we have the sane update
<sbeattie> oh cool
 * sbeattie was playing around with u-u last night, too, but is not sure he was driving it correctly.
<tdaitx> at the same time it means that 8.5.30-1ubuntu1.3 was not upgraded for users that had local changes to its initd
<tdaitx> * automatically upgraded by u-u
<tdaitx> anyhow, now that is done, I'm looking over a few autopkgtests that were marked as failed and a couple updates from debian
<tdaitx> sbeattie: meanwhile, how long do you want to let the new uploads bake in -proposed?
<sbeattie> given that the recent changes should not have touched code, I don't think they need to do the 7 day wait.
<tdaitx> ok
<tdaitx> the updates on debian that I am looking into are https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925071 and https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=925586
<tdaitx> * am planning to look into
<tdaitx> the first bug would affect xenial to bionic updates, but I haven't tested that
<tdaitx> the second is reported against android-sdk-helper which we did not rebuild, but could possibly cause other packages to fail as well (the ones we uploaded were not affected by that issue)
<tdaitx> so neither feel like an actual blocker
<tdaitx> doko: sbeattie: vorlon: let me know if any of you disagree with that assumption ^
<vorlon> tdaitx: so one last question, do the new binary packages from openjdk-lts declare Breaks: on older versions of the packages that are runtime-incompatible with the new jre?
<tdaitx> vorlon: we only have that "Breaks: clojure1.8 (<= 1.8.0-7ubuntu1~)"
<tdaitx> in openjdk-11-jre-headless
<vorlon> tdaitx: I was just chatting w/ sarnold and it occurred to me that this might matter, in particular for packages that could be held back in some cases by u-u (AIUI: netbeans, visualvm, jetty9, tomcat8)
<tdaitx> hmm, yeah, we didn't update it to add the "Breaks" clause for those
<tdaitx> netbeans never worked afaik, so we could ignore that one
<tdaitx> oh well, maybe somebody got netbeans working with _some_ jdk by playing around the conffiles, so yeah, we might want to add it anyway
<vorlon> sbeattie: ^^ do you think we should do a rebuild of openjdk-lts to add these breaks before pushing out, or do you think we should bundle that fix (which is correct but probably only helps a very small number of people) with the subsequent openjdk-lts security upload?
 * sbeattie hrms.
<tdaitx> wth, why does openjdk in bionic-proposed (11.0.2+9-3ubuntu1~18.04.2) shows the armhf as failed while the armhf build page says all was fine?
<vorlon> tdaitx: https://launchpad.net/ubuntu/+source/openjdk-lts/11.0.2+9-3ubuntu1~18.04.2/+publishinghistory shows doko had to delete it and recopy it because it was "copied without armhf binaries" the first tiem
<vorlon> so the binaries made it across the second time, but unfortunately the web ui gives you links to the build record for this archive instead of for the source archive, for armhf
<tdaitx> we could rebuild it, just consider that armhf takes ~12 hours (and arm64 about 11h)
<vorlon> tdaitx: it doesn't need rebuilt
<vorlon> for this
<tdaitx> I meant for the breaks =)
<vorlon> right
<sbeattie> I'm less concerned about netbeans, visualvm, and jetty9, but potentially breaking people's tomcat8 in the middle of the night seems ill-advised.
<sbeattie> so my inclination is to lean towards adding the breaks
<tdaitx> sbeattie: vorlon: is this good enough: "Breaks: clojure1.8 (<= 1.8.0-7ubuntu1~), jetty9 (<< 9.4.15-1~), netbeans (<< 10.0-3~), tomcat8 (<< 8.5.39-1ubuntu1~), visualvm (<< 1.4.2-2~)"?
<tdaitx> do we want it for cosmic as well? disco?
<vorlon> tdaitx: are those the correct binary package names for each case?
<vorlon> and is it the case that each of those 4 packages is included in the update due to runtime breakage?
<vorlon> but e.g. maybe you should have libjetty9-java instead of jetty9
<tdaitx> vorlon: yes they are, I think libjetty9-java does not ship any of the conf files
<tdaitx> they were all in jetty9 iirc, let me double check that
<tdaitx> libjetty9-java only has the jar and maven files
<tdaitx> vorlon: is my assumption correct that we want the binary that carries the actual conffiles?
<vorlon> tdaitx: the breaks: should be against whichever packages are actually broken at runtime, and *might* be held back by u-u
<tdaitx> so, libjetty9-java does not depend on the conffiles afaik, it is just the shared classes
<tdaitx> jetty9 does use those shared classes to get the server setup and then uses the conffiles for configuration
<vorlon> tdaitx: right, so that makes sense for jetty9
<vorlon> if the other packages fit in the same category, then all good
<tdaitx> yep, all of the same
<tdaitx> oh lintian, oh joy
<tdaitx> uploaded new openjdk-lts into stage5 for bionic
<tdaitx> same for cosmic, if we don't want the breaks in cosmic for any reason feel free to stop the builders and delete it
<tdaitx> afk, back in ~2.5h
#ubuntu-java 2019-04-11
<doko> if we want the breaks, then the breaks should be against the binary package that all other binaries built from the same source depend on
<doko> so we have to wait for the build until Thu evening, and we don't want to copy these to -security on Friday? Does this mean the copy won't happen before Monday?
<vorlon> Thursday evening> it wouldn't be Thursday evening here, if it's a 12h build
<vorlon> 10h from now would be mid-morning European time
<doko> let's see
<doko> I'll join the meeting tonight
<tdaitx> "then the breaks should be against the binary package that all other binaries built from the same source depend on" ok, but why? where I can see more of that, I did search but I don't remember seeing how Breaks should be written
<tdaitx> in our particular case, the other binaries do not use the conffiles, so when loading eg libjetty9-java one needs to provide the configuration to it
<tdaitx> libjetty9-java is not going to look at /etc/jetty/blah, and if it did then we would have to move the conffile to it
<tdaitx> whatever is loading libjetty9-java should not expect to be able to use the conffile if it does not depend on jetty9 (which is the package with the conffiles)
<tdaitx> thus, why breaks on any other package? it would make sense if we were adding the breaks because of code incompatibility, but we never tested if the previous libjetty9-java would or would not load with our new openjdk-11, we only know that for sure about jetty9 itself (same for all other packages in this list)
<tdaitx> doko: vorlon: ^ so what should be done about Breaks?
<doko> tdaitx: I copied your upload to the proposed pockets
<tdaitx> yeah I saw that and it does not match what you said earlier
<tdaitx> so I am a bit confused =)
<doko> ?
<vorlon> tdaitx: we're ok as long as u-u does not calculate (based on package relationships) that it is allowed to upgrade openjdk-lts, while holding back a package with a conffile conflict, resulting in the old version of that package being broken due to runtime incompatibilities
<vorlon> so a direct Breaks: against the packages shipping the conffiles should suffice
<tdaitx> yes, that was my understanding, but that is not the same as "then the breaks should be against the binary package that all other binaries built from the same source depend on"
<tdaitx> what I mean is, the Breaks that I proposed and were uploaded:
<tdaitx> 1) do satisfy "u-u does not calculate (based on package relationships) that it is allowed to upgrade openjdk-lts, while holding back a package with a conffile conflict, resulting in the old version of that package being broken due to runtime incompatibilities"
<tdaitx> 2) do *not* satisfy "then the breaks should be against the binary package that all other binaries built from the same source depend on"
<vorlon> tdaitx: right. I'm saying that I think what you've done is fine, and if there is any case where users still end up broken, that means the inter-binary dependencies within the other packages are wrong and we should fix those instead of having to re-upload openjdk-lts
<tdaitx> yeah, that
<tdaitx> yeah, that is what I was thinking about
<tdaitx> thanks
<sbeattie> vorlon: if we wait until monday to publish, is that going to mess with the disco release freeze?
<vorlon> sbeattie: no, it just shortens the runway between this going out and the next openjdk security update having to follow
<vorlon> sbeattie: I have no concerns from this side about pushing it out today, however, provided we get to the end of the list of checks. do you?
<vorlon> I'm manually retriggering the libreoffice/bionic autopkgtests now
<vorlon> (they had to be manually retriggered for the last one, so that's nothing I'm concerned about)
<sbeattie> if there are regressions we've overlooked, I'm a little leery of trying to hurridly push fixes on a friday, for as large a transition as we are doing.
<vorlon> ok, I'd defer to you
<vorlon> for SRUs we treat Thursday as the cutoff in order to give us Friday as margin
<vorlon> (with the weekend in extraordinary cases)
<sbeattie> vorlon: yeah, same for security team; however, the scale here is a little larger than normal, and I'd really rather none of us were working over the weekend on it.
<huehner> tdaitx: i just notice finally you reverted the tomcat8.service topic? and went back to init-script for the bionic sru?
<tdaitx> huehner: yes, we decided to revert it, bionic was initially released with the initd script and never got the systemd service (compared to cosmic which had the systemd update)
<tdaitx> this makes the update much less disruptive (for users) and easier to handle (for us)
<vorlon> gaughen: ^^ note the preference from sbeattie for deferring the release until Monday
<tdaitx> vorlon: gaughen: sbeattie: that and the fact that we wanted to give people some heads up before the actual change, right?
<tdaitx> but that means the notice would have to be released either today or tomorrow
<sbeattie> advance warning would be good, too, yes.
<huehner> tdaitx: better for sru i agree. maybe i should been a bit louder about same topic (see pasetbin link from yesterday i send you) some weeks ago ;)
<huehner> tdaitx: will try to retest on latest proposed tomorrow or over the weekend fomr our side
<tdaitx> huehner: ok, thanks, indeed, eveything you addressed on that pastebin is fixed by removing the systemd.service and relying on the initd script
<huehner> tdaitx: seen, thanks for the work. than we can revisit that more calmly for 20.04
#ubuntu-java 2019-04-12
<vorlon> tdaitx, gaughen: it was news to me that we wanted to give additional notice /before/ the security updates were released.  Does that refer to the Ubuntu blog post or something else?  That blog post draft is written in present tense, so is meant to go out when the release happens, not before
<vorlon> if it refers to something else: who should give that notice, and where?
<gaughen> we should not block on the ubuntu blog post
<vorlon> gaughen: I agree; tdaitx suggested some other notice was needed before releasing though
<vorlon> and I don't remember previously discussing that
<gaughen> vorlon, I don't recall what that is. I know sbeattie was plotting to do a usn.
<vorlon> well, usn is also at time of release AIUI
<sbeattie> yes, we only publish a usn once packages are available in the archive.
<tdaitx> we discussed about giving a heads up in one of the meetings and it was bought up again when we were discussing about u-u and saw which packages were affected
<tdaitx> not that I remember we ever saying it was going to block anything, only that it would be good to have a notice out
<vorlon> tdaitx: ok, I guess I don't remember this.  I think this only happens today if you have strong opinions and want to drive it
