gtksourceview3 was superseded by gtksourceview4 in 2018. Both libraries
provide a GTK 3 widget to display source code with syntax highlighting,
for use in text editors and similar applications.
gtksourceview4 has itself been superseded by gtksourceview5 (ITP: #996609),
which is for GTK 4
On Tue, 05 Oct 2021 at 06:14:26 -0700, Otto Kekäläinen wrote:
> So, which one of these paths should be used and why?
> - /lib/systemd/system/
> - /usr/lib/systemd/system/
tl;dr: Continue to use /lib/systemd/system.
Moving files to /usr/lib/systemd/system can cause debhelper >= 13.5.2
(and
Package: wnpp
Severity: wishlist
Owner: Simon McVittie
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: xdg-desktop-portal-gnome
Version : 41.0
Upstream Author : Georges Basile Stavracas Neto, Matthias Clasen et al
* URL : https://gitlab.gnome.org/GNOME/xdg
On Mon, 20 Sep 2021 at 17:25:32 +0200, Chris Hofstaedtler wrote:
> * Hsieh-Tseng Shen [210920 16:54]:
> > The ledmon package was reported by
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994521 to cause ledmon
> > service was unable to run due to the broken dependency of libsgutils2-2.
>
On Wed, 08 Sep 2021 at 07:31:59 +, Bastien ROUCARIES wrote:
> Simon, do you think you could implement a version of libcapasule for PE
> object ?
Given that libcapsule is very glibc- and ELF-specific, doesn't work
properly without new glibc feature work that isn't in Debian yet (I've
lost
On Sat, 04 Sep 2021 at 17:02:50 +0300, Timo Aaltonen wrote:
> On 4.9.2021 11.58, Marc Haber wrote:
> > You're of course free to roll your own, local package. It shold be
> > possible. Just don't expect any official movement in Debian stable,
> > testing or stable-backports until that RC bug is
On Fri, 03 Sep 2021 at 02:46:20 +0200, Jonas Smedegaard wrote:
> I suspect that it helps if separating reasons for _encouraging_
> embedding (tiny upstream projects and deeply integrated sets of
> upstreams, I guess) from reasons for _discouraging_ embdding (all other
> cases, I guess).
If the
On Sun, 29 Aug 2021 at 14:17:10 +0900, Charles Plessy wrote:
> Judging from IANA's registered types for other script languages, it
> looks like the application type is more relevant. Also, the
> application/ types appear first in our /etc/media.types file, and if I
> remember well this gives them
On Tue, 24 Aug 2021 at 10:46:45 -0400, Theodore Ts'o wrote:
> the definition of usrmerged is
> relatively well understood (symlinks for /{bin,lib,sbin} to
> /usr/{bin,lib,sbin})
For completeness: also /libQUAL to usr/libQUAL, for each libQUAL
that either participates in multilib or contains
On Mon, 23 Aug 2021 at 10:53:12 +0200, Fabian Greffrath wrote:
> The downside is that dsda-coom introduced a new versioning scheme which
> is currently at v0.21.0, whereas prboom-plus is already at 2.6.1um. To
> provide for an easy upgrade path for prboom-plus users, I'd like to
> introduce the
On Fri, 20 Aug 2021 at 19:01:00 +0100, Luca Boccassi wrote:
> I can confirm that if you build in split-usr mode then the generators
> are looked for only in /lib:
>
> https://github.com/systemd/systemd/blob/v247/meson.build#L156
>
> (the systemgeneratordir meson variable is set from
Control: retitle 992554 debhelper: moves systemd system generators to a
location not searched by systemd
Control: reassign 992554 debhelper 13.4
Control: affects 992554 + tor ostree
On Fri, 20 Aug 2021 at 16:20:04 +, Peter Palfrader wrote:
> It seems that generators in /usr/lib/systemd are
On Fri, 20 Aug 2021 at 07:26:51 +0200, Helmut Grohne wrote:
> The options you present to work around this sound plausible to me, but
> they do complicate the transition plan somewhat. In essence, we'll get
> two transition points. One for non-buildds and another for them.
Maybe that, but what I
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> > If we want to make buildd chroots merged-/usr any time soon, then I
> > think we need to say this class of bugs is RC for bookworm.
>
> For a
On Thu, 19 Aug 2021 at 10:06:27 +0200, Helmut Grohne wrote:
> You keep proposing adding /bin/foo -> /usr/bin/foo symbolic links via
> maintainer scripts.
I'm not proposing this! I'm trying to *not* need to do that in any more
packages, and instead do usrmerge or equivalent, so that individual
On Tue, 17 Aug 2021 at 23:24:26 -0400, Theodore Ts'o wrote:
> That being said, you do have a good point that there might be scripts
> that have "/sbin/fsck." hard-coded in the shell scripts, just as
> I've seen /bin/rm, /bin/mv, etc., hard coded in some shell scripts ---
> not to mention
On Tue, 17 Aug 2021 at 12:59:21 -0400, Theodore Ts'o wrote:
> > Such packages are already violating a Policy "should", because they're
> > not building reproducibly (and the reproducible-builds infra tests this
> > for testing and unstable).
>
> Do we have a dashboard for this so the list of
tl;dr: I would prefer it if the usrmerge variation continues to be
exercised for the testing suite for the foreseeable future.
On Tue, 17 Aug 2021 at 09:16:01 -0700, Vagrant Cascadian wrote:
> The short of it, as I read it, is that non-usrmerge systems will be
> unsupported for bookworm, or did I
On Tue, 17 Aug 2021 at 08:08:15 -0600, Sam Hartman wrote:
> In order to build packages that work on a non-usrmerge system, you need
> a build chroot that is not usrmerge.
Well. That's not 100% true: it's more accurate to say that when *some*
source packages are built in a merged-/usr chroot, the
Before Valve's Steam game distribution platform became available on
Linux, the Debian source package name 'steam' was used by an unrelated
package sTeam, an "environment for cooperative knowledge managment"
(a wiki and related software). sTeam was removed from Debian in 2010,
and from Ubuntu in
On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote:
> You snipped both times the [for me] logical consequence that all
> bookworm build chroots are kept in a [then unsupported] unmerged state
> as "one of the last things" aka until bookworm is discontinued,
> so that they are building
On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote:
> Wouldn't it be kinda strange to have the chroots building the packages
> for the first bookworm release using a layout which isn't supported by
> bookworm itself…
Yes, it's a little strange, but that's what happens when we don't
On Sat, 14 Aug 2021 at 14:33:44 +0200, David Kalnischkies wrote:
> the current 'transition' plan is to have the
> release notes nudge all people who upgrade instead of reinstall their
> systems, chroots and what not to please do it for all of them by hand
> at a to be specified flag day someday
On Fri, 13 Aug 2021 at 02:29:02 +0200, Guillem Jover wrote:
> On Tue, 2021-08-10 at 12:34:18 +, Bastien Roucariès wrote:
> > I am going to compile shell.efi from source.
> >
> > I whish to install to something stable, but I need an arch triplet
> > in order to put in a multiarch (like)
On Tue, 10 Aug 2021 at 15:19:10 -0700, Josh Triplett wrote:
> Bastien Roucariès wrote:
> > I suppose that [EFI] will be x86_64-efi-none (or maybe x86_64-windows-efi
> > ) and
> > i686-uefi-none ?
It's certainly not x86_64-windows-efi. The EFI environment isn't Windows
(even though it borrows
On Thu, 22 Jul 2021 at 15:53:32 +0200, Wouter Verhelst wrote:
> I've suggested previously that we can easily make it RC for bookworm to
> have a file outside a limited set of directories (/etc and /usr would be
> OK, but notably /bin /lib and /sbin wouldn't be) that is not a symlink.
> This is
On Tue, 20 Jul 2021 at 21:16:57 -0400, Polyna-Maude Racicot-Summerside wrote:
> I'd love to know more about what made you switch to Devuan
You're welcome to have this discussion privately, but please take it
off-list. A few days before the provisional release date for Debian 11
is not the time to
On Tue, 20 Jul 2021 at 00:09:32 +0100, Wookey wrote:
> I see that the reason is given in
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=955349
> 'uses unmaintained libunique'.
>
> Any further comments on what would be required to get this back? Was
> libunique actually broken/a problem, or
(Disclosure: I work for Collabora, and I'm currently working on the
Steam Runtime.)
On Sat, 17 Jul 2021 at 13:48:32 +0100, Samuel Henrique wrote:
> As some of you already seem, we have very good news for the Linux
> gaming community, although somewhat bad for Debian:
...
>
On Mon, 19 Jul 2021 at 02:25:16 +, Paul Wise wrote:
> BTW, the Valve Arch Linux overlay thing appears to be here:
>
> https://repo.steampowered.com/arch/valveaur/
FYI, that's an overlay for "upstream" Arch, for Arch users who want to
try out Mesa and kernel patches that are not yet mainline
On Mon, 19 Jul 2021 at 16:41:42 +0200, Johannes Schauer Marin Rodrigues wrote:
> Should I rather file bugs with patches against individual packages
> to move their files from /(sbin|bin|lib)/ to /usr/(sbin|bin|lib)/
As discussed in previous iterations of the ongoing merged-/usr megathread,
I
On Mon, 19 Jul 2021 at 11:33:49 +0200, Stephan Lachnit wrote:
> We could start with collecting the packages that install to /bin*
> instead of /usr/bin, and adjust the packaging so that they don't do
> that. [...] At this point, it shouldn't
> matter if you run a merged usr system or not, or am I
On Sat, 17 Jul 2021 at 20:34:41 +, Johannes Drexl wrote:
> /usr is allowed to be not only on a separate partition, but even on a
> network device
This has been discussed at considerable length before, but I'll try to
recap:
A separate or network-mounted /usr is possible in Debian, whether
On Thu, 08 Jul 2021 at 23:03:48 +0200, Michael Biebl wrote:
> [a separate libsystemd-shared-249 .deb] would also mean, that on every
> new upstream release, systemd would have to go through NEW
It seems like we're rejecting a good technical solution because
social/organisational factors block it
On Mon, 05 Jul 2021 at 02:30:00 -0500, Daniel Lewart wrote:
> Comparing important/required/standard packages between
> Buster and Bullseye, I noticed some inconsistencies.
We have been in hard freeze for almost 4 months[1], so I don't think
now is necessarily the right time to be changing what is
On Fri, 02 Jul 2021 at 20:04:45 +0200, Mathieu Parent wrote:
> On a related topic, I'm currently developing support for Debian
> repositories in Gitlab (and transitively Salsa).
That's great news - being able to build packages in CI and make the results
easily installable seems like a big step
On Thu, 27 May 2021 at 16:53:45 +0200, David Kalnischkies wrote:
> So, here is a thing: I like transitional packages – because it means the
> package is not removed.
Right - it tells both apt and human users "this
replacement/removal/upgrade (depending how you look at it) is intentional,
On Thu, 27 May 2021 at 08:30:11 +0200, Simon Josefsson wrote:
> I do think it would be a wortwhile release
> goal, at some point, to fix tooling so that dummy packages are no longer
> necessary for package transitions.
Transitional packages have the huge advantage that they already work
(and the
On Wed, 26 May 2021 at 19:18:24 +0200, Simon Josefsson wrote:
> Andreas Metzler writes:
> > Why not use a versioned Provides *instead* of the dummy package?
>
> Yeah, I never understand exactly when these dummy packages are needed.
My understanding is that they are usually still necessary for
On Wed, 26 May 2021 at 00:11:29 +0200, Simon Josefsson wrote:
> Andreas Metzler writes:
> > On 2021-05-24 Simon Josefsson wrote:
> >> I want to upload a new upstream libidn release into Debian, but upstream
> >> has done a shared library transition.
...
> >> Package: libidn11-dev
> >> +Section:
Package: wnpp
Severity: wishlist
Owner: Simon McVittie
X-Debbugs-Cc: debian-devel@lists.debian.org, debian-gtk-gn...@lists.debian.org
* Package name: gi-docgen
Version : 2021.2 or git snapshot
Upstream Author : Emmanuele Bassi
* URL : https://gitlab.gnome.org/GNOME/gi
On Sun, 04 Apr 2021 at 13:23:14 +0200, Joerg Jaspert wrote:
> On 16093 March 1977, Dominik George wrote:
> > That surprised me. If a package is free software, in ful laccordance
> > with the DFSG, why is it put into contrib?
>
> There is, as usual, no clear answer.
>
> The policy for main is
On Sun, 14 Feb 2021 at 20:06:00 +, Phil Morrell wrote:
> On Sun, Feb 14, 2021 at 04:58:35PM +0000, Simon McVittie wrote:
> > I wanted to provide some signal boost for this and related upgrade issues.
> > Ryan Pavlik, one of my colleagues at Collabora, ran into a similar upgr
On Sat, 13 Feb 2021 at 19:52:10 +0100, Paul Gevers wrote:
> [The release team are] pretty concerned about a couple of known RC bugs
> which need the proper attention of people familiar with upgrade paths
> as there's potential to leave upgrading systems unbootable and/or
> without a working apt.
On Mon, 01 Feb 2021 at 11:16:48 -0800, Russ Allbery wrote:
> pam_limits also does some things that are unrelated to starting services,
> such as setting up limits for interactive user sessions, and I think pure
> systemd systems still rely on that?
My understanding was that pam_limits is *only*
On Mon, 01 Feb 2021 at 09:54:56 -0800, Russ Allbery wrote:
> Simon McVittie writes:
> > The wider context here is that gnome-keyring-daemon, GNOME's
> > implementation of the org.freedesktop.Secrets interface, is currently
> > setcap cap_ipc_lock=ep so that it can mlock(2)
On Mon, 01 Feb 2021 at 11:49:25 -0500, Sam Hartman wrote:
> >>>>> "Simon" == Simon McVittie writes:
> I'm assuming that the proposal is to change this for bookworm.
I'm sorry, I don't have a concrete proposal, and I don't understand which
package is meant to be r
On Mon, 01 Feb 2021 at 13:58:57 +, Simon McVittie wrote:
> Rationale: on sysvinit or runit systems, pid 1 is very simple and is
> unlikely to need to elevate any limits, but sysadmins are expected
> to restart system services in an unpredictable execution environment
> (ce
A recent regression in gnome-keyring (perhaps only on systems that
use dbus-x11, it isn't completely clear to me yet) has prompted me to
look at how rlimits work in Debian. It isn't clear to me which package
is or should be responsible for choosing what arbitrary limits we use
in practice.
The
On Thu, 21 Jan 2021 at 06:03:52 +0100, Guillem Jover wrote:
> I mentioned this before, this does not look specific to whatever
> method to do merged-/usr, instead this seems like a general dpkg
> problem related to missing fsync() on the directories during unpacks
It's great news that someone has
On Wed, 20 Jan 2021 at 20:29:49 +0100, Aaron Dewes wrote:
> Not sure if this is the right place to report this, but the package
> "nfs-common" still recommends python instead of python3 in bullseye
> where only Python 3 is available
This is
On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote:
> On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the
> > algorithm for use is similar: if it is in the environment then use it, if
> > not,
> > fall
On Mon, 18 Jan 2021 at 09:39:05 +, Andrew M.A. Cater wrote:
> The pointers to the Debian image on the Debian front page (and the discussion
> about standard/installer with firmware) relate to the non-live Debian
> installer.
>
> If we want the Calamares image to include firmware - that's a
On Sun, 17 Jan 2021 at 23:18:57 +0200, Andrei POPESCU wrote:
> On Du, 17 ian 21, 17:42:48, Marek Ľach wrote:
> > Package: gnome-notes
...
> > - formerly was known as ''Bijiben''.
https://tracker.debian.org/pkg/bijiben already exists. Is that the package
you wanted?
smcv
On Sun, 17 Jan 2021 at 11:49:00 +, Philip Wyett wrote:
> I am no Pipewire expert like you
Please don't mistake me for a Pipewire expert! I'm only doing drive-by
uploads because we need it for GNOME. I do not have the bandwidth to be
responsible for Pipewire and you'll notice I have
On Sun, 17 Jan 2021 at 05:01:30 +, Philip Wyett wrote:
> Installing Debian testing and now also using bullseye-DI-alpha3, the
> default desktop install/gnome is still installing vino and not
> installing gnome-remote-desktop by default.
The version of meta-gnome3 in GNOME team git Suggests
On Mon, 11 Jan 2021 at 00:48:42 +1100, Stuart Prescott wrote:
> Looking to the future, tests using SOURCE_BASE_DIR to locate test data would
> allow build-time tests to be repurposed as autopkgtest tests too, as the
> autopkgtest could tell the tests where the test input data is to be found.
On Sat, 09 Jan 2021 at 08:22:26 +0900, Charles Plessy wrote:
> I ran /usr/share/lighttpd/create-mime.conf.pl and only had duplicate
> warnings, that do not cause errors (the scripts returns 0).
...
> In the latest CI log of lighttpd on amd64, there is:
>
> defconfigFAIL stderr:
On Sun, 27 Dec 2020 at 06:01:45 +, M. Zhou wrote:
> I don't quite understand the meaning of automatic upgrades on a rolling
> system such as Debian/Sid. According to my own experience, such
> automatic upgrades could be dangerous.
You're using a suite named "unstable". It does what the name
On Sat, 26 Dec 2020 at 14:55:17 -0800, Josh Triplett wrote:
> I'm talking about packaging xyz 1.3.1 and 2.0.1, as separate xyz-1 and
> xyz-2 packages, and allowing the use of both in build dependencies.
This is not all that rare even for C/C++ code, as exemplified by
GTK and other libraries that
On Sat, 12 Dec 2020 at 18:09:02 +0200, Adrian Bunk wrote:
> 3. Computers that do support MMX and SSE2, but do not support 64bit.
Right, that's basically the second use-case I mentioned, but moving the
boundary for what we do and don't support to be more modern. We could
put the boundary anywhere
On Mon, 07 Dec 2020 at 08:41:40 +0100, Christoph Biedl wrote:
> over all the years I had assumed the -x and -b operations of dpkg-source
> are inverse, and the other way around as well. In other words, I
> expected to rely on the following:
>
> Running "dpkg-source -x" on a .dsc, and then
On Wed, 02 Dec 2020 at 11:15:44 +0100, Raphael Hertzog wrote:
> But this has the obvious downside that "${source:Version}" is unchanged
> and that you might have issues with dependencies against the arch: all
> package.
Yes, I already said that this is why OBS can't realistically do its builds
On Tue, 01 Dec 2020 at 10:56:28 +, Simon McVittie wrote:
> We can and do autobuild arch-independent packages (since 2015: on the
> timescale of multi-release transitions, this is relatively recent).
>
> However, we cannot currently do arch-independent *binNMUs* [because...]
On Tue, 01 Dec 2020 at 11:05:54 +0100, Jonas Smedegaard wrote:
> Can someone remind me: Why is it that we cannot do arch-independent
> auto-building?
We can and do autobuild arch-independent packages (since 2015: on the
timescale of multi-release transitions, this is relatively recent).
On Sun, 29 Nov 2020 at 20:33:22 +0100, RhineDevil wrote:
> I ask the teams responsible for sbuild and debootstrap development
> permission to integrate these changes
If you have made changes to sbuild and debootstrap and you want those
changes to be merged, the way to make that happen is to open
On Sun, 29 Nov 2020 at 12:33:22 +0100, Johannes Schauer Marin Rodrigues wrote:
> What I would like even more, would be to add a podman backend to autopkgtest.
> This has the following advantages:
>
> - it would already work with sbuild today (no changes in sbuild required)
> - no duplicated
Paul Gevers wrote:
> > 1) use 2.0.0+really1.8.3 pattern for our Debian package version
> As it seems not unreasonable to expect the upstream version to go past
> 2.0.0 in the not infinite future, this is the approach I would take.
The +really pattern is normally used when the version in Debian
On Fri, 20 Nov 2020 at 11:12:20 +0100, Ansgar wrote:
> On Fri, 2020-11-20 at 10:19 +0100, Adam Borowski wrote:
> > On Fri, Nov 20, 2020 at 09:35:42AM +0100, Ansgar wrote:
> > > As far as I know nothing broke catastrophically over the last releases
> > > with merged-/usr.
> >
> > Unless you look
On Sat, 14 Nov 2020 at 00:06:26 +0900, Norbert Preining wrote:
> > OK, that makes sense. You should be able to achieve this with:
> >
> > dh_installsystemduser --no-enable
>
> Hmm, I have
> override_dh_installinit:
> dh_installinit --no-start --no-enable
>
> but the actual .service
On Fri, 13 Nov 2020 at 21:32:37 +0900, Norbert Preining wrote:
[I wrote:]
> > I still think doing this as a user service
> > would be a better approach to use by default
>
> But isn't that what we are doing by shipping
> /usr/lib/systemd/user/onedrive.service
> ?
Yes it is, but you started
On Wed, 11 Nov 2020 at 14:26:55 +0100, Matthias Klose wrote:
> If you ask some upstreams of Python based software, their recommendation would
> be to use pip, and probably conda (a cross OS distribution focusing on Python)
> to do upstream development. If you ask casual users, you probably will
On Wed, 11 Nov 2020 at 09:32:46 +0900, Norbert Preining wrote:
> once again, thanks a lot. I have now tried out your suggestion and it
> works nicely. Just to make sure, I have now the following units, see
> below. I am aware that the system instantiation service onedrive@ is not
> optimal since
On Tue, 10 Nov 2020 at 10:45:07 +0100, Johannes Schauer wrote:
> I'm confused. We are packaging libraries of language X but then those packages
> will not be used by people who write software for language X on Debian?
> Intuitively, should I ever start with Rust, I would've thought that I had to
>
On Sun, 08 Nov 2020 at 21:07:03 -0500, Aaron M. Ucko wrote:
> Debian has had two versions of the FLTK GUI toolkit with nearly
> identical APIs for over nine years: 1.1 and 1.3. The only breaking
> change in the 1.3 series is that it expects text to be in UTF-8 rather
> than legacy national
On Mon, 09 Nov 2020 at 09:25:25 +0900, Norbert Preining wrote:
> Onedrive ships
> /lib/systemd/system/onedrive@.service
> and for example on my system root has started
> onedrive@norbert
> service (this is better than an actual user starting, since systemd
> tears down the service
On Mon, 09 Nov 2020 at 12:24:03 +0900, Norbert Preining wrote:
[Paul wrote]:
> > These are not "systemd user services" as described in your email subject,
> > they are
> > per-user instances of systemd system services.
How to tell: run systemd-cgls and look at where they appear in the tree.
On Mon, 26 Oct 2020 at 18:35:53 +, Colin Watson wrote:
> LC_ALL should imply LANG
One thing that it does not imply is LANGUAGE, used for LC_MESSAGES as a
GNU extension (at a higher precedence than even LC_ALL).
smcv
On Mon, 26 Oct 2020 at 00:35:45 -0400, Nick Black wrote:
> Thanks for the quick response, Felix. You say that "[you] will
> probably start setting $LANG in that part of Lintian." what LANG
> will you be using? Attempting to set LANG=en_US.UTF-8 in my
> salsa ci variables resulted in setlocale(3)
On Thu, 08 Oct 2020 at 05:54:27 +0900, Charles Plessy wrote:
> /bin/open has been kindly freed a couple years ago (#732796) and I would
> like to propose to repurpose it as a standard command for opening files,
> like on Mac OS and NextStep before it.
>
> As I maintain the mime-support package
On Sat, 03 Oct 2020 at 14:42:07 +0100, Paul Sutton wrote:
> Just noticed a problem with Salsa, reporting issues with repositories.
>
> https://salsa.debian.org/public
>
> that has a list of public repositories, on the right are 4 icons for
> each repository, the one on far right of the 4,
On Mon, 21 Sep 2020 at 09:09:51 -0300, Antonio Terceiro wrote:
> Maybe you could include something like this (the wording can be improved):
>
> Note, however, that such superficial tests are still somewhat useful,
> as they will be considered, for example, to block dependencies from
>
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
> &g
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
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
On Tue, 08 Sep 2020 at 13:35:50 +0300, Alexander Volkov wrote:
> Description: Disable CIL (Common Intermediate Language) bindings
This seems like a useful profile to have.
Perhaps a slightly longer Description with more keywords would give people
a better hint about what this means, since the
On Sun, 30 Aug 2020 at 15:36:53 +0200, Raphael Hertzog wrote:
> If I know that the next upstream release
> breaks backwards compatitibly and that it will have to mature a long time
> in experimental until all other packages are ready, I might start to
> package it rigth now in debian/experimental
On Sat, 29 Aug 2020 at 15:07:07 -0500, Richard Laager wrote:
> However, this is still saying that one should prefer debian/latest over
> debian/unstable, and that debian/unstable is (sort of) only for use when
> you're also uploading to experimental.
The way I think of it phrases this a bit
On Sat, 29 Aug 2020 at 01:05:32 +0200, Raphael Hertzog wrote:
> But given that we recommend upstream/latest for the upstream branch, I'm now
> leaning towards using debian/latest as default as well.
FWIW, I like this better than any of the other suite-neutral names that
I'd previously suggested.
On Fri, 28 Aug 2020 at 01:53:59 +, stan clay wrote:
> * Package name : deepin-metacity
> Description : lightweight GTK+ window manager
Does Deepin really need both a version of Mutter *and* a version of
Metacity?
If deepin-metacity and deepin-mutter are both uploaded, they'd be the
On Fri, 28 Aug 2020 at 01:32:02 +, stan clay wrote:
> Description : lightweight GTK+ window manager for Deepin
Presumably this is a fork of src:mutter, similar to Cinnamon's src:muffin.
> https://github.com/linuxdeepin/deepin-mutter
I notice this Github repository is marked as
On Wed, 26 Aug 2020 at 16:00:02 +0200, Jonas Smedegaard wrote:
> DEP-14 includes a renaming of default branch, and even if it suggests
> using "debian/master" instead, it is explicitly not strict about that
> but suggests alternatively using "debian/unstable" or "debian/sid"
> instead.
On Wed, 19 Aug 2020 at 10:28:51 -0700, Sean Whitton wrote:
> On Wed 19 Aug 2020 at 12:49PM +02, Ulrike Uhlig wrote:
> > For actively maintained packages I personally do not understand that
> > people in 2020 develop code without using a VCS and still put out only
> > tarballs. But I might be
On Mon, 17 Aug 2020 at 12:29:13 +0200, Mattia Rizzolo wrote:
> On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> > The GNOME team intend to add an epoch to the babl and gegl libraries,
>
> Question: what about changing the package name instead, and doing a
> t
On Mon, 17 Aug 2020 at 11:52:46 +0200, Adam Borowski wrote:
> On Mon, Aug 17, 2020 at 10:21:37AM +0100, Simon McVittie wrote:
> > The GNOME team intend to add an epoch to the babl and gegl libraries
>
> Another option: as these libs are used only by gimp and gnome-photos
(for com
The GNOME team intend to add an epoch to the babl and gegl libraries,
so I'm checking for consensus (Debian Policy §5.6.12.1). As usual with
epochs, this is a bad situation that I am trying to mitigate as much as
possible, rather than anything elegant or exemplary.
babl and gegl are 2D image
On Mon, 17 Aug 2020 at 01:44:14 -0300, Tiago Zaniquelli wrote:
> After [configuring unstable apt sources] I executed apt-update and apt
> full-upgrade, so after that show me
> that the "wicd" will removed, but I can't do that because if I do that I
> will lost the program that configure my WiFi.
>
On Fri, 14 Aug 2020 at 14:46:39 +0200, Jonas Smedegaard wrote:
> Regardless of the -s option, why is command preferred over which? Due
> to it being POSIX or for some other reason?
* command is POSIX, so any Unixish environment should have it, whereas
which is non-standard, so it's anyone's
On Fri, 14 Aug 2020 at 00:55:03 +0200, Erik Gustafsson wrote:
> This "which" is heavily used at the company where I work, for java
> development etc like
> which -s java || echo "You have to install java to run this program"
Another angle you could attack this from is to change these scripts to
On Sun, 09 Aug 2020 at 15:22:20 +0100, Barak A. Pearlmutter wrote:
> I could check which architectures have julia, and which have clang,
> and list them.
>
> Build-Depends: julia [amd64 arm64 i386 ...], clang [amd64 arm64 armel
> armhf i386 ...]
>
> but that makes my skin crawl because it is
201 - 300 of 2944 matches
Mail list logo
