Bug#858557: marked as done (RFS: golang-github-klauspost-reedsolomon/1.3-1~exp1 -- Reed-Solomon Erasure Coding in Go)

[Debian Bug Tracking System]

Your message dated Wed, 29 Mar 2017 02:05:31 +
with message-id 
and subject line golang-github-klauspost-reedsolomon_1.3-1~exp1_amd64.changes 
uploaded
has caused the Debian Bug report #858557,
regarding RFS: golang-github-klauspost-reedsolomon/1.3-1~exp1 -- Reed-Solomon 
Erasure Coding in Go
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
858557: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858557
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: normal
X-Debbugs-Cc: pkg-go-maintain...@lists.alioth.debian.org, fr...@debian.org,
daniel820...@gmail.com, rogershim...@gmail.com

Dear mentors,

I am looking for a sponsor for my package
"golang-github-klauspost-reedsolomon",
which is a dependency of another my package "golang-github-xtaci-kcp".

 * Package name: golang-github-klauspost-reedsolomon
   Version : 1.3-1~exp1
   Upstream Author : Klaus Post 
 * URL : https://github.com/klauspost/reedsolomon
 * License : MIT
   Section : devel

It builds those binary packages:

  golang-github-klauspost-reedsolomon-dev - Reed-Solomon Erasure Coding in
Go

To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/golang-github-klauspost-reedsolomon

  Alternatively, one can download the package with dget using this command:

dget -x
https://mentors.debian.net/debian/pool/main/g/golang-github-klauspost-reedsolomon/golang-github-klauspost-reedsolomon_1.3-1~exp1.dsc

or you can use git-buildpackage to build:
  gbp clone --pristine-tar
https://anonscm.debian.org/git/pkg-go/packages/golang-github-klauspost-reedsolomon.git
  cd golang-github-klauspost-reedsolomon
  git checkout mentors
  mk-build-deps --root-cmd sudo --install --tool "apt-get -o
Debug::pkgProblemResolver=yes --no-install-recommends"
  gbp buildpackage -uc -us --git-ignore-branch --git-pristine-tar

I also built this package on debomatic (amd64):

http://debomatic-amd64.debian.net/distribution#experimental/golang-github-klauspost-reedsolomon/1.3-1~exp1/buildlog

Changes since the last upload:
golang-github-klauspost-reedsolomon (1.3-1~exp1) experimental;
urgency=medium

  * New upstream 1.3
  * debian/control:
- Add myself as uploader.

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
--- End Message ---
--- Begin Message ---
Hi Roger.  Apologies for the delay - I meant to do this at the beginning of the 
week.

I've just uploaded the 1.3~exp1 version to Debian unstable.


Regards,

Tim.


signature.asc
Description: Message signed with OpenPGP using GPGMail
--- End Message ---

Bug#858800: RFS: xtrs/4.9d-1 [ITA]

[G. Branden Robinson]

On Tue, Mar 28, 2017 at 05:16:21PM -0700, Sean Whitton wrote:
> Hello Branden,
> 
> On Tue, Mar 28, 2017 at 05:28:25PM -0400, G. Branden Robinson wrote:
> > > You are very unlikely to get release team approval for this upload as it
> > > stands.  Given what you wrote in #511645, is your intention for xtrs to
> > > drop out of stretch, to be reintroduced in buster?
> > 
> > I've been making conservative (pessimistic) estimates about how fast I'd
> > be getting things done since I'm freshly back to the project after a
> > long absence.  There were and are best practices I need(ed) to get
> > caught up on.  I also couldn't be absolutely sure I'd get a sponsor
> > before the removal-from-testing date (scheduled for 11 April); I don't
> > know when I'll be able to get my new GPG key into the Debian keyring so
> > that I can upload under my own power[1], and so forth.  Finally, I don't
> > want to cause the release team any trouble.
> > 
> > So my goals were, in this order:
> > 1) Get the package suitable for unstable (which it wasn't); then
> > 2) Get the package suitable for testing.
> 
> Generally speaking, something shouldn't go into unstable unless it would
> also be suitable for testing (once deps and r-deps are also ready to
> migrate).

It'll be suitable for testing for Buster, that's for sure.  My bad luck
to return during a release freeze.

I'm interested in the least-effort solution (for other people) that
doesn't involve shipping a badly broken package in Stretch.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#858800: RFS: xtrs/4.9d-1 [ITA]

[Sean Whitton]

Hello Branden,

On Tue, Mar 28, 2017 at 05:28:25PM -0400, G. Branden Robinson wrote:
> > You are very unlikely to get release team approval for this upload as it
> > stands.  Given what you wrote in #511645, is your intention for xtrs to
> > drop out of stretch, to be reintroduced in buster?
> 
> I've been making conservative (pessimistic) estimates about how fast I'd
> be getting things done since I'm freshly back to the project after a
> long absence.  There were and are best practices I need(ed) to get
> caught up on.  I also couldn't be absolutely sure I'd get a sponsor
> before the removal-from-testing date (scheduled for 11 April); I don't
> know when I'll be able to get my new GPG key into the Debian keyring so
> that I can upload under my own power[1], and so forth.  Finally, I don't
> want to cause the release team any trouble.
> 
> So my goals were, in this order:
> 1) Get the package suitable for unstable (which it wasn't); then
> 2) Get the package suitable for testing.

Generally speaking, something shouldn't go into unstable unless it would
also be suitable for testing (once deps and r-deps are also ready to
migrate).

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#832941: marked as done (RFS: 4pane/4.0-1 [ITP])

[Debian Bug Tracking System]

Your message dated Tue, 28 Mar 2017 17:04:20 -0700
with message-id <20170329000420.tp6pvseswdij3...@iris.silentflame.com>
and subject line Re: Bug#832941: RFS: 4pane
has caused the Debian Bug report #832941,
regarding RFS: 4pane/4.0-1 [ITP]
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
832941: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832941
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "4pane"

  * Package name: 4pane
Version : 4.0-1
Upstream Author : David Hart 
  * URL : http://4Pane.co.uk
  * License : GPL3
Section : x11

It builds those binary packages:

  4pane - four-pane detailed-list file manager

To access further information about this package, please visit the following
URL:

  http://mentors.debian.net/package/4pane


Alternatively, one can download the package with dget using this command:

dget -x http://mentors.debian.net/debian/pool/main/4/4pane/4pane_4.0-1.dsc

More information about 4Pane can be obtained from http://4Pane.co.uk.

4Pane is a multi-pane, detailed-list file manager. Though anyone can use it, it
is aimed more at the expert than the average user, with extra features such as
multiple undo and redo, multiple renaming and user-defined tools. Since the
initial release in 2008, 4Pane has been taken up by a few distros, most notably
Arch and PCLinuxOS, and it's now in openMandriva's 'cooker'. 

I have been creating on-site packages since 2008, so I do have some packaging
experience. Apart from a necessary override, the uploaded package is
lintian-clean.

This is an update for the 4.0 release of 4Pane. Since my #764520 RFS I'm
pleased to report that 4Pane has been taken up by Fedora and is in openSUSE
tumbleweed. So, of the major distros the only ones missing are those based on
debian...

Regards,
David Hart
--- End Message ---
--- Begin Message ---
Dear David,

On Tue, Mar 28, 2017 at 10:52:12PM +0100, David Hart wrote:
> However a 4th is added by ChangeToAutomakeBuild.patch, and that does
> indeed need a d/copyright entry. I've added one, calling it
> .build/wxwin.m4 as that's where it will end up. Please let me know if
> I should instead have referred to d/patches/.

The spec is not clear.  So let's keep it how you've done it.

Uploaded -- thank you for your patience!

-- 
Sean Whitton


signature.asc
Description: PGP signature
--- End Message ---

Bug#854395: RFS: golang-go-xdg/0~bzr20140219-2 [RC] -- Go interface for XDG standards

[Roger Shimizu]

Dear Gianfranco,

Thanks for the upload!

On Wed, Mar 29, 2017 at 3:50 AM, Gianfranco Costamagna
 wrote:
>
> maybe sending an email to some dev would be nice!

Sure. Will do later.

> >> 2) why are you disabling tests?
>
> >my local gbp build (with or without pbuilder) is fine, however two
> >test items fail on debomatic.
> >I already paste the log from debomatic to the patch.
>
> it fails in pbuilder too
> base_directory_test.go:45:
> c.Check(h, Matches, s.home+".*"+s.val1)
> ... value string = "/root/something"
> ... regex string = "/home/locutus.*something"
>
> reason is, somewher xdg is returning my $HOME to be /root,
> but echo $HOME returns /home/locutus
> this is probably related to the fact I'm inside a chroot,
> where /home/locutus points to nothing, while /root is my directory
>
> (I'm root but $HOME is not the root one)
>
> anyhow,
>
> HOME=/root dpkg-buildpackageworks here

Thanks for digging it so deep!

> lets go for unstable instead :)
> please push the tag on git!

Pushed with version tag (and removed the mentors branch).
Thanks again!

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Bug#832941: RFS: 4pane

[David Hart]

Dear Sean,

>Sorry, I assumed that uscan would redownload the .pgp file, but it was
>using the old one.  Apologies for wasting your time with that.

That's OK, I've wasted plenty of yours ;)

>While you previously said that everything remaining in .build/ is your
>own work, the file wxwin.m4 is not yours.  So that needs to be added to
>d/copyright.

Ah, I see the problem. In the tarball .build/ contains only 3 files, all mine.
However a 4th is added by ChangeToAutomakeBuild.patch, and that does indeed
need a d/copyright entry. I've added one, calling it .build/wxwin.m4 as that's
where it will end up. Please let me know if I should instead have referred to
d/patches/.

>The patch header for ChangeToAutomakeBuild.patch does not make sense...

Well spotted. A copy/paste error, now fixed.

>These two are the only remaining issues in d35ef45.

>I also noticed that you often cram several copyright lines into a single
>line.  Please consider using line breaks.

Done.

>If you're able to address the issues I've raised in this message, please
>remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
>to refresh the changelog timestamp.

I hope I've removed the tag, though the bug's status has not yet updated.


Regards,

David Hart

Bug#858800: RFS: xtrs/4.9d-1 [ITA]

[G. Branden Robinson]

On Mon, Mar 27, 2017 at 07:11:10PM -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo

Dummy response to -quiet to test Mutt/GPG configuration.

-- 
Regards,
Branden


signature.asc
Description: PGP signature

Bug#858800: RFS: xtrs/4.9d-1 [ITA]

[G. Branden Robinson]

On Mon, Mar 27, 2017 at 07:11:10PM -0700, Sean Whitton wrote:
> control: tag -1 +moreinfo
> 
> Dear Branden,
> 
> On Sun, Mar 26, 2017 at 06:45:34PM -0400, Branden Robinson wrote:
> > Changes since the last upload:
> > 
> >   * Merge new upstream release.
> > + "Deleted all SIGIO code.  The code was a kludge to begin with and it 
> > no
> >   longer worked with current X libraries and Linux kernels, causing xtrs
> >   to hang.  It was also reported to cause hangs when xtrs was compiled 
> > for
> >   Windows using Cygwin.  Thanks to Howard Pepper, Dennis Lovelady, 
> > Arumin
> >   Nueckel, Christopher Currie, and Joe Peterson for bug reports."
> >   (Closes: #511645)
> 
> Is it impossible to backport this fix to the version currently in
> stretch?

No, likely not impossible.  The crudest fix might be simply to just
#undef SIGIO in Makefile.local.

I will explore this.

> You are very unlikely to get release team approval for this upload as it
> stands.  Given what you wrote in #511645, is your intention for xtrs to
> drop out of stretch, to be reintroduced in buster?

I've been making conservative (pessimistic) estimates about how fast I'd
be getting things done since I'm freshly back to the project after a
long absence.  There were and are best practices I need(ed) to get
caught up on.  I also couldn't be absolutely sure I'd get a sponsor
before the removal-from-testing date (scheduled for 11 April); I don't
know when I'll be able to get my new GPG key into the Debian keyring so
that I can upload under my own power[1], and so forth.  Finally, I don't
want to cause the release team any trouble.

So my goals were, in this order:
1) Get the package suitable for unstable (which it wasn't); then
2) Get the package suitable for testing.

Thanks for following up!

Regards,
Branden

[1] That might take a while; my new key is not in the web of trust.

Bug#858538: RFS: fadecut/0.2.0-1

[Sean Whitton]

Dear Marco,

On Tue, Mar 28, 2017 at 01:51:18PM +0200, Marco Balmer wrote:
> Is the package quality from your view ok?

Sorry, I haven't reviewed it.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#854395: marked as done (RFS: golang-go-xdg/0~bzr20140219-2 -- Go interface for XDG standards)

[Debian Bug Tracking System]

Your message dated Tue, 28 Mar 2017 18:50:32 + (UTC)
with message-id <590812699.9581790.1490727032...@mail.yahoo.com>
and subject line Re: Bug#854395: RFS: golang-go-xdg/0~bzr20140219-2 [RC] -- Go 
interface for XDG standards
has caused the Debian Bug report #854395,
regarding RFS: golang-go-xdg/0~bzr20140219-2 -- Go interface for XDG standards
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
854395: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=854395
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: important
X-Debbugs-Cc: pkg-go-maintain...@lists.alioth.debian.org,
sergio.schve...@canonical.com, t...@pault.ag, rogershim...@gmail.com

Dear mentors,

I am looking for a sponsor for my package "golang-go-xdg"

 * Package name: golang-go-xdg
   Version : 0~bzr20140219-2
   Upstream Author : John R. Lenton.
 * URL : https://launchpad.net/go-xdg
 * License : BSD-2-Clause
   Section : devel

  It builds those binary packages:

golang-go-xdg-dev - Go interface for XDG standards

  To access further information about this package, please visit the
following URL:

  https://mentors.debian.net/package/golang-go-xdg

  Alternatively, one can download the package with dget using this command:

dget -x 
https://mentors.debian.net/debian/pool/main/g/golang-go-xdg/golang-go-xdg_0~bzr20140219-2.dsc

or you can use git-buildpackage to build:
  gbp clone --pristine-tar
https://anonscm.debian.org/git/pkg-go/packages/golang-go-xdg.git
  cd golang-go-xdg
  git checkout mentors
  gbp buildpackage -uc -us --git-ignore-branch --git-pristine-tar

I also made it available on debomatic (amd64):
  
http://debomatic-amd64.debian.net/distribution#unstable/golang-go-xdg/0~bzr20140219-2/buildlog

  Changes since the last upload:

  * Team upload.

  [ Paul Tagliamonte ]
  * Use a secure transport for the Vcs-Git and Vcs-Browser URL

  [ Roger Shimizu ]
  * debian/control:
- Update Build-Depends on golang-check.v1-dev, in stead of
  golang-gocheck-dev which is already non-active upstream.
- Use cgit URL for Vcs-Browser.
  * debian/patches:
- Add a patch to use golang-check.v1-dev.
- Add a patch to remove failure tests (Closes: #830446).

Cheers,
-- 
Roger Shimizu, GMT +9 Tokyo
PGP/GPG: 4096R/6C6ACD6417B3ACB1
--- End Message ---
--- Begin Message ---


Hello,


>> 1) did you forward the patch upstream?

>

>sorry, no.

>upstream hosts in launchpad, which I don't have an account.



maybe sending an email to some dev would be nice!

>> 2) why are you disabling tests?

>my local gbp build (with or without pbuilder) is fine, however two

>test items fail on debomatic.

>I already paste the log from debomatic to the patch.


it fails in pbuilder too

base_directory_test.go:45:

c.Check(h, Matches, s.home+".*"+s.val1)

... value string = "/root/something"

... regex string = "/home/locutus.*something"



reason is, somewher xdg is returning my $HOME to be /root,

but echo $HOME returns /home/locutus


this is probably related to the fact I'm inside a chroot,

where /home/locutus points to nothing, while /root is my directory


(I'm root but $HOME is not the root one)


anyhow,

HOME=/root dpkg-buildpackageworks here



>I'm not sure. Last upload was 3 years ago, though.>I don't use the package 
>myself, but it's a dependency of another

>package I'm interested in, so I'm just trying to help on this package.


seems legit


>Since I fixed another library dependency issue (Build-Depends on

>golang-check.v1-dev), how about upload first to experimental without

>the patch disabling two tests, to see how the test goes on buildd

>(instead of debomatic)?

>If the two tests fail also on buildd, we can investigate further.

>

>If you agree with things above, I can prepare another upload to mentors. 
>Thanks!



lets go for unstable instead :)
please push the tag on git!

G.--- End Message ---

Bug#858089: marked as done (RFS: ubertooth/2017.03.R2-1~exp1 and libbtbb/2017.03.R2-1~exp1)

[Debian Bug Tracking System]

Your message dated Tue, 28 Mar 2017 20:38:50 +0200
with message-id 
and subject line Re: RFS: ubertooth/2017.03.R2-1~exp1 and 
libbtbb/2017.03.R2-1~exp1
has caused the Debian Bug report #858089,
regarding RFS: ubertooth/2017.03.R2-1~exp1 and libbtbb/2017.03.R2-1~exp1
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
858089: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=858089
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: sponsorship-requests
Severity: wishlist

Dear mentors,

These two packages both have backwards-incompatible ABI changes. This leads to 
2 new binary packages: libbtbb1 and libubertooth1

As a DM I cannot upload new binary packages.

Can anyone help me out?

You will find the packages here:
  https://mentors.debian.net/package/libbtbb
  https://mentors.debian.net/package/ubertooth


Thank you very much in advance!

Cheers
Ruben
--- End Message ---
--- Begin Message ---
On Sat, 18 Mar 2017 07:58:00 +0100 Ruben Undheim  
wrote:
> Package: sponsorship-requests
> Severity: wishlist
> 
> Dear mentors,
> 
> These two packages both have backwards-incompatible ABI changes. This leads 
> to 2 new binary packages: libbtbb1 and libubertooth1
> 
> As a DM I cannot upload new binary packages.
> 
> Can anyone help me out?
> 
> You will find the packages here:
>   https://mentors.debian.net/package/libbtbb
>   https://mentors.debian.net/package/ubertooth
> 

taking care of them :)

G.



signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#832941: RFS: 4pane

[Sean Whitton]

Dear David,

On Tue, Mar 28, 2017 at 01:36:03PM +0100, David Hart wrote:
> Hmm, I can't make it fail here. e.g.

Sorry, I assumed that uscan would redownload the .pgp file, but it was
using the old one.  Apologies for wasting your time with that.

While you previously said that everything remaining in .build/ is your
own work, the file wxwin.m4 is not yours.  So that needs to be added to
d/copyright.

The patch header for ChangeToAutomakeBuild.patch does not make sense...

These two are the only remaining issues in d35ef45.

As a suggestion, strictly optional:

I also noticed that you often cram several copyright lines into a single
line.  Please consider using line breaks.  E.g.

Copyright: 2005-2014, Mike Hommey 
 1998-2010, Mozilla Project

instead of

Copyright: 2005-2014, Mike Hommey  1998-2010, Mozilla 
Project

Similarly for some Files: fields.

If you're able to address the issues I've raised in this message, please
remove the moreinfo tag in this bug, and don't forget to re-run `dch -r`
to refresh the changelog timestamp.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Gert Wollny]

At second thought it might not be a bug in python-tz, but some
undefined behavior that results from the pandas use of tz._utcoffset: 


>   tz = pytz.timezone('Asia/Tokyo')
>   dt = datetime.datetime(2011,1,1)
>  
>   In[76]:  tz.utcoffset(dt)
>   Out[76]: datetime.timedelta(0, 32400)
> 
>   In [77]: tz._utcoffset
>   Out[77]: datetime.timedelta(0, 33540)
> 

In the first case tz.utcoffset has a reference date, and can select the
 proper time offset, i.e. in 2011 this is 09:00, but tz._utcoffset
doesn't know which year it refers to, and hence, it picks one offset,
in this case the first on the list that has the additional 19 minutes
offset. 

I do also not understand why the test fails only now though, and why
pandas picks one code path to define the test case, and another to
create the expected value.

Best, 
Gert 

Re: After upgrading pbuilder jessie-backports pbuilder stopped working

[Mattia Rizzolo]

On Tue, Mar 28, 2017 at 03:23:46PM +0200, Andreas Tille wrote:
> yesterday I upgraded pbuilder from jessie-backports on a Jessie machine:

Yes, we have a regression.

I've been told one "solution" is to recreate the chroot using the
jessie-bpo debootstrap.  otherwise please downgrade pbuilder for the
time being, while we work on it.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[gregor herrmann]

On Tue, 28 Mar 2017 15:18:20 +0200, Gert Wollny wrote:

> I did some digging: 

> > Maybe it's a bug in python-tz? 
> Most likely: 

FWIW, python-tz also has a FTBFS bug:
https://bugs.debian.org/858133
 

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 of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   


signature.asc
Description: Digital Signature

Re: After upgrading pbuilder jessie-backports pbuilder stopped working

[Gianfranco Costamagna]

Hello,


>yesterday I upgraded pbuilder from jessie-backports on a Jessie machine:
>
>$ grep pbuilder /var/log/dpkg.log  | grep  " installed"
>2017-03-16 11:02:36 status installed pbuilder:all 0.228.5~bpo8+1
>2017-03-27 09:22:52 status installed pbuilder:all 0.228.6~bpo8+1
>Since then I get for any build:
>...
>I: Generated dsc will be overwritten by build result; not generating changes 
>file
>I: Copying COW directory
>I: forking: rm -rf /var/cache/pbuilder/build/cow.7226
>I: forking: cp -al /var/cache/pbuilder/base.cow 
>/var/cache/pbuilder/build/cow.7226
>cp: cannot create hard link '/var/cache/pbuilder/build/cow.7226/dev/ptmx' to 
>'/var/cache/pbuilder/base.cow/dev/ptmx': Invalid cross-device link
>E: Failed cowcopy.


I got something similar some time ago, and I fixed by adding
APTCACHEHARDLINK=no

to my ~/.pbuilderrc configuration file

G.

After upgrading pbuilder jessie-backports pbuilder stopped working

[Andreas Tille]

Hi,

yesterday I upgraded pbuilder from jessie-backports on a Jessie machine:

$ grep pbuilder /var/log/dpkg.log  | grep  " installed"
2017-03-16 11:02:36 status installed pbuilder:all 0.228.5~bpo8+1
2017-03-27 09:22:52 status installed pbuilder:all 0.228.6~bpo8+1

Since then I get for any build:

...
I: Generated dsc will be overwritten by build result; not generating changes 
file
I: Copying COW directory
I: forking: rm -rf /var/cache/pbuilder/build/cow.7226
I: forking: cp -al /var/cache/pbuilder/base.cow 
/var/cache/pbuilder/build/cow.7226
cp: cannot create hard link '/var/cache/pbuilder/build/cow.7226/dev/ptmx' to 
'/var/cache/pbuilder/base.cow/dev/ptmx': Invalid cross-device link
E: Failed cowcopy.


I have not fiddled around with any configuration that was working
before.  Unfortunately my attempt to revert the change by installing
pbuilder_0.228.5~bpo8+1 from snapshot.debian.org failed and the issue
remains. :-(

Any idea what might be wrong here (possibly not the pbuilder package
but something else?

Kind regards

  Andreas.

-- 
http://fam-tille.de

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Gert Wollny]

Hello, 

I did some digging: 


> Maybe it's a bug in python-tz? 

Most likely: 

Pandas uses this code to get the time offset for the local time
in tslib.pyx:  

cpdef _get_utcoffset(tzinfo, obj):
try:
return tzinfo._utcoffset
except AttributeError:
return tzinfo.utcoffset(obj)

Now with 

  tz = pytz.timezone('Asia/Tokyo')
  dt = datetime.datetime(2011,1,1)
  

I get 

  In[76]:  tz.utcoffset(dt)
  Out[76]: datetime.timedelta(0, 32400)

  In [77]: tz._utcoffset
  Out[77]: datetime.timedelta(0, 33540)

which is exactly the 19 min difference we see, and the result  depends
on the code path taken in _get_utoffset. 

Best, 
Gert

Bug#832941: RFS: 4pane

[David Hart]

Dear Sean,

>I can't review your latest work because the PGP signature for the
>tarball fails to verify:
>iris ~/rfs/4pane % origtargz -u
>W: Unable to locate package 4pane
>Trying uscan --download-current-version ...
>uscan: Newest version of 4pane on remote site is 4.0, specified download
> version is 4.0 gpgv: Signature made Wed 22 Mar 2017 01:04:44 PM MST
>gpgv:using RSA key D594F63B22250D6A
>gpgv: BAD signature from "David Hart "
>uscan warn: OpenPGP signature did not verify.
>Could not find any location for 4pane_4.0+dfsg.orig.tar.*
>I guess that you haven't uploaded an updated signature.

Hmm, I can't make it fail here. e.g.

~/temp/retry/4pane> origtargz -u
W: Unable to locate package 4pane
Trying uscan --download-current-version ...
uscan: Newest version of 4pane on remote site is 4.0, specified download
version is 4.0 gpgv: Signature made Wed 22 Mar 2017 20:04:44 GMT
gpgv:using RSA key D594F63B22250D6A
gpgv: Good signature from "David Hart "
Unpacking ../4pane_4.0+dfsg.orig.tar.gz

That was using a fresh debian repo clone. I also tried uscan direct, and did a
gpg2 --verify direct on the uploaded file. Finally I tested in a new
virtualbox guest. All were successful.

Can you think of anything else that might be going wrong?

Regards,

David Hart

Bug#858538: RFS: fadecut/0.2.0-1

[Marco Balmer]

Dear Sean,

Thanks for reply.

On Mon, Mar 27, 2017 at 07:12:33PM -0700, Sean Whitton wrote:
> On Thu, Mar 23, 2017 at 09:47:44AM +0100, Marco Balmer wrote:
> > Changes since the last upload:
> > fadecut (0.2.0-1) unstable; urgency=low
> > [...]
> These changes are not appropriate during the current freeze.
> If you want to upload this as-is, you will need to target experimental.

Is the package quality from your view ok?
So it can wait from my point of view, until the freeze is over.

--
Marco Balmer


signature.asc
Description: Digital signature

Re: Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[James Cowgill]

Hi,

On 28/03/17 10:37, Andreas Tille wrote:
> tags 858260 help
> thanks
> 
> Hi,
> 
> I admit that when reading the bug report I have no idea how to fix it.
> I can confirm that I can reproduce the issue in a recent unstable
> chroot.  I have added maintainers of tzdata, Debian Science and Debian
> mentors in CC - just hoping for any helpful hint.

Whatever has happened, tzdata 2017a triggered it.

tzdata 2016j-2:
> $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, 
> tzinfo = pytz.timezone('Asia/Tokyo'"
> datetime.datetime(2011, 1, 1, 0, 0, tzinfo= JST+9:00:00 STD>)

tzdata 2017a-1:
> $ python3 -c "import datetime, pytz; print(repr(datetime.datetime(2011, 1, 1, 
> tzinfo = pytz.timezone('Asia/Tokyo'"
> datetime.datetime(2011, 1, 1, 0, 0, tzinfo= LMT+9:19:00 STD>)

There was a Asia/Tokyo change in tzdata 2017a, but I don't really know
how it caused this:

@@ -1462,8 +1452,6 @@

 # Zone NAMEGMTOFF  RULES   FORMAT  [UNTIL]
 Zone   Asia/Tokyo  9:18:59 -   LMT 1887 Dec 31 15:00u
-   9:00-   JST 1896 Jan  1
-   9:00-   JCST1937 Oct  1
9:00Japan   J%sT
 # Since 1938, all Japanese possessions have been like Asia/Tokyo.

Maybe it's a bug in python-tz?

James



signature.asc
Description: OpenPGP digital signature

Help needed for pandas bug: Could anybody verify the suspicion that tzdata might have some influence?

[Andreas Tille]

tags 858260 help
thanks

Hi,

I admit that when reading the bug report I have no idea how to fix it.
I can confirm that I can reproduce the issue in a recent unstable
chroot.  I have added maintainers of tzdata, Debian Science and Debian
mentors in CC - just hoping for any helpful hint.

Kind regards

   Andreas.


PS: Yaroslav, you know my opinion about using Vcs outside of debian.org and
deriving from policies that are widely established.  Currently
  git://github.com/neurodebian/pandas.git
is not even featuring the latest uploads - last changelog entry is

pandas (0.19.2-2) unstable; urgency=medium

  * Exclude a number of tests while running on non-amd64 platforms
due to bugs in numpy/pandas

 -- Yaroslav Halchenko   Wed, 11 Jan 2017 12:13:05 -0500


I'm sorry to repeat myself but you are not creating a welcoming
environment for people who intend to help.

-- 
http://fam-tille.de

Re: Sigrok packages review/mentoring

[Andreas Tille]

On Tue, Mar 28, 2017 at 01:41:58AM +0200, Zoltan Gyarmati wrote:
> 
> So as you mentioned for sponsoring you would like to have these git
> repos hosted on
> alioth.debian.org. Given that i have only -guest account there
> (zgyarmati-guest), how
> can i create a repository? What else I need  to do (both technical- and
> administration-wise) to get started?

If you are a member of a packaging team (I think Debian Science is
apropriate in this case) you have permissions to create Git repositories
at git.debian.org:/git/debian-science/packages.  Please check Debian
Science policy or ask here if you have no idea how this can be done.
 
The -guest is no restriction of permissions, just reflecting the fact
that you do not (yet) have the Debian Developer status.

Kind regards

   Andreas.

-- 
http://fam-tille.de