Re: Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

On Mon, 27 Jan 2025 at 20:35:59 +0100, Leopold Palomo-Avellaneda wrote: > El 27/1/25 a les 20:21, Eric Dorland ha escrit: > > Apologies, this is my fault. automake-1.17 landed in unstable today > > and I neglected to "Provides: automake-1.16" on it. I'll fix that with > > an upload tonight. If it

Re: Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

On Mon, 27 Jan 2025 at 20:15:35 +0100, Leopold Palomo-Avellaneda wrote: > I don't know if it is a problem of just time to have all the mirrors > synchronized, but I'm trying to rebuild a package in sid that has > libltdl-dev as Build-dep. > > However, libltdl-dev is no installable because it depen

Re: Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

El 27/1/25 a les 20:21, Eric Dorland ha escrit: * Leopold Palomo-Avellaneda (l...@alaxarxa.net) wrote: Hi, I don't know if it is a problem of just time to have all the mirrors synchronized, but I'm trying to rebuild a package in sid that has libltdl-dev as Build-dep. However, libltdl-dev is no

Rebuild all the automake-1.16 dependencies? A libltdl-dev issue?

Hi, I don't know if it is a problem of just time to have all the mirrors synchronized, but I'm trying to rebuild a package in sid that has libltdl-dev as Build-dep. However, libltdl-dev is no installable because it depends on automake-1.16 [1] and it is a "Package not available" Checking the ne

Bug#1093373: marked as done (general: lots of dependencies missing fro upgrade on trixie)

Your message dated Fri, 17 Jan 2025 15:02:23 -0700 with message-id <1864248.CLbsiaQdQ3@soren-desktop> and subject line Re: Bug#1093373: general: lots of dependencies missing fro upgrade on trixie has caused the Debian Bug report #1093373, regarding general: lots of dependencies missi

Re: Bug#1093373: general: lots of dependencies missing fro upgrade on trixie

On Friday, January 17, 2025 12:18:15 PM MST Cristobal Lanzagorta wrote: > Dependency resolution failed: > > The following packages have unmet dependencies: libkf6konq7: Breaks: > libkf5konq6 but 4:22.12.3-2+b4 is to be installed > libkpimaddressbookimporte

Bug#1093373: general: lots of dependencies missing fro upgrade on trixie

are a lot of others that present missing dependencies. I am running the KDE DE. trying to install the updates through the command line just says that the packages were ignored, and trying t do it through "Discover" just throws an error with the text bellow. It also shows a legend mention

Bug#1084906: ITP: python-pyinstaller -- bundle a Python application and all its dependencies into a single package

Programming Lang: Python Description : bundle a Python application and all its dependencies into a single package PyInstaller reads a Python script written by you. It analyzes your code to discover every other module and library your script needs in order to execute. Then it collects

Bug#1083234: RFH: libpgjava libscram-java libstringprep-java -- Java database (JDBC) driver for PostgreSQL and dependencies

assistance with maintaining the libpgjava package and the libscram-java libstringprep-java dependencies. PostgreSQL JDBC Driver allows Java programs to connect to a PostgreSQL database (8.4 or later) using standard, database independent Java code. It is an open source JDBC driver written in Pure Java

Re: RFC: packages that can be installed by the user but not used as build dependencies

On Tue Aug 20, 2024 at 12:17 AM BST, Lisandro Damián Nicanor Pérez Meyer wrote: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Qt > installa

Re: RFC: packages that can be installed by the user but not used as build dependencies

a concept that has already existed in Debian for some > time. There have always been metapackages or other similar cases that are > only intended for end users and would make no sense as build dependencies, > such as all of the task-* packages. > > Lintian feels like the right place t

Re: RFC: packages that can be installed by the user but not used as build dependencies

On Mon, 19 Aug 2024 at 20:21, Samuel Thibault wrote: > > Hello, > > Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a > ecrit: > > But users would love to have something like 'qt6-full-dev'. And the > > reason we never provided them with this meta-package is that package

Re: RFC: packages that can be installed by the user but not used as build dependencies

en adding a special section in our > policy. I could have sworn that we already had tags like that in Lintian. Certainly, this is a concept that has already existed in Debian for some time. There have always been metapackages or other similar cases that are only intended for end users and would make no

Re: RFC: packages that can be installed by the user but not used as build dependencies

Hello, Lisandro Damián Nicanor Pérez Meyer, le lun. 19 août 2024 20:17:08 -0300, a ecrit: > But users would love to have something like 'qt6-full-dev'. And the > reason we never provided them with this meta-package is that package > maintainers would use it almost everywhere, dragging the whole Q

RFC: packages that can be installed by the user but not used as build dependencies

bian.net/images/qt6_build_deps.png At the moment of this writing Qt has 36 submodules. Almost all of them provide a -dev package with the usual headers et al, and required dependencies. So, if you install qt6-multimedia-dev you should also get basic stuff like qt6-base-dev. Apart from being easier to build

Re: MBF: drop dependencies on system-log-daemon

On Wed, 29 May 2024 at 11:48, Lorenzo wrote: > > Hi, > > socklog-run is a syslog daemon, it has no dependency on > system-log-daemon Yes the initial list had some false positives, it has been pruned when filing and socklog-run is not part of it: https://bugs.debian.org/cgi-bin/pkgreport.cgi?users

Re: MBF: drop dependencies on system-log-daemon

On Tue, 28 May 2024 at 08:43, Guillem Jover wrote: > > Hi! > > On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote: > > On 5/27/24 22:18, Simon McVittie wrote: > > > So I think your syslogd-is-journald could not be a Provides on the > > > existing systemd-sysv package, and would have to be a

Re: MBF: drop dependencies on system-log-daemon

On Tue, 28 May 2024 at 02:57, Simon Richter wrote: > > Hi, > > On 5/27/24 22:18, Simon McVittie wrote: > > > So I think your syslogd-is-journald could not be a Provides on the > > existing systemd-sysv package, and would have to be a separate package. > > I'm not sure that the benefit is worth it

Re: MBF: drop dependencies on system-log-daemon

Hi! On Tue, 2024-05-28 at 10:57:13 +0900, Simon Richter wrote: > On 5/27/24 22:18, Simon McVittie wrote: > > So I think your syslogd-is-journald could not be a Provides on the > > existing systemd-sysv package, and would have to be a separate package. > > I'm not sure that the benefit is worth it

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 15:08:38 +0100, Simon McVittie wrote: >I know fail2ban and logcheck do read plain-text logs (although as >mentioned, fail2ban already has native Journal-reading support too), and I >would guess that fwlogwatch, snort and xwatch probably also read the logs. Those files could us

Re: MBF: drop dependencies on system-log-daemon

Hi, On 5/27/24 22:18, Simon McVittie wrote: So I think your syslogd-is-journald could not be a Provides on the existing systemd-sysv package, and would have to be a separate package. I'm not sure that the benefit is worth it (and I see that Luca is sure that the benefit *isn't* worth it). I a

Re: MBF: drop dependencies on system-log-daemon

Russ Allbery writes: > Simon McVittie writes: > >> I know fail2ban and logcheck do read plain-text logs (although as >> mentioned, fail2ban already has native Journal-reading support too), and >> I would guess that fwlogwatch, snort and xwatch probably also read the >> logs. > > logcheck also ha

Re: MBF: drop dependencies on system-log-daemon

Simon McVittie writes: > On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote: >> The list of affected packages according to apt-cache showpkg is not >> that long either: >> >> logcheck > However, for packages that want to read a traditional /var/log/syslog > or similar, notably logch

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 17:04, Russ Allbery wrote: > > Simon McVittie writes: > > > I know fail2ban and logcheck do read plain-text logs (although as > > mentioned, fail2ban already has native Journal-reading support too), and > > I would guess that fwlogwatch, snort and xwatch probably also read

Re: MBF: drop dependencies on system-log-daemon

Simon McVittie writes: > I know fail2ban and logcheck do read plain-text logs (although as > mentioned, fail2ban already has native Journal-reading support too), and > I would guess that fwlogwatch, snort and xwatch probably also read the > logs. logcheck also has native journal-reading support.

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 15:09, Simon McVittie wrote: > > On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote: > > Yes this sounds reasonable - do you already have an idea about which > > is which, from the list above? > > Nothing reliable, so please check before opening bugs. > > I know fail

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 14:38:44 +0100, Luca Boccassi wrote: > Yes this sounds reasonable - do you already have an idea about which > is which, from the list above? Nothing reliable, so please check before opening bugs. I know fail2ban and logcheck do read plain-text logs (although as mentioned, f

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 13:59, Simon McVittie wrote: > > On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote: > > The list of affected packages according to apt-cache showpkg is not > > that long either: > > > > anacron > > approx > > fail2ban > > fwlogwatch > > heartbeat > > hip

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 21:38:07 +0900, Simon Richter wrote: > My train of thought here is that there should be a "syslogd-is-journald" > package that Provides/Conflicts system-log-daemon ... > hence the idea to use systemd-sysv instead of a new empty > package as the alternative I wonderered about

Re: MBF: drop dependencies on system-log-daemon

nly remaining choice is the status quo: systemd(-sysv) *do not* > have a Provides: system-log-daemon. But then most of the dependent > packages need to change, if we want the persistent Journal to be enough > to satisfy their dependencies (which makes sense). > > Is that all correct? Yep, that's the gist of it

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 03:29:53 +0100, Luca Boccassi wrote: > The list of affected packages according to apt-cache showpkg is not > that long either: > > anacron > approx > fail2ban > fwlogwatch > heartbeat > hippotat-server > inetutils-ftpd > inetutils-inetd > inetutils-talkd >

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 13:38, Simon Richter wrote: > > Hi, > > On 5/27/24 19:59, Luca Boccassi wrote: > > > This MBF is > > not about removing the virtual provides where they are defined, they > > can stay as-is, but downgrading/removing the hard dependenci

Re: MBF: drop dependencies on system-log-daemon

fer to have a text version because their other tools consume it. So the only remaining choice is the status quo: systemd(-sysv) *do not* have a Provides: system-log-daemon. But then most of the dependent packages need to change, if we want the persistent Journal to be enough to satisfy their depend

Re: MBF: drop dependencies on system-log-daemon

Hi, On 5/27/24 19:59, Luca Boccassi wrote: This MBF is not about removing the virtual provides where they are defined, they can stay as-is, but downgrading/removing the hard dependencies so that we can make Debian minimal images. So the policy becomes "a logging service is present ev

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 12:53, Ansgar 🙀 wrote: > > Hi, > > On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote: > > TL;DR: drop or downgrade dependency on system-log-daemon from any > > package that declares it > > +1. Log service freedom is important. Packages should in general not > pull in a

Re: MBF: drop dependencies on system-log-daemon

On Mon, 27 May 2024 at 06:00, Simon Richter wrote: > > Hi, > > On 5/27/24 11:29, Luca Boccassi wrote: > > > With the default system installation including persistent journald by > > default, it doesn't seem useful anymore to have such dependencies. They > &g

Re: MBF: drop dependencies on system-log-daemon

Hi, On Mon, 2024-05-27 at 03:29 +0100, Luca Boccassi wrote: > TL;DR: drop or downgrade dependency on system-log-daemon from any > package that declares it +1. Log service freedom is important. Packages should in general not pull in a log service as a dependency. > The list of affected packages a

Re: MBF: drop dependencies on system-log-daemon

Hi, On 5/27/24 11:29, Luca Boccassi wrote: With the default system installation including persistent journald by default, it doesn't seem useful anymore to have such dependencies. They are leftovers from an era where not having a system logging setup that just worked by default was a

MBF: drop dependencies on system-log-daemon

package system-log-daemon, which we cannot add on systemd given it would make rsyslog and other packages that also declare it uninstallable, which is not nice. But this means other logging systems get pulled in even when they are not requested, due to this dependencies. I tried playing with apt and

Re: openssl 3.1.5-1.1 effect on reverse dependencies

On Wed, Mar 06, 2024 at 08:50:59PM +0100, Micha Lenk wrote: > >> You recently uploaded openssl 3.1.5-1.1. > >> > >> Are you tracking the effect it had on reverse dependencies? > >That's just a part of the time64 transition and it's definitely tracked by

Re: openssl 3.1.5-1.1 effect on reverse dependencies

Hi all, Am 6. März 2024 17:05:15 MEZ schrieb Andrey Rahmatullin : >On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote: >> Hi Benjamin! >> >> You recently uploaded openssl 3.1.5-1.1. >> >> Are you tracking the effect it had on reverse dependencies?

Re: openssl 3.1.5-1.1 effect on reverse dependencies

On Wed, Mar 06, 2024 at 07:47:57AM -0800, Otto Kekäläinen wrote: > Hi Benjamin! > > You recently uploaded openssl 3.1.5-1.1. > > Are you tracking the effect it had on reverse dependencies? That's just a part of the time64 transition and it's definitely tracked

openssl 3.1.5-1.1 effect on reverse dependencies

Hi Benjamin! You recently uploaded openssl 3.1.5-1.1. Are you tracking the effect it had on reverse dependencies? Do you have plans to do any follow-up uploads or +b1 rebuilds of other packages? For example curl is unable to satisfy build dependencies on armhf/armel at the moment: https

Splitting collectd dependencies [Was: Re: Another take on package relationship substvars]

tall *all* > > plugin dependencies with collectd, which would be a big waste of space. > > > > The other option would be to make one packe per plugin as redhat does, > > but do we really want 20 packages with a single file? > > Yes, please. So that installing package colle

Bug#1060312: ITP: node-yarn-plugin-apt -- Yarn plugin to resolve dependencies from packages installed in apt

: Expat Programming Lang: JavaScript Description : Yarn plugin to resolve dependencies from packages installed in apt This yarn plugin allows apt installed packages satisfy a nodejs project's dependencies. The package is a valuable addition to Debian because if facilitate

Re: sbuild can't find piuparts even when it's listed in build dependencies

On 9/26/23 10:24, Johannes Schauer Marin Rodrigues wrote: piuparts is run outside the build chroot, not inside of it. Thanks, that's useful info. My best guess is that the issue here is that piuparts is installed in /sbin and /sbin isn't in the default sudo path, but that would imply that there

Re: sbuild can't find piuparts even when it's listed in build dependencies

Hi, Quoting Jonathan Kamens (2023-09-26 15:20:49) > I'm trying to use sbuild to build my package, and it's failing to find > piuparts: > > | Post Build   > | > +--

sbuild can't find piuparts even when it's listed in build dependencies

I'm trying to use sbuild to build my package, and it's failing to find piuparts: | Post Build   | +--+ piuparts sudo: piuparts: command not foun

Re: versioned dependencies between -dev packages

Hi, Le sam. 15 juil. 2023, 17:36, Nicolas Boulenguez a écrit : > Julien Puydt > > - Indeed this is quite fragile; I have two scripts for Coq packages [1]: > > one to tell me about the deps (I give it which package I have to upgrade > > and it gives the list of affected packages by pass) and the

Re: versioned dependencies between -dev packages

Julien Puydt > - Indeed this is quite fragile; I have two scripts for Coq packages [1]: > one to tell me about the deps (I give it which package I have to upgrade > and it gives the list of affected packages by pass) and the other to > generate the migration script (I give it the list of new packa

Bug#1039093: ITP: libalien-build-perl -- module to build external dependencies for use in CPAN

-Build * License : Artistic or GPL-1+ Programming Lang: Perl Description : module to build external dependencies for use in CPAN Alien::Build provides tools for building external (non-CPAN) dependencies for CPAN. It is mainly designed to be used at install time of a CPAN client, and

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Wed, 21 Jun 2023 10:33:01 +0100, Simon McVittie wrote: > On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie > > wrote: > > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer > > > receives upstream maintenance or

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Wed, 21 Jun 2023 at 08:50:30 +0200, Stephen Kitt wrote: > On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to S

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

Hi Simon, On Mon, 12 Jun 2023 17:24:03 +0100, Simon McVittie wrote: > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > upstream maintenance or releases. Maintained software that uses SDL 1.2 > should be ported to SDL 2. Given the time scales involved, is it worth waiti

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Tue, 13 Jun 2023 at 11:10:41 +0800, Paul Wise wrote: > On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > > upstream maintenance or releases. Maintained software that uses SDL 1.2 > > should be ported to SDL 2.

Re: Mass bug filing / call for testing: dependencies on SDL 1.2

On Mon, 2023-06-12 at 17:24 +0100, Simon McVittie wrote: > SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives > upstream maintenance or releases. Maintained software that uses SDL 1.2 > should be ported to SDL 2. It was pointed out to me on IRC that some SDL 1.2 extension l

Mass bug filing / call for testing: dependencies on SDL 1.2

SDL 1.2 was superseded by SDL 2 several years ago, and no longer receives upstream maintenance or releases. Maintained software that uses SDL 1.2 should be ported to SDL 2. For legacy software that cannot be ported, SDL upstream have produced a replacement library, sdl12-compat, which implements t

Bug#1027770: ITP: python-hatch-requirements-txt -- Read dependencies from requirements-txt

/repo-helper/hatch-requirements-txt * License : MIT/expat Programming Lang: Python Description : Read dependencies from requirements-txt This module required for packing python-apeye-core: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1027765 Where python-apeye-core dependency

Mass bug filing: dependencies on dbus

The dbus package in bookworm has been broken up into several smaller packages, so that people who want to use a non-reference implementation of the D-Bus message buses (like dbus-broker) can do so. Various packages should ideally change their dependencies. The dbus package in Debian 11 already

Re: libc6-dev have unmet dependencies in stable-bullseye

orry for the confusion. > > Step to reproduce: > > 1. Install Debian with debian-11.5.0-amd64-netinst.iso > 2. echo 'deb http://deb.debian.org/debian bullseye main' > > /etc/apt/sources.list > 3. apt-get clean > 4. apt-get update > 5. apt-get install libc6-dev &

Re: libc6-dev have unmet dependencies in stable-bullseye

bullseye main' > /etc/apt/sources.list 3. apt-get clean 4. apt-get update 5. apt-get install libc6-dev Then I get the same message: > The following packages have unmet dependencies: > libc6-dev : Depends: libc6 (= 2.31-13+deb11u4) but 2.31-13+deb11u5 > is to be installed > E: Una

Re: libc6-dev have unmet dependencies in stable-bullseye

On Mon, 31 Oct 2022 at 11:21:57 +0100, Markus Ritzmann wrote: > > The following packages have unmet dependencies: > > libc6-dev : Depends: libc6 (= 2.31-13+deb11u4) but 2.31-13+deb11u5 is to be > > installed > > E: Unable to correct problems, you have held broken packages

libc6-dev have unmet dependencies in stable-bullseye

Hi Currently libc6-dev cannot be installed on bullseye because of unmet dependencies. Error message: > The following packages have unmet dependencies: > libc6-dev : Depends: libc6 (= 2.31-13+deb11u4) but 2.31-13+deb11u5 is to be > installed > E: Unable to correct problems, y

Bug#1009141: ITP: importlab -- Importlab is a library for Python that automatically infers dependencies and calculates a dependency graph.

Lang: Python3 Description : Importlab is a library for Python that automatically infers dependencies and calculates a dependency graph Importlab is a library for Python that automatically infers dependencies and calculates a dependency graph. It can perform dependency ordering of a set of

Bug#1000297: ITP: node-jose -- JOSE library without dependencies

Description : JOSE library without dependencies "JSON Web Almost Everything" - JWA, JWS, JWE, JWT, JWK, JWKS with no dependencies using runtime's native crypto in Node.js, Browser, Cloudflare Workers, Electron, and Deno. . The following specifications are implemented by jo

Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

Am Donnerstag, dem 28.10.2021 um 11:58 +0300 schrieb Uladzimir Bely: > > I need to cache outside of schroot these .deb files that were downloaded by > apt. They are supposed to be used for creaing a local partial debian > repository, so that the second build will use this local repo instead of

Re: Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

ny results under `buster` host - apt cache is hardcoded to be cleaned by sbuild after installing dependencies. So, as I understood, the only way to cache dependency packages under `buster` is to download them in some external way. -- Uladzimir Bely Promwad Ltd. External service provider of ilbers

Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

gt; based distro for embedded systems. In two words, it's similar to Buildroot, > Yocto and others, but it uses official Debian packages plus allows to build > own customer packages. > > Currently it uses some own set of scripts to download dependencies, install > them is build

Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

Hello. Thanks for the idea with $apt_keep_downloaded_packages=1. I'll try to play with it. Previously I tried to mount external directory to /var/cache/apt/archives inside schroot, but finally found it almost empty (only some .lock file was there, AFAIR). As I understand, that it was really us

Re: Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

, but it uses official Debian packages plus allows to build own customer packages. Currently it uses some own set of scripts to download dependencies, install them is build chroot and build the package. Every .deb that was downloaded during system build is cached internally. So, for the seco

Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

Hi, Quoting Uladzimir Bely (2021-10-28 10:58:26) > When building a package with sbuild, some packages (dependencies of package > being built) are internally downloaded and installed by apt. After the build > finished, schroot is cleaned again (while everything is done in overlay) >

Re: sbuild/schroot: need to get .deb files internally downloaded as package dependencies

On Thu, Oct 28, 2021 at 11:58:26AM +0300, Uladzimir Bely wrote: > When building a package with sbuild, some packages (dependencies of package > being built) are internally downloaded and installed by apt. After the build > finished, schroot is cleaned again (while everything is done i

sbuild/schroot: need to get .deb files internally downloaded as package dependencies

When building a package with sbuild, some packages (dependencies of package being built) are internally downloaded and installed by apt. After the build finished, schroot is cleaned again (while everything is done in overlay) I need to cache outside of schroot these .deb files that were

Mass bug filing: dependencies on gtksourceview3

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 applicati

Re: Question about generated dependencies

;t make it obvious for me what > > part of libnih requires this dependency. Can someone aware with that > > package shed some light? > > So... I just learned something new today, thanks! :) > > My first thought was "dpkg-shlibdeps and symbols files". So in short: &

Re: Question about generated dependencies

) My first thought was "dpkg-shlibdeps and symbols files". So in short: - once upon a time, the library -dev packages came with a .shlibs file that said "if you use this package to compile against the library, you need to add these dependencies to your binary package" -

Question about generated dependencies

-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi All, While playing with glibc 2.33 (I made a couple of changes on the 2.31-9 and built it locally), I stumbled upon the following generated dependency in libnih1: $ apt info libnih1 Package: libnih1 Version: 1.0.3-11 Priority: optional Section:

Re: Usage of language specific profiles in build dependencies

Hi Paul, > FTBFS) but it avoids busywork for maintainers that are not involved in > bootstrapping java. Machine time is cheap, volunteer time is not. this is not for bootstrapping. This is to prevent building of language bindings for e.g. Java on platforms where there is simply no Java. This is a

Re: Usage of language specific profiles in build dependencies

On 2/11/21 10:40 AM, Paul Gevers wrote: > Hi, > > On 11-02-2021 10:16, Matthias Klose wrote: >> These dependencies should look like: >> >> default-jdk [!hppa !hurd-i386 !kfreebsd-any] >> >> or >> >> default-jdk [alpha amd64 arm64 armel ar

Re: Usage of language specific profiles in build dependencies

Hi, On 11-02-2021 10:16, Matthias Klose wrote: > These dependencies should look like: > > default-jdk [!hppa !hurd-i386 !kfreebsd-any] > > or > > default-jdk [alpha amd64 arm64 armel armhf i386 ia64 m68k mips64el mipsel > powerpc ppc64 ppc64el riscv64 s390x sh4 spa

Usage of language specific profiles in build dependencies

Please see https://bugs.debian.org/982085 I think it's wrong to encode build dependencies for language stacks that are not available on some platforms, just using a profile. Seen in gettext: default-jdk , maven-repo-helper and also in db5.3. A more cooperative usage of such

Bug#978600: Substantial increase in pseudo-Essential due to libnsl2 and libtirpc3 (and dependencies)

Package: libpam-modules Version: 1.4.0-1 Severity: normal X-Debbugs-Cc: j...@joshtriplett.org, debian-devel@lists.debian.org The new pam 1.4.0 has switched pam_unix from libnsl.so.1 (in libc6) to libnsl2 and libtirpc3, which brings those packages into the pseudo-Essential set. This is a rather sub

Bug#976703: ITP: vendorcheck -- Check that all your Go dependencies are properly vendored

: Go Description : Check that all your Go dependencies are properly vendored vendorcheck Check that all your Go dependencies are properly vendored . . $ vendorcheck ./... [!] dependency not vendored: golang.org/x/tools/go/buildutil [!] dependency not vendored: github.com/kisielk/gotool

Re: Mass bug filing: dependencies on GTK 2

On Thu, May 14, 2020 at 9:28 AM Jonathan Dowland wrote: > Thanks for expressing this so well! For folks interested in working with > historical software, historical toolkits are vital. It was for this > reason I am sad at the glee with which people removed Qt4 from the > archive, and similar such

Re: Mass bug filing: dependencies on GTK 2

On Wed, Apr 29, 2020 at 11:40:01AM +0200, Simon McVittie wrote: GTK 2 is used by some important productivity applications like GIMP, and has also historically been a popular UI toolkit for proprietary software that we can't change, so perhaps removing GTK 2 from Debian will never be feasible. How

Re: Mass bug filing: dependencies on GTK 2

On 2020-04-29 18:37:50 +0100, Simon McVittie wrote: > Given GTK 2's lack of feature development (for things like HiDPI) it > seems higher-severity than "a problem which doesn't affect the package's > usefulness", and it's certainly not "presumably trivial to fix" in > many cases. Note that missing

Bug#959397: ITP: python-resolvelib -- module to resolve abstract dependencies into concrete ones

resolve abstract dependencies into concrete ones python3-resolvelib provides a `Resolver` class that includes dependency resolution logic. You give it some things, and a little information on how it should interact with them, and it will spit out a resolution result. This is a new dependency

Re: Mass bug filing: dependencies on GTK 2

On Wed, Apr 29, 2020 at 5:58 PM Adam Borowski wrote: > I wonder, perhaps it'd be better to use "normal" for packages that _use_ > GTK2, and no bug at all for those that provide an input method/theme/etc > for GTK2+3? A bug that's not supposed to be actioned upon is no good. > > And probably an im

Re: Mass bug filing: dependencies on GTK 2

On Wed, 29 Apr 2020 at 23:58:01 +0200, Adam Borowski wrote: > I wonder, perhaps it'd be better to use "normal" for packages that _use_ > GTK2, and no bug at all for those that provide an input method/theme/etc > for GTK2+3? If I can immediately identify a package as providing one of those, I'll sk

Re: Mass bug filing: dependencies on GTK 2

On Wed, Apr 29, 2020 at 06:37:50PM +0100, Simon McVittie wrote: > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: > > I think you should > > file the bugs at severity:minor, given the amount of involved packages, > > and the fact that you state we might not be able to remove gtk2 in ma

Re: Mass bug filing: dependencies on GTK 2

On Wed, 29 Apr 2020 at 21:48:55 +0200, Johannes Schauer wrote: > I wasn't able to figure out what code is generating this but usually the right > tool to analyze transitive dependency relationships is dose3 or tools using it > like build-rdeps from devscripts. I generated the MBF list by using dak

Re: Mass bug filing: dependencies on GTK 2

On Wed, 29 Apr 2020, 9:29 pm Michael Biebl, wrote: > Am 29.04.20 um 19:37 schrieb Simon McVittie: > > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: > > >> I think you should > >> file the bugs at severity:minor, given the amount of involved packages, > >> and the fact that you stat

Re: Mass bug filing: dependencies on GTK 2

t does not yet automatically turn a src:foo argument into the binary packages produced by foo. Another disadvantage is, that it's often non-intuitive how non-direct dependencies are pulled in. In this case it's a direct dependency so that's easy but in the general case you can obtain th

Re: Mass bug filing: dependencies on GTK 2

Am 29.04.20 um 19:37 schrieb Simon McVittie: > On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: >> I think you should >> file the bugs at severity:minor, given the amount of involved packages, >> and the fact that you state we might not be able to remove gtk2 in many >> many years. >

Re: Mass bug filing: dependencies on GTK 2

On Wed, 29 Apr 2020 at 18:04:41 +0200, Mattia Rizzolo wrote: > You haven't included a copy of the proposed text My intention was for it to be very similar to this MBF announcement (apart from adding a few references to "this package" etc.), except in cases where I can tell the dependency is likely

Re: Mass bug filing: dependencies on GTK 2

Hi Andreas, On 29/04/2020 12:11, Andreas Henriksson wrote: > reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep gscan2pdf > * gscan2pdf (for libgail-common) > * gscan2pdf (for libgail-common) Thanks! Regards Jeff signature.asc Description: OpenPGP d

Re: Mass bug filing: dependencies on GTK 2

On Wed, Apr 29, 2020 at 10:38:27AM +0100, Simon McVittie wrote: > Quite a lot of source packages (see attached list and dd-list) have > Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with > a Depends on it. > > Mass-filed bugs for this will be usertagged to appear in > https://

Re: Mass bug filing: dependencies on GTK 2

Hi Jeff, On Wed, Apr 29, 2020 at 11:58:53AM +0200, Jeff wrote: > Hi Simon, > > I don't understand why gscan2pdf is in the list, as the versions in > stable, testing and unstable are Perl packages which use libgtk3-perl. > > Can you explain? reverse-depends -r testing -b src:gtk+2.0 2>&1 | grep

Re: Mass bug filing: dependencies on GTK 2

Hi Simon, On 29/04/2020 11:38, Simon McVittie wrote: > Quite a lot of source packages (see attached list and dd-list) have > Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with > a Depends on it. I don't understand why gscan2pdf is in the list, as the versions in stable, testi

Mass bug filing: dependencies on GTK 2

Quite a lot of source packages (see attached list and dd-list) have Build-Depends on GTK 2 (libgtk2.0-dev), or produce binary packages with a Depends on it. GTK 2 was superseded by GTK 3 in 2011 (see ). It no longer receives any significant upstream maintenance, and

  1   2   3   4   5   6   7   8   9   10   >