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 webcamoid/webcamoid_7.2.0+dfsg.orig.tar.gz > has size 3160998 instead of expected 3148208 > [...] > > Is this a big problem ? (replace a +dfsg.orig.tar.gz file > with the same upstream version) 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 +dfsg1, and incrementing that on each change to the tarball. -- Feri
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 decision about uploading or not and where should depend on many factors, e.g. userbase kind of bugs and probability, maintainer opinion "cum grano salis".I usually prefer to not bother when the maintainer puts low, because "better safe than sorry" :)Gianfranco
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 wants to start over from scratch.
>>
>> The problem is, it is not documented the correct way to delete
>> the chroot and tar ball. The users want to put sbuild back to
>> the way it was just after sbuild was installed.
>>
>>
>> What is the proper way to do that?
>
> Asking for a friend? ;)
>
> Assuming you used the suggestions for making the chroot on the sbuild
> wiki page, this should do it:
>
> # rm -rf /srv/chroot/* /etc/sbuild/chroot/*-sbuild
> /etc/schroot/chroot.d/*-sbuild
Please note that this will delete *all* chroots and their configuration.
I woud prefer something like:
SCHROOT=unstable-amd64-sbuild
SCHROOT_DIR=$(readlink -e /etc/sbuild/${SCHROOT})
rm -r ${SCHROOT_DIR} /etc/sbuild/${SCHROOT} \
/etc/schroot/chroot.d/$[SCHROOT}-*
Afterwards you can start over by creating a fresh version of the schroot
with sbuild-createchroot as documented on the wiki page[1].
Cheers,
jonas
[1] https://wiki.debian.org/sbuild
> If you didn't use the suggestions on the wiki page, just start nuking
> stuff in those three directories.
>
signature.asc
Description: OpenPGP digital signature
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 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.) -- 833312: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=833312 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for this updated backport of btrfs-progs. Package name: btrfs-progs Version: 4.6.1-1~bpo8+1 It builds these binary packages: btrfs-progs - Checksumming Copy on Write Filesystem utilities btrfs-progs-dbg - Checksumming Copy on Write Filesystem utilities (debug) btrfs-progs-udeb - Checksumming Copy on Write Filesystem utilities (udeb) (udeb) btrfs-tools - transitional dummy package btrfs-tools-dbg - transitional dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/btrfs-progs Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/btrfs-progs/btrfs-progs_4.6.1-1~bpo8+1.dsc Changes since the last upload: btrfs-progs (4.6.1-1~bpo8+1) jessie-backports; urgency=medium * Rebuild for jessie-backports. -- Nicholas D Steeves Tue, 26 Jul 2016 16:58:05 -0400 btrfs-progs (4.6.1-1) unstable; urgency=high [ Dimitri John Ledkov ] * New upstream release * Update debian/copyright as package is mostly GPL-2 only, not GPL-2+ (Closes: #824896) * Provide upstream changelog, thanks to Nicholas D Steeves (Closes: #824894) * Set Vcs-* control headers pointing at dgit git repositories * Add udev build-dependency, to install upstream btrfs-dm udev rules * Ship libgcc_s into the initrd, for scrub to work because it uses pthread_cancel. Thanks Guilhem. (Closes: #830883) [ Nicholas D Steeves ] * debian/watch: add mangling rules to prefer non-rcN versions; add cryptographic signature verification of tarball (Closes: #827778) -- Dimitri John Ledkov Tue, 26 Jul 2016 13:50:21 +0100 btrfs-progs (4.5.2-1) unstable; urgency=medium [ Dimitri John Ledkov ] * Thanks for NMU of package rename. * New upstream release 4.5.2. * Upload using dgit. * Source-only upload. * btrfs-convert should not be included in the initramfs, but should be compiled. Using btrfs-convert is not a trivial operation, and especially not from a minimal shell. Also it is known to fail, and for a sophisticated user it is trivial to include it in the initramfs. Thus won't fix Closes: #801192 * No sponsorship required Closes: #823474 * Add Provides btrfs-tools-udeb to the -progs-udeb package. * Enable verbose build. [ Ben Hutchings ] * Show only errors from boot-time "btrfs scan" if "quiet" is used. Closes: #812722 -- Dimitri John Ledkov Tue, 10 May 2016 09:59:51 +0100 Thank you, Nicholas --- End Message --- --- Begin Message --- Hi, >Done. I'm not sure how much of an issue it is, so I'll leave starting >a discussion up to you. I monitor -backport mail list, and if somebody complains I'll start a new thread. "bad" fixes, because of a single user error, fixing something that is not documented, are not worth a discussion to me :) cheers, G.--- End Message ---
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 building the doc? is some sort of "chicken and egg" issue? can I presume you will add the package later? 2) missing copyright! ./nbconvert/resources/style.min.css: * Copyright 2011-2015 Twitter, Inc. 3) FTBFS! http://debomatic-amd64.debian.net/distribution#experimental/nbconvert/4.2.0-1/buildlog hurray! I found something to nitpick :) if you can fix the above I'll be happy to upload! G.
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 > CHROOT_MODE configuration variable. > > Indeed I do remember having had a similar question when I started using sbuild > but never got around filing a bug. 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 tool for the chroot in question and schroot should have a corresponding command that would DTRT. -- bye, pabs https://wiki.debian.org/PaulWise
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 is used by sbuild-createchroot and the default of the > > CHROOT_MODE configuration variable. > > > > Indeed I do remember having had a similar question when I started using > > sbuild > > but never got around filing a bug. 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 tool for the chroot in question and > schroot should have a corresponding command that would DTRT. it is unlikely, that there will be a schroot command that does the right thing because schroot also leaves it up to the user to create the chroot in the first place. This is also why sbuild-createchroot is doing everything manually including assembling the right schroot configuration file. My last attempt at implementing a command that does this was stopped early on by the question how this tool should best be called: - sbuild-deletechroot - sbuild-removechroot - sbuild-destroychroot Maybe a native English speaker could tell me the most natural choice for a tool that does the opposite of what sbuild-createchroot does. Thanks! cheers, josch signature.asc Description: 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 tool for the chroot in question and > > schroot should have a corresponding command that would DTRT. > > it is unlikely, that there will be a schroot command that does the right thing > because schroot also leaves it up to the user to create the chroot in the > first > place. This is also why sbuild-createchroot is doing everything manually > including assembling the right schroot configuration file. schroot does have the info it needs though - to lok up where the chroot is stored and remove it, so it could... > My last attempt at implementing a command that does this was stopped early on > by the question how this tool should best be called: > > - sbuild-deletechroot > - sbuild-removechroot > - sbuild-destroychroot > > Maybe a native English speaker could tell me the most natural choice for a > tool > that does the opposite of what sbuild-createchroot does. 'destroy' is closest to the opposite of 'create'. But 'remove' sounds a bit less cataclysmic :-) Either will do fine. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ signature.asc Description: Digital signature
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
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 * License : BSD Section : science It builds those binary packages: python-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 2 python-dtcwt-doc - Documentation of the Python implementation of the DT-CWT python3-dtcwt - Dual-Tree Complex Wavelet Transform library for Python 3 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-dtcwt Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python-dtcwt/python-dtcwt_0.11.0-2.dsc Successful build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/python-dtcwt/0.11.0-2/buildlog Changes since the last upload: * Make build reproducible. * Simplify packaging testsuite using Test-Command. * cme fix dpkg-control: - Drop unnecessary versioned dependency on sphinx. - Bump standards version to 3.9.8, no changes required. Regards, Ghislain Vaillant
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 : http://www-user.tu-chemnitz.de/~potts/nfft/ * License : GPL-2+ Section : science It builds those binary packages: libarrayfire-cpu-dev - Development files for ArrayFire (CPU backend) libarrayfire-cpu3 - High performance library for parallel computing (CPU backend) libarrayfire-dev - Common development files for ArrayFire libarrayfire-doc - Common documentation and examples for ArrayFire libarrayfire-opencl-dev - Development files for ArrayFire (OpenCL backend) libarrayfire-opencl3 - High performance library for parallel computing (OpenCL backend) libarrayfire-unified-dev - Development files for ArrayFire (unified backend) libarrayfire-unified3 - High performance library for parallel computing (unified backend) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/arrayfire Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/a/arrayfire/arrayfire_3.3.2+dfsg1-3.dsc Successful build on debomatic: http://debomatic-amd64.debian.net/distribution#unstable/arrayfire/3.3.2+dfsg1-3/buildlog Changes since the last upload: * d/rules: fix test exclusion regex. * d/rules: drop usage of AF_INSTALL_INC_DIR flag. * d/rules: use relative paths for AF_INSTALL* flags. Regards, Ghislain Vaillant
Bug#833372: RFS: python-dtcwt/0.11.0-2
control: close -1 control: close 833373 sponsoring them. g.
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 doc, you need nbsphinx. To build nbsphinx, you need nbconvert. So the plan is: (1) nbconvert without doc ; (2) nbsphinx ; (3) nbconvert. 2) missing copyright! ./nbconvert/resources/style.min.css: * Copyright 2011-2015 Twitter, Inc. Oh! Added. 3) FTBFS! http://debomatic-amd64.debian.net/distribution#experimental/nbconvert/4.2.0-1/buildlog 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 :-/ Cheers, Snark
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 Reverse-Build-Depends-Indep === * nova Reverse-Build-Depends = * jupyter-client * jupyter-core locutus@Unimatrix04-Xenial:/tmp $ reverse-depends -r experimental ipython Reverse-Depends === * python-caffe-cpu [s390x] * python-ipykernel Packages without architectures listed are reverse-dependencies in: amd64, arm64, armel, armhf, hurd-i386, i386, kfreebsd-amd64, kfreebsd-i386, mips, mips64el, mipsel, powerpc, ppc64el, s390x so, ipykernel seems a good candidate. what do you think about? you might enforce a version in setup.py "'ipython>=4.0.0'," and let the magic do the other stuff. what do you think about? G.
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 > +dfsg1, and incrementing that on each change to the tarball. The version in experimental[0] now is 7.2.0+dfsg-2. https://buildd.debian.org/status/package.php?p=webcamoid&suite=experimental The next upload will be 7.2.0+dfsg1-1 ? regards, -- Herbert Parentes Fortes Neto (hpfn) signature.asc Description: This is a digitally signed message part
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 part to the version after +dfsg, like >> +dfsg1, and incrementing that on each change to the tarball. > > The version in experimental[0] now is 7.2.0+dfsg-2. > > https://buildd.debian.org/status/package.php?p=webcamoid&suite=experimental > > The next upload will be 7.2.0+dfsg1-1 ? $ dpkg --compare-versions 7.2.0+dfsg-2 \< 7.2.0+dfsg1-1 && echo yes yes , that would be a valid choice. -- Feri
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 the version after +dfsg, like > > > +dfsg1, and incrementing that on each change to the tarball. > > > > The version in experimental[0] now is 7.2.0+dfsg-2. > > > > https://buildd.debian.org/status/package.php?p=webcamoid&suite=experimental > > > > The next upload will be 7.2.0+dfsg1-1 ? > > $ dpkg --compare-versions 7.2.0+dfsg-2 \< 7.2.0+dfsg1-1 && echo yes > yes > > , that would be a valid choice. Thanks! regards, -- Herbert Parentes Fortes Neto (hpfn) signature.asc Description: This is a digitally signed message part
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 : Expat Section : x11 It builds those binary packages: 9wm - X11 window manager inspired by the Plan 9's rio To access further information about this package, please visit the following URL: https://mentors.debian.net/package/9wm Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/9/9wm/9wm_1.3.7-1.dsc Changes since the last upload: 9wm (1.3.7-1) unstable; urgency=medium * New upstream version * Bump standards version to 3.9.8, no changes * md extension on README -- Jacob Adams Wed, 03 Aug 2016 22:32:34 -0400 Regards, -- Jacob Adams GPG Key: AF6B 1C26 E2D0 A988 432B 94F4 24C0 2B85 B59F E5A9 signature.asc Description: OpenPGP digital signature
