Re: gbp import-orig has defeated me

2018-10-01 Thread Steve Robbins
On Monday, October 1, 2018 10:35:01 PM CDT Shengjing Zhu wrote:

> I think you have configured your git to auto convert the line ending
> when commit.
> 
> In the pristine-tar tarball,
> $ file googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln
> googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode
> (with BOM) text, with CRLF line terminators
> 
> In your master and upstream branch
> $ file googletest-1.8.1/googlemock/msvc/2005/gmock.sln
> googletest-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode (with BOM)
> tex
> 
> I import the orig tarball in my env, these files are CRLF in my git tree.
> I'm not sure what git config influences this, but maybe core.eol,
> core.autocrlf, core.safecrlf.
> I'm just using the default values, at least my `git config --list`
> output didn't show anything related.

I think you've pointed in the right direction.  I have started reading through 
https://adaptivepatchwork.com/2012/03/01/mind-the-end-of-your-line/ 
and discovered that I have one non-default: core.autocrlf=input.  According to 
the article, this is recommended for linux.  Maybe that's not true; or maybe I 
just need to generate a .gitattributes file?  I'll try that tomorrow.

Thanks,
-Steve





Re: gbp import-orig has defeated me

2018-10-01 Thread Fritz Reichwald

Hi steve,
>  git init
>  gbp import-orig --pristine-tar ../googletest_1.8.1.orig.tar.gz
>  ... copy debian dir from the salsa repo & commit ...
>  gbp buildpackage
have you added a new changelog entry after importing the new upstream
tarball?

e.g by executing 'dch -v 1.8.1-1'

Regards
Fritz


signature.asc
Description: PGP signature


Re: gbp import-orig has defeated me

2018-10-01 Thread Shengjing Zhu
On Tue, Oct 2, 2018 at 10:51 AM Steve Robbins  wrote:
>
> Hi,
>
> I would like to update the googletest salsa repo [1] with upstream 1.8.1.  So
> I downloaded the tarball and ran "gbp import-orig" on it.  That appeared to
> work, but "gbp buildpackage" fails with
>
>   dpkg-source: error: aborting due to unexpected upstream changes ...
>
> from the diffs, my guess is there is some line ending issue.  I've pushed
> everything to salsa repo.  Hoping someone here can take a look and point me in
> the right direction.
>

I think you have configured your git to auto convert the line ending
when commit.

In the pristine-tar tarball,
$ file googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln
googletest-release-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode
(with BOM) text, with CRLF line terminators

In your master and upstream branch
$ file googletest-1.8.1/googlemock/msvc/2005/gmock.sln
googletest-1.8.1/googlemock/msvc/2005/gmock.sln: UTF-8 Unicode (with BOM) tex

I import the orig tarball in my env, these files are CRLF in my git tree.
I'm not sure what git config influences this, but maybe core.eol,
core.autocrlf, core.safecrlf.
I'm just using the default values, at least my `git config --list`
output didn't show anything related.


-- 
Shengjing Zhu



gbp import-orig has defeated me

2018-10-01 Thread Steve Robbins
Hi,

I would like to update the googletest salsa repo [1] with upstream 1.8.1.  So 
I downloaded the tarball and ran "gbp import-orig" on it.  That appeared to 
work, but "gbp buildpackage" fails with

  dpkg-source: error: aborting due to unexpected upstream changes ...

from the diffs, my guess is there is some line ending issue.  I've pushed 
everything to salsa repo.  Hoping someone here can take a look and point me in 
the right direction.

For good measure, I tried creating a brand new git repo to import the tarball, 

  git init
  gbp import-orig --pristine-tar ../googletest_1.8.1.orig.tar.gz
  ... copy debian dir from the salsa repo & commit ...
  gbp buildpackage

and ended up in the same situation!

Thanks,
-Steve

[1] https://salsa.debian.org/debian/googletest





Re: Q: Best practice for maintainer address with "alioth"

2018-10-01 Thread Alex Muntada
Hi Ted,

> Is there something official from the lists.d.o maintainers
> about what their preferences should be?

I found some pointers in «Alioth: the future of mailing lists»:
https://lists.debian.org/debian-devel-announce/2017/09/msg4.html

Hope this helps,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature


Re: Q: Best practice for maintainer address with "alioth"

2018-10-01 Thread Theodore Y. Ts'o
On Mon, Oct 01, 2018 at 09:59:59AM +0200, Alex Muntada wrote:
> Hi Paul,
> 
> > As I understand it, alioth-lists.d.n is an interim location
> 
> This is correct, when asked what to do we're encouraging people
> to keep the former lists.alioth.d.o addresses.
> 
> > and folks should migrate to either a lists.d.o list, a
> > tracker.d.o team or pkgn...@packages.debian.org.
> 
> FWIW, we're fine with maintainers/teams migrating to lists.d.o,
> tracker.d.o or packages.d.o. Just let us know if any alioth list
> isn't needed anymore ;)

There was at least some impression that the lists.d.o maintainers
weren't enthusiastic of absorbing a large number of team maintainer
addresses as lists.  This came up when I was asking if we should
migrate filesystems-de...@lists.alioth.debian.org to list.d.o, and one
of the primary maintainers on filesystems-devel thought that was
frowned upon.

Is there something official from the lists.d.o maintainers about what
their preferences should be?

Thanks,

- Ted



Re: Q: Best practice for maintainer address with "alioth"

2018-10-01 Thread Alex Muntada
Hi Holger,

> On Mon, Oct 01, 2018 at 09:59:59AM +0200, Alex Muntada wrote:
> > > As I understand it, alioth-lists.d.n is an interim location
> > This is correct, when asked what to do we're encouraging people
> > to keep the former lists.alioth.d.o addresses.
>  
> I find this quite confusing, because this way its not clear
> whether an alioth.debian.org mail address is still working or
> whether something needs an update :/

The whole point of our taking over the alioth lists service
was that maintainers do not need to update maintainers field
(e.g. several thousand packages for perl packages only).

Now imagine that alioth lists service was eventually taken over
by DSA and the new canonical domain became debian.org again.
Should maintainers update their packages again? That's what we
want to avoid, hence suggesting to keep lists.alioth.d.o instead
of alioth-lists.d.n.

BTW, you can take a look at the Mailman list of lists to find out
if some list was migrated:

https://lists.alioth.debian.org/mailman/listinfo
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo
(linked from alioth-lists.d.n home page)

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature


Re: Q: Best practice for maintainer address with "alioth"

2018-10-01 Thread Holger Levsen
On Mon, Oct 01, 2018 at 09:59:59AM +0200, Alex Muntada wrote:
> > As I understand it, alioth-lists.d.n is an interim location
> This is correct, when asked what to do we're encouraging people
> to keep the former lists.alioth.d.o addresses.
 
I find this quite confusing, because this way its not clear whether an
alioth.debian.org mail address is still working or whether something
needs an update :/


-- 
cheers,
Holger

---
   holger@(debian|reproducible-builds|layer-acht).org
   PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C


signature.asc
Description: PGP signature


Re: Q: Best practice for maintainer address with "alioth"

2018-10-01 Thread Alex Muntada
Hi Paul,

> As I understand it, alioth-lists.d.n is an interim location

This is correct, when asked what to do we're encouraging people
to keep the former lists.alioth.d.o addresses.

> and folks should migrate to either a lists.d.o list, a
> tracker.d.o team or pkgn...@packages.debian.org.

FWIW, we're fine with maintainers/teams migrating to lists.d.o,
tracker.d.o or packages.d.o. Just let us know if any alioth list
isn't needed anymore ;)

Cheers,
Alex

--
  ⢀⣴⠾⠻⢶⣦⠀
  ⣾⠁⢠⠒⠀⣿⡁  Alex Muntada 
  ⢿⡄⠘⠷⠚⠋   Debian Developer - log.alexm.org
  ⠈⠳⣄



signature.asc
Description: PGP signature