Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Johannes Schauer wrote: > [the need for Javascript] should be reported as a bug against the tracker. Submitted as https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178 and subscribed to it. i wrote: > > Doesn't "Architecture: all" imply "Multi-arch: foreign" ? > No. Multi-arch:foreign means that a package of architecture foo is able to > satisfy the dependencies of a package with architecture bar. > [...] > imagine an Architecture:all package doing this: > #!/bin/sh > gcc "$@" > Certainly, what this architecture independent shell script does is > architecture dependent and thus the package containing it cannot be > marked as Multi-Arch:foreign. How can this script be "Architecture:all" if it does not work as expected on some architectures ? https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture says: "all, which indicates an architecture-independent package." So is there a difference between "being architecture independent" and "acting architecture independent" ? (Hopefully i will never have to decide which of both is in effect.) Have a nice day :) Thomas
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Quoting Thomas Schmitt (2016-09-18 09:09:09) > Johannes Schauer wrote: > > [the need for Javascript] should be reported as a bug against the tracker. > > Submitted as > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838178 > and subscribed to it. thanks! > > imagine an Architecture:all package doing this: > > #!/bin/sh > > gcc "$@" > > Certainly, what this architecture independent shell script does is > > architecture dependent and thus the package containing it cannot be > > marked as Multi-Arch:foreign. > > How can this script be "Architecture:all" if it does not work as expected > on some architectures ? > https://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Architecture > says: > "all, which indicates an architecture-independent package." > > So is there a difference between "being architecture independent" and > "acting architecture independent" ? > (Hopefully i will never have to decide which of both is in effect.) When we say "an Architecture:all package is architecture independent" then we actually mean to say "an Architecture:all package contains content (files) which are the same across all architectures". In fact, we could easily live without Architecture:all packages. It would just mean that mirrors would then carry many identical binary packages for different architectures. So in the debian/control of src:libisofs you could mark libisofs-doc as Architecture:any and then you would get a libisofs-doc package on each architecture which would be completely identical (because src:libisofs seems to build reproducibly [1]). This would totally work as far as dependency relationships are concerned. It would just "waste" a little bit of mirror space because now you have to store X identical copies of a binary package, where X is the number of architectures in Debian. So the only thing that marking a package as Architecture:all tells you is, that its *content* is equal across all architectures and that it is thus not necessary to build and ship an individual copy of that binary package for each architecture. Thanks! cheers, josch [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/libisofs.html signature.asc Description: signature
Re: partimage/0.6.9-2 new upstream build partimage-0.6.9
Ok Uploaded partimage-0.6.9-1 again... On 18 September 2016 at 00:58, Eriberto wrote: > Hi, > > 2016-09-17 11:38 GMT-03:00 Andrew Worsley : >> On 17 September 2016 at 22:43, Eriberto wrote: >>> Hi Andrew, > > However, the last revision (0.6.9-1) is not in Debian yet. Do you > understand now? The Police tells about revisions already in Debian. > > >> Should I do it again - or is it too late now? > > > Not late! Send to mentors and I will help you. > > Regards, > > Eriberto ok - just uploaded partimage-0.6.9-1 again... - hopefully that is what you meant... -) Andrew
Bug#829520: RFS: mbpfan/1.9.1-1 ITP
On 08/31, Herminio Hernandez, Jr. wrote: Mentors, I am trying to convert my package using git. I am running into the lintian error gbp:error: Can't determine upstream version from changelog Mentors, I am trying to convert my package using git. I am running into the lintian error gbp:error: Can't determine upstream version from changelog Mentors, I am trying to convert my package using git. I am running into the lintian error gbp:error: Can't determine upstream version from changelog Mentors, I am trying to convert my package using git. I am running into the lintian error gbp:error: Can't determine upstream version from changelog Mentors, I am trying to convert my package using git. I am running into the lintian error gbp:error: Can't determine upstream version from changelog Mentors, I am trying to convert my package using git. I am running into the lintian error W: mbpfan source: source-nmu-has-incorrect-version-number 1.9.1-1 Based on what I read here: https://lintian.debian.org/tags/source-nmu-has-incorrect-version-number.html I tried to change the version to -0.1 in the changelog. Now I am getting this error gbp:error: upstream/0 is not a valid treeish If can point into the right direction I would appreciate it. Thanks! Herminio Aug 31, 2016 at 2:43 PM, Sean Whitton > wrote: > > > Dear Herminio, > > > > [please CC the RFS so that your e-mail gets recorded and others can > > provide feedback as well as me -- use reply-to-all] > > > > On Tue, Aug 30, 2016 at 10:23:09PM -0700, Herminio Hernandez, Jr. wrote: > > > I have combined the patches using combinediff. I know you want me to > > convert to > > > git. Can you recommend good documentation to convert my package? Thanks! > > > > One easy way is to do this: > > > > apt-get install git-buildpackage > > gbp import-dsc mbpfan_1.9.1-1.dsc > > > > -- > > Sean Whitton > > signature.asc Description: PGP signature
Bug#838014: marked as done (RFS: imagemagick/8:6.9.5.9+dfsg-1)
Your message dated Sun, 18 Sep 2016 08:46:31 + with message-id <20160918084621.pezpdtwujdnvl...@chase.mapreri.org> and subject line Re: Bug#838014: RFS: imagemagick has caused the Debian Bug report #838014, regarding RFS: imagemagick/8:6.9.5.9+dfsg-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.) -- 838014: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=838014 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: important X-Debbugs-CC: Mattia Rizzolo X-Debbugs-CC: Salvatore Bonaccorso Dear mentors, I am looking for a sponsor for my package "imagemagick" * Package name: imagemagick Version : 8:6.9.5.9+dfsg-1 Section : graphics It builds those binary packages: imagemagick - image manipulation programs -- binaries imagemagick-6-common - image manipulation programs -- infrastructure imagemagick-6-doc - document files of ImageMagick imagemagick-6.q16 - image manipulation programs -- quantum depth Q16 imagemagick-common - image manipulation programs -- infrastructure dummy package imagemagick-doc - document files of ImageMagick -- dummy package libimage-magick-perl - Perl interface to the ImageMagick graphics routines libimage-magick-q16-perl - Perl interface to the ImageMagick graphics routines -- Q16 versio libmagick++-6-headers - object-oriented C++ interface to ImageMagick - header files libmagick++-6.q16-6v6 - object-oriented C++ interface to ImageMagick libmagick++-6.q16-dev - object-oriented C++ interface to ImageMagick - development files libmagick++-dev - object-oriented C++ interface to ImageMagick -- dummy package libmagickcore-6-arch-config - low-level image manipulation library - architecture header files libmagickcore-6-headers - low-level image manipulation library - header files libmagickcore-6.q16-2 - low-level image manipulation library -- quantum depth Q16 libmagickcore-6.q16-2-extra - low-level image manipulation library - extra codecs (Q16) libmagickcore-6.q16-dev - low-level image manipulation library - development files (Q16) libmagickcore-dev - low-level image manipulation library -- dummy package libmagickwand-6-headers - image manipulation library - headers files libmagickwand-6.q16-2 - image manipulation library libmagickwand-6.q16-dev - image manipulation library - development files libmagickwand-dev - image manipulation library -- dummy package perlmagick - Perl interface to ImageMagick -- dummy package To access further information about this package, please visit the following URL: https://mentors.debian.net/package/imagemagick Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/i/imagemagick/imagemagick_6.9.5.9+dfsg-1.dsc More information about hello can be obtained from https://www.example.com. Regards, bastien roucaries --- End Message --- --- Begin Message --- On Sat, Sep 17, 2016 at 09:49:12PM +0200, Bastien ROUCARIÈS wrote: > Le samedi 17 septembre 2016, 17:28:03 CEST Mattia Rizzolo a écrit : > > On Sat, Sep 17, 2016 at 06:23:19PM +0200, Bastien ROUCARIÈS wrote: > > > Done > > > > not in git. > > Pushed Great! I'm uploading it right now! -- 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 --- End Message ---
Bug#836903: RFS: qevercloud/3.0.2+ds-1 [ITP] -- Unofficial Evernote Cloud API library for Qt
Hello,
2016-09-17 22:31 GMT+08:00 Sean Whitton :
> Hello Boyuan,
>
> On Wed, Sep 14, 2016 at 12:23:48PM +0800, Boyuan Yang wrote:
>> Yes, they are up-to-date now. The package on debian-mentors is also
>> updated.
>
> The packaging is in great shape. Here's a review for you.
Thank you for your detailed review!
All the statements below are fixed/adjusted.
> Must-fixes:
> ---
>
> 1. The changelog entry won't close the ITP unless you put a # in front of
> the bug number!
That is indeed my mistake. Fixed.
> 2. We need to test building something against your new shared library,
> and we'll need to confirm that the right dependencies get generated for
> it by dpkg-shlibdeps. If you haven't done so already, could you update
> your nixnote packaging to use your new qevercloud shlib, please?
The new version (2.0~beta9+dfsg-1) was pushed to GitHub, mentors
and debomatic-amd64.
Source package changed (ds -> dfsg) due to unclear license status (as
discussed previously in nixnote2 RFS).
> 3. In a recent commit you renamed debian/{*.symbols => *.symbols.amd64}.
> So now you are not providing any symbols files for other architectures.
> But for a shared library, you need to provide a symbols or shlibs file
> for all the reasons described in ch. 8 of the Debian Policy Manual.
>
> I assume that you did this rename because the symbols files is
> architecture-dependent. That probably means it's very fragile: changes
> which don't break the ABI might change the symbols file. This is a
> known issue with C++ shared libs.[1]
It was indeed because of architecture-dependent symbols of C++.
>
> You need to make the symbols file less fragile (some suggestions
> involving sed(1) here[2]) so that it will work for all archs, or switch
> to a shlibs file instead. README.md suggests that upstream is aware of
> the issue of ABI compatibility, so shlibs files might be enough.
Anyway I switched to shlibs using dh_makeshlibs. It is reasonable for
this package to depend on upstream to keep ABI comaptibility, but I
will also try to test symbol files on each release (even it is not included
in the tarball, it can be stored in the git history).
> Suggestions:
>
>
> 1. Please add Forwarded: headers to the patches.
Added (mostly Forwarded: not-needed).
> 2. It seems like debhelper's cmake buildsystem
> (/usr/share/perl5/Debian/Debhelper/Buildsystem/cmake.pm) should handle
> what your 0001 patch does. Are there situations where we wouldn't want
> GNUInstallDirs? If not, please submit a bug against debhelper.
I was trying to bypass problem No.12 using this patch but failed. After that
I forgot to remove this patch (since it will not harm anything).
This patch is removed now.
> 3. README.md suggests that there is doxygen documentation available for
> generation and install. Please consider installing this in a new
> qevercloud-doc binary package.
The new qevercloud-doc added.
I dropped the tex / pdf / postscript files in the -doc package because
they are not that
useful when html files are provided as well.
> 4. Since you added a "Section:" field to each binary package, the
> "Section: libs" at the top of the file does nothing. Better to remove
> it.
Now I declared the Section in the source package section and removed
the duplicated Section:libs in binary packages.
> 5. Since debhelper 10 has just been released, consider using compat
> level 10.
Just switched.
> 6. Are you sure you need the debian/*.dirs files? Have you tried
> building without them? They are very rarely necessary these days.
Those files are leftovers from original upstream debian packaging
scripts and are (of course) not useful at all in this situation.
Now removed.
> 7. In your rules file you make a lot of explicit calls to dh_auto_*.
> When you do something like this
>
> override_dh_auto_clean:
> dh_auto_clean
> rm -rf $(_QEVERCLOUD_QT5_BUILDDIR)
>
> it's fine, because it's clear to a reader that you are appending to an
> automatic command. However, when you do this:
>
> custom_regenerate_source_code:
> (cd $(_QEVERCLOUD_GENERATOR_DIR); cmake .;)
> dh_auto_build --buildsystem=makefile -- -C
> $(_QEVERCLOUD_GENERATOR_DIR)
> mkdir -p QEverCloud/src/generated
> etc.
>
> the dh_auto_build line is quite hard to understand -- someone would need
> to look up the makefile buildsystem. It would be better to replace that
> with an explicit call to $(MAKE). In dh_auto_build(1) it says "If it
> doesn't work, you're encouraged to skip using dh_auto_build at all, and
> just run the build process manually."
That is reasonable indeed. Switched to call $(MAKE).
> 8. Perhaps rename custom_regenerate_source_code to include the name of
> what you're regenerating, e.g. custom_regenerate_from_thrift.
A meaningful name can be helpful. Fixed.
> 9. Your rules file contains some very long lines. Consider inserting
> line breaks between long arguments.
Lines has been wrapped inside 80
Re: partimage/0.6.9-2 new upstream build partimage-0.6.9
Hi Andrew, Fine! Uploaded. Thanks for your work. Regards, Eriberto 2016-09-18 5:03 GMT-03:00 Andrew Worsley : > Ok Uploaded partimage-0.6.9-1 again... > On 18 September 2016 at 00:58, Eriberto wrote: >> Hi, >> >> 2016-09-17 11:38 GMT-03:00 Andrew Worsley : >>> On 17 September 2016 at 22:43, Eriberto wrote: Hi Andrew, >> >> However, the last revision (0.6.9-1) is not in Debian yet. Do you >> understand now? The Police tells about revisions already in Debian. >> >> >>> Should I do it again - or is it too late now? >> >> >> Not late! Send to mentors and I will help you. >> >> Regards, >> >> Eriberto > ok - just uploaded partimage-0.6.9-1 again... - hopefully that is what > you meant... -) > > Andrew
Bug#837408: marked as done (RFS: partimage/0.6.9-1 new upstream build partimage-0.6.9)
Your message dated Sun, 18 Sep 2016 11:19:01 -0300 with message-id and subject line Re: partimage/0.6.9-2 new upstream build partimage-0.6.9 has caused the Debian Bug report #837408, regarding RFS: partimage/0.6.9-1 new upstream build partimage-0.6.9 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.) -- 837408: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837408 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems --- Begin Message --- Package: sponsorship-requests Severity: normal [important for RC bugs, wishlist for new packages] Dear mentors, I am looking for a sponsor for my package "partimage" * Package name: partimage Version : 0.6.9-1 Upstream Author : Orphaned package * URL : http://www.partimage.org/ * License : GPLv2 Section : admin It builds these binary packages: partimage - backup partitions into a compressed image file partimage-server - server to use partimage across a network To access further information about this package, please visit the following URL: https://mentors.debian.net/package/partimage Alternatively, one can download the package with dget using this command: dget -x https://mentors.debian.net/debian/pool/main/p/partimage/partimage_0.6.9-1.dsc More information about hello can be obtained from https://www.example.com. Changes since the last upload: * New upstream release. * Drop now redundant patches as now in new upstream release: - 01-openssl.patch - 02-format-security.patch new upstream release (from upstream's changelog): 0.6.9) 2010-07-25: applied modifications by Vadim S. (v...@slackware.ru) applied patch nvieville_server_closenowait_clients_number.patch from Nicolas Vieville applied patch nvieville_filesel_NEWT_FLAG_SCROLL.patch from Nicolas Vieville applied patch partimage-0.6.7-chown.patch from mandriva (on Makefile.am) applied patch partimage-0.6.8-format-security.patch from mandriva applied patches from Nicolas Vieville to fix compilation warnings with gcc-4.4 / glibc-2.10 applied patches from Nicolas Vieville to improve internationalisation (mostly on partimaged) applied patches from Nicolas Vieville to free ressources in netclient (fixes memory leaks) applied patches from Nicolas Vieville to fix issues with openssl-1.0.0 allow different versions to connect as long as they use the same protocol and ssl/login options I have created a vfat image (it still has the same slightly clunky X windows / function key interface) and can read the image Regards, Andrew Worsley --- End Message --- --- Begin Message --- Hi Andrew, Fine! Uploaded. Thanks for your work. Regards, Eriberto 2016-09-18 5:03 GMT-03:00 Andrew Worsley : > Ok Uploaded partimage-0.6.9-1 again... > On 18 September 2016 at 00:58, Eriberto wrote: >> Hi, >> >> 2016-09-17 11:38 GMT-03:00 Andrew Worsley : >>> On 17 September 2016 at 22:43, Eriberto wrote: Hi Andrew, >> >> However, the last revision (0.6.9-1) is not in Debian yet. Do you >> understand now? The Police tells about revisions already in Debian. >> >> >>> Should I do it again - or is it too late now? >> >> >> Not late! Send to mentors and I will help you. >> >> Regards, >> >> Eriberto > ok - just uploaded partimage-0.6.9-1 again... - hopefully that is what > you meant... -) > > Andrew--- End Message ---
Bug#838140: RFS: zfs-linux/0.6.5.8-0.1 [NMU] -- git format-patch -- version 4
Hi,
I refreshed the whole patch stack, with some new changes added.
* add a patch to enable zfs-import-scan.service by default.
in 0.6.5.7 all zfs services are enabled, and in 0.6.5.8 all
services are enabled by upstream except for zfs-import-scan.
* add the missing zfs.target .From 2878754d162ec1e8ad11447b5eadc9d19036e3b3 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sun, 18 Sep 2016 14:23:43 +
Subject: [PATCH 1/5] Patch: remove merged patches.
- 1003-Add-tunable-to-ignore-hole_birth.patch
- 1004-ignore-hole_birth-by-default.patch
---
.../1003-Add-tunable-to-ignore-hole_birth.patch| 63 --
.../1004-ignore-hole_birth-by-default.patch| 20 ---
debian/patches/series | 2 -
3 files changed, 85 deletions(-)
delete mode 100644 debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
delete mode 100644 debian/patches/1004-ignore-hole_birth-by-default.patch
diff --git a/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch b/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
deleted file mode 100644
index 3fed916..000
--- a/debian/patches/1003-Add-tunable-to-ignore-hole_birth.patch
+++ /dev/null
@@ -1,63 +0,0 @@
-Description: Add tunable to ignore hole_birth.
- Adds a module option which disables the hole_birth optimization
- which has been responsible for several recent bugs, including
- issue https://github.com/zfsonlinux/zfs/issues/4050.
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Rich Ercolani
-Reviewed-By: Brian Behlendorf
-Applied-Upstream: 6d836e6f8b358270d55a57ad8e8868c957f15bf3 (master commit)
-Last-Update: 2016-08-16
- man/man5/zfs-module-parameters.5 | 13 +
- module/zfs/dmu_traverse.c| 6 +-
- 2 files changed, 18 insertions(+), 1 deletion(-)
-
a/man/man5/zfs-module-parameters.5
-+++ b/man/man5/zfs-module-parameters.5
-@@ -27,6 +27,19 @@
- .sp
- .ne 2
- .na
-+\fBignore_hole_birth\fR (int)
-+.ad
-+.RS 12n
-+When set, the hole_birth optimization will not be used, and all holes will
-+always be sent on zfs send. Useful if you suspect your datasets are affected
-+by a bug in hole_birth.
-+.sp
-+Use \fB1\fR for on and \fB0\fR (default) for off.
-+.RE
-+
-+.sp
-+.ne 2
-+.na
- \fBl2arc_feed_again\fR (int)
- .ad
- .RS 12n
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,6 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
-+int32_t ignore_hole_birth = 0;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
-@@ -250,7 +251,7 @@
- *
- * Note that the meta-dnode cannot be reallocated.
- */
-- if ((!td->td_realloc_possible ||
-+ if (!ignore_hole_birth && (!td->td_realloc_possible ||
- zb->zb_object == DMU_META_DNODE_OBJECT) &&
- td->td_hole_birth_enabled_txg <= td->td_min_txg)
- return (0);
-@@ -692,4 +693,7 @@
-
- module_param(zfs_pd_bytes_max, int, 0644);
- MODULE_PARM_DESC(zfs_pd_bytes_max, "Max number of bytes to prefetch");
-+
-+module_param(ignore_hole_birth, int, 0644);
-+MODULE_PARM_DESC(ignore_hole_birth, "Ignore hole_birth txg for send");
- #endif
diff --git a/debian/patches/1004-ignore-hole_birth-by-default.patch b/debian/patches/1004-ignore-hole_birth-by-default.patch
deleted file mode 100644
index 5eed797..000
--- a/debian/patches/1004-ignore-hole_birth-by-default.patch
+++ /dev/null
@@ -1,20 +0,0 @@
-Description: Enable by default the tunable to ignore hole_birth.
- Once hole_birth becomes more reliable, this patch should be
- removed, making the tunable default back to false.
-Bug: https://github.com/zfsonlinux/zfs/issues/4050
-Bug-Debian: https://bugs.debian.org/830824
-Forwarded: https://github.com/zfsonlinux/zfs/pull/4833
-Author: Carlos Alberto Lopez Perez
-Last-Update: 2016-08-16
-
a/module/zfs/dmu_traverse.c
-+++ b/module/zfs/dmu_traverse.c
-@@ -39,7 +39,7 @@
- #include
-
- int32_t zfs_pd_bytes_max = 50 * 1024 * 1024; /* 50MB */
--int32_t ignore_hole_birth = 0;
-+int32_t ignore_hole_birth = 1;
-
- typedef struct prefetch_data {
- kmutex_t pd_mtx;
diff --git a/debian/patches/series b/debian/patches/series
index d9fac31..26e7ae3 100644
--- a/debian/patches/series
+++ b/debian/patches/series
@@ -4,5 +4,3 @@
1000-ppc64el-endian-support.patch
1002-fix-mips-build.patch
enable-zed.patch
-1003-Add-tunable-to-ignore-hole_birth.patch
-1004-ignore-hole_birth-by-default.patch
--
2.9.3
From 8256e109fd4123f4fd84f905dc9dc8b717714061 Mon Sep 17 00:00:00 2001
From: Zhou Mo
Date: Sun, 18 Sep 2016 14:25:04 +
Subject: [PATCH 2/5] Override dh_fixperms, which fixes a lintian warning.
---
debian/rules | 4
1 file changed, 4 insertions(+)
diff --git a/debian/rules b/debian/rules
index 5036f42..08cf981 100755
--- a/debian/rules
+++ b/debian/rules
@@ -139,6 +139,10 @@ override_dh_install:
find . -name lib*.la -delete
dh_install --list-missing
+override_dh_fixperms:
+ dh_fixperms
+ find debian -type f -name dsl_pool.c -exec chmod -x {} + # f
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-15 10:49, Gianfranco Costamagna wrote: changes are huge, but being half mia, and on lowNMU threshold... (and too many bugs here, so lets do it) First of all, thanks for the detailed review. I have addressed most issues but not yet uploaded a new version to mentors, pending a couple of questions. 1) have patches been upstreamed? Patch 0001 (pkg-config change) comes from the upstream bug tracker and patch 0002 (empty index.html) has been upstreamed. Patch 0003 (removal of /usr/bin/cgicc-config, see also below, point 7) is not, since I see this as a packaging issue rather than an upstream problem. 2) patch description might be nice 3) d/p/003-no-old-style-config.patch So, in case please patch Makefile.am 4) automake, libtool, doxygen, dh-autoreconf doxygen might be needed only for arch:all builds, so you might want to move it into Build-Depends-Indep Fair points, my next upload to mentors will fix these. 5) automake, libtool, are them useful? They are both used in the build. But if I understand you right, are you suggesting to drop the explicit dependencies since dh-autoreconf already depends on automake and libtool? If this is the customary way then I'll drop the explicit dependencies on automake and libtool. 6) new files diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.dirs diff -Nru libcgicc-3.2.9/debian/libcgicc-dev.install why? Uh, these files are not needed and are leftovers from my experiments with a multi-arch library and will be removed in my next upload. 7) /usr/bin/cgicc-config this was shipped before, why are you removing it? This file is made obsolete by the pkg-config file, and it was creating a problem for multiarch packages: it would install in /usr/bin/cgicc-config, making it impossible to install two architectures of this package. Also, https://lintian.debian.org/tags/old-style-config-script.html says: | Using this kind of system to pass compile file is obsolete and will likely introduce bugs in a multi-arch system. | Particularly, this kind of script could only belong to a package that is not Multi-Arch. So I took this as excuse to remove the file from the package. One possible solution (suggested by lintian) is to move the file out of the way (to /usr/share/doc, I presume) so it is still shipped, but it won't be found by build tools, which kind of defeats its purpose. I'm doubtful there is any benefit in shipping this file. 8) library changed soname? from libcgicc.so.5.0.2 to libcgicc.so.3.2.10 As far as I can see from the CVS changes, the 'current' value in the soname was increased in the early 2000's, presumably due to ABI changes. Then in 2013 the soname was decreased from 5 to 3 in order to match the library version. This was done as part of these bugs: https://savannah.gnu.org/bugs/?func=detailitem&item_id=38053 https://savannah.gnu.org/bugs/?func=detailitem&item_id=38224 I presume the package should follow the upstream soname. And this would probably also justify the renamed package, as you were musing in your mail. If there are no objections, I will rename the packages from libcgicc5 to libcgicc. W: libcgicc5: package-name-doesnt-match-sonames libcgicc3 This should be fixed by the renaming from libcgicc5* -> libcgicc*. X: libcgicc5: shlib-calls-exit usr/lib/x86_64-linux-gnu/libcgicc.so.3.2.10 (^^ this is something for upstream) Raised as https://savannah.gnu.org/bugs/index.php?49120 Thanks, Thomas
Bug#838217: RFS: license-reconcile/0.12+nmu1 [NMU] [RC]
Package: sponsorship-requests Severity: important I'm looking for a sponsor for my NMU on license-reconcile It closes an FTBFS RC bug. The debdiff is attached The package can be downloaded from -mentors https://mentors.debian.net/debian/pool/main/l/license-reconcile/license-reconcile_0.12+nmu1.dsc Changes since the last upload: license-reconcile (0.12+nmu1) unstable; urgency=low [ gustavo panizzo ] * Non-maintainer upload. * Update test cases to match licensecheck output. Thanks Petter Reinholdtsen for the patches, Fix FTBFS (Closes: #832840). [ gregor herrmann ] * Remove Nicholas Bamber from Uploaders. Thanks for your work! -- gustavo panizzo Sun, 18 Sep 2016 10:40:39 +0800 Upstream had a change non yet published but it is non-functional, so I've included it as well. The maintainer (gregoa) and the umbrella group (perl group) are on https://wiki.debian.org/LowThresholdNmu The NMU fixes the tests as the output on the underlying tool has changed. thanks! -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (300, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.6.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) diff -Nru license-reconcile-0.11/debian/changelog license-reconcile-0.12+nmu1/debian/changelog --- license-reconcile-0.11/debian/changelog 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/debian/changelog 2016-09-18 10:40:39.0 +0800 @@ -1,3 +1,15 @@ +license-reconcile (0.12+nmu1) unstable; urgency=low + + [ gustavo panizzo ] + * Non-maintainer upload. + * Update test cases to match licensecheck output. Thanks Petter Reinholdtsen +for the patches, Fix FTBFS (Closes: #832840). + + [ gregor herrmann ] + * Remove Nicholas Bamber from Uploaders. Thanks for your work! + + -- gustavo panizzo Sun, 18 Sep 2016 10:40:39 +0800 + license-reconcile (0.11) unstable; urgency=medium * debian/copyright: change Copyright-Format 1.0 URL to HTTPS. diff -Nru license-reconcile-0.11/debian/control license-reconcile-0.12+nmu1/debian/control --- license-reconcile-0.11/debian/control 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/debian/control 2016-09-16 09:27:33.0 +0800 @@ -1,6 +1,6 @@ Source: license-reconcile Maintainer: Debian Perl Group -Uploaders: gregor herrmann , Nicholas Bamber +Uploaders: gregor herrmann Section: devel Testsuite: autopkgtest-pkg-perl Priority: optional diff -Nru license-reconcile-0.11/lib/Debian/LicenseReconcile/App.pm license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/App.pm --- license-reconcile-0.11/lib/Debian/LicenseReconcile/App.pm 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/App.pm 2016-09-18 10:23:37.0 +0800 @@ -244,11 +244,11 @@ =head1 VERSION -Version 0.11 +Version 0.12+nmu1 =cut -our $VERSION = '0.11'; +our $VERSION = '0.12+nmu1'; =head1 SYNOPSIS @@ -289,6 +289,8 @@ =head2 files +=head2 suggest_stanzas + =head1 AUTHOR Nicholas Bamber, C<< >> diff -Nru license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightDatum/Holder.pm license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightDatum/Holder.pm --- license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightDatum/Holder.pm 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightDatum/Holder.pm 2016-09-17 20:18:04.0 +0800 @@ -61,11 +61,11 @@ =head1 VERSION -Version 0.11 +Version 0.12+nmu1 =cut -our $VERSION = '0.11'; +our $VERSION = '0.12+nmu1'; =head1 SYNOPSIS diff -Nru license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightDatum.pm license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightDatum.pm --- license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightDatum.pm 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightDatum.pm 2016-09-17 20:24:09.0 +0800 @@ -214,11 +214,11 @@ =head1 VERSION -Version 0.11 +Version 0.12+nmu1 =cut -our $VERSION = '0.11'; +our $VERSION = '0.12+nmu1'; =head1 DESCRIPTION diff -Nru license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightTarget.pm license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightTarget.pm --- license-reconcile-0.11/lib/Debian/LicenseReconcile/CopyrightTarget.pm 2016-07-05 20:20:50.0 +0800 +++ license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/CopyrightTarget.pm 2016-09-17 20:18:48.0 +0800 @@ -100,11 +100,11 @@ =head1 VERSION -Version 0.11 +Version 0.12+nmu1 =cut -our $VERSION = '0.11'; +our $VERSION = '0.12+nmu1'; =head1 SYNOPSIS diff -Nru license-reconcile-0.11/lib/Debian/LicenseReconcile/Errors.pm license-reconcile-0.12+nmu1/lib/Debian/LicenseReconcile/Errors.pm --- license-reconcile-0.11/lib
Bug#838140: 838140
Hi lumin, please update the sources for download thanks
Bug#837798: RFS: libcgicc/3.2.16-0.1 NMU -- C++ class library for writing CGI applications
On 2016-09-18 17:39, Thomas Pircher wrote: W: libcgicc5: package-name-doesnt-match-sonames libcgicc3 This should be fixed by the renaming from libcgicc5* -> libcgicc*. Thinking again, I guess that's not correct. This would require the packages to be renamed to libcgicc3. Thomas
Bug#838239: RFS: budgie-desktop/10.2.7-2
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package "budgie-desktop" * Package name: budgie-desktop Version : 10.2.7-2 Upstream Author : i...@solus-project.com * URL : https://github.com/solus-project/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-desktop-1.0 - GNOME introspection library for budgie-desktop libbudgie-plugin0 - Plugin 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.2.7-2.dsc Notes: As requested as part of the previous submission (#837609) I've looked at trying to remove the upstream generated C files through the maintainer recommended "make maintainer-clean". Unfortunately this removes more than it should and the subsequent source does not rebuild. I'll continue looking at this but for the moment this bug-fix submission does not include this packaging change. Notes 2: This patch added has been deemed a priority 1 by the upstream maintainer since it causes lots of crashes around power management. Changes since the last upload: * Add patch to fix crash - 0003 - update to upower 0.99API to stop panel crash Regards, David Mohammed
Javascript Re: Multiarch hinter on package tracker: Shall i obey ?
Without Javascript the web becomes a much more unexcited place. Regrettably Iceweasel seems not to offer finely granulated enabling. A whitelist would be nice. That's available in xul-ext-noscript
Re: Multiarch hinter on package tracker: Shall i obey ?
Hi, Rebecca N. Palmer wrote: > xul-ext-noscript I will check this out. Have a nice day :) Thomas
