Re: Push rights for salsa/java-team
I've set all DDs and DMs as masters for the java-team, so anyone should be able to create new repositories. As a replacement of the /srv/git.debian.org/git/pkg-java/setup-repository script we used on Alioth to configure new repositories I've created an equivalent script for Salsa: https://salsa.debian.org/java-team/pkg-java-scripts/blob/master/setup-salsa-repository Emmanuel Bourg
Re: libjsyntaxpane-java: Java9 fix
On Tue, May 01, 2018 at 03:47:53PM +0200, Felix Natter wrote: > hello Debian-java, > > I have added a patch against libjsyntaxpane-java which fixes a Java9 > issue, ported roughly from here: > > https://github.com/nordfalk/jsyntaxpane/commit/5fc75594f8bc4df6e8f7096d4a440490b768fd46 > (which has the same license as jsyntaxpane) > > > > The update is here: > https://salsa.debian.org/java-team/libjsyntaxpane-java > > Could someone please sponsor this? Hi Felix, Uploaded and tagged. Cheers, tony signature.asc Description: PGP signature
Re: Import git repo from alioth to salsa
Am 01.05.2018 um 23:35 schrieb Emmanuel Bourg: > Le 01/05/2018 à 23:21, Markus Koschany a écrit : > >> apt source yourpackage ? > > This doesn't give a Git working copy. The command git clone will give you a working copy. You can also use git clone g...@salsa.debian.org:java-team/yourpackagegit.git if you prefer to have all variables set correctly right from the start. In addition there is also gbp clone which will automatically checkout master, upstream and pristine-tar branch in one go. This is usually all I need to work from. Maybe this is simply a matter of different work flows but surely not a reason why VCS fields in debian/control fields are required. You can also call both commands in a script with the source package name as a parameter. >> Seriously I can write you a little shell script that does all that for >> you too. If this is the only _real_ blocker, I'm more than happy to do that. > > We'll probably also want to preserve the links to the VCS on > tracker.debian.org. > > I think the right plan would be to get #897227 implemented, and then > update debcheckout to use the overridden values from tracker.debian.org. Yes, that's certainly a bonus but not a real blocker for me because very soon all source packages, including the old SVN repos, will be pushed to salsa.debian.org. Now we have a uniform address space which is easy to remember. Not really a show stopper for a handful of regular contributors IMO. signature.asc Description: OpenPGP digital signature
Re: Import git repo from alioth to salsa
Le 01/05/2018 à 23:21, Markus Koschany a écrit : > apt source yourpackage ? This doesn't give a Git working copy. > Seriously I can write you a little shell script that does all that for > you too. If this is the only _real_ blocker, I'm more than happy to do that. We'll probably also want to preserve the links to the VCS on tracker.debian.org. I think the right plan would be to get #897227 implemented, and then update debcheckout to use the overridden values from tracker.debian.org.
Re: Import git repo from alioth to salsa
Am 01.05.2018 um 23:17 schrieb Emmanuel Bourg: > Le 01/05/2018 à 22:54, Markus Koschany a écrit : > >> debcheckout https://salsa.debian.org/java-team/yourpackage ? >> >> I don't understand why you would need such a tool that simply calls >> >> git clone >> >> though... > > It also pulls the upstream tarball and the .dsc of the latest upload. apt source yourpackage ? Seriously I can write you a little shell script that does all that for you too. If this is the only _real_ blocker, I'm more than happy to do that. signature.asc Description: OpenPGP digital signature
Re: Import git repo from alioth to salsa
Le 01/05/2018 à 22:54, Markus Koschany a écrit : > debcheckout https://salsa.debian.org/java-team/yourpackage ? > > I don't understand why you would need such a tool that simply calls > > git clone > > though... It also pulls the upstream tarball and the .dsc of the latest upload.
Re: Import git repo from alioth to salsa
Am 01.05.2018 um 22:49 schrieb Emmanuel Bourg: > Le 01/05/2018 à 21:18, Markus Koschany a écrit : > >> I have tried to discuss this on debian-devel but as usual there is >> always someone who strongly disagrees, mostly those people who update >> five packages per year. In my opinion there is no need to convince >> everyone. It's completely fine if they want to keep their VCS fields. >> I'm talking about a pragmatical decision for one team. > > I use debcheckout a lot to fetch the packages I work on, and AFAIK it > relies on the Vcs-* fields. I don't mind dropping the Vcs-* fields in > our packages but only after this tool is updated to use an alternate > source of repository URLs. debcheckout https://salsa.debian.org/java-team/yourpackage ? I don't understand why you would need such a tool that simply calls git clone though... signature.asc Description: OpenPGP digital signature
Re: Import git repo from alioth to salsa
Le 01/05/2018 à 21:18, Markus Koschany a écrit : > I have tried to discuss this on debian-devel but as usual there is > always someone who strongly disagrees, mostly those people who update > five packages per year. In my opinion there is no need to convince > everyone. It's completely fine if they want to keep their VCS fields. > I'm talking about a pragmatical decision for one team. I use debcheckout a lot to fetch the packages I work on, and AFAIK it relies on the Vcs-* fields. I don't mind dropping the Vcs-* fields in our packages but only after this tool is updated to use an alternate source of repository URLs. Emmanuel Bourg
Re: Import git repo from alioth to salsa
Le 30/04/2018 à 22:02, Giovanni Mascellani a écrit : > BTW, this recalls me that libjgrapht0.8 (which is my only package still > on svn) is probably in the need of some dust removal. Debian also ships > libjgrapht0.6 as a separate source package. Both are terribly old, since > upstream has released 1.1.0. However, I am a bit unsure on how to handle > this situation: I suggest starting from scratch with a new unversioned jgrapht package containing the latest upstream release. The reverse dependencies of the versions 0.6 and 0.8 can later be updated to use the latest version if necessary. > I also have a similar problem with libstax2-api-java and libwoodstox-java. What is the issue with these package? Emmanuel Bourg
Re: Import git repo from alioth to salsa
Le 30/04/2018 à 21:20, Markus Koschany a écrit : > I believe we shouldn't panic about this. Do you have a list with names > of those packages? I can clone and import them into a single Git > repository (todo-subversion) ? and when we have time and there is a need > to we can convert them into proper single Git repositories. We can get the list of packages still in SVN from the DDPO [1] after keeping only the packages in unstable and sorting by VCS. This gives the list below. As I understand the SVN repository will be made available as an archive. If we aren't able to convert the remaining packages in time we can rebuild a SVN server somewhere based on the archive and convert the packages later. asm3 boilerpipe c3p0 colorpicker fontchooser jama jardiff jcm jline kunststoff libajaxtags-java libbasicplayer-java libbsf-java libcobra-java libcommons-discovery-java libcommons-el-java libcommons-launcher-java libezmorph-java libflexdock-java libfonts-java libformula libisfreetype-java libisrt-java libjamon-java libjazzy-java libjcalendar-java libjcip-annotations-java libjdepend-java libjdom1-java libjdom2-java libjemmy2-java libjgrapht0.6-java libjgrapht0.8-java libjgraphx-java libjhlabs-filters-java libjlayer-java libjmac-java libjorbis-java libjrosetta-java liblastfm-java libloader libmp3spi-java libpdfrenderer-java libpixie-java libsimple-validation-java libswarmcache-java libswingx1-java libvorbisspi-java libxmpcore-java libyanfs-java mockobjects netbeans-cvsclient opencsv plexus-utils simple-xml slashtime stringtemplate swing-layout tagsoup werken.xpath xmlbeans xom Emmanuel Bourg [1] https://qa.debian.org/developer.php?login=pkg-java-maintain...@lists.alioth.debian.org
Re: Import git repo from alioth to salsa
Hi, Am 01.05.2018 um 20:31 schrieb Giovanni Mascellani: > Hi, > > Il 29/04/2018 23:13, Markus Koschany ha scritto: >> Let's remove all VCS fields from all our packages. Those fields are >> optional and not required. We simply use conventions. All packages are >> maintained in Git at salsa.debian.org. Period. > > In line of principle I agree that some package meta information like > Vcs-* and others should be maintained in databases that are independent > of the specific .dsc packages and should not require an upload to be > updated. However, I also personally value homogeneity among Debian > packages, a value so rare that I actually would think twice before > dispersing it. Use different conventions with respect to anything else > make contributions more difficult and makes some tools less useful or > even useless. The reality is there is no homogeneity in regards with VCS fields in Debian. They are completely optional. Some people don't use them at all, some are still stuck with http://git.debian.org addresses, then we have http|https://anonscm.debian.org or some random github/gitlab address. Some links are broken for years. I know because I have changed this in hundreds of packages before. I don't see the technical merit of those fields if all you have to remember is: the tool is called git and your source package name. git clone https://salsa.debian.org/java-team/myawesomepackage It is a misbelief that contributions would be more difficult without optional values like VCS fields in debian/control. On the contrary the work flow would become simpler and less repetitive. No longer updating VCS or Uploader fields for 1000+ packages. Though our answer to more boilerplate is to create more tools to deal with it. Instead of simplicity we force contributors to add and maintain even more information. > So, unless the proposal is about pushing for a general acceptance of > this change in Debian and about updating somewhat systematically all the > available tools, I personally disagree with it. I have tried to discuss this on debian-devel but as usual there is always someone who strongly disagrees, mostly those people who update five packages per year. In my opinion there is no need to convince everyone. It's completely fine if they want to keep their VCS fields. I'm talking about a pragmatical decision for one team. Regards, Markus signature.asc Description: OpenPGP digital signature
Re: Import git repo from alioth to salsa
Hi, Il 29/04/2018 23:13, Markus Koschany ha scritto: > Let's remove all VCS fields from all our packages. Those fields are > optional and not required. We simply use conventions. All packages are > maintained in Git at salsa.debian.org. Period. In line of principle I agree that some package meta information like Vcs-* and others should be maintained in databases that are independent of the specific .dsc packages and should not require an upload to be updated. However, I also personally value homogeneity among Debian packages, a value so rare that I actually would think twice before dispersing it. Use different conventions with respect to anything else make contributions more difficult and makes some tools less useful or even useless. So, unless the proposal is about pushing for a general acceptance of this change in Debian and about updating somewhat systematically all the available tools, I personally disagree with it. Just my 2 cents, fully aware that my participation in this team is tangential at its best. Giovanni. -- Giovanni Mascellani Postdoc researcher - Université Libre de Bruxelles
libjsyntaxpane-java: Java9 fix
hello Debian-java, I have added a patch against libjsyntaxpane-java which fixes a Java9 issue, ported roughly from here: https://github.com/nordfalk/jsyntaxpane/commit/5fc75594f8bc4df6e8f7096d4a440490b768fd46 (which has the same license as jsyntaxpane) Here are the changes: libjsyntaxpane-java (0.9.6~r156-7) unstable; urgency=medium * Fix java 9 problem (ported from https://github.com/nordfalk/jsyntaxpane) * Patch out pom.xml to avoid maven build * Use debhelper compat level 11 * Add myself to Uploaders: * Declare conformance with standards-version 4.1.4 * Update Vcs-* to point to salsa * Overide bad-jar-name and obsolete-url-in-packaging lintians * Ignore embedded-javascript-library lintian for javadoc output for now, see #883981 -- Felix Natter Tue, 24 Apr 2018 19:43:37 +0200 The update is here: https://salsa.debian.org/java-team/libjsyntaxpane-java Could someone please sponsor this? Thanks and Best Regards, -- Felix Natter debian/rules!
Re: Import git repo from alioth to salsa
Am 29.04.2018 um 23:13 schrieb Markus Koschany:
[...]
> I suggest the following:
>
> Let's remove all VCS fields from all our packages. Those fields are
> optional and not required. We simply use conventions. All packages are
> maintained in Git at salsa.debian.org. Period. The address space always
> looks like
>
> https://salsa.debian.org/java-team/${SourcePackageName}
>
> I intend to file bugs against tracker.debian.org tomorrow and request
> two new features.
[...]
FTR: Those feature requests are tracked now as
https://bugs.debian.org/897225
https://bugs.debian.org/897227
signature.asc
Description: OpenPGP digital signature
Re: Push rights for salsa/java-team
Markus Koschany writes: > Hi Felix, > > Am 01.05.2018 um 13:57 schrieb Felix Natter: > [...] >> Can I (fnatter-guest) be added to team-java, or did I do something >> wrong? > > Sure, please request membership at salsa.debian.org and I will add you > to the team. Done, thank you. -- Felix Natter debian/rules!
Re: Push rights for salsa/java-team
Hi Felix, Am 01.05.2018 um 13:57 schrieb Felix Natter: [...] > Can I (fnatter-guest) be added to team-java, or did I do something > wrong? Sure, please request membership at salsa.debian.org and I will add you to the team. Cheers, Markus signature.asc Description: OpenPGP digital signature
Push rights for salsa/java-team
hello Debian-java, after having added my ssh key, I get this git url in gitlab: g...@salsa.debian.org:java-team/libjsyntaxpane-java.git When trying to push, I get this message: $ git push Enter passphrase for key '/home/felix/.ssh/id_rsa': GitLab: You are not allowed to push code to this project. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Can I (fnatter-guest) be added to team-java, or did I do something wrong? Thanks and Best Regards, -- Felix Natter debian/rules!
Bug#897298: O: libjfreechart-java
Package: wnpp Severity: normal Hello, I'm hereby orphaning the libjfreechart-java package. Although it is technically team-maintained under the debian java team, no uploader (including myself) has been active for ages, it is better to mark it as orphaned. Kind regards, Vincent
Bug#897295: O: java-wrappers -- wrappers for java executables
Package: wnpp Severity: normal Hello, I'm hereby orphaning the java-wrappers package. It is technically maintained by the debian java team, but I am the sole uploader, so I prefer to mark it as orphaned as of now. It is widely used, but does not need much maintenance, since it seems to "just do the job". Someone from the java team should probably step up and officially take over the maintenance. Kind regards, Vincent The package description is: Wrapper script facilities for java executables. . This package can be used by packagers of java programs to provide java runtime detection, jar lookup and a consistent user interface (debugging, environment variables).
