Bug#895940: marked as done (RFS: python-dataclasses/0.5-1 [ITP])
Your message dated Thu, 06 Sep 2018 04:20:27 + with message-id and subject line closing RFS: python-dataclasses/0.5-1 [ITP] has caused the Debian Bug report #895940, regarding RFS: python-dataclasses/0.5-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.) -- 895940: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=895940 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 "python-dataclasses" * Package name: python-dataclasses Version : 0.5-1 Upstream Author : Eric V. Smith * URL : https://github.com/ericvsmith/dataclasses * License : MIT Section : python It builds those binary packages: python3-dataclasses - Python dataclasses backport from 3.7 To access further information about this package, please visit the following URL: https://mentors.debian.net/package/python-dataclasses Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/python- dataclasses/python-dataclasses_0.5-1.dsc More information about Python dataclasses can be obtained from https://www.python.org/dev/peps/pep-0557. Regards, Joel Cross -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (1, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.15.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled --- End Message --- --- Begin Message --- Package python-dataclasses has been removed from mentors.--- End Message ---
Re: Formal definitions of Provides and Replaces
Andrius Merkys writes:
> thanks for pointing this out. I was quite surprised that
> Provides/Replaces does not formally require the providing/replacing
> binaries to completely cover provided/replaced binaries.
> The reason I'm asking is the removal of binaries of blacs-mpi, which is
> indicated as provided/replaced by scalapack now. However, scalapack's
> libraries have other sonames, what requires adaptation and rebuilding of
> all packages depending on blacs-mpi. I have spent quite some time to
> figure this out when packaging espresso. Isn't this a bug in scalapack?
I think you're expecting a stronger guarantee than Debian necessarily
provides here. Even a newer version of the same package doesn't have to
provide all the same files as an earlier version of the package.
Some history is here: https://bugs.debian.org/886711. It sounds from that
bug at least like the functionality provided in blacs-mpi is now provided
by scalapack, and at least some packages could just be rebuilt against
scalapack to handle that transition. That's about all that's needed to
justify a Provides/Replaces. There isn't a requirement that everything
work; it's a transition, and the functionality provided is changing (in
this case, apparently based on upstream changes). Using Provides/Replaces
is a mostly pragmatic decision: does it create less work than just
removing the package completely and forcing sourceful uploads of all other
packages? (With an eye to what the upgrade experience for Debian users is
as well, of course.)
As part of that transition, it looks like exactly what you said
("adaptation and rebuilding of all packages depending on blacs-mpi") was
done for the packages in Debian.
Usually it's not worth the effort to diverge too far from upstream in
trying to maintain backward compatibility. If upstream has decided not to
maintain that compatibility, trying to do it ourselves in Debian is rarely
a good use of scarce resources. That sometimes means package-breaking
transitions that require a bit of work for dependencies.
--
Russ Allbery (r...@debian.org)
Bug#896970: RFS: odp/1.19.0.0-1 [ITP]
Hi Dmitry, Thanks for the update! On Fri, Aug 31, 2018 at 03:41:01PM +0300, Dmitry Eremin-Solenikov wrote: > Hello, > > I've uploaded new 1.19.0.2-1 version to mentors.d.o. > I've added manpages, fixed copyright info, fixed alternatives > and enabled auto-tests. Could you please review it? Build-dependency libibverbs-dev is missing. It failed to build from source because the linker cannot find -libverbs After adding that dependency I tried to build again however it ended up with a test failure. (also see the appendix part of this mail) http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.2-1/buildlog > сб, 2 июн. 2018 г. в 7:08, Lumin : > > > > On Sat, Jun 02, 2018 at 03:24:07AM +, Lumin wrote: > > > Please fix the aforementioned problems. Hopefully we'll have the last > > > round of check next time. Thank you for working on this. > > > > > > [1] > > > http://debomatic-amd64.debian.net/distribution#unstable/odp/1.19.0.1-1/buildlog > > > > Forgot to check the copyright ... The copyright looks incomplete. A > > simple search on the source tree would reveal many non-Linaro copyright > > holders: > > > > grep -ri copyright | grep -vi linaro | grep -i copyright > > > > The package will be rejected by ftp-master if we don't fix the > > copyright. > > Should be fixed now. Oops, you may have missed my second mail. The copyright file could be simpler by merging similar paragraphs into one instead one paragraph per file. A template can be generated with the following command: licensecheck -r --deb-machine . Which will automatically merge paragraphs. > > grep -ri copyright | grep -vi linaro | grep -i copyright ^ And I use this command for double-checking the copyright. Apart from that, these lintian complains should be fixed: I: odp source: wildcard-matches-nothing-in-dep5-copyright platform/linux-generic/odp_hash.c (paragraph at line 101) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_check_compile_flag.m4 (paragraph at line 219) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_compiler_vendor.m4 (paragraph at line 224) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_compiler_version.m4 (paragraph at line 229) I: odp source: wildcard-matches-nothing-in-dep5-copyright m4/ax_pthread.m4 (paragraph at line 237) I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 101 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 109 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 219 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 224 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 229 I: odp source: unused-file-paragraph-in-dep5-copyright paragraph at line 237 > > When checking odp-dpdk, one more problem was found: > > > > root@b69fed1c16e0 ~/odp-dpdk-1.19.0.0# update-alternatives --config > > libodp-linux.so-x86_64-linux-gnu > > There are 2 choices for the alternative libodp-linux.so-x86_64-linux-gnu > > (providing /usr/lib/x86_64-linux-gnu/libodp-linux.so). > > > > SelectionPath > > Priority Status > > > > * 0/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > >auto mode > > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so 40 > >manual mode > > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so 40 > >manual mode > > > > > > * 0/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > > 60auto mode > > 1/usr/lib/x86_64-linux-gnu/odp-dpdk/libodp-linux.so.119 > > 60manual mode > > 2/usr/lib/x86_64-linux-gnu/odp-generic/libodp-linux.so.119 > > 40manual mode > > > > Taking BLAS as an example, the generic and slow libblas3 provides > > libblas.so.3 symlink with a priority of 10. Faster implementations > > provides the same symlink with higher priorities, e.g. 40 for openblas. > > > > Maybe you want to adjust the priority values in those postinst scripts? > > The exact value is up to you, as long as it helps to tell the difference > > among different implementations. > > I'll fix odp-dpdk later. It's good as long as all odp-generic packages are assigned with the same priority, and odp-dpdk with a higher one. > -- > With best wishes > Dmitry > Appendix FAIL: scheduler/scheduler_main == odp_ishm.c:936:_odp_ishm_reserve():No huge pages, fall back to normal pages. check: /proc/sys/vm/nr_hugepages. Queue config: queue_basic.max_queue_size: 8192 queue_basic.default_queue_size: 4096 Using scheduler 'basic' Scheduler config: sched_basic.prio_spread: 4 PKTIO: initialized loop interface. PKTIO: initialized dpdk pktio, use export ODP_PKTIO_DISABLE_DPDK=1 to disable. PKTIO: initialized pcap
Bug#907601: RFS: groonga/8.0.6-1
Hi, On Tue, 4 Sep 2018 15:00:54 + (UTC) Gianfranco Costamagna wrote: > Hello Kentaro, > Can you please explain why you did depend on runtime to libjemalloc directly, > without letting shlibs:Depends do the right thing? > > I had to apply this patch to Ubuntu, where jemalloc is updated, and this will > become RC in Debian once jemalloc in experimental goesin unstable...what > about removing that line entirely?If jemalloc is not picked up, probably it > means it is not used by underlying libraries... > snip > diff -pruN 8.0.5-1/debian/control 8.0.5-1ubuntu1/debian/control > --- 8.0.5-1/debian/control 2018-07-27 13:46:23.0 + > +++ 8.0.5-1ubuntu1/debian/control 2018-07-30 14:26:21.0 + As you pointed out, it should use shlibs:Depends. It has been missed to fix it. I'll fix it later. P.S. For the record, Cc:907...@bugs.debian.org Regards, pgpciTZnvbcL0.pgp Description: PGP signature
Re: nodoc solution HOWTO -- Avoid building Sphinx documentation on request (was: Bug#905750: RFS: elpy/1.23.0-1)
Hi Niels, On Wed, Sep 05, 2018 at 05:45:00AM +, Niels Thykier wrote: [...] > Rather, I think there is a typo in changes. > > > --- > > debian/changelog | 6 ++ > > debian/control | 4 ++-- > > debian/rules | 8 +++- > > 3 files changed, 15 insertions(+), 3 deletions(-) > > > > [...] > > diff --git a/debian/rules b/debian/rules > > index a9d70b4..bd4c218 100755 > > --- a/debian/rules > > +++ b/debian/rules > > @@ -11,7 +11,13 @@ export LC_ALL > > # docs are not generated without this override > > override_dh_auto_build: > > dh_auto_build > > - PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator > > +# support the nodoc build profile > > +ifneq ($(filter nodocs,$(DEB_BUILD_PROFILES)),) >^^ > > nodocs != nodoc Thank you for pointing this out, you're right, my mistake :-) When I fixed it, I also discovered that dh_sphinxdoc doesn't detect that nodoc is active, so worked around it and filed #908078. For now, here is the working solution (including dh_sphinxdoc workaround) sans typo. --- a/debian/control +++ b/debian/control @@ -27,8 +27,8 @@ Build-Depends: debhelper (>= 11~) , python3-mock , python3-nose , python3-pip - , python3-sphinx - , texinfo + , python3-sphinx + , texinfo Standards-Version: 4.2.1 Vcs-Browser: https://salsa.debian.org/emacsen-team/elpy Vcs-Git: https://salsa.debian.org/emacsen-team/elpy.git diff --git a/debian/rules b/debian/rules index a9d70b4..47f597b 100755 --- a/debian/rules +++ b/debian/rules @@ -6,12 +6,23 @@ LC_ALL := C.UTF-8 export LC_ALL %: +ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),) + echo -e "\nnodoc profile enabled, building without sphinxdoc..\n" + dh $@ --with elpa,python3 --buildsystem=pybuild +else dh $@ --with elpa,python3,sphinxdoc --buildsystem=pybuild +endif # docs are not generated without this override override_dh_auto_build: dh_auto_build - PYTHONPATH=. sphinx-build -N -bman docs/ build/man # Manpage generator +# support the nodoc build profile +ifneq ($(filter nodoc,$(DEB_BUILD_PROFILES)),) + echo -e "\nnodoc build profile enabled, therefor not building docs.\n" +else + PYTHONPATH=. sphinx-build -N -bman docs/ build/man PYTHONPATH=. sphinx-build -N -btexinfo docs/ build/info makeinfo --no-split build/info/Elpy.texi -o build/info/elpy.info cat NEWS.rst debian/local-var-snippet > build/NEWS +endif Sincerely, Nicholas signature.asc Description: PGP signature
Bug#908061: RFS: rapid-photo-downloader/0.9.11-1
Control: owner -1 anar...@debian.org On 2018-09-05 18:39:07, Jörg Frings-Fürst wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Package: sponsorship-requests > Severity: normal > > Dear mentors, > > I am looking for a sponsor for my package "rapid-photo-downloader" Hi! As the uploader for the package, I'll be happy to sponsor this. I've reviewed your changes and they seem mostly good. However, they seem to omit some changes I've uploaded to the git repository 4 weeks ago: https://salsa.debian.org/debian/rapid-photo-downloader ... namely: https://salsa.debian.org/debian/rapid-photo-downloader/commit/ff0358a5e0783fb2464391cd06d02021a881ccae https://salsa.debian.org/debian/rapid-photo-downloader/commit/c0027837223b83325d653a59146e16d2206fcccf Those are necessary (I think?) to completely fix #900709. With those changes, I'll be happy to do the upload. I would also encourage you to register on salsa.debian.org and upload your changes there, as it will make future collaboration easier: it would have avoided such confusion, for example. Thanks! A. -- The value of a college education is not the learning of many facts but the training of the mind to think. - Albert Einstein
Bug#908061: RFS: rapid-photo-downloader/0.9.11-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "rapid-photo-downloader" Package name: rapid-photo-downloader Version : 0.9.11-1 Upstream Author : Damon Lynch URL : https://damonlynch.net/rapid License : GPL-2+ Section : graphics It builds those binary packages: rapid-photo-downloader - Photo downloader (importer) from cameras, memory cards, other dev To access further information about this package, please visit the following URL: https://mentors.debian.net/package/rapid-photo-downloader Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/r/rapid-photo-downloader/rapid-photo-downloader_0.9.11-1.dsc git: https://jff.email/cgit/rapid-photo-downloader.git/?h=release%2Fdebian%2F0.9.11-1 Changes since the last upload: * New upstream release. - Refresh patches. * debian/control: - Change VCS-* to point to the new repository. * debian/copyright: - Use secure copyright format URI. - Change source to new homepage. - Add year 2018 to Antoine Beaupré. * debian/watch: - Use secure URI. * Declare compliance with Debian Policy 4.2.1 (No changes needed). Regards, Jörg Frings-Fürst - -- New: GPG Fingerprint: 63E0 075F C8D4 3ABB 35AB 30EE 09F8 9F3C 8CA1 D25D GPG key (long) : 09F89F3C8CA1D25D GPG Key: 8CA1D25D CAcert Key S/N : 0E:D4:56 Old pgp Key: BE581B6E (revoked since 2014-12-31). Jörg Frings-Fürst D-54470 Lieser git: https://jff.email/cgit/ Threema: SYR8SJXB Wire: @joergfringsfuerst Skype:joergpenguin Ring: jff Telegram: @joergfringsfuerst My wish list: - Please send me a picture from the nature at your home. -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEY+AHX8jUOrs1qzDuCfifPIyh0l0FAluQBqsACgkQCfifPIyh 0l3GDhAAxQysiYBzoyexRwibfHJuRpiPayKA0d9kUmhxKcRov71gVWfpnFdxA6fp oIvsYdMNs6C6yaWc0Im4jnkuZw/2lU9hRfgKjXgo2XXlMdd0tf0vBj6KG3AA+1+2 6TWJ62XnfC2WcSqqqvOG22JlmHO+4ppzasdCeTI8AXytGrI54h/TGArsCjkmN+mQ rOU3Vktbl5d/1H2FNCH1ydfPRPthdFjSGTFyWwkC69r1VvBwaZROa65v+3IsoRdx oF9FMoCKzWT+utvu4HK9AFNETAKo+uZMch7rPI1jy+TzaOG+Bggu2iPuVJcCbh6V y+BItMc8WOdeXMuqfs+1bFkR/I+Zia6XdNAl+f1hrChv+Cc0LPRxhKeAcarwu5F+ TEV0InpbcA3QNC4lS1oyvIdpiYJpeODHbhivc29011hp7k5N8yYkysuQWvzqplRZ 7KgoDD9HH9sVrfUkACpDPEy0QKm7P6atfjmrnJipfnV1Z/OQVs6SqqmlWq1Zrz1W 9cGXTOGESHzrSlnN9z6O6Tg57RrB/3446+jKJwjAalPYMJtV5sPAZG5ar46I+4V9 c5lJKozcXhLdoS5LK64fTLvKOp8pVF4QyWZxZWOWjcB6dMY8A+GJyaShejSvcILE vVKym+Wj4jvloZxZQFycq3LIIALWga025rb/16+DuWw948BF4rc= =B8bg -END PGP SIGNATURE-
Bug#907664: marked as done (RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1)
Your message dated Wed, 05 Sep 2018 16:22:57 + with message-id and subject line closing RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1 has caused the Debian Bug report #907664, regarding RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-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.) -- 907664: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907664 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 my package "budgie-desktop" * Package name: budgie-desktop Version : 10.4+git20180830.01.f2dbc215fdb-1 Upstream Author : i...@solus-project.com * URL : https://github.com/budgie-desktop/budgie-desktop * License : LGPL-2.1/GPL2.0 Section : x11 It builds those binary packages: budgie-core - Core package for Budgie-Desktop budgie-core-dev - Development package for budgie-desktop budgie-desktop - Desktop package for budgie-desktop budgie-desktop-doc - documentation files for the budgie-desktop gir1.2-budgie-1.0 - GNOME introspection library for budgie-desktop libbudgie-plugin0 - Plugin library for budgie-desktop libbudgie-private0 - Budgie Private library for budgie-desktop libbudgietheme0 - Theme library for budgie-desktop libraven0 - Raven library for budgie-desktop To access further information about this package, please visit the following URL: https://mentors.debian.net/package/budgie-desktop Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/b/budgie-desktop/budgie-desktop_10.4+git20180830.01.f2dbc215fdb-1.dsc Notes: This upload to experimental has been requested to facilitate the upcoming GNOME mutter 3.30 transition that is about to be undertaken (Serious: #907616) Tested by pbuilder-dist on experimental; this has been tested on Ubuntu 18.10 (cosmic) and is part of the daily ISO builds check-all-the-things has been run on the source lintian -i -I --pedantic run on the built changes files. W: orig-tarball-missing-upstream-signature --> this is due to using a git release tarball. A v10.5 signed tarball is expected soon by the upstream project but date is yet to be set publically; I am using a git release to increase testing exposure in Ubuntu; since Debian is now about to transition I'm more than happy for the Debian community to join the testing effort. May I request that this package be added to my debian maintainers list of packages I'm allowed to look after (dak fossfree...@ubuntu.com) ? ; timeliness of uploads is key especially as I am working with upstream with development activities and the production of additional patches as we move towards budgie-desktop v10.5 Changes since the last upload: * Release to experimental (Closes: #907616) - base on ubuntu cosmic package; this includes a git release of budgie-desktop that will form the forthcoming v10.5 release. Includes additional patches to compile for mutter 3.30 plus current work-in-progress stability patches * Packaging Changes - budgie-core.lintian-overrides - revise explanation of the lintian false positive results with the objdump test to confirm the observations - bump control Standards-Version; no additional changes required - libraven0.symbols add two additional symbols for git release Regards, David Mohammed --- End Message --- --- Begin Message --- Package budgie-desktop version 10.4+git20180830.01.f2dbc215fdb-1 is in NEW now, and the package at mentors is not newer (2018-08-30) than the package in NEW (2018-08-30), so there is currently no package to sponsor. https://ftp-master.debian.org/new/budgie-desktop_10.4+git20180830.01.f2dbc215fdb-1.html https://mentors.debian.net/package/budgie-desktop If for some reason you need to replace the package in NEW, then you can upload an updated package to mentors and feel free to reopen this RFS 907664 or open a new RFS.--- End Message ---
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Andreas Henriksson wrote: > PS. after sending you the previous mail I thought to myself that a > Recommends might be more suitable, so people can remove gconf2 again > after upgrade is finished (and anyone not installing recommends gets > their choice of not migrating their settings) just thought I'd > mention it... Makes sense, thank you. Reuploaded with this change.
Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1
On Wed, Sep 05, 2018 at 08:50:56AM -0300, Herbert Fortes wrote: > > Thanks Herver - due to the new binary with this upload (libbudgie-private0) > > FTP-Master has rejected the package with this message > > > > "ACL dm: NEW uploads are not allowed > > > > binary:libbudgie-private0 is NEW." > > > > Can this be sponsored this time around please? > > > > Uploaded to experimental. > > But please update debian/copyright before the upload to SID. Ah, I had just come here to look at uploading this to *unstable* - we've just uploaded mutter-3 there, and so budgie-desktop will need fixing now. Could you possibly re-upload to unstable NEW please? I guess if some copyright fixes are required then David might need to post a new package. Cheers! -- Iain Lane [ i...@orangesquash.org.uk ] Debian Developer [ la...@debian.org ] Ubuntu Developer [ la...@ubuntu.com ] signature.asc Description: PGP signature
Bug#907664: RFS: budgie-desktop/10.4+git20180830.01.f2dbc215fdb-1
Thanks Herver - due to the new binary with this upload (libbudgie-private0) FTP-Master has rejected the package with this message "ACL dm: NEW uploads are not allowed binary:libbudgie-private0 is NEW." Can this be sponsored this time around please? Uploaded to experimental. But please update debian/copyright before the upload to SID. Regards, Herbert
Re: Formal definitions of Provides and Replaces
Hi Paul, On 09/02/2018 12:44 PM, Paul Wise wrote: > The fields are defined in Debian Policy: > > https://www.debian.org/doc/debian-policy/ch-relationships.html#virtual-packages-provides > https://www.debian.org/doc/debian-policy/ch-relationships.html#overwriting-files-and-replacing-packages-replaces thanks for pointing this out. I was quite surprised that Provides/Replaces does not formally require the providing/replacing binaries to completely cover provided/replaced binaries. The reason I'm asking is the removal of binaries of blacs-mpi, which is indicated as provided/replaced by scalapack now. However, scalapack's libraries have other sonames, what requires adaptation and rebuilding of all packages depending on blacs-mpi. I have spent quite some time to figure this out when packaging espresso. Isn't this a bug in scalapack? Best wishes, Andrius -- Andrius Merkys Vilnius University Institute of Biotechnology, Saulėtekio al. 7, room V325 LT-10257 Vilnius, Lithuania
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Hello Yavor Doganov, thanks for your quick followup. On Wed, Sep 05, 2018 at 11:22:23AM +0300, Yavor Doganov wrote: > Andreas Henriksson wrote: > > On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: > > > * debian/patches/gsettings-port.patch: New, migrate from GConf to > > > GSettings (Closes: #885817). > > > With gsettings migration I guess you feel it's unwelcome to have > > a dependency on gconf2 remaining in buster, but for data conversion > > the dependency needs to remain until gsettings conversion has shipped > > in one stable debian release (as a minimum). > > I agree completely. Some time ago I asked on the pkg-gnome list > precisely about this scenario [1] but didn't receive a reply. As the > situation now is clear and the new maintainer announced gconf is going > to be shipped in buster, I added explicit dependency on gconf2 and > removed the comment regarding migration from the patch. > > [1] > https://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/2018-August/145477.html The main problem here is that the gconf2->gsettings migration should have been done ~ 10 years ago already. Then it wouldn't have been a problem for buster. Unmaintained packages are a burden which we just can't allow block progress forever. It might just be better to remove them from debian and then provide them to potential users on the side. > > > > * debian/pixmaps/gnomint.xpm: > > > * debian/gnomint.menu: > > > * debian/gnomint.install: Delete. > > > > I guess you mean 'Delete' applies to all three above? > > Yes, this is a short variant that's widely used in upstream > changelogs. I changed it to "Delete" followed by "Likewise". "widely used in upstream changelogs" makes your GNU bias show. ;) > > > Maybe would have been better to write them under the same bullet > > point. (Also I'm not sure about separating the changelog on a > > per-file basis, rather than on a per-change basis but I guess that's > > related to personal taste and different people do it differently.) > > Well, yes, it is personal taste. I prefer the former concept as it's > very easy to miss some file or some tiny change with the latter. It > also corresponds with the GNU ChangeLog requirements so I don't have > to adapt mentally when I switch between a GNU-style ChangeLog and a > Debian changelog. > > OTOH, the per-change approach is very useful for commit messages. > > Thanks for the review. I reuploaded the package with these changes > and the timestamp updated. Regards, Andreas Henriksson PS. after sending you the previous mail I thought to myself that a Recommends might be more suitable, so people can remove gconf2 again after upgrade is finished (and anyone not installing recommends gets their choice of not migrating their settings) just thought I'd mention it...
Bug#907826: RFS: gnomint/1.3.0-1 [QA] [RC]
Andreas Henriksson wrote: > On Sun, Sep 02, 2018 at 07:41:18PM +0300, Yavor Doganov wrote: > > * debian/patches/gsettings-port.patch: New, migrate from GConf to > > GSettings (Closes: #885817). > With gsettings migration I guess you feel it's unwelcome to have > a dependency on gconf2 remaining in buster, but for data conversion > the dependency needs to remain until gsettings conversion has shipped > in one stable debian release (as a minimum). I agree completely. Some time ago I asked on the pkg-gnome list precisely about this scenario [1] but didn't receive a reply. As the situation now is clear and the new maintainer announced gconf is going to be shipped in buster, I added explicit dependency on gconf2 and removed the comment regarding migration from the patch. [1] https://alioth-lists.debian.net/pipermail/pkg-gnome-maintainers/2018-August/145477.html > > * debian/pixmaps/gnomint.xpm: > > * debian/gnomint.menu: > > * debian/gnomint.install: Delete. > > I guess you mean 'Delete' applies to all three above? Yes, this is a short variant that's widely used in upstream changelogs. I changed it to "Delete" followed by "Likewise". > Maybe would have been better to write them under the same bullet > point. (Also I'm not sure about separating the changelog on a > per-file basis, rather than on a per-change basis but I guess that's > related to personal taste and different people do it differently.) Well, yes, it is personal taste. I prefer the former concept as it's very easy to miss some file or some tiny change with the latter. It also corresponds with the GNU ChangeLog requirements so I don't have to adapt mentally when I switch between a GNU-style ChangeLog and a Debian changelog. OTOH, the per-change approach is very useful for commit messages. Thanks for the review. I reuploaded the package with these changes and the timestamp updated.
Bug#907914: RFS: elpy/1.24.0-1
Nicholas, > > If it's an genuine exception that just happens to trigger the > package regex, then a lintian override could be justified. > > Aha! Yes, I agree, that sounds like the best way forward. WRT to > "genuine exception" shouldn't someone ACK the official section change > in Bug #900212 before I remove the lint/reminder with an override? If you are unsure, yes, I would wait. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#907192: pre-RFS: tensorflow/1.10.0+dfsg-A1 [ITP] -- debian archve += 1 million lines of code
> Currently I can build it manually on my daily Debian experimental > system (amd64) and another unclean chroot (amd64). However I'm > still not sure whether the other can build it successfully like I do. Preliminary lintian-clean binary packages are available on debomatic-amd64: http://debomatic-amd64.debian.net/debomatic/experimental/pool/tensorflow_1.10.1+dfsg-A1u27/tensorflow_1.10.1+dfsg-A1u27_amd64.changes Which was built from https://salsa.debian.org/science-team/tensorflow - tag: lumin/A1u27 The shared object libtensorflow.so is not expected to change before the upload. I'll upload it to experimental once I've finished the sanity checks and tests.
