Maintainer field of openjdk-8
Hi, Lately, we have been receiving a significant number of automatic emails concerning openjdk-8. This is because this diffusion list is in the Maintainer field of the package. I remember that a few years ago, I had put the list as the Maintainer of one of my packages and I was asked to set it to pkg-java-maintain...@lists.alioth.debian.org instead. What is the current consensus on the matter? Regards, Vincent Le 03/07/2023 à 00:33, Debian FTP Masters a écrit : openjdk-8_8u382~b04-2_source.changes uploaded successfully to localhost along with the files: openjdk-8_8u382~b04-2.dsc openjdk-8_8u382~b04-2.debian.tar.xz Greetings, Your Debian queue daemon (running on host usper.debian.org)
Bug#980321: ITP: eclipse-collections -- comprehensive collections library for Java
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-java@lists.debian.org Package : eclipse-collections Version : 10.4.0 Upstream Author : Goldman Sachs and others URL : https://www.eclipse.org/collections/ License : EPL-1.0 and EDL-1.0 Programming Lang: Java X-Debbugs-CC: debian-java@lists.debian.org Description : comprehensive collections library for Java Eclipse Collections is a comprehensive collections library for Java. The library enables productivity and performance by delivering an expressive and efficient set of APIs and types. The iteration protocol was inspired by the Smalltalk collection framework, and the collections are compatible with the Java Collection Framework types. Eclipse Collections is compatible with Java 8+. Eclipse Collections is a part of the OpenJDK Quality Outreach program, and it is validated for different versions of the OpenJDK. Eclipse Collections is the evolution of GS Collections (packaged as gs-collections). It is required by version 2.0.0 of NatTable. The package will be maintained within the team of Debian Java Maintainers.
Re: gs-collections vs eclipse-collections
Hi Tony, >> Should we package Eclipse Collections as a separate project (in which >> case I will submit an ITP bug), or update and rename the existing package? >> For your information, the package gs-collections has no reverse >> dependency and has not been updated since September 2017. > I see either choice as acceptable, but my suggestion is to update > the existing package (and rename it only if you think it is necessary). > It is the evolution of (and thus an update to) gs-collections. This > approach means you don't have to go through NEW, we don't have to > introduce a new package to archive, and developers who know the software > by gs-collections will still find it. Even if there aren't r-deps in > Debian, perhaps a downstream is using gs-collections and will benefit > from the update without a rename. What about developers who do not know the software and need Eclipse Collections? Do they have to guess that the Java package is provided by the Debian package gs-collections? Eclipse Collections is indeed the evolution of GS Collections, but the latter still exists as such, even though only bug fixes are made. By the way, the version present in Debian is out-of-date. > If you decide to create a new source package for eclipse-collections, > please also take the time to RM gs-collections. We don't need to keep > the old package around if we have a compatible replacement. (I'm > assuming that eclipse-collections is a drop-in replacement, or nearly so > - maybe just a Java package name change?) Yes, the Java package name is different. So, even if the API is compatible, this would require downstream to change imports, classpaths, etc. In any case, since Emmanuel Bourg was the one who packaged gs-collections in the first place, it would be nice to have his opinion on the question. Cheers, Vincent
gs-collections vs eclipse-collections
Dear all, The latest version of NatTable (2.0.0) depends on Eclipse Collections (https://www.eclipse.org/collections/). Originally, it was called GS Collections, and was renamed when it migrated to the Eclipse Foundation. GS Collections is present in Debian (as gs-collections: https://tracker.debian.org/pkg/gs-collections), but not Eclipse Collections. Should we package Eclipse Collections as a separate project (in which case I will submit an ITP bug), or update and rename the existing package? For your information, the package gs-collections has no reverse dependency and has not been updated since September 2017. Best wishes for the new year Vincent
Sorry (was Processing of re2j_1.5+dfsg-1_amd64.changes)
Dear all, It seems that I put once again the wrong email address in the control file. Sorry for that. Cheers, Vincent Le 25/10/2020 à 19:56, Debian FTP Masters a écrit : > re2j_1.5+dfsg-1_amd64.changes uploaded successfully to localhost > along with the files: > re2j_1.5+dfsg-1.dsc > re2j_1.5+dfsg.orig.tar.xz > re2j_1.5+dfsg-1.debian.tar.xz > libre2j-java_1.5+dfsg-1_all.deb > re2j_1.5+dfsg-1_amd64.buildinfo > > Greetings, > > Your Debian queue daemon (running on host usper.debian.org) >
Re: nattable_1.6.0+dfsg-3_source.changes ACCEPTED into unstable
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi Markus, I was wondering why I received the messages twice. Sorry for the inconvenience and thank you for the tip. Best regards, Vincent Le 17/07/2020 à 22:27, Markus Koschany a écrit : > Hi Vincent, > > please change the maintainer address of your Java packages to Debian > Java Maintainers > > You are currently using the Java discussion mailing list but the other > one is more appropriate for bug reports and status emails. > > Regards, > > Markus > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwN+g0Kj2VQgeB/icBzHNjq6Fm38FAl8SD7gACgkQBzHNjq6F m3/v+Q//ab1HrAgQvtfF1A7DqqASyIg8Qe8Lw0OAtC3f99OLrKNbPh3HUfj3E9uw j3Du473XfClkUaANY9FBukYLZT3g+/0rbIfClrZOmzF/kQXngO7WmD1HT2Qtj1ji POGXT4Ytf4ZTcAriLWMdLdbElJiFzsoEkOvJtuZnx5OXl9zJe8SZHPMKEYA1xdwD 30MoMNZZ61PUr2Ck+/E5FWgw8xemguKhP7LeXXXIt2eLc9qpDKkQoO13k4tmUYDm IueSaz+livDLzFCeOrJiSensGCCVIxUnpH3HWE9lvLcsWzSkcyzKFbpvzbPgeuHE 2hbCw5Nj8zByB2sg5hVZ67NbYZOfHYNgC1uDkXoz8ixquAocwjh4JBUvfxN/5btx rQ7eYYsqDcqla4W4sPf+vKgumEH7OfSWJRDcDHEJjQMO2+DQSlMXlFwEAw524qAr 7dH8knJAizjtuhqcbWLJcbTmEbBRKrnh3CxsKAioQ03lIhxFSYjysX6VGBu6jDcy bX5jk5QBNGyzqK2zCeREBnudR8llk/h547KXuvGgimmpFNmp1jvs7WOWNgGkst7e ImqbC7nCqq7B49zW5fovS1m/bJ+ZavNNSjXXX/xrn3+e9ca+yuLRiq10LnIAKHEg nLoLge87Swl4cVwuDhc5wJ7bNOzf06zBKFMvEXV5sg0l6qEj6rw= =Y1ic -END PGP SIGNATURE-
Re: Gradle problems in Debian
Hi,
I agree that Gradle can be a pain to package software for Debian.
According to the documentation of the antonov protobuf gradle plugin
[1], the name of the plugin is just "protobuf".
Maybe you could try this.
Best regards,
Vincent
[1] https://github.com/aantono/gradle-plugin-protobuf
Le 19/06/2020 à 10:29, Olek Wojnar a écrit :
> Java Maintainers,
>
> Has anyone been able to successfully use Gradle for Debian packaging?
> I am finding the experience an exercise in extreme frustration
>
> For example, I have been trying to build grpc-java and it needs the
> Gradle Protobuf plugin ("com.google.protobuf"). Seems simple enough,
> right? But no, it's not. First of all, the gradle-plugin-protobuf
> package that seems like it should provide this plugin instead
> provides "ws.antonov.gradle.plugins.protobuf.ProtobufPlugin" although
> I had to dig through the jar file to find that. I'm assuming that's
> the plugin name since it's listed in
> META-INF/gradle-plugins/protobuf.properties as "implementation-class".
> However, when I replace
> apply plugin: "com.google.protobuf"
> with
> apply plugin: "ws.antonov.gradle.plugins.protobuf.ProtobufPlugin"
> Gradle continues to give me:
> * What went wrong:
> A problem occurred evaluating project ':grpc-compiler'.
> > Plugin with id
> 'ws.antonov.gradle.plugins.protobuf.ProtobufPlugin' not found.
>
> Does anyone have any suggestions on how I can get this working?? It
> appears that gradle-plugin-protobuf has no reverse depends so I
> couldn't even check to see how someone else got it working... I'm
> wondering if they gave up. I'm regretting trying to use Gradle in the
> first place and thinking I should have just downloaded source jars
> from Maven Central and built the package from those...
>
> Side note: grpc-java also supports building with Bazel and, looking at
> the build files, this seems to be a much simpler process.
> Unfortunately, I'm doing all this so that we can package Bazel in the
> first place so that doesn't really help
>
> Thanks in advance if anyone can shed light on this...
>
> -Olek
Bug#962388: ITP: re2j -- linear-time regular expression matching in Java
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-java@lists.debian.org * Package name : re2j Version : 1.3 Upstream Author : The Go Authors * URL : https://github.com/google/re2j * License : BSD-3 Programming Lang: Java Description : linear-time regular expression matching in Java RE2 is a regular expression engine that runs in time linear in the size of the input. RE2/J is a port of RE2 to pure Java. Java's standard regular expression package, |java.util.regex|, and many other widely used regular expression packages such as PCRE, Perl and Python use a backtracking implementation strategy: when a pattern presents two alternatives such as |a|b|, the engine will try to match subpattern |a|first, and if that yields no match, it will reset the input stream and try to match |b|instead. If such choices are deeply nested, this strategy requires an exponential number of passes over the input data before it can detect whether the input matches. If the input is large, it is easy to construct a pattern whose running time would exceed the lifetime of the universe. This creates a security risk when accepting regular expression patterns from untrusted sources, such as users of a web application. In contrast, the RE2 algorithm explores all matches simultaneously in a single pass over the input data by using a nondeterministicfinite automaton. There are certain features of PCRE or Perl regular expressions that cannot be implemented in linear time, for example, backreferences, but the vast majority of regular expressions patterns in practice avoid such features. This package is a dependency of the netCDF Java library. It will be maintained under the umbrella of the Java Maintainers Team.
Bug#961931: ITP: netcdf-java -- netCDF Java library
Package: wnpp Severity: wishlist X-Debbugs-CC: debian-scie...@lists.debian.org, debian-java@lists.debian.org * Package name : netcdf-java Version : 5.3.2 Upstream Author : University Corporation for Atmospheric Research/UnidataName * URL : https://www.unidata.ucar.edu/software/netcdf-java/ * License : BSD-3 Programming Lang: Java Description : netCDF Java library The netCDF Java library provides an interface for scientific data access. It can be used to read scientific data from a variety of file formats including netCDF, HDF, GRIB, BUFR, and many others. By itself, the netCDF-Java library can only write netCDF-3 files. It can write netCDF-4 files by using JNI to call the netCDF-C library. It also implements Unidata's Common Data Model (CDM) to provide data geolocation capabilities. This package is a dependency of HDFView. It will be maintained under the umbrella of the Debian Science Team.
Bug#943350: RFS: nattable/1.5.0+dfsg-1 [ITP] -- high performance SWT data grid
Package: sponsorship-requests Severity: wishlist X-Debbugs-CC: debian-java@lists.debian.org, debian-scie...@lists.debian.org Dear mentors, I am looking for a sponsor for my package "NatTable": * Package Name : nattable Version : 1.5.0+dfsg-1 Upstream author : NatTable developers * URL : https://www.eclipse.org/nattable/ * License : Eclipse Public License 1.0 Programming language : Java Description : high-performace SWT data grid NatTable is a powerful and flexible SWT table/grid widget that is built to handle very large data sets, real-time updates, dynamic styling, and more. NatTable is a subproject of Nebula. This package is a dependency of HDFView. It builds the following binary package: libeclipse-nebula-widgets-nattable-core-java - core java library To find the package, please visit the following URL: https://salsa.debian.org/java-team/nattable Best regards, Vincent Prat
Re: NatTable, ready for review and upload
Hi Emmanuel, I did consider the option. However, there are several issues. The main one is that the tests do not explicitly require a session manager. The requirement comes from one of the dependencies. Therefore, there is no clear way to determine a priori if a test needs a session manager. Of course, this could be done a posteriori, but given the large number of tests, this would be a very tedious task. Another problem is that the tests are automatically collected and run by ant, so even if I managed to identify which tests require a session manager, I would not know how to disable them specifically. Finally, from what I have seen, a large fraction of the tests do require a session manager. Disabling them would likely lead to a significantly restricted set of tests that are not very relevant, since NatTable is a graphical library. Best regards, Vincent Le 02/09/2019 à 13:03, Emmanuel Bourg a écrit : > Hi Vincent, > > Did you consider disabling the tests requiring a session manager instead > of excluding the tests completely? > > Emmanuel Bourg > > > Le 31/08/2019 à 20:00, Vincent Prat a écrit : >> Dear all, >> >> Since I am not able to run the tests at build time, I guess they will >> not run in the CI pipeline either. >> Therefore, I think it is reasonable not to include the tests in the package. >> >> The package is thus now ready for review and eventually upload, if >> someone wants to sponsor it. >> Feel free to have a look at https://salsa.debian.org/java-team/nattable.git. >> >> Best regards, >> Vincent >> >> Le 26/08/2019 à 18:01, Vincent Prat a écrit : >>> Dear all, >>> >>> I managed to build the tests, and now I am trying to run them during the >>> packaging process with pbuilder. >>> For information, I use xvfb to run the tests on a virtual X server. >>> The last issue I encountered is that some tests (I would say a >>> significant fraction) seem to require a session manager: >>> >>> [junit] - Standard Error - >>> [junit] SWT SessionManagerDBus: Failed to connect to >>> org.gnome.SessionManager: Could not connect: Connection refused >>> [junit] SWT SessionManagerDBus: Failed to connect to >>> org.xfce.SessionManager: Could not connect: Connection refused >>> [junit] - --- >>> >>> Any idea of how to solve this? >>> >>> Best regards, >>> Vincent >>> >>> >>
NatTable, ready for review and upload
Dear all, Since I am not able to run the tests at build time, I guess they will not run in the CI pipeline either. Therefore, I think it is reasonable not to include the tests in the package. The package is thus now ready for review and eventually upload, if someone wants to sponsor it. Feel free to have a look at https://salsa.debian.org/java-team/nattable.git. Best regards, Vincent Le 26/08/2019 à 18:01, Vincent Prat a écrit : > Dear all, > > I managed to build the tests, and now I am trying to run them during the > packaging process with pbuilder. > For information, I use xvfb to run the tests on a virtual X server. > The last issue I encountered is that some tests (I would say a > significant fraction) seem to require a session manager: > > [junit] - Standard Error - > [junit] SWT SessionManagerDBus: Failed to connect to > org.gnome.SessionManager: Could not connect: Connection refused > [junit] SWT SessionManagerDBus: Failed to connect to > org.xfce.SessionManager: Could not connect: Connection refused > [junit] - --- > > Any idea of how to solve this? > > Best regards, > Vincent > >
NatTable, running tests
Dear all, I managed to build the tests, and now I am trying to run them during the packaging process with pbuilder. For information, I use xvfb to run the tests on a virtual X server. The last issue I encountered is that some tests (I would say a significant fraction) seem to require a session manager: [junit] - Standard Error - [junit] SWT SessionManagerDBus: Failed to connect to org.gnome.SessionManager: Could not connect: Connection refused [junit] SWT SessionManagerDBus: Failed to connect to org.xfce.SessionManager: Could not connect: Connection refused [junit] - --- Any idea of how to solve this? Best regards, Vincent
Re: Packaging NatTable, more details
Le 19/08/2019 à 15:46, Vincent Prat a écrit : > Hi all, > > I have finished packaging the core library using eclipse-debian-helper. > Should I also package extensions even if I do not plan to use them? > > Examples and tests are also provided, as java classes. > Should I install the examples? If yes, should I build them or provide > them as is? > What about tests? It would be nice to declare an autopkgtest test suite. > Has anyone done this for a Java package? > > Thanks in advance for your answers. > > Best regards, > Vincent Hi all, Let me explain a bit more the situation. The upstream tarball contains several directories with Java source files: - the core library (nattable.core); - some extensions of the core library (nattable.extension.*); - examples (nattable.examples.*), for both the core library and the extensions; - tests (nattable.*.test), also for both; - a dataset library (nattable.dataset) used by examples and tests to generate fake data. As already mentionend, I have packaged the core library as an eclipse bundle using eclipse-debian-helper. It results in a package named libeclipse-nebula-widgets-nattable-core-java. My first question was about the extensions. To package HDFView (which is the reason why I want NatTable in Debian), I only need the core library. Should I also package the extensions as eclipse bundles (libeclipse-nebula-widgets-nattable-extension-*-java) even though I do not need them? My second question was about the examples. For me, it does not seem a good idea to package them as independent eclipse bundles. The simplest solution is to add them as is (i.e. Java source files) to the corresponding packages using .examples files. Another solution would be to manually build the examples before installing them. What is the best option? There is also another problem: the examples depend on the dataset library. Does it mean that I should also package it, so that the user can compile and/or run the examples, even though this library is useless apart from examples and tests? My third question was about the tests. On the one hand, as for examples, I do not think it is a good idea to package them separately. On the other hand, I do not know how to add tests to an eclipse bundle. I guess I could try to manually build the tests and install them in the corresponding packages. In addition, is there a standard way to collect and run JUnit tests? Again, the tests would require to package the dataset library. I would value any opinion on these questions. Thank you in advance. Best regards, Vincent
Packaging NatTable
Hi all, I have finished packaging the core library using eclipse-debian-helper. Should I also package extensions even if I do not plan to use them? Examples and tests are also provided, as java classes. Should I install the examples? If yes, should I build them or provide them as is? What about tests? It would be nice to declare an autopkgtest test suite. Has anyone done this for a Java package? Thanks in advance for your answers. Best regards, Vincent
Re: New here, NatTable repository push to master
Le 18/08/2019 à 20:56, Geert Stappers a écrit : > On Sun, Aug 18, 2019 at 11:12:43AM -0700, tony mancill wrote: >> On Sun, Aug 18, 2019 at 09:16:51AM +0200, Geert Stappers wrote: >>> On Sat, Aug 17, 2019 at 02:31:45PM +0200, Vincent Prat wrote: >>>> Le 17/08/2019 à 13:52, Geert Stappers a écrit : >>>>> On Sat, Aug 17, 2019 at 01:34:43PM +0200, Vincent Prat wrote: >>>> ... >>>> >>>> Now I get the following error when I try to push to master: >>>> >>>> remote: GitLab: You are not allowed to push code to protected branches >>>> on this project. >>>> >>> >>> Strange. According >>> https://salsa.debian.org/java-team/nattable/-/project_members?page=3 >>> has vivi-guest the developer privilege. >>> >>> I don't know how to fix this properly. >>> Here I need help from a team member. >>> >>> >>>> Pushes to other branches work. >>> >>> >>> That allows to create a branch like "helpneeded" or "vivimaster". >>> And work with that branch for the time being. >> Looking at the settings for Protected Branches [1], we have: >> >>> By default, protected branches are designed to: >>> >>> * prevent their creation, if not already created, from everybody except >>> Maintainers >>> * prevent pushes from everybody except Maintainers >>> * prevent anyone from force pushing to the branch >>> * prevent anyone from deleting the branch >> And for the master branch of nattable, on Maintainers are allowed to >> merge and push. >> >> Looking at the hierarchy of user permissions for gitlab [2,3], the issue >> is that Developer is not the same as Maintainer, and vivi-guest is >> configured as a Developer (as are others). >> >> As Geert suggests, pushing another branch and opening a merge request >> should work fine for now. >> >> The team can discuss what the default access level should be. > Current default access level are fine. > Fine for most cases. > > This case, vivi-guest requested the nattable repository, > he should be able work with it without the hurdle of merge requests. > > I have granted vivi-guest the maintainer role for nattable. It now works. Thanks. Best regards, Vincent
Re: New here, NatTable repository push
Now I get the following error when I try to push to master: remote: GitLab: You are not allowed to push code to protected branches on this project. Pushes to other branches work. Le 17/08/2019 à 13:52, Geert Stappers a écrit : > On Sat, Aug 17, 2019 at 01:34:43PM +0200, Vincent Prat wrote: >> Hi, >>> You are welcome. >>> And very welcome to report write permission errors. >>> >> `git clone g...@salsa.debian.org:java-team/nattable.git` works, but >> `git push` fails with the error >> >> remote: A default branch (e.g. master) does not yet exist for >> java-team/nattable >> remote: Ask a project Owner or Maintainer to create a default branch: >> remote: >> remote: https://salsa.debian.org/java-team/nattable/-/project_members >> remote: >> To salsa.debian.org:java-team/nattable.git >> ! [remote rejected] master -> master (pre-receive hook declined) >> >> > Added a README.md, Please retry. > > > /me > Currently on the road ( away from keyboard ) > >
Re: New here, NatTable repository
Hi, > You are welcome. > And very welcome to report write permission errors. > > Just post something like > > | doing `git clone ..URL` went fine > | with `git push [...]` I get this error > | ... Indeed: `git clone g...@salsa.debian.org:java-team/nattable.git` works, but `git push` fails with the error remote: A default branch (e.g. master) does not yet exist for java-team/nattable remote: Ask a project Owner or Maintainer to create a default branch: remote: remote: https://salsa.debian.org/java-team/nattable/-/project_members remote: To salsa.debian.org:java-team/nattable.git ! [remote rejected] master -> master (pre-receive hook declined) Best regards, Vincent
Re: New here, NatTable
Hi Geert, Thank you for the repository. Best regards, Vincent Le 16/08/2019 à 00:42, Geert Stappers a écrit : > On Fri, Aug 16, 2019 at 12:29:18AM +0200, Vincent Prat wrote: >> Le 15/08/2019 à 14:31, Markus Koschany a écrit : >>> Welcome on board! I have granted you developer permissions >>> on salsa.debian.org. You should be able to modify any existing >>> packages but your future sponsor must create the repository for the >>> new dependency. >>> Cheers, >>> Markus >> The piece of software I want to package is NatTable, which is needed for >> the newest version of HDFView. >> Is anyone willing to create the repository for me? >> For information, you can find the ITP at >> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934793. > > There is now https://salsa.debian.org/java-team/nattable > > > > > Groeten > Geert Stappers > In UTC+2, going to sleep > > P.S. > Happy Birthday
Re: New here
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello, Thank you Geert and Markus. The piece of software I want to package is NatTable, which is needed for the newest version of HDFView. Is anyone willing to create the repository for me? For information, you can find the ITP at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934793. Thanks in advance. Best regards, Vincent Le 15/08/2019 à 14:31, Markus Koschany a écrit : > Hello Vincent, > > Am 15.08.19 um 01:31 schrieb Vincent Prat: >> Hi > everybody, >> >> My name is Vincent, and I am a DM (applying for becoming a DD). >> So far I have mainly worked on astronomy-related packages and games. >> I intend to adopt a science-related package, but it is written in Java >> and requires a new dependency, so I decided to join this team. >> I have applied for access in Salsa. Could someone please accept me? >> Thank you in advance. > > Welcome on board! I have granted you developer permissions on > salsa.debian.org. You should be able to modify any existing packages but > your future sponsor must create the repository for the new dependency. > > Cheers, > > Markus > -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEwN+g0Kj2VQgeB/icBzHNjq6Fm38FAl1V3LkACgkQBzHNjq6F m3+rVw//UxaGfipQ4AOJdmjqQwidik/kOYwde2bdba4D5zzh/mKTc+V84qNaxgyh H93RcK1vBjcf9B1XtYSzSjbxGbtF/NFlf/SlkNdyOSjG+OzQ+xMDprE9KaLgyaG9 603fs9oMSpwRG40JpLrdKMyEbHnqhmQbEKIP6pbrwc8+RIwRAI6LxY73zNAKFR+a 2+/Grxgeh0JTk9mM36lpQtIMLwejKMd5heKRF/+S+C4SZnJ1DUcc5OBKDT0nI/jg KrDOw9kjlXI9l9dPwauetVfmXETNxx/r7F6LHGPQn5Yl9s/Jdrab/ZkLa12YGiaC QysUti/UZlQ0tb4kcsWJIxc1Lakc1Vxyf4zsNgsWHPdbiseFM73YRXGLqtWaZPAZ hmdVO9aQp5OjhA4hg/yFpUfBU+Qcmwgh9FqoBfrsNfUzxwiJ2JZ0Z7SD2+lxog4m A+psD/Mwpde5Q1j4ftva5mJjqwvfX22nab2oGfRlzW7FoQkrnIpjgCdHDs98GUYx PzW7r2TyRr3x6yA141Zq3vGETmWd562vKkzoSx+yR1W9NByEeppM4TPaYquJI6Xp Oj7MMe0DEGvQH11AzSQQ0i/tUozeAE49EkuLyjrQT0H5C42QJrptzXNNS7nJ1yyM rHzOyww9UXTR9igjxjGWin+lCYAKKmArSCoQeMV8inA/jAxwHto= =Emmj -END PGP SIGNATURE-
New here
Hi everybody, My name is Vincent, and I am a DM (applying for becoming a DD). So far I have mainly worked on astronomy-related packages and games. I intend to adopt a science-related package, but it is written in Java and requires a new dependency, so I decided to join this team. I have applied for access in Salsa. Could someone please accept me? Thank you in advance. Best regards, Vincent
