Re: After upgrading pbuilder jessie-backports pbuilder stopped working
Hi Gianfranco, On Tue, Mar 28, 2017 at 01:29:03PM +, Gianfranco Costamagna wrote: > >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 Just for the record: This did not worked in my case - so I'll wait for a fix from Mattia who confirmed the regression. Mattia, I'm fine with testing any patch. Kind regards Andreas. -- http://fam-tille.de
Bug#858557: marked as done (RFS: golang-github-klauspost-reedsolomon/1.3-1~exp1 -- Reed-Solomon Erasure Coding in Go)
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]
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]
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])
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
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
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]
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]
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
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)
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)
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
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?
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
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?
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
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
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?
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
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
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?
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?
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
