Re: Re: Cannot create chroots with cowbuilder because of usr-is-merged
> Try > DEBOOTSTRAPOPTS="--merged-usr" > > in your ~/.pbuilderrc > > In trixie and sid, all chroots, including those to build packages, > are already supposed > to be usr-merged. Enabling proposed-updates on Debian 11 or 12, to get the new debootstrap, will also allow to create new unstable/testing chroots out of the box, without config changes. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
On Fri, 29 Jul 2022 at 22:44, Ben Westover wrote: > > Hi Luca, > > On 7/29/22 5:50 AM, Luca Boccassi wrote: > > Still a couple of Lintian warnings to fix, then you can finalize the > > changelog and I'll upload: > > > > I: pacman-package-manager source: duplicate-long-description libalpm-dev > > libalpm13 [debian/control] > > I: libalpm-dev: extended-description-is-probably-too-short > > Fixed > > > I: libalpm13: extended-description-is-probably-too-short > > There's not really much more information to say on libalpm; I don't know > what else to put in the description without making it a word salad. > > > I: libalpm13: package-contains-empty-directory [usr/share/libalpm/hooks/] > > I: makepkg: package-contains-empty-directory [usr/share/makepkg-template/] > > Fixed > > > This one doesn't need to be fixed in the package, just send a patch > > upstream and it can be picked up in the next version: > > > > I: pacman-package-manager: typo-in-manual-page "allows to" "allows one to" > > [usr/share/man/man8/pacman.8.gz:264] > > Sent the patch upstream. > > I didn't even know about these Lintian tags since lintian by default > only shows warnings and above (these are info tags). I've updated my > machine's Lintian config to show me everything, even down to pedantic. > My (minor) changes have been pushed to Salsa and Mentors. Looks good, uploaded.
Re: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
On Thu, 2022-07-28 at 22:55 -0400, Ben Westover wrote:
> Hello Luca and Michel,
>
> On 7/28/22 5:50 PM, Michel Alexandre Salim wrote:
> > Hi Ben,
> > I was independently working on pacman, and (thanks to the name
> > collision with the existing pacman package) didn't notice this until
> > it's mostly done.
>
> That existing package is orphaned anyway, so it's annoying that it's
> already there and not even being maintained. I do think it's still a
> good idea to keep the current package name so people don't get confused
> and accidentally install a potentially dangerous package manager for
> another distribution instead of an arcade game.
>
> > My use case is helping make systemd/mkosi CI easier (since it's hosted
> > on GitHub, which provides Ubuntu LTS builders) - I'll flag this to
> > some relevant people so they can help get this sponsored.
> >
> > PS archlinux-keyring is on its way to unstable, and per some feedback
> > the keyring target directory is moved to the standard Debian path:
> >
> > https://salsa.debian.org/michel/archlinux-keyring/-/blob/main/debian
> > /patches/use_std_keyring_dir.diff
> >
> > might want to apply this to your pacman, and configure pacman to use
> > this path:
> >
> > https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/11
>
> Okay, I've added the patch to my package and configured the keyringdir
> option in debian/rules.
>
> On 7/28/22 6:27 PM, Luca Boccassi wrote:
> > Hi,
> >
> > I can sponsor this.
> >
> > A few remarks, aside from the keyring change mentioned by Michel:
> >
> > - all the doc build-dependencies (asciidoc, doxygen, help2man) can be
> > marked with so that nodoc builds can be done
> > - are curl and fakechroot really needed to build the package, or are
> > they just used by self tests? if they are used only by tests, mark them
> > as
> > - is pkgconf really needed instead of pkgconfig, which is the default?
> > - you need to add a libalpm-dev and ship the headers, pkgconfig file,
> > unversioned .so and manpage in it, instead of in libalpm13, and remove
> > the lintian override
> > - libalpm13 is missing Pre-Depends: ${misc:Pre-Depends}
> > - no need to specify the libarchive-tools and libgpgme11 dependencies
> > on libalpm13, they will be autogenerated
> > - does libalpm13 really need to depend on the binary curl executable?
>
> Thanks, all of those have been fixed.
>
> > - makepkg should not depend on build-essential nor on sudo
>
> I was under the impression that makepkg depended on sudo, but after a
> deeper look into the code, it appears to fall back on su if sudo is not
> detected. I put build-essential there since makepkg expects base-devel,
> the Arch Linux equivalent of build-essential, to be installed. I've now
> removed sudo from Depends and moved build-essential to Recommends since
> in most cases you would want it installed but it's not required.
>
> > - no need to manually specify the dependency on libalpm13 in makepkg,
> > it will be autogenerated
> > - libalpm13 is missing the symbols file, you can generate it after
> > building the library with:
> > dpkg-gensymbols -plibalpm13
> > -edebian/tmp/usr/lib/x86_64-linux-gnu/libalpm.so.13.0.1
> > -Odebian/libalpm13.symbols
> > - makepkg is missing a dependency on ${perl:Depends}
>
> Fixed
>
> > - are you sure all of these can run on GNU/Hurd and debian/kFreeBSD? If
> > not, use 'linux-any' instead of 'any' as the architecture
>
> Funny you should say that; I actually have a Debian GNU/kFreeBSD system
> that I installed out of curiosity last year. When I was originally
> making this package, I tested it out on that system and it worked.
>
> > - it is not necessary anymore to specify the build system in
> > debian/rules, meson is autodetected
> > - use execute_before_dh_auto_clean instead of override_
>
> Fixed
>
> > - 228 tests fail when running in a pbuilder chroot, this is a strong
> > hint that the build might fail once uploaded
>
> I use sbuild instead of pbuilder since it's considered to be legacy at
> this point. As Michel noted, these failures are solved by two additional
> build depends (one of which you should've already had) which I've added.
>
> > - you should try and fix the reproducible build, rather than disabling
> > it in the CI
>
> I've tested reproducibility with reprotest and it's perfectly
> reproducible. Salsa CI fails a bunch of tests on its second
> reproducibility build, and
Re: RFS: pacman-package-manager/6.0.1-1 [ITP] -- Simple library-based package manager
On Sat, 19 Feb 2022 00:13:37 -0500 Ben Westover
wrote:
> Package: sponsorship-requests
> Severity: wishlist
>
> Dear mentors,
>
> I am looking for a sponsor for my package "pacman-package-manager":
>
> * Package name : pacman-package-manager
> Version : 6.0.1-1
> Upstream Author : Pacman Development Team
> * URL : https://archlinux.org/pacman/
> * License : GPL-2+, MIT, curl, unlicense, public-domain
> * Vcs : https://salsa.debian.org/benthetechguy/pacman
> Section : admin
>
> It builds those binary packages:
>
> pacman-package-manager - Simple library-based package manager
> libalpm13 - Arch Linux Package Management library
> makepkg - Arch Linux package build utility
>
> To access further information about this package, please visit the
> following URL:
>
> https://mentors.debian.net/package/pacman-package-manager/
>
> Alternatively, one can download the package with dget using this
command:
>
> dget -x
>
https://mentors.debian.net/debian/pool/main/p/pacman-package-manager/pacman-package-manager_6.0.1-1.dsc
>
> Changes for the initial release:
>
> pacman-package-manager (6.0.1-1) unstable; urgency=medium
> .
> * Initial Package (Closes: #511994)
Hi,
I can sponsor this.
A few remarks, aside from the keyring change mentioned by Michel:
- all the doc build-dependencies (asciidoc, doxygen, help2man) can be
marked with so that nodoc builds can be done
- are curl and fakechroot really needed to build the package, or are
they just used by self tests? if they are used only by tests, mark them
as
- is pkgconf really needed instead of pkgconfig, which is the default?
- you need to add a libalpm-dev and ship the headers, pkgconfig file,
unversioned .so and manpage in it, instead of in libalpm13, and remove
the lintian override
- libalpm13 is missing Pre-Depends: ${misc:Pre-Depends}
- no need to specify the libarchive-tools and libgpgme11 dependencies
on libalpm13, they will be autogenerated
- does libalpm13 really need to depend on the binary curl executable?
- makepkg should not depend on build-essential nor on sudo
- no need to manually specify the dependency on libalpm13 in makepkg,
it will be autogenerated
- libalpm13 is missing the symbols file, you can generate it after
building the library with:
dpkg-gensymbols -plibalpm13
-edebian/tmp/usr/lib/x86_64-linux-gnu/libalpm.so.13.0.1
-Odebian/libalpm13.symbols
- makepkg is missing a dependency on ${perl:Depends}
- are you sure all of these can run on GNU/Hurd and debian/kFreeBSD? If
not, use 'linux-any' instead of 'any' as the architecture
- it is not necessary anymore to specify the build system in
debian/rules, meson is autodetected
- use execute_before_dh_auto_clean instead of override_
- 228 tests fail when running in a pbuilder chroot, this is a strong
hint that the build might fail once uploaded
- you should try and fix the reproducible build, rather than disabling
it in the CI
- the GPL-2+ in debian/copyright says in the last paragraph:
"On Debian systems, the full text of the GNU General Public
License version 3 can be found in the file"
instead of version 2
--
Kind regards,
Luca Boccassi
signature.asc
Description: This is a digitally signed message part
Re: Bug#1016095: RFS: archlinux-keyring/0~20220713-1 [ITP] -- Arch Linux PGP keyring
On Wed, 27 Jul 2022 at 23:13, Michel Alexandre Salim wrote: > > On Wed, 2022-07-27 at 16:39 -0500, Michel Alexandre Salim wrote: > > Hi Luca, > > > > Note: after deduplicating the GPL-3+ snippets, this now generates an > > additional lintian warning because it thinks the license snippet is > > missing. > > > This is fixed now, thanks Luca for pointing out that all instances of a > shared license should not contain the text, and there should be a > separate section with both the single license line and the license > blurb. > > > Thanks, Looks good to me, uploaded.
Re: Bug#1016095: RFS: archlinux-keyring/0~20220713-1 [ITP] -- Arch Linux PGP keyring
> Dear mentors, > > I am looking for a sponsor for my package "archlinux-keyring": I can sponsor this. A few comments on the package: - I imagine the makefile patch will be upstreamed? - no need to repeat the GPL3 license snippet in debian/copyright, have it as a single line in the Copyright stanzas: "License: GPL-3+", and then one block at the bottom of the file with "License: GPL-3+" and the full body to follow. - the keyring files are installed in /usr/share/pacman/keyrings/ but other keyrings (like ubuntu-keyring) install to /usr/share/keyrings, so I think this should do the same for consistency - in debian/control the VCS fields list https://gitlab.archlinux.org/archlinux/archlinux-keyring as the repository, but there's no sign of the packaging code there. You should have it on a debian/sid (or similar) branch. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#996963: RFS: dwarves/1.22-1 -- set of advanced DWARF utilities
On Mon, 2021-10-25 at 22:28 +0200, Domenico Andreoli wrote: > Hi Adam, Luca and Theodore, > > On Thu, Oct 21, 2021 at 04:50:36PM +0200, Domenico Andreoli wrote: > > Package: sponsorship-requests > > Severity: normal > > > > Dear all, > > > > I'm looking for a sponsor for this package: > > Could any of you please review this upload? > > Thanks! > Dom Looks good to me, uploaded. Just a minor thing for the next time you prepare an upload: the build- dep on libbpf-dev needs to be bumped, this version requires >= 0.4. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#900407: RFS: odp-dpdk/1.19.0.0-1 [ITP]
On Wed, 30 May 2018 13:37:29 +0300 Dmitry Eremin-Solenikov wrote: > Package: sponsorship-requests > Severity: normal > Control: block -1 by 896970 > Control: block 899383 by -1 > > Dear mentors, > > I am looking for a sponsor for my package "odp-dpdk" > > * Package name: odp-dpdk >Version : 1.19.0.0-1 >Upstream Author : Linaro / ODP community > * URL : https://www.opendataplane.org/ > * License : BSD-3-Clause >Section : libs > > It builds those binary packages: > > libodp-dpdk-dev - OpenDataPlane DPDK faceplate library (development) > libodp-dpdk119 - OpenDataPlane DPDK faceplate library (runtime) > > To access further information about this package, please visit the following URL: > > https://mentors.debian.net/package/odp-dpdk > > > Alternatively, one can download the package with dget using this command: > > dget -x https://mentors.debian.net/debian/pool/main/o/odp-dpdk/odp- dpdk_1.19.0.0-1.dsc > > More information about hello can be obtained from https://www.opendat aplane.org. > These packages provide hardware-optimized implementation of ODP API > (using DPDK as a backend). > > -- > With best wishes > Dmitry Eremin-Solenikov I'd recommend to change the build system to check for pkg-config first (libdpdk.pc), and only fallback to the manual checks if not found. We have already shipped libdpdk.pc for years in Ubuntu and Debian, and now upstream is shipping it too when using the new build system based on Meson. This will make your life much easier as there are frequently changes in compiler flags or headers or libraries locations happening, for example there are a few queued for 18.11. With pkg-config you can just ignore all that and it will just work (TM). -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#793350: RFS: czmq/3.0.2-1 ITP: 630761
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package "czmq" * Package name: czmq Version : 3.0.2-1 Upstream Author : iMatix Corporation * URL : http://czmq.zeromq.org/ * License : MPL-2.0 Section : libs It builds those binary packages: libczmq3 - High-level C binding for ZeroMQ libczmq3-dbg - High-level C binding for ZeroMQ (debugging symbols) libczmq3-dev - High-level C binding for ZeroMQ (development files) To access further information about this package, please visit the following URL: http://mentors.debian.net/package/czmq Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/c/czmq/czmq_3.0.2-1.dsc More information about hello can be obtained from http://czmq.zeromq.org/ CZMQ is a high-level C bindings library for ZMQ, which is available in Debian from the libzmq1 and libzmq3 packages, made by the same authors. The packaging repository is on Collab-Maint on Alioth: https://anonscm.debian.org/cgit/collab-maint/czmq.git Upstream code is on Github: https://github.com/zeromq/czmq Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Re: Bug#777347: RFS: pidgin-gnome-keyring/2.0-1 [ITP] [RFP #714018] -- integrates pidgin (and libpurple) with the system keyring
On 10 February 2015 at 20:10, Tobias Frost wrote: > Am Montag, den 09.02.2015, 22:32 + schrieb Luca Boccassi: >> On 9 February 2015 at 10:55, Michael Fladischer wrote: >> > Hi Luca, > >> Final question, the changelog lists the package as "UNRELEASED", I >> think it's right since it's never been in any Debian distro, but on >> mentors it's raised as a red flag, any idea if I should change it? > > This field describes which distribution the uploaded package goes to and > it is not fiddled with automatically e.g after an upload. Check out > Policy §4.4. Summary: Write "unstable" here. Hello Tobias, Done, upload on mentors now lists "unstable" as a distribution in the changelog. Thank you very much! :-) Luca -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMw=ZnSgALJKSL2kJ9Gp9KA+KTkOMsP=jsorzrnpwtnngks...@mail.gmail.com
Re: Bug#777347: RFS: pidgin-gnome-keyring/2.0-1 [ITP] [RFP #714018] -- integrates pidgin (and libpurple) with the system keyring
On 9 February 2015 at 10:55, Michael Fladischer wrote: > Hi Luca, Hello Michael, thanks for taking the time to have a look! > On 2015-02-07 16:45, luca.bocca...@gmail.com wrote: >> I am looking for a sponsor for my package "pidgin-gnome-keyring" > > I'm not a DD yet, so I can't sponsor your package, but I did a review on > what to improve to attract more potential sponsors: > > * Create a debian/watch file for use with `uscan` so automatic checks > for newer upstream releases are possible. Done. > * The Vcs-* fields do not point to a repository that contains the > packaging. Furthermore, the use of services like github is disputed for > packaging in Debian. Maybe collab-maint on Alioth is a better place to > keep your VCS, but that's up to you and your sponsor. I changed the master branch, now it tracks the "debianised" version of the repo so that the landing page and default branch have the packaging bits. If the sponsor objects to GitHub I'll switch. Thanks for pointing out Alioth, I'll be ready if needed. I picked GitHub because the upstream code is there as well and it makes sending back contributions easier. > * You do not have to use overrides for dh_auto_install and > dh_installdocs in debian/rules. Youc can use debian/.install > and debian/.docs for a source package with multiple binary > packages. Took out the install override, but I couldn't find an alternative for " dh_installdocs --link-doc" that will make the -dbg package symlink the doc directory to the binary package. Any idea how to do it? > * The PHONY target declaration is not really necessary. Took it out. > * Is the packaging (debian/*) really from Ali Ebrahim as described in > debian/copyright or was it your work? Good point, the original control file comes from Ali's Ubuntu packages, but I changed it and added other files, so I added myself under the debian/* copyright listing. One more change I did, I added "export DEB_BUILD_MAINT_OPTIONS = hardening=+all" to the debian/rules file since by default "Immediate binding" is not turned on. A new upload with the changes is on mentors. Final question, the changelog lists the package as "UNRELEASED", I think it's right since it's never been in any Debian distro, but on mentors it's raised as a red flag, any idea if I should change it? Thank you very much for the tips, I really appreciate them! Kind regards, Luca Boccassi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAMw=ZnS80X4oUWru7gsNgEhzSb=4js8ogky1ovb5uhnkmqr...@mail.gmail.com
Bug#777347: RFS: pidgin-gnome-keyring/2.0-1 [ITP] [RFP #714018] -- integrates pidgin (and libpurple) with the system keyring
Package: sponsorship-requests Severity: whishlist Dear mentors, I am looking for a sponsor for my package "pidgin-gnome-keyring" * Package name: pidgin-gnome-keyring Version : 2.0-1 Upstream Author : Ali Ebrahim * URL : https://github.com/aebrahim/pidgin-gnome-keyring * License : GPL-2.0+ Section : net It builds those binary packages: pidgin-gnome-keyring - integrates pidgin (and libpurple) with the system keyring pidgin-gnome-keyring-dbg - debugging symbols for pidgin-gnome-keyring To access further information about this package, please visit the following URL: http://mentors.debian.net/package/pidgin-gnome-keyring Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/p/pidgin-gnome-keyring/pidgin-gnome-keyring_2.0-1.dsc More information about pidgin-gnome-keyring can be obtained from https://github.com/aebrahim/pidgin-gnome-keyring. Related wnpp: #714018 Changes since the last upload: none pidgin-gnome-keyring (2.0-1) UNRELEASED; urgency=low * Initial release (Closes: #714018) -- Luca Boccassi Fri, 06 Feb 2015 22:02:05 + Regards, Luca Boccassi -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/e1yk7zy-0007gi...@nas-host.banana.lan
