Re: NATS Server Debian Package
On 27/08/2019 22.43, Colin Sullivan wrote: > Soft ping... Would you be willing to provide some guidance and > sponsor us? Hello Colin, Are you subscribed to the mailing-list? Below is what I replied two weeks ago. You'll also find another reply in the list archive. [3] As a prospective user of NATS, I'd welcome its inclusion in Debian. :) Have you already contacted the Debian Go Packaging team? [1] They can probably help you prepare your package for Debian. I think one thing in particular that Debian requires and is very alien to golang developers is that all your software's dependencies must also be Debian packages. A Debian package isn't allowed to contain copies of code from other software packages. [2] Likewise, your build system can't download dependencies to build and link them (Debian's servers build packages without network access). I hope this helps you getting started. Cheers, Etienne [1] https://go-team.pages.debian.net/ [2] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-of-code [3] https://lists.debian.org/debian-mentors/2019/08/msg00098.html signature.asc Description: OpenPGP digital signature
Re: NATS Server Debian Package
On 14/08/2019 21.15, Colin Sullivan wrote: > Would you be willing to provide some guidance and sponsor us? Hello Colin, As a prospective user of NATS, I'd welcome its inclusion in Debian. :) Have you already contacted the Debian Go Packaging team? [1] They can probably help you prepare your package for Debian. I think one thing in particular that Debian requires and is very alien to golang developers is that all your software's dependencies must also be Debian packages. A Debian package isn't allowed to contain copies of code from other software packages. [2] Likewise, your build system can't download dependencies to build and link them (Debian's servers build packages without network access). I hope this helps you getting started. Cheers, Etienne [1] https://go-team.pages.debian.net/ [2] https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-of-code signature.asc Description: OpenPGP digital signature
Re: .dput.cf WAS: Upload failed: 301 Moved Permanently
On 21/03/18 12:58, Mattia Rizzolo wrote: > Like I said in my first post¹, just to fulfil my curiosity. > As an admin of mentors.d.n (and as a chronically lazy person) I'm > curious as to why anybody would go to the extra length of using a local > configuration when both dput and dput-ng ship with good enough default > one. I vaguely remember creating my ~/.dput.cf when I began packaging and using mentors.d.n following some instructions somewhere... Maybe people do it because https://mentors.debian.net/intro-maintainers shows example dput configurations? This suggests that some configuration is needed in order to upload to mentors after installing dput. The phrasing of section "How to upload packages to mentors.debian.net?" could be changed to say that dput's default configuration is enough. Cheers, Etienne signature.asc Description: OpenPGP digital signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 21/01/17 09:32, Ferenc Wágner wrote: > Shall I upload the backport, or do you plan to add anything else? Yes, please upload it. :) I updated the debian/jessie-backports branch with the contents of the package on mentors. Etienne signature.asc Description: OpenPGP digital signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 20/01/17 12:31, Ferenc Wágner wrote: > https://www.debian.org/doc/debian-policy/ch-maintainerscripts.html says: > > The postrm script is called after the package's files have been > removed or replaced. The package whose postrm is being called may > have previously been deconfigured and only be "Unpacked", at which > point subsequent package changes do not consider its dependencies. > Therefore, all postrm actions may only rely on essential packages > and must gracefully skip any actions that require the package's > dependencies if those dependencies are unavailable. > > This is exactly what happens. Shibboleth-sp2-utils is removed, then > init-system-helpers is removed, then shibboleth-sp2-utils is purged, but > it can't use init-system-helpers to fully clean up after itself. Ah I see! thanks for the reference :) Since init-system-helpers is not marked as essential in jessie and is installed as a dependency during the piuparts test, it gets removed. > But we'd still need the functionality of dh-systemd in our backport. > I'll look through #822670 and #837585 for hints. Just keeping dh-systemd (without version, like I added in commit 518aa2b) in the build dependencies is enough I think. piuparts with --warn-on-leftovers-after-purge does not report other problems. Will this piuparts error block the package from getting into jessie-backports? Etienne signature.asc Description: OpenPGP digital signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 19/01/17 23:46, Ferenc Wágner wrote: > I couldn't reproduce this on a real jessie system, only in a piuparts > chroot. I think the reason is that piuparts removes init-system-helpers > (the home of deb-systemd-helper) before the shibboleth-sp2-utils postrm > could instruct it to clean up. I'm not sure what we could do about > this. Indeed piuparts does remove init-system-helpers before shibboleth-sp2-utils. I hadn't noticed before but it's in the log: > 0m33.9s DEBUG: Command ok: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', '--purge', > 'libxerces-c3.1:amd64', 'libcurl4-openssl-dev:amd64', 'libshibsp-dev:amd64', > 'librtmp1:amd64', 'libgssapi-krb5-2:amd64', 'libssh2-1:amd64', > 'libxml-security-c17:amd64', 'libaprutil1:amd64', 'libk5crypto3:amd64', > 'libfcgi0ldbl', 'libxml-security-c-dev:amd64', 'libkeyutils1:amd64', > 'zlib1g-dev:amd64', 'libshibsp-plugins:amd64', 'init-system-helpers', > 'libaprutil1-dbd-sqlite3:amd64', 'libapr1:amd64', 'libicu-dev:amd64', > 'libldap-2.4-2:amd64', 'liblog4shib1:amd64', 'libxmltooling-dev:amd64', > 'libssl1.0.0:amd64', 'libnettle4:amd64', 'icu-devtools', 'liblua5.1-0:amd64', > 'libssl-dev:amd64', 'libtasn1-6:amd64', 'libxmltooling7:amd64', > 'libkrb5-3:amd64', 'libsasl2-modules-db:amd64', 'libexpat1:amd64', > 'libltdl7:amd64', 'libsaml9:amd64', 'libaprutil1-ldap:amd64', > 'libodbc1:amd64', 'libicu52:amd64', 'libxml2:amd64', 'libidn11:amd64', > 'apache2-bin', 'libsaml2-dev:amd64', 'liblog4shib-dev', 'libshibsp7:amd64', > 'libmemcached11:amd64', 'libffi6:amd64', 'libgnutls-deb0-28:amd64', > 'libcurl3:amd64', 'libkrb5support0:amd64', 'opensaml2-schemas', > 'libsasl2-2:amd64', 'libxerces-c-dev', 'xmltooling-schemas', > 'libhogweed2:amd64', 'libp11-kit0:amd64'] > 0m33.9s DEBUG: Starting command: ['chroot', '/tmp/tmpH_vjLg', 'dpkg', > '--purge', 'libshibsp-doc', 'shibboleth-sp2-common', 'shibboleth-sp2-utils', > 'libapache2-mod-shib2'] Why would puiparts do it in this order? shibboleth-sp2-utils depends on init-system-helpers! >> So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). > > Why? I mean, where did this version number come from? The version comes from debhelper's changelog in jessie-backports [1]. It's when dh-systemd was moved to debhelper. Since adding this version constraint was motivated by piuparts's report, it may not be necessary in the end... Etienne [1] http://metadata.ftp-master.debian.org/changelogs/main/d/debhelper/debhelper_10.2.2~bpo8+1_changelog signature.asc Description: OpenPGP digital signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 17/01/17 18:30, Niels Thykier wrote: >>> E: libshibsp7: postinst-must-call-ldconfig >>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 > > This lintian error: > > * is aimed at stretch or later, and > * should be ignored for stable and stable-backports After having overridden this lintian error, it turns out it was a bit of a red herring: piuparts still reports files left after purging. > 0m39.2s ERROR: FAIL: Package purging left files on system: > /etc/systemd/system/multi-user.target.wants/shibd.service -> > /lib/systemd/system/shibd.service not owned > /etc/systemd/system/shibd.service -> /dev/null not owned > /var/lib/systemd/deb-systemd-helper-enabled/ not owned > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ > not owned > > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service > not owned > /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also not > owned > /var/lib/systemd/deb-systemd-helper-masked/ not owned > /var/lib/systemd/deb-systemd-helper-masked/shibd.service not owned So is the postrm script from shibboleth-sp2-utils not executed? signature.asc Description: OpenPGP digital signature
Re: Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
On 17/01/17 18:30, Niels Thykier wrote: >>> E: libshibsp7: postinst-must-call-ldconfig >>> usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 > > This lintian error: > > * is aimed at stretch or later, and > * should be ignored for stable and stable-backports Thanks Niels! :) That's a bit strange though because I'm running lintian from stable (2.5.30+deb8u4). It wouldn't surprise me if I were running a more recent version. I'll create an override for this test in jessie-backports then. Cheers, Etienne signature.asc Description: OpenPGP digital signature
Backporting shibboleth-sp2 2.6.0+dfsg1-4 to jessie: dh-systemd, piuparts and lintian errors
Hello mentors, Since shibboleth-sp2 2.6.0+dfsg1-4 migrated to testing during the holidays, I'm now backporting it to jessie. So far there is nothing to change, however piuparts gives me the following error (which does not appear on stretch): > 0m34.6s ERROR: FAIL: Package purging left files on system: > /etc/systemd/system/multi-user.target.wants/shibd.service -> > /lib/systemd/system/shibd.service not owned > /etc/systemd/system/shibd.service -> /dev/null not owned > /var/lib/systemd/deb-systemd-helper-enabled/ not owned > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/ > not owned > > /var/lib/systemd/deb-systemd-helper-enabled/multi-user.target.wants/shibd.service > not owned > /var/lib/systemd/deb-systemd-helper-enabled/shibd.service.dsh-also not > owned > /var/lib/systemd/deb-systemd-helper-masked/ not owned > /var/lib/systemd/deb-systemd-helper-masked/shibd.service not owned It looked like dh-systemd wasn't properly cleaning up despite shibboleth-sp2-utils's postrm script looking like it would: > #!/bin/sh > > set -e > > if [ "$1" = purge ]; then > for dir in /var/cache/shibboleth /var/log/shibboleth; do > if dpkg-statoverride --list "$dir" >/dev/null 2>&1; then > dpkg-statoverride --remove "$dir" > fi > rm -rf "$dir" > done > fi > > # Automatically added by dh_installinit > if [ "$1" = "purge" ] ; then > update-rc.d shibd remove >/dev/null > fi > > > # In case this system is running systemd, we make systemd reload the unit > files > # to pick up changes. > if [ -d /run/systemd/system ] ; then > systemctl --system daemon-reload >/dev/null || true > fi > # End automatically added section > # Automatically added by dh_systemd_enable > if [ "$1" = "remove" ]; then > if [ -x "/usr/bin/deb-systemd-helper" ]; then > deb-systemd-helper mask shibd.service >/dev/null > fi > fi > > if [ "$1" = "purge" ]; then > if [ -x "/usr/bin/deb-systemd-helper" ]; then > deb-systemd-helper purge shibd.service >/dev/null > deb-systemd-helper unmask shibd.service >/dev/null > fi > fi > # End automatically added section So I bumped the build-dep up a bit to: dh-systemd (>= 9.20160709). But then a get a lintian error > E: libshibsp7: postinst-must-call-ldconfig > usr/lib/x86_64-linux-gnu/libshibsp.so.7.0.0 that I don't understand because the postinst script in libshibsp7_2.6.0+dfsg1-4~bpo8+1_amd64.deb contains: > #!/bin/sh > set -e > # Automatically added by dh_makeshlibs > if [ "$1" = "configure" ]; then > ldconfig > fi > # End automatically added section So hmm... any clues? Who's wrong? me, piuparts, lintian or debhelper? My source package is available at https://mentors.debian.net/package/shibboleth-sp2 if you want to take a look at it. Etienne signature.asc Description: OpenPGP digital signature
Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Thank you very much for your review Gianfranco. :) On 10/08/16 11:31, Gianfranco Costamagna wrote: > 1) really? what about don't care to wheezy anymore? What do you mean? Should backports only be done for jessie now? Here is the backstory: we (SWITCH) are providing Shibboleth packages for Debian and Ubuntu to members of our community (universities and high schools in Switzerland). We chose to support wheezy, jessie, precise, trusty and xenial as you can see in our Shibboleth Service Provider installation guide [1]. To this end, I'm already packaging for all five distributions so why not have Debian benefit from it by contributing backports at the same time? Also, I want our packages to be closer to Debian's to 1) avoid version conflicts 2) reduce the repackaging needed on our end. [1] https://www.switch.ch/aai/guides/sp/installation/ > Did you get in touch with the maintainers? they seems active, one > of them is a DM, and might be able to upload it for you if needed Yes, I'm in touch with Ferenc Wágner. He wasn't able to upload that package yesterday evening. > 2) > > this looks wrong to me. the library has been renamed and > conflicting with the non-v5 version, because of the libstdc++ > transition. > > backporting to jessie and wheezy (where the transition didn't > happen), means you have to revert that change, because otherwise > the package will be uninstallable with all of the reverse > dependencies, because of: Package: libxml-security-c17v5 > > Conflicts: libxml-security-c17, Replaces: libxml-security-c17, Oh good catch! I'll revert the names to c17. > 3) > > also, can the new patch be added to the package in unstable too? - > * [aba87f7] New patch > Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch > > is it a breaking and non-compatible with new pkg-config change? I'll defer to Ferenc on that one. > 4) dpkg-source: warning: failed to verify signature on > /tmp/xml-security-c_1.7.3-3~bpo7+1.dsc > > dpkg-source: error: file /tmp/xml-security-c_1.7.3.orig.tar.gz has > size 909320 instead of expected 897454 > > please use the right orig tarball, thanks. Will do at the next upload. Should I increment the bpo revision for the next upload (bpo7+2)? Cheers, Etienne -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJXqwk3AAoJEDtvu5hdVFPu1foQAJ3IYdbeUfC469j5hIY6kATu 6yec4wIr9T4bnuG5jlsbiEThZFdGjMG30Oy82qyyoYvCq5Y3Wf/XycGRSm4yQj8V jz0Mc67pfUvoHDGTEuo/hq3OBod7iWIYp/O2AL1fhxC3OtYs/E6brMVIlSg9EySp lSETydFiyUzYXMbqQhxXO0fUn3Q7hovEluzcFNOEPVSiCe9WH4Zcl1MXXRpq4dv1 ZJdFyB4m4gjClYTTEzHphZANrzpSB+aPtJNabOeI1gGyTOYgFOXcYqP1BzqwEEA1 uFA8zQbGlkWERJWu9zr9G/sGiiV1cbFn9SG/BH/Xr9Y49TGALotqDxP8XE19c7Q5 YULxhc8AFRWZkxvGgktzfcm8gDIi5kk1PSE5dvFUEwFqHtZA9QBkoZEJ4BhfgAKa U3+qYPDYFkdo0nJ+cGNz8GQkTy/4aVhO2V8wvc5r9rS+AbD3Z5Bll20sKMT/JacA RSe5ih2qqtFXipxYGYgT/FbO4YCoAzaenG37PyiSAGILL9rM/eDjB+LHldMiUqvo TlWfhIr5L5bI8Tz9USdDkm3olaW2Ju4+OWNxr8Hvj1YZ3s3ZU8zVB+J8FwWuehiE TInzXCt7fhbF+ub/jDul8Mgn/G+OKkIiHg9h8pmjJ4pXAshZlCIYRArr+4hFxKcR PfJY+Cror7LT894JUHhm =32aN -END PGP SIGNATURE-
Bug#833909: RFS: xml-security-c/1.7.3-3~bpo7+1 [BPO]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my backport of package "xml-security-c" to wheezy-backports-sloppy as a first step to backporting other Shibboleth packages to wheezy and jessie (see https://qa.debian.org/developer.php?email=pkg-shibboleth-devel%40lists.a lioth.debian.org for a list of Shib packages). * Package name: xml-security-c Version : 1.7.3-3~bpo7+1 Upstream Author : http://santuario.apache.org/team.html * URL : http://santuario.apache.org/cindex.html * License : Apache-2.0 Section : libs It builds those binary packages: libxml-security-c-dev - C++ library for XML Digital Signatures (development) libxml-security-c17v5 - C++ library for XML Digital Signatures (runtime) xml-security-c-utils - C++ library for XML Digital Signatures (utilities ) To access further information about this package, please visit the following URL: https://mentors.debian.net/package/xml-security-c Alternatively, one can download the package with dget using this command : dget -x https://mentors.debian.net/debian/pool/main/x/xml-security-c/xml-securit y-c_1.7.3-3~bpo7+1.dsc More information about xml-security-c can be obtained from http://santuario.apache.org/cindex.html. Changes since the last upload (wheezy 1.6.1-5+deb7u2): xml-security-c (1.7.3-3~bpo7+1) wheezy-backports-sloppy; urgency=medium . [ Etienne Dysli Metref ] * Rebuild for wheezy-backports-sloppy. * [aba87f7] New patch Remove-PKG_INSTALLDIR-to-build-with-older-pkg-config.patch . xml-security-c (1.7.3-3) unstable; urgency=medium . * [dee8abd] New patch Only-add-found-packages-to-the-pkg-config- dependenci.patch . xml-security-c (1.7.3-2) unstable; urgency=medium . * [9af4b2f] New patches fixing GCC-6 FTBFS, warnings and typos (Closes: #811620) * [eb1af76] Update Standards-Version to 3.9.8 (no changes needed) * [e742472] Switch to secure VCS URIs * [894b638] New patch Use-pkg-config-for-Xerces-OpenSSL-and-NSS-and- provid.patch * [64c49b7] New patch We-do-not-use-pthreads-threadtest.cpp-is-Window s- onl.patch * [a5a8a19] The build system now links with the needed libraries only . xml-security-c (1.7.3-1) unstable; urgency=medium . * [df661d6] Check signature in watch file * [b78a045] Add debian/gbp.conf enabling pristine-tar * [ca9476a] Imported Upstream version 1.7.3 * [f8b635d] Delete upstreamed patch "Avoid use of PATH_MAX where possible" * [9d2337f] Switch watch file to check for bzip-compressed archives * [f95b4ef] The default compressor is xz since jessie * [ed19f44] Renaming of the binaries happends via a patch since 4771f62 and 017dc35 * [34dd591] Enable all hardening features * [893eda7] Remove superfluous dh_clean override * [2207b52] Fail package build if any installed file is left out in the future * [62c8d2f] Add myself to Uploaders * [4afa12e] Update Standards-Version to 3.9.6 (no changes needed) * [d338569] Since 2b8a713 we've got proper patch files * [cd68dec] Enable commit ids in gbp dch * [71cc459] Add version number to the manual pages * [e544a7b] Run wrap-and-sort -ast on the package * [cf73c2b] Get rid of patch numbers * [0832cf9] New patch Avoid-forward-incompatibility-warnings-from-Automake.patch * [3099c82] Comment the --as-needed tricks * [e26686c] Update debian/copyright * [3fad239] Add NOTICE.txt to all binary packages * [4eaef76] Incorporate the 1.7.2-3.1 NMU. Thanks to Julien Cristau. . xml-security-c (1.7.2-3.1) unstable; urgency=medium . * Non-maintainer upload. * Rename library packages for g++5 ABI transition (closes: 791323). . xml-security-c (1.7.2-3) unstable; urgency=medium . * Avoid use of PATH_MAX where possible by using getcwd to allocate th e appropriate size string. Fixes FTBFS on GNU/Hurd. Patch from Svan te Signell. (Closes: #735162) * Convert all Debian patches to separate patch files managed via gbp pq. * Update standards version to 3.9.5 (no changes required). . xml-security-c (1.7.2-2) unstable; urgency=low . * Upload to unstable. . xml-security-c (1.7.2-1) experimental; urgency=high . * New upstream release. - The attempted fix to address CVE-2013-2154 introduced the possibility of a heap overflow, possibly leading to arbitrary cod e execution, in the processing of malformed XPointer expressions in the XML Signature Reference processing code. Fix that heap overflow. (Closes: #714241, CVE-2013-2210) . xml-security-c (1.7.1-1) experimental; urgency=high . * New upstream release. - Fix a spoofing vulnerability that allows an attacker to reuse existing signatures with arbitrary content. (CVE-2013-2153) - Fix a stack overflow in the processing of malformed XPointer expressions in the XML
Re: backport questions
On 23/07/16 01:07, Ferenc Wágner wrote: >> - Can I push the backport branches to the repositories in [1]? > > Yes, please do so. Please discuss the necessary changes on our mailing > list beforehand, I'd like to keep the delta small. > >> - What should the changelog entry look like? "Backport to "? > > Start with what dch --bpo proposes, then add new bullets for your > backporting changes (if needed). > >> - Are older "backport" changelog entries kept or removed when a new >> version is backported? > > I think it means that you can keep them (interleaved by the unstable > entries), or you can merge them into a single entry at the tip. The > former is probably easier to generate, while the latter is easier to > grasp. Thank you for the explanations Feri! :) Etienne signature.asc Description: OpenPGP digital signature
Re: backport questions
On 22/07/16 14:15, Alexander Wirt wrote: >> And the distribution field should be the backport target >> (jessie-backports-sloppy), right? > Depends on your backport. The one that matches to your backport. And > jessie-backports-sloppy is in every case wrong at this point in time. Ah right, yes! that should be jessie-backports or wheezy-backports-sloppy. Etienne signature.asc Description: OpenPGP digital signature
Re: backport questions
Thank you Alex :) On 22/07/16 13:16, Alexander Wirt wrote: >> - Can I push the backport branches to the repositories in [1]? > The backports team doesn't care about the git, you will have to ask the other > maintainers. Ok >> - What should the changelog entry look like? "Backport to "? > That + all backports specific changes to the package. And the distribution field should be the backport target (jessie-backports-sloppy), right? Cheers, Etienne signature.asc Description: OpenPGP digital signature
backport questions
Hello mentors, I would like to backport Shibboleth packages [1] to jessie and wheezy. - What branch name should I use? Documentation for git-buildpackage [2] says "debian/" so that would yield "debian/jessie-backports-sloppy", but I've seen "backports/" earlier so I'm unsure. - Can I push the backport branches to the repositories in [1]? - What should the changelog entry look like? "Backport to "? - Are older "backport" changelog entries kept or removed when a new version is backported? The Backports contribution doc [3] says: > Backports of an updated version of a package that was backported > before may have a changelog that merges entries of backports of > previous versions, but this is not required. but I can't make sense out of this... Thanks for your help, Etienne [1] https://anonscm.debian.org/cgit/pkg-shibboleth/ [2] http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING [3] https://backports.debian.org/Contribute/ signature.asc Description: OpenPGP digital signature
