Re: Import git repo from alioth to salsa

2018-05-04 Thread Emmanuel Bourg
Le 04/05/2018 à 15:40, Markus Koschany a écrit :

> That's true. I didn't check whether the Git repository was up-to-date,
> only if it existed. By looking at colorpicker I can see your suspicion
> is confirmed. I would just import the latest version with gbp import-dsc
> though and be done with it.

I'd rather preserve the history, don't bother I'll reimport them.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-05-04 Thread Markus Koschany


Am 04.05.2018 um 15:26 schrieb Emmanuel Bourg:
> Le 04/05/2018 à 11:48, Markus Koschany a écrit :
> 
>> I have converted all these packages and moved them to salsa.
> 
> Thank you!
> 
>> libjgraphx-java, libjrosetta-java, xmlbeans, c3p0 and colorpicker did
>> already exist.
> 
> Do you know if the existing repositories were up to date? The SVN
> repository may have more changes if the Git repository wasn't used by
> lack of upload with the updated Vcs-* fields.

That's true. I didn't check whether the Git repository was up-to-date,
only if it existed. By looking at colorpicker I can see your suspicion
is confirmed. I would just import the latest version with gbp import-dsc
though and be done with it.

>> The only step left now is to import the current (and
>> maybe stable/olstable) packages into Git when someone works on them
>> again. Git-buildpackage and gbp import-dsc come in handy for that.
> 
> Do you mean the packages removed from unstable, still in SVN, and never
> migrated to Git?

The SVN->Git conversion gives us only the debian directory with all its
changes and tags, provided releases were tagged. I usually import the
complete package with all source code afterwards. I haven't done this
automatically because sometimes you want to import older releases as
well not only the latest one and I thought I leave that decision to the
next uploader of the package. In some cases it may even make sense to
just commit the debian directory because Git is not very good at
handling large binary files (images/sounds/videos) but this use case is
very rare for the Java team.

Markus



signature.asc
Description: OpenPGP digital signature


Re: Import git repo from alioth to salsa

2018-05-04 Thread Emmanuel Bourg
Le 04/05/2018 à 11:48, Markus Koschany a écrit :

> I have converted all these packages and moved them to salsa.

Thank you!

> libjgraphx-java, libjrosetta-java, xmlbeans, c3p0 and colorpicker did
> already exist.

Do you know if the existing repositories were up to date? The SVN
repository may have more changes if the Git repository wasn't used by
lack of upload with the updated Vcs-* fields.


> The only step left now is to import the current (and
> maybe stable/olstable) packages into Git when someone works on them
> again. Git-buildpackage and gbp import-dsc come in handy for that.

Do you mean the packages removed from unstable, still in SVN, and never
migrated to Git?

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-05-04 Thread Markus Koschany
Am 01.05.2018 um 22:07 schrieb Emmanuel Bourg:
[...]
>   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

I have converted all these packages and moved them to salsa.
libjgraphx-java, libjrosetta-java, xmlbeans, c3p0 and colorpicker did
already exist. The only step left now is to import the current (and
maybe stable/olstable) packages into Git when someone works on them
again. Git-buildpackage and gbp import-dsc come in handy for that.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Re: Import git repo from alioth to salsa

2018-05-02 Thread Giovanni Mascellani
Hi,

Il 01/05/2018 22:24, Emmanuel Bourg ha scritto:
> 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.

Ok, thanks.

>> I also have a similar problem with libstax2-api-java and libwoodstox-java.
> 
> What is the issue with these package?

I have packaged in experimental new upstream releases, but I am not sure
on how to handle the little transition associated to them, not having
ever done such a thing. Upstream said that the new version should be
mostly compatible with the old one, except that the maven group id has
changed (but the namespaces did not).

So I guess what should happen is that I upload the new version, then go
through the reverse dependencies and file bugs/patches or directly
upload a new version for team maintained packages. But what if at some
point a reverse dependency does not build anymore with the new woodstox?
Should I first test rebuilding everything on my computer with the new
woodstox?

When I uploaded the packages to experimental, I emailed all the reverse
dependencies to ask them to test them, but noone answered. Then I forgot
about that thing until now.

So basically the questions boil down to: what is the best way to handle
a small transition for Java packages, trying to cause the less
disruption and surprise possible, but not depending on the
responsiveness of too many people?

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



Re: Import git repo from alioth to salsa

2018-05-01 Thread Markus Koschany

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

2018-05-01 Thread Emmanuel Bourg
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

2018-05-01 Thread Markus Koschany


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

2018-05-01 Thread 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.



Re: Import git repo from alioth to salsa

2018-05-01 Thread Markus Koschany


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

2018-05-01 Thread 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.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-05-01 Thread Emmanuel Bourg
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

2018-05-01 Thread Emmanuel Bourg
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

2018-05-01 Thread Markus Koschany
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

2018-05-01 Thread 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.

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



Re: Import git repo from alioth to salsa

2018-05-01 Thread Markus Koschany


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: Import git repo from alioth to salsa

2018-04-30 Thread Giovanni Mascellani
Hi,

Il 30/04/2018 19:22, Emmanuel Bourg ha scritto:
> I've moved the geogebra repository, could you check if it's ok?
> 
>   https://salsa.debian.org/java-team/geogebra

It is, thank you!

> I think I'll just complete the mass migration myself, but I'll need help
> afterward to check if everything is ok (like missing or empty
> repositories). I'll also need help to migrate the ~60 packages still in
> Subversion.

I can help to check, at least for my packages. I can also check others,
but maybe will not be as good as spotting problems.

For svn, I think I can help, although if you already have a list (as
Markus asked) that would help.

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 do not know much the API remained stable between 0.6,
0.6 and 1.1.0 and thus how to manage the update causing the least
inconvenience possible. I also have a similar problem with
libstax2-api-java and libwoodstox-java. Maybe it is better to wait for
the end of the migration, but if someone could at some point enlighten
me on the best practices, I would be grateful.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



Re: Import git repo from alioth to salsa

2018-04-30 Thread Emmanuel Bourg
Le 30/04/2018 à 13:42, Giovanni Mascellani a écrit :

> Thank you very much for working on this migration. Is manual migration
> of one's packages helpful, neutral or disruptive? I would like to upload
> geogebra (and maybe other packages), and would take the chance to
> migrate it and update Vcs-* tags, but I can wait for the migration to
> finish if this would disturb your scripts.

Hi Giovanni,

I've moved the geogebra repository, could you check if it's ok?

  https://salsa.debian.org/java-team/geogebra

I think I'll just complete the mass migration myself, but I'll need help
afterward to check if everything is ok (like missing or empty
repositories). I'll also need help to migrate the ~60 packages still in
Subversion.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-04-30 Thread Giovanni Mascellani
Dear Emmanuel,

Il 30/04/2018 09:25, Emmanuel Bourg ha scritto:
> Yes, I plan to do that once I'm confident the migration worked properly.

Thank you very much for working on this migration. Is manual migration
of one's packages helpful, neutral or disruptive? I would like to upload
geogebra (and maybe other packages), and would take the chance to
migrate it and update Vcs-* tags, but I can wait for the migration to
finish if this would disturb your scripts.

Thanks, Giovanni.
-- 
Giovanni Mascellani 
Postdoc researcher - Université Libre de Bruxelles



Re: Import git repo from alioth to salsa

2018-04-30 Thread Emmanuel Bourg
Le 29/04/2018 à 04:00, Paul Wise a écrit :

> I'd suggest deleting the migrated repositories so that DSA doesn't
> have to store a copy of them in the alioth archive forever.

Yes, I plan to do that once I'm confident the migration worked properly.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-04-29 Thread Paul Wise
On Mon, Apr 30, 2018 at 1:18 AM, tony mancill wrote:

> I realize that this isn't the right forum, so please redirect
> appropriately for follow-ups, but do you know whether there is any plan
> for a redirect host/service for the alioth repos?  The BTS is full of
> links commits in Alioth, so the migration will leave all of these links
> broken.

The Alioth/Salsa folks are providing a redirector:

https://salsa.debian.org/salsa/AliothRewriter

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Import git repo from alioth to salsa

2018-04-29 Thread Markus Koschany
Am 29.04.2018 um 22:33 schrieb Thorsten Glaser:
[...]
> As far as I’m informed, due to the massively different structure
> of GitLab, such a service cannot be provided with reasonable or
> even somewhat unreasonable effort, and there *were* tons of URL
> redirection layers already anyway, so they decided on a clean cut.
> 
> I’m afraid you will have to somehow change all these URLs in the
> place where they’re written.

It is possible to redirect alioth URLs to salsa. For instance when I
click on the browser link of armagetronad I will be redirected to
salsa.debian.org now. This is implemented for all packages maintained by
the games team.

https://anonscm.debian.org/cgit/pkg-games/armagetronad.git

Creating a similar mapping for pkg-java should be doable.

I'm also not happy with the current approach of changing thousands of
VCS URLs again. It was also made clear that we have to go through the
same renaming again should we ever move away from Gitlab.

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. The first one is the ability to create custom fields
so that we could make it clear that java-team packages are maintained at
salsa.debian.org. (more use cases are conceivable)

The other one is the ability to override the value of a certain field,
e.g. the VCS field, because tracker.debian.org already knows what
packages belong to a certain team, so it would become trivial to
autogenerate VCS links in the future. No matter what the next service is
called it would be a matter of minutes instead of days to change all VCS
links and make them immediately visible to all users. At the moment we
have lots of broken links anyway and tracker.debian.org seems to me the
best option to maintain such information in an efficient way.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature


Re: Import git repo from alioth to salsa

2018-04-29 Thread Thorsten Glaser
Hi tony,

> On Sun, Apr 29, 2018 at 10:00:58AM +0800, Paul Wise wrote:

> > I'd suggest deleting the migrated repositories so that DSA doesn't
> > have to store a copy of them in the alioth archive forever.

in fact we were *requested* to do so by DSA, so we SHOULD comply.

> appropriately for follow-ups, but do you know whether there is any plan
> for a redirect host/service for the alioth repos?  The BTS is full of
> links commits in Alioth, so the migration will leave all of these links
> broken.

As far as I’m informed, due to the massively different structure
of GitLab, such a service cannot be provided with reasonable or
even somewhat unreasonable effort, and there *were* tons of URL
redirection layers already anyway, so they decided on a clean cut.

I’m afraid you will have to somehow change all these URLs in the
place where they’re written.

Disclaimer: I’m not happy with the entire move either (in fact,
I’ve moved my not otherwise maintained repos to another FusionForge
instance instead of to Salsa), just informing about what I seem to
recall we were told.

bye,
//mirabilos
-- 
Yes, I hate users and I want them to suffer.
-- Marco d'Itri on gmane.linux.debian.devel.general



Re: Import git repo from alioth to salsa

2018-04-29 Thread tony mancill
On Sun, Apr 29, 2018 at 10:00:58AM +0800, Paul Wise wrote:
> On Sat, Apr 28, 2018 at 4:48 AM, Emmanuel Bourg wrote:
> 
> > Thank you Tony. I was leaning toward such a solution, but considering
> > that Alioth is going to be killed and the repositories archived and
> > moved offline there is no real point disabling the migrated
> > repositories. I think I'll just move them under a special directory (for
> > example /srv/git.debian.org/git/pkg-java/migrated).
> 
> I'd suggest deleting the migrated repositories so that DSA doesn't
> have to store a copy of them in the alioth archive forever.

Hi Paul,

I realize that this isn't the right forum, so please redirect
appropriately for follow-ups, but do you know whether there is any plan
for a redirect host/service for the alioth repos?  The BTS is full of
links commits in Alioth, so the migration will leave all of these links
broken.

It is for this reason that I have been using the migration scripts + the
disable hooks.  It gives users a pointer of sorts.  (For example, see
[1].)  My concern is that if I delete the repo, the redirect crumbtrail
will be gone forever.

Thanks,
tony

[1] https://anonscm.debian.org/cgit/collab-maint/bobcat


signature.asc
Description: PGP signature


Re: Import git repo from alioth to salsa

2018-04-28 Thread Paul Wise
On Sat, Apr 28, 2018 at 4:48 AM, Emmanuel Bourg wrote:

> Thank you Tony. I was leaning toward such a solution, but considering
> that Alioth is going to be killed and the repositories archived and
> moved offline there is no real point disabling the migrated
> repositories. I think I'll just move them under a special directory (for
> example /srv/git.debian.org/git/pkg-java/migrated).

I'd suggest deleting the migrated repositories so that DSA doesn't
have to store a copy of them in the alioth archive forever.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise



Re: Import git repo from alioth to salsa

2018-04-28 Thread Emmanuel Bourg
On 27/04/2018 22:48, Emmanuel Bourg wrote:

> I think I'll just move them under a special directory (for
> example /srv/git.debian.org/git/pkg-java/migrated).

I migrated a first batch of ~100 Maven related packages. Moving the
repositories on Alioth wasn't a great idea since the import process on
Salsa is asynchronous. The migration script moved the repositories
before the import was complete and I had to fix about half of the
migrated repositories manually.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-04-28 Thread Emmanuel Bourg
On 19/04/2018 21:52, tony mancill wrote:

> Regarding item (1), perhaps you can leverage the disable-repository
> script [4]?  I used the migration scripts from that repo for non-team
> migrations with good results.

Thank you Tony. I was leaning toward such a solution, but considering
that Alioth is going to be killed and the repositories archived and
moved offline there is no real point disabling the migrated
repositories. I think I'll just move them under a special directory (for
example /srv/git.debian.org/git/pkg-java/migrated).

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-04-19 Thread tony mancill
On Mon, Apr 16, 2018 at 10:16:07PM +0200, Emmanuel Bourg wrote:
> Le 16/04/2018 à 20:30, Andreas Tille a écrit :
> 
> > I noticed that under
> > 
> >https://salsa.debian.org/java-team/
> > 
> > some packages are migrated but the mass of packages is on Alioth as far
> > as I can see.  Is there any migration date?  I'm just asking since Alioth
> > will be switched of in about two weeks.
> 
> Hi Andreas,
> 
> Markus has created/migrated some packages there, and I've used
> java-package as a test repository to experiment with the migration.
> 
> So far I've prepared a migration script [1] that does the following:
> - Imports the repository from Alioth to Salsa
> - Disables the unnecessary Salsa features (issues, snippets, wiki, jobs)
> - Configures the hook tagging pending bugs in the BTS
> - Configures the hook notifying the #debian-java IRC channel on events
> (with KGB)
> - Configures the Gitlab's emails-on-push hook (targeting
> pkg-java-comm...@lists.alioth.debian.org and dispa...@tracker.debian.org)
> 
> There is also a repository creation script [2] that can be used instead
> of /srv/git.debian.org/git/pkg-java/setup-repository on Alioth.
> 
> The migration script is still missing a few things :
> 1. It doesn't disable the Alioth repository after the migration
> 2. The emails-on-push hook is incomplete because it only notifies about
> pushes and not about other events like comments and merge requests. I
> started working on such a hook [3] but it isn't ready yet. It's probably
> better to start the migration without this hook and add it latter to the
> repositories.
> 
> Assuming I complete the script this week we can consider moving the
> repositories next week.
> 
> Emmanuel Bourg
> 
> [1]
> https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/migrate-to-salsa
> [2]
> https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/setup-salsa-repository
> [3] https://salsa.debian.org/salsa/webhook/merge_requests/6

Hi Emmanuel,

Regarding item (1), perhaps you can leverage the disable-repository
script [4]?  I used the migration scripts from that repo for non-team
migrations with good results.

Cheers,
tony

[4] 
https://salsa.debian.org/anarcat/alioth-migration/blob/master/disable-repository


signature.asc
Description: PGP signature


Re: Import git repo from alioth to salsa

2018-04-16 Thread Emmanuel Bourg
Le 16/04/2018 à 20:30, Andreas Tille a écrit :

> I noticed that under
> 
>https://salsa.debian.org/java-team/
> 
> some packages are migrated but the mass of packages is on Alioth as far
> as I can see.  Is there any migration date?  I'm just asking since Alioth
> will be switched of in about two weeks.

Hi Andreas,

Markus has created/migrated some packages there, and I've used
java-package as a test repository to experiment with the migration.

So far I've prepared a migration script [1] that does the following:
- Imports the repository from Alioth to Salsa
- Disables the unnecessary Salsa features (issues, snippets, wiki, jobs)
- Configures the hook tagging pending bugs in the BTS
- Configures the hook notifying the #debian-java IRC channel on events
(with KGB)
- Configures the Gitlab's emails-on-push hook (targeting
pkg-java-comm...@lists.alioth.debian.org and dispa...@tracker.debian.org)

There is also a repository creation script [2] that can be used instead
of /srv/git.debian.org/git/pkg-java/setup-repository on Alioth.

The migration script is still missing a few things :
1. It doesn't disable the Alioth repository after the migration
2. The emails-on-push hook is incomplete because it only notifies about
pushes and not about other events like comments and merge requests. I
started working on such a hook [3] but it isn't ready yet. It's probably
better to start the migration without this hook and add it latter to the
repositories.

Assuming I complete the script this week we can consider moving the
repositories next week.

Emmanuel Bourg

[1]
https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/migrate-to-salsa
[2]
https://anonscm.debian.org/cgit/pkg-java/pkg-java-scripts.git/tree/setup-salsa-repository
[3] https://salsa.debian.org/salsa/webhook/merge_requests/6



Re: Import git repo from alioth to salsa

2018-04-16 Thread Andreas Tille
Hi,

On Thu, 1 Feb 2018 Emmanuel Bourg wrote:
> I personally would prefer migrating all
> the repositories simultaneously, leaving only the packages still managed
> by Subversion on Alioth for a migration later.

I noticed that under

   https://salsa.debian.org/java-team/

some packages are migrated but the mass of packages is on Alioth as far
as I can see.  Is there any migration date?  I'm just asking since Alioth
will be switched of in about two weeks.

Kind regards

Andreas.

-- 
http://fam-tille.de



Re: Import git repo from alioth to salsa

2018-02-01 Thread Sebastiaan Couwenberg
On 02/02/2018 12:31 AM, gregor herrmann wrote:
> On Thu, 01 Feb 2018 17:13:53 +0100, Bas Couwenberg wrote:
> 
>>> Mehdi Dogguy wrote some scripts performing most of these operations [1],
>>> I'd like to assemble them into a unique script tailored for the Java
>>> team.
>> For the Debian GIS team I wrote similar scripts, see:
>>  https://lists.debian.org/debian-gis/2018/01/msg00023.html
> 
> Oh, that's in perl; nice :)
> You might be interested in GitLab::API::v4
> https://metacpan.org/pod/GitLab::API::v4
> packaged as libgitlab-api-v4-perl.

That wasn't packaged yet when I started, and currently not backported to
stretch, so I'll rely on plain LWP for the time being.

Kind Regards,

Bas



signature.asc
Description: OpenPGP digital signature


Re: Import git repo from alioth to salsa

2018-02-01 Thread gregor herrmann
On Thu, 01 Feb 2018 17:13:53 +0100, Bas Couwenberg wrote:

> > Mehdi Dogguy wrote some scripts performing most of these operations [1],
> > I'd like to assemble them into a unique script tailored for the Java
> > team.
> For the Debian GIS team I wrote similar scripts, see:
>  https://lists.debian.org/debian-gis/2018/01/msg00023.html

Oh, that's in perl; nice :)
You might be interested in GitLab::API::v4
https://metacpan.org/pod/GitLab::API::v4
packaged as libgitlab-api-v4-perl.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-   NP: Red Hot Chili Peppers: transcending


signature.asc
Description: Digital Signature


Re: Import git repo from alioth to salsa

2018-02-01 Thread Emmanuel Bourg
Le 01/02/2018 à 17:13, Bas Couwenberg a écrit :

> For the Debian GIS team I wrote similar scripts, see:
> 
>  https://lists.debian.org/debian-gis/2018/01/msg00023.html

Thank you for sharing! This will help.

Emmanuel Bourg



Re: Import git repo from alioth to salsa

2018-02-01 Thread Bas Couwenberg

On 2018-02-01 15:22, Emmanuel Bourg wrote:

Ideally I'd like to come up with a migration script that :
1. imports the repository to Salsa
2. configures the hook notifying pkg-java-maintainers on pushes
3. configures the hook notifying the #debian-java channel on IRC
4. configures the hook adding the pending tag to the BTS
5. disables the alioth repository with a pre-receive hook
6. disables the unused features of Gitlab (pipelines, wiki, snippets)
7. updates the Vcs-* fields
8. configures the alioth rewriter

Mehdi Dogguy wrote some scripts performing most of these operations 
[1],
I'd like to assemble them into a unique script tailored for the Java 
team.


For the Debian GIS team I wrote similar scripts, see:

 https://lists.debian.org/debian-gis/2018/01/msg00023.html

Kind Regards,

Bas



Re: Import git repo from alioth to salsa

2018-02-01 Thread Emmanuel Bourg
Le 01/02/2018 à 12:44, Hideki Yamane a écrit :

>  Can someone import git repos in alioth to salsa under java-team?
>  Use script with java-team ID (2588) like below with certain privilege 
>  would be fine.

Hi Hideki,

I started working on the migration to Salsa. This topic hasn't been
discussed with the team yet, but I personally would prefer migrating all
the repositories simultaneously, leaving only the packages still managed
by Subversion on Alioth for a migration later.

I imported the java-policy package to the java-team group on Salsa with
a script similar to yours, but that wasn't sufficient because the
post-receive hooks aren't preserved.

Ideally I'd like to come up with a migration script that :
1. imports the repository to Salsa
2. configures the hook notifying pkg-java-maintainers on pushes
3. configures the hook notifying the #debian-java channel on IRC
4. configures the hook adding the pending tag to the BTS
5. disables the alioth repository with a pre-receive hook
6. disables the unused features of Gitlab (pipelines, wiki, snippets)
7. updates the Vcs-* fields
8. configures the alioth rewriter

Mehdi Dogguy wrote some scripts performing most of these operations [1],
I'd like to assemble them into a unique script tailored for the Java team.

Emmanuel Bourg

[1] https://salsa.debian.org/mehdi/salsa-scripts



Import git repo from alioth to salsa

2018-02-01 Thread Hideki Yamane
Hi,

 Can someone import git repos in alioth to salsa under java-team?
 Use script with java-team ID (2588) like below with certain privilege 
 would be fine.


#!/bin/sh

set -eux

PROJECT="${1%.git}"
DESCRIPTION="$PROJECT packaging"
ALIOTH_URL="https://anonscm.debian.org/git;
ALIOTH_GROUP="pkg-java"
SALSA_URL="https://salsa.debian.org/api/v4;
SALSA_NAMESPACE="2588" # 2 is "debian"
SALSA_TOKEN="xxx"

curl -f "$SALSA_URL/projects?private_token=$SALSA_TOKEN" \
  --data 
"path=$PROJECT_id=$SALSA_NAMESPACE=$DESCRIPTION_url=$ALIOTH_URL/$ALIOTH_GROUP/$PROJECT=public"