Bug#833414: RFS: 9wm/1.3.7-1

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "9wm" * Package name: 9wm Version : 1.3.7-1 Upstream Author : Neale Pickett * URL : https://github.com/nealey/9wm * License :

Re: same upstream version but different orig.tar.gz

Hi Ferenc Wágner, > > > You can work around this locally by rewriting your .changes files; the > > > changestool utility in the reprepro packages can help with that.  But > > > you won't be able to upload different files with the same name.  The > > > usual solution is adding a numeric part to

Re: same upstream version but different orig.tar.gz

Herbert Fortes writes: >> You can work around this locally by rewriting your .changes files; the >> changestool utility in the reprepro packages can help with that.  But >> you won't be able to upload different files with the same name.  The >> usual solution is adding a numeric

Re: same upstream version but different orig.tar.gz

Hi, > > You can work around this locally by rewriting your .changes files; the > changestool utility in the reprepro packages can help with that.  But > you won't be able to upload different files with the same name.  The > usual solution is adding a numeric part to the version after +dfsg, like

Bug#833320: RFS: nbconvert/4.2.0-1 (ITP -- to experimental!)

Hi, >That's not surprising : the bot takes the ipython in unstable and not the one >in experimental! Notice that the dep on ipython is indirect, so >I don't know which package needs a versioned dep :-/ I would wild guess: reverse-depends -r experimental -b ipython

Bug#833320: RFS: nbconvert/4.2.0-1 (ITP -- to experimental!)

Hi, On 03/08/2016 11:06, Gianfranco Costamagna wrote: It has been a long time since my last nitpick, and this time I found one! hurray! :) Aie. 1) why aren't you building the doc? is some sort of "chicken and egg" issue? can I presume you will add the package later? To build nbconvert's

Bug#833372: RFS: python-dtcwt/0.11.0-2

control: close -1 control: close 833373 sponsoring them. g.

Bug#833373: RFS: arrayfire/3.3.2+dfsg1-3

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "arrayfire" * Package name: arrayfire Version : 3.3.2+dfsg1-3 Upstream Author : Prof. Dr. Daniel Potts * URL :

Bug#833372: RFS: python-dtcwt/0.11.0-2

Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "python-dtcwt" * Package name: python-dtcwt Version : 0.11.0-2 Upstream Author : Rich Wareham * URL : https://github.com/rjw57/dtcwt

Re: How do you delete a sbuild an sbuild chroot and start over?

Hello, On Wed, Aug 03, 2016 at 10:21:46AM +0200, Jonas Meurer wrote: > Please note that this will delete *all* chroots and their configuration. > I woud prefer something like: That's what he said he wanted to do :) -- Sean Whitton signature.asc Description: PGP signature

Re: How do you delete a sbuild an sbuild chroot and start over?

On 2016-08-03 13:12 +0200, Johannes Schauer wrote: > Hi, > > Quoting Paul Wise (2016-08-03 12:41:28) > > > As far as I know, schroot still doesn't > > > document how to delete a chroot. > > > > Seems to me like sbuild should have an sbuild-deletechroot command > > that should call the relevant

Re: How do you delete a sbuild an sbuild chroot and start over?

Hi, Quoting Paul Wise (2016-08-03 12:41:28) > On Wed, Aug 3, 2016 at 1:06 PM, Johannes Schauer wrote: > > > The main issue here is, that it is not clear *where* the bug should be > > filed. > > Sbuild supports multiple backends. The probably most used one is the schroot > > backend because that

Re: How do you delete a sbuild an sbuild chroot and start over?

On Wed, Aug 3, 2016 at 1:06 PM, Johannes Schauer wrote: > The main issue here is, that it is not clear *where* the bug should be filed. > Sbuild supports multiple backends. The probably most used one is the schroot > backend because that is used by sbuild-createchroot and the default of the >

Bug#833320: RFS: nbconvert/4.2.0-1 (ITP -- to experimental!)

control: owner -1 ! control: tags -1 moreinfo Hi, > I am looking for a sponsor for my package "nbconvert" I admit you already have a Python packaging knowledge higher than mine :) It has been a long time since my last nitpick, and this time I found one! hurray! :) 1) why aren't you

Bug#833312: marked as done (RFS: btrfs-progs/4.6.1-1~bpo8+1)

Your message dated Wed, 3 Aug 2016 08:57:55 + (UTC) with message-id <2025137989.15159992.1470214675417.javamail.ya...@mail.yahoo.com> and subject line Re: Bug#833312: RFS: btrfs-progs/4.6.1-1~bpo8+1 has caused the Debian Bug report #833312, regarding RFS: btrfs-progs/4.6.1-1~bpo8+1 to be

Re: How do you delete a sbuild an sbuild chroot and start over?

Am 03.08.2016 um 06:20 schrieb Sean Whitton: > On Tue, Aug 02, 2016 at 11:06:31PM -0500, Paul Elliott wrote: >> Sometimes a user gets a sbuild chroot so screwed up that it does not >> work anymore, and the user has no idea how to fix it, because he does not >> know what he did wrong. >> >> He

Re: Upload priorities for NEW packages (was: Bug#827933: RFS: yabar/0.4.0-3 [ITP])

Hi >I agree.  Something known to be >buggy shouldn't be uploaded >anywhere >other than maybe experimental.  When >I talked about low priority in my >previous e-mail, I meant to refer to >disruptive and major changes as you >describe.  Thanks! I would say *everything* is buggy by definition. The

Re: same upstream version but different orig.tar.gz

Herbert Fortes writes: > So I did a new Debian revision after the +dfsg.orig.tar.gz file be > replaced. > > I just did a 'debdiff' to check the differences between the Debian > revisions, and of course, the output is: > > dpkg-source: error: file