Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 10:35:48 +0100, Simon McVittie wrote: > On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > > Can we have this uploaded for the upcoming 10.6? Still seen no love and > > missed so many point releases now. Just need someone with permissions to > > do it and a little time. > > I'll put this on my queue to review and test. Uploaded. In future, if you have changes for a package in stable, please try to work with the package's maintainers first, rather than bypassing them. I know the GNOME team has taken too long to respond, and I'm sorry about that. We are responsible for a lot of packages, of which gnome-maps is far from our highest priority. smcv
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 21:39:49 +0800, xiao sheng wen 肖盛文 wrote: > The only question is lintian check has some info Some Lintian warnings are normal for a stable update, where the changes that would prevent those warnings would break the rule of including only minimal changes. smcv
Re: RFS: gnome-maps/3.30.3.1-0+deb10u1 [NMU] -- map application for GNOME
On Sun, 13 Sep 2020 at 04:02:56 +0100, Phil Wyett wrote: > Can we have this uploaded for the upcoming 10.6? Still seen no love and > missed so many point releases now. Just need someone with permissions to > do it and a little time. Sorry, the GNOME team has the same problem as every other major team in Debian: too many packages and too little time. Many of us run testing or unstable, so properly testing an upload to stable requires switching between installations or machines, or borrowing partners'/family members' stable installations. The default for stable is always to not upload, because regressions in stable are considered worse than pre-existing bugs. I'll put this on my queue to review and test. smcv
Re: Bug#886291: Debian package transition: Rename package and reuse old name with new content
On Sat, 18 Aug 2018 at 16:31:37 +0200, Alexis Murzeau wrote: > To fix #886291, we should: > - Rename python3-pycryptodome to python3-pycryptodomex > - Reuse python3-pycryptodome package name to package a non compatible > python3 module. > > The rationale of this rename + reuse is that currently, > python3-pycryptodome contains, in fact, the pycryptodomex module. So > renaming that one + introduce the new package for the pycryptodome module. According to apt-file(1), python3-pycryptodome contains /usr/lib/python3/dist-packages/Cryptodome, which you use via "import Cryptodome". If you're renaming packages anyway, would it be better for the package containing /usr/lib/python3/dist-packages/Cryptodome to be the python3-cryptodome package? (My reasoning is that the name you import is the name of the "ABI", the same way the ABI of, for example, libdbus is represented by its SONAME libdbus-1.so.3, which we translate into libdbus-1-3 as a Debian package name.) > I already though of a solution on 886...@bugs.debian.org use multiple > dependencies with "|" but the package must still be buildable with the > first dependency (sbuild ignore dependencies after "|" for example) It's OK for packages in unstable to be uninstallable or unbuildable for a short time, as long as Depends/Breaks/Conflicts or RC bugs ensure that the brokenness doesn't propagate into testing. For instance, if you are going ahead with your renaming plan, you could give the new packages a versioned Breaks on python3-httpsig (<< H) and python3-pysnmp4 (<< S), where H is the first version of python3-httpsig that has been modified to use/expect the new (py)cryptodome(x) package layout, and S is the corresponding version of python3-pysnmp4. smcv
Re: Systemd user instance equivalent of dh_systemd_enable?
On Sun, 08 Apr 2018 at 08:26:13 -0600, Daniele Nicolodi wrote: > the package is dbus-broker, a replacement for dbus-deamon. You may have > heard of it: there has been a short exchange about its packaging for > Debian with its developers with the Debian dbus maintainers in Cc. Sorry, I didn't see that conversation until now. Please use the role address @packages.debian.org if you want to reach package maintainers: mailing lists used to represent team maintenance often don't have the entire team subscribed, particularly if the team maintains many not-entirely-related packages (as pkg-utopia does), because the list receives all the "messages to the maintainer" for every package that it maintains, making it inconveniently high-traffic. If dbus-broker is uploaded to Debian as an optional dbus-daemon replacement, it will definitely need to be coordinated with the dbus source package. Having the two packages coexist is probably not going to be straightforward to set up, and if any diversions, alternatives etc. are going on, all maintainers of the dbus package will need to be aware of them. I do not expect that dbus-broker will be compatible with every D-Bus service in Debian. The one incompatibility that I'm reasonably sure exists is that if the Exec= for an activatable service points to a command that will fork (background itself) and exit 0, dbus-daemon tolerates this (at the cost of worse error behaviour because it cannot tell whether the service subsequently fails), while dbus-broker almost certainly does not. This is inadvisable behaviour even with the reference dbus-daemon, so I'd consider it to be a bug in the service, but unfortunately it can't be detected statically. It's unfortunate that current Debian infrastructure conflates the concepts of "should receive every communication about all of these packages" and "is a team": hopefully current/near-future work being done on tracker.debian.org will address that. smcv
Re: Systemd user instance equivalent of dh_systemd_enable?
On Sat, 07 Apr 2018 at 18:18:11 -0600, Daniele Nicolodi wrote:
> I'm working on a package that installs a systemd user instance unit file
> that needs to be enabled with
>
> # systemctl --global enable foo.service
I believe the only way to do this is currently to make
it be statically enabled for all users (ship a symlink in
/usr/lib/systemd/user/${something}.wants).
What is the package?
Is it something that all users are going to want?
Is it something that makes sense to run every time any user logs in in
any way (ssh, console login, graphical login) or only on entry to a
graphical session?
Would it make sense to arrange for it to be socket-activated (like
dbus-user-session, gpg-agent, pulseaudio) or D-Bus-activated (like
gnome-terminal-server) or autostarted on login to a graphical session (via
/etc/xdg/autostart), rather than being started eagerly on every login?
(The way packages like dbus-user-session, gpg-agent and pulseaudio set
themselves up for socket activation is to have their *.socket unit be
statically enabled in sockets.target, but not their *.service unit in
default.target.)
smcv
Re: Request for sponsor for Stendhall Installer
On Sun, 23 Jul 2017 at 11:14:16 +0100, Phil Morrell wrote: > As this is an initial release, have you considered using > game-data-packager (if default-jre can be considered a game engine)? game-data-packager does not place any limitations on what can be considered a game engine. In addition to the games it was originally designed for (Free engines with non-Free data, like Doom, Quake and ScummVM games) it already supports a few binary-only games that ship their own executables in the game-data-packager-generated packages (Unreal, Unreal Tournament (1999), Quake 4 and Enemy Territory: Quake Wars). There is a data-driven launcher in the game-data-packager-runtime package which can be used to start such games - Unreal probably makes the best example at the moment. (However, because g-d-p is careful to match installed files against known-good hashes, it is less suitable for games that are updated frequently. I don't know how often the user-facing executables for Stendhall, Runescape and Minecraft are updated.) S
Re: Bug#795344: libmems-1.6-1: not properly linked to its dependencies
On 13/08/15 15:06, Andreas Tille wrote: +libMems_la_LIBADD = $(DEPS_LIBS) @BOOST_FILESYSTEM_LIB@ @BOOST_IOSTREAMS_LIB@ @BOOST_SYSTEM_LIB@ + SUBDIRS = libMems Move this from /Makefile.am into /libMems/Makefile.am, where libMems.la is built and the rest of the libMems_la_WHATEVER variables appear. S
Bug#759535: Bug#739030: severity of 739030 is serious, severity of 755207 is serious
On Wed, 03 Sep 2014 at 09:32:26 +0200, Etienne Millon wrote: I prepared an upload that makes it possible to build gmpc with a recent vala. If you're interested in sponsoring this fix, I filed a RFS as #759535. I occasionally use gmpc, and the debdiff looks good, so I'll sponsor this (assuming the build that's running now is successful and the result works). Thanks for maintaining this package. S -- 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/20140903084613.ga25...@reptile.pseudorandom.co.uk
Re: RFS: naev
On Sat, 09 Jul 2011 at 18:34:09 -0700, Vincent Cheng wrote: Thanks for the review. Please also consider reviewing my most up-to-date packaging in the Debian Games svn repository; my Naev packaging at mentors.d.n is heavily outdated at the moment, mostly because I'm getting tired of having to upload a 200 MB tarball every time I want to make a minor change to my packaging. Have you considered splitting the package, along the same lines as OpenArena and Nexuiz? Even if your upstream always releases the code and data together, you're much more likely to need to fix bugs in the packaging or code than you are in the data. If you keep the .menu files and other Debian additions with the code, you'll only need to upload a relatively small .deb for fixes to either the code, or the menu entries etc. There are basically three ways you could go: * Single monolithic source package, like Wesnoth. As you have noted, this is a pain to upload! * One source package for code (and other small/easy-to-patch things like menu entries and man pages), one for data, like OpenArena in squeeze. naev Depends: naev-data with version constraints. This is quicker for you to upload, but if the -data package is too large, it won't get into debian-cd CD releases, only DVDs and BluRays (I think the cutoff for CDs is a couple of hundred MB). * One source package for code, several for data, like OpenArena in sid/experimental. naev Depends: naev-textures, naev-music, naev-data (or whatever) with version constraints. When I asked the ftp-masters, Mark Hymer said they didn't object to this. Steve McIntyre (debian-cd maintainer) recommended aiming for about 50 to 100 MB when splitting data packages like this. As far as I understand, it's not an issue that blocks Naev from entering the archives (while binaries/executables need to be able to be built from source code, I don't think policy mandates that images must be built/rendered from source...if that's the case, an awful lot of packages currently in Debian would have to tweak their build system). In my understanding of Policy and the DFSG, there's a difference between data not being built from source code, and data not being accompanied by source code at all. Data not *being built from* source code is a technical bug: it means upstream haven't given you a deterministic build system (and you haven't been able to construct one). It's a bug, but not necessarily a fatal one. (OpenArena has that bug too - upstream don't provide a build system for the data, probably because it involves a lot of manual exporting; the derived files are checked-in to svn alongside the source files.) Data not *having* source code is a Policy/DFSG bug. In principle, for each file in the binary package, the DFSG require you to include corresponding source code in the source package, even if it isn't actually rebuilt. For some (most?) game upstreams, it's difficult to tell what the corresponding source code *is* (is image.jpg the preferred form for modification or is there a .xcf version somewhere? we just don't know), but you should at least include a best-effort guess at what the source is. (OpenArena also has this problem; the source packages in sid/experimental contain my best guess at what the source was.) Where possible, the most reliable way to know that the source you're providing is the actual source is to rebuild it, but I realise this isn't always feasible, particularly for upstreams whose background is game modding rather than Free Software. S -- To UNSUBSCRIBE, email to debian-devel-games-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110710075050.ga2...@reptile.pseudorandom.co.uk -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110710075050.ga2...@reptile.pseudorandom.co.uk
Re: RFS: oss-compat (adoption, updated package)
On Wed, 08 Jun 2011 at 15:39:34 +0200, Bruno Kleinert wrote: It seems as if sbuild exchanges the Maintainer field in the binary package. If I schroot into my build environment and use dpkg-buildpackage instead of sbuild the Maintainer field in the resulting binary package remains unchanged. When sbuild is behaving like a maintainer or sponsor (as opposed to behaving like a buildd) make sure you leave $maintainer_name and $uploader_name unset, assuming your sbuild is recent. In older versions of sbuild, which insisted on having at least one of $maintainer_name, $uploader_name or $key_id, it was necessary to set $key_id, and also set $pgp_options so that $key_id wasn't used (assuming you want to test the package before signing it): see http://www.pseudorandom.co.uk/2008/sbuild-dm/. That page also indicates how to check the .changes file for a sponsored upload to check that the right things happened. S -- To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110608135501.ga27...@reptile.pseudorandom.co.uk
Re: Bug#539813: nautilus-clamscan upload sponsored
On Mon, 14 Jun 2010 at 13:14:23 -0400, Andrew SB wrote: The attached debdiff fixes the RC bug (BTS #539813) against nautilus-clamscan as well as all other bugs against the package. Hi, This upload looks good to me, and there's been no response on the RC bug for a while, so I've sponsored it. Thanks for improving Debian! However, it's not clear what the future of nautilus-clamscan in Debian is. The security team seem to have plans to move clamav and all its reverse-dependencies to volatile.debian.org, which will mean n-c would be removed from testing and have to go into volatile too; it'd be worth talking to debian-security, or perhaps to the ClamAV maintainers. The package is also in need of a maintainer, at least in Debian. Andrew, are you just doing drive-by QA, or would you be interested in maintaining this package? Clément: since you're the author, it wasn't entirely clear to me from Bug #585687 whether you're looking for a new Debian maintainer, or a new upstream maintainer. Which is it? (While testing the NMU I imported the last maintainer upload and the NMU into a git repository suitable for git-buildpackage; please feel free to clone http://git.debian.org/?p=users/smcv/nmu/nautilus-clamscan.git if you'd find it useful.) Regards, Simon signature.asc Description: Digital signature
