Re: Looking at an archive rebuild with opendjk-9-jdk

[Matthias Klose]

On 29.06.2017 15:16, Chris West wrote:
> I rebuilt ~300 packages[1] which build-depend on default-jdk in a
> hacked-up[2] "chroot" which uses openjdk-9-jdk, in place of openjdk-8-jdk.
> (i.e. custom java-common build + some Provides: hacks.)

thanks for doing that!  Usually java9 support comes in new upstream versions, so
updating packages in unstable to at least the first version supporting java9
would be nice.

> Most things fail: 87% failures.
> 
> 
> ~41% are hitting a bug in Maven, e.g. argparse4j:
>dh_auto_build -O--buildsystem=maven
> /usr/lib/jvm/default-java/bin/java -noverify -cp /usr/[...]
> [ERROR] Error executing Maven.
> [ERROR] java.lang.IllegalStateException: Unable to load cache item
> [ERROR] Caused by: Unable to load cache item
> [ERROR] Caused by: Could not initialize class
>   com.google.inject.internal.cglib.core.$ReflectUtils
> 
> There's an old mailing list post about this, but it doesn't seem to have
> a resolution beyond "works for me!":
> https://www.mail-archive.com/jigsaw-dev@openjdk.java.net/msg06073.html
> 
> Someone more aware of what versions of things we're running, and how
> they were built, should investigate this.

I assume a lot more issues are hiding here once the build system is fixed.

> ~30% are using an outdated -source or -target, e.g. dom4j:
> [javac] error: Source option 1.3 is no longer supported. Use 1.6 or later.
> [javac] error: Target option 1.3 is no longer supported. Use 1.6 or later.
> 
> We discussed on IRC perhaps patching javac (or ant/maven) to just use
> 1.6 here, and pray. Annoying to try, as neither ant nor maven build in
> my "chroot".

That sounds ok. But why not using 1.7? should be fine for even oldstable.

> Does anyone have a less horrifying suggestion, beyond patching 30% of
> the libraries in Debian?

For the future we maybe could add these defaults in a common package.

> ~8% are hitting a bug in gradle, e.g. gant:
> Caused by: java.lang.reflect.InaccessibleObjectException:
>   Unable to make protected java.lang.Package[]
> java.lang.ClassLoader.getPackages() accessible:
>   module java.base does not "opens java.lang" to unnamed module @14fc5f04
> 
> https://github.com/gradle/gradle/issues/1095 suggests it's fixed in 4.1
> nightly, as of a fortnight ago.
> 
> I guess we just wait for upstream to fix this one, and the new gradle to
> make it into sid.
> 
> 
> 
> 
> The remaining failures are much more random:
>  * eclipse stuff has weird failures, e.g. eclipse-cdt fails to find some 
> files[3]

eclipse is so outdated, maybe better remove it.

Matthias

Looking at an archive rebuild with opendjk-9-jdk

[Chris West]

I rebuilt ~300 packages[1] which build-depend on default-jdk in a
hacked-up[2] "chroot" which uses openjdk-9-jdk, in place of openjdk-8-jdk.
(i.e. custom java-common build + some Provides: hacks.)


Most things fail: 87% failures.


~41% are hitting a bug in Maven, e.g. argparse4j:
   dh_auto_build -O--buildsystem=maven
/usr/lib/jvm/default-java/bin/java -noverify -cp /usr/[...]
[ERROR] Error executing Maven.
[ERROR] java.lang.IllegalStateException: Unable to load cache item
[ERROR] Caused by: Unable to load cache item
[ERROR] Caused by: Could not initialize class
  com.google.inject.internal.cglib.core.$ReflectUtils

There's an old mailing list post about this, but it doesn't seem to have
a resolution beyond "works for me!":
https://www.mail-archive.com/jigsaw-dev@openjdk.java.net/msg06073.html

Someone more aware of what versions of things we're running, and how
they were built, should investigate this.



~30% are using an outdated -source or -target, e.g. dom4j:
[javac] error: Source option 1.3 is no longer supported. Use 1.6 or later.
[javac] error: Target option 1.3 is no longer supported. Use 1.6 or later.

We discussed on IRC perhaps patching javac (or ant/maven) to just use
1.6 here, and pray. Annoying to try, as neither ant nor maven build in
my "chroot".

Does anyone have a less horrifying suggestion, beyond patching 30% of
the libraries in Debian?




~8% are hitting a bug in gradle, e.g. gant:
Caused by: java.lang.reflect.InaccessibleObjectException:
  Unable to make protected java.lang.Package[]
java.lang.ClassLoader.getPackages() accessible:
  module java.base does not "opens java.lang" to unnamed module @14fc5f04

https://github.com/gradle/gradle/issues/1095 suggests it's fixed in 4.1
nightly, as of a fortnight ago.

I guess we just wait for upstream to fix this one, and the new gradle to
make it into sid.




The remaining failures are much more random:
 * eclipse stuff has weird failures, e.g. eclipse-cdt fails to find some 
files[3]
 * broken dependencies (i.e. probably not caused by jdk9,
or caused by my build env), e.g. dogtag-pki
 * javadoc is more picky about some things, e.g. imports of sealed packages 
(hacked ant),
 [javadoc]
 /build/classycle-1.4.2/src/classycle/ant/ReportTask.java:97: error:
 no summary or caption for table
 * bnd actually fails due to a jdk9 reason, it uses _ as an identifier!
 * Full list (without reasons): https://paste.debian.net/973904/


I suggest we attempt to address these three major issues before trying
a bigger rebuild.

Chris.

1: Processed dose output: https://paste.debian.net/973901/
2: https://github.com/FauxFaux/debjdk9
3: https://paste.debian.net/973906/

Re: Problems to package a Java-based application and uploading the resulting deb package to mentors

[Markus Koschany]

Hi,

Am 29.06.2017 um 11:40 schrieb Eloy García (PC Actual):
> Hi Markus,
> 
> No discourage at all :)
> 
> I see your point here but I think you are only partly right. IMHO I see
> other small applications in the repository too.

Yes, there are other small applications in Debian but from my own
experience I know that people who start out with packaging their own
hobby project will most likely vanish in the near future after they have
achieved their goal. They only want to get the app into Debian but they
are neither interested in maintaining the (build-)dependencies nor do
they really want to contribute to Debian as a whole. You can prove me
wrong though. We are always looking for new contributors. If you start
with fixing bugs in existing Debian packages, it would demonstrate that
you really want to make Debian better, not just your own package.

> In addition,
> WallpaperDownloader is already in AUR and available as a snap package in
> the Ubuntu Store, being daily used.

The AUR and snap packages are not comparable to Debian's main
distribution. Most Java packages in Arch Linux are poorly maintained.
They often don't even bother with compiling them and just distribute the
binary jar file. And if they build something they just download the
build-dependencies from the Internet, like you do with your package. [1]
Also the AUR is for user produced content and is not really part of Arch.

> Some of those users have complained
> because the truth is snap packages are still in an early stage, so there
> are some crucial aspects of the application (the automated changer for
> example) that doesn't work properly in some cases within an isolated
> environment as the snap package.
> Because of this, and because I think the right of choice is very
> important in the Open Source world (I know there are scripts that can
> download wallpapers and applications like Variety that are already in
> the repos and are quite similar [although they have different features])
> I decided to start packaging the application for Debian.

I think you are underestimating the difference between a real Debian
package and AUR/snap packages on the other hand. Snap packages are
basically isolated containers and work independently from the rest of
the system. You don't really have to care for the rest of the system.
That's very different from packaging software for Debian main where your
package is part of the system and where you need to take care of your
build-dependencies.

Choice is not everything in the FOSS world. We already have thousands of
great packages. The difficulty is to maintain them, long term.

Regards,

Markus

[1]
https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=wallpaperdownloader




signature.asc
Description: OpenPGP digital signature

Re: Problems to package a Java-based application and uploading the resulting deb package to mentors

[PC Actual]

Hi Markus,

No discourage at all :)

I see your point here but I think you are only partly right. IMHO I see
other small applications in the repository too. In addition,
WallpaperDownloader is already in AUR and available as a snap package in
the Ubuntu Store, being daily used. Some of those users have complained
because the truth is snap packages are still in an early stage, so there
are some crucial aspects of the application (the automated changer for
example) that doesn't work properly in some cases within an isolated
environment as the snap package.
Because of this, and because I think the right of choice is very important
in the Open Source world (I know there are scripts that can download
wallpapers and applications like Variety that are already in the repos and
are quite similar [although they have different features]) I decided to
start packaging the application for Debian.

Best regards,

Eloy

2017-06-29 10:20 GMT+02:00 Markus Koschany :

> Hi,
>
> I don't want to discourage you from getting more involved with Debian
> and Java packaging in general but in my opinion you shouldn't start with
> packaging your own application. wallpaperdownloader sounds like a nice
> little application but it is probably just that. Debian is not a
> general-purpose store for private projects. An application should have a
> considerable user base already or the application should satisfy a real
> demand. Downloading images from the Internet...I think a list of URLs
> and a web browser will most certainly do.
>
> Regards,
>
> Markus
>
>


-- 
Eloy García Almadén

Re: Problems to package a Java-based application and uploading the resulting deb package to mentors

[PC Actual]

Hi Emmanuel!

Thank you very much for the tips. I'll try all your suggestions and come
back here to post the results :)

Best regards.

Eloy

2017-06-29 9:23 GMT+02:00 Emmanuel Bourg :

> Hi Eloy,
>
> Le 28/06/2017 à 21:34, Eloy García (PC Actual) a écrit :
>
> > Those are the steps I have followed so far:
> >
> > 01.- I installed Debian and switched to Sid
> > 02.- I cloned the master branch from the upstream repo in Bitbucket: git
> > clone https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader.git
> > 
>
> Don't forget to also checkout the latest release tag.
>
> > 03.- I installed manually all the dependencies needed from Debian
> > repository (sudo apt install liblog4j1.2-java libslf4j-java
> > libcommons-io-java libjsoup-java libjna-java)
>
> Ok
>
> > 04.- I installed all the tools needed for building the package (sudo apt
> > install git build-essential devscripts debhelper javahelper
> > maven-debian-helper apt-file)
>
> Ok
>
> > 05.- I executed mh_make (I have used maven debian helper for creating
> > the initial structure instead of dh_make)
>
> Ok
>
> > 06.- I modified rules and control files. You can see the definitive
> > files if you go to the code repository and navigate to debian folder
> > (https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/src
> > )
>
> Looks good. You could add the debian/watch file to track the new
> releases, something like this:
>
>   version=3
>   opts="mode=git,repack,compression=xz" \
>   https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader.git
> refs/tags/([\d\.]+)
>
> > 07.- I created some new files for the packaging process:
> > wallpaperdownloader.install, wallpaperdownloader.manifest,
> > wallpaperdownloader.manpages
>
> Ok. You may want to add a SVG icon if you have one.
>
> > 08.- I created the Debian package using dpkg-buildpackage -b -rfakeroot
> > -us -uc from the root directory of the wallpaperdownloader application.
> > WARNING: ONLY three files were generated in this process:
> > wallpaperdownloader_2.7-1_all.deb,
> > wallpaperdownloader_2.7-1_amd64.buildinfo,
> > wallpaperdownloader_2.7-1_amd64.changes. No orig.tar.gz, no .dsc files
> > were automatically generated.
>
> Assuming you have the watch file above, you can generate the upstream
> tarball with:
>
>   uscan --download-version 2.7 --rename
>
> And for building the package simply use:
>
>   debuild
>
>
> > 09.- I checked the package with lintian. No warnings, no errors (I
> > removed all of them one by one before).
>
> Excellent
>
> > 10.- I installed the generated package and it installs properly.
>
> Good
>
> > 11.- I opened a bug (ITP) against WNPP:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863572
> > 
>
> Perfect
>
> > 12.- I opened a bug (RFS) against sponsorship-requests
> >  sponsorship-requests>:
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864174
> > > 13.- Then,
> I realized that I needed to upload the package to
> > https://mentors.debian.net/ in order to look for a person to sponsor my
> > package so this is what I did:
>
> Going through a RFS and mentors.debian.net isn't strictly required, you
> can just ask on this list and we'll upload it for you.
>
> Emmanuel Bourg
>



-- 
Eloy García Almadén

Re: PDFBox 2.0.6

[Emmanuel Bourg]

Le 29/06/2017 à 10:07, Markus Koschany a écrit :

> Unfortunately src:libpdfbox-java also includes the sources for fontbox.
> The packages can't be updated separately. I could update
> src:libpdfbox-java as a whole or I need to create a new source package,
> say src:libfontbox2-java. I think I do as tony suggested and upload
> src:libpdfbox-java 2.0.6 to experimental first. Then let's see what work
> is required to make the r-deps work again.

As I understand fontbox is just a submodule of the pdfbox project,
pdfbox and fontbox are always released together and with the same
version number. So I think we should keep them in the same source package.

Emmanuel Bourg

Re: Problems to package a Java-based application and uploading the resulting deb package to mentors

[Markus Koschany]

Hi,

I don't want to discourage you from getting more involved with Debian
and Java packaging in general but in my opinion you shouldn't start with
packaging your own application. wallpaperdownloader sounds like a nice
little application but it is probably just that. Debian is not a
general-purpose store for private projects. An application should have a
considerable user base already or the application should satisfy a real
demand. Downloading images from the Internet...I think a list of URLs
and a web browser will most certainly do.

Regards,

Markus



signature.asc
Description: OpenPGP digital signature

Re: PDFBox 2.0.6

[Markus Koschany]

Am 29.06.2017 um 09:02 schrieb Emmanuel Bourg:
> Le 29/06/2017 à 00:13, Markus Koschany a écrit :
> 
>> Thoughts?
> 
> Let's just update fontbox, that's the right time to do it and there
> aren't many reverse dependencies. If we fail to port them to the new
> version we can still upload the latest 1.x version as a separate package
> later.

Unfortunately src:libpdfbox-java also includes the sources for fontbox.
The packages can't be updated separately. I could update
src:libpdfbox-java as a whole or I need to create a new source package,
say src:libfontbox2-java. I think I do as tony suggested and upload
src:libpdfbox-java 2.0.6 to experimental first. Then let's see what work
is required to make the r-deps work again.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Problems to package a Java-based application and uploading the resulting deb package to mentors

[Emmanuel Bourg]

Hi Eloy,

Le 28/06/2017 à 21:34, Eloy García (PC Actual) a écrit :

> Those are the steps I have followed so far:
> 
> 01.- I installed Debian and switched to Sid
> 02.- I cloned the master branch from the upstream repo in Bitbucket: git
> clone https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader.git
> 

Don't forget to also checkout the latest release tag.

> 03.- I installed manually all the dependencies needed from Debian
> repository (sudo apt install liblog4j1.2-java libslf4j-java
> libcommons-io-java libjsoup-java libjna-java)

Ok

> 04.- I installed all the tools needed for building the package (sudo apt
> install git build-essential devscripts debhelper javahelper
> maven-debian-helper apt-file)

Ok

> 05.- I executed mh_make (I have used maven debian helper for creating
> the initial structure instead of dh_make)

Ok

> 06.- I modified rules and control files. You can see the definitive
> files if you go to the code repository and navigate to debian folder
> (https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader/src
> )

Looks good. You could add the debian/watch file to track the new
releases, something like this:

  version=3
  opts="mode=git,repack,compression=xz" \
  https://bitbucket.org/eloy_garcia_pca/wallpaperdownloader.git
refs/tags/([\d\.]+)

> 07.- I created some new files for the packaging process:
> wallpaperdownloader.install, wallpaperdownloader.manifest,
> wallpaperdownloader.manpages

Ok. You may want to add a SVG icon if you have one.

> 08.- I created the Debian package using dpkg-buildpackage -b -rfakeroot
> -us -uc from the root directory of the wallpaperdownloader application.
> WARNING: ONLY three files were generated in this process:
> wallpaperdownloader_2.7-1_all.deb,
> wallpaperdownloader_2.7-1_amd64.buildinfo,
> wallpaperdownloader_2.7-1_amd64.changes. No orig.tar.gz, no .dsc files
> were automatically generated.

Assuming you have the watch file above, you can generate the upstream
tarball with:

  uscan --download-version 2.7 --rename

And for building the package simply use:

  debuild


> 09.- I checked the package with lintian. No warnings, no errors (I
> removed all of them one by one before).

Excellent

> 10.- I installed the generated package and it installs properly.

Good

> 11.- I opened a bug (ITP) against WNPP:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=863572
> 

Perfect

> 12.- I opened a bug (RFS) against sponsorship-requests
> :
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864174
> > 13.- Then, I 
> realized that I needed to upload the package to
> https://mentors.debian.net/ in order to look for a person to sponsor my
> package so this is what I did:

Going through a RFS and mentors.debian.net isn't strictly required, you
can just ask on this list and we'll upload it for you.

Emmanuel Bourg

Re: PDFBox 2.0.6

[Emmanuel Bourg]

Le 29/06/2017 à 00:13, Markus Koschany a écrit :

> Thoughts?

Let's just update fontbox, that's the right time to do it and there
aren't many reverse dependencies. If we fail to port them to the new
version we can still upload the latest 1.x version as a separate package
later.

Emmanuel Bourg