On Saturday, January 25, 2025 10:57:26 P.M. CST you wrote:
> I've come to realise the ITK build has 15 libraries that lintian flags with
> error library-not-linked-against-libc.
Someone suggested to run ldd -r. Okay, so what does this tell me?
$ ldd -r /lib/x86_64-linux-gnu/libITKColormap-5.4.so
On Sat, Jan 25, 2025 at 10:57:26PM -0600, Steven Robbins wrote:
> I've come to realise the ITK build has 15 libraries that lintian flags with
> error library-not-linked-against-libc.
>
> https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]
>
> The error description seems str
I've come to realise the ITK build has 15 libraries that lintian flags with
error library-not-linked-against-libc.
https://lintian.debian.org/tags/library-not-linked-against-libc.html[1]
The error description seems straightforward. But how does one solve this? I
have to
assume that the lin
Hi!
> > I'm going to have to disagree with this part, the whole point of DEP14
> > is that our debianisms are namespaced, so there's no harm in pushing
> > all branches.
>
> Are you really sure that there is no harm in, for example, pushing all
> the 5785 (and counting) branches of https://github.
Hi Rene,
> What should debian/latest be? The latest upstream (pre-)release? Aka what is
> in experimental? Or not even there,
> just preparing stuff for experimental?
This is a good question, as it goes to the core of why DEP-14
recommends debian/latest first, respectively in the debian/unstable
On Fri, 24 Jan 2025 12:22:20 +0100, Fabio Fantoni wrote:
> Il 24/01/2025 02:06, Otto Kekäläinen ha scritto:
> > Why does the majority of Debian packages still use 'master' or
> > 'debian/master' branch as the main development branch?
> I think:
> - because is not the default in tools
Yes, and mor
On Wed, 15 Jan 2025 08:43:21 +0100, Andreas Tille wrote:
> However, in all teams I'm deeply involved we asked Jelmer to not run
> Janitor automatically on the Git repositories. The rationale is, that
> if a package is not uploaded commits by the Janitor might become
> outdated - well, finally wha
Hi,
Am 25.01.25 um 22:05 schrieb Rene Engelhard:
firebird4.0 (4.0.5.3140.ds6-11) unstable; urgency=medium
.
* Upload to unstable
Which now takes over firebird-dev.
Which now means reverse-dependencies build against 4.0 firebird but do have
Depends: libreoffice-core-nogui | libreoffice
Hi,
Hi,
Am 25.01.25 um 17:34 schrieb Debian FTP Masters:
Format: 1.8
Date: Sat, 25 Jan 2025 15:24:35 +
Source: firebird4.0
Architecture: source
Version: 4.0.5.3140.ds6-11
Distribution: unstable
Urgency: medium
Maintainer: Damyan Ivanov
Changed-By: Damyan Ivanov
Changes:
firebird4.0 (4.0.
Package: wnpp
Severity: wishlist
Owner: Arthur Diniz
* Package name: kubectl
Version : 0.31.4
Upstream Author : Kubernetes
* URL : https://github.com/kubernetes/kubectl
* License : Apache-2.0
Programming Lang: Go
Description : Command-line tool for cont
Hi,
Am 25.01.25 um 19:33 schrieb Gioele Barabucci:
On 25/01/25 16:23, Rene Engelhard wrote:
I am maintaining a package which does only have debian/ in git, so gbp stuff
does not really apply, but still.
Hi,
just for the record: gbp supports debian/-only repositories.
Just for the record, i
On Thu, 2025-01-23 at 17:06 -0800, Otto Kekäläinen wrote:
> Current https://dep-team.pages.debian.net/deps/dep14/ states that the
> default Debian branch name is 'debian/latest':
>
> > In Debian this means that uploads to unstable and experimental should be
> > prepared either in
> > the debian/l
On Sat, Jan 25, 2025 at 07:17:52PM +, Tim Woodall wrote:
> I know this is experimental and so breakage is expected but it seems to
> have been like this for a while now so I'm reporting it here in case
> it's been missed.
You may be confused, as perl 5.40.1-1 was only uploaded to experimental
I know this is experimental and so breakage is expected but it seems to
have been like this for a while now so I'm reporting it here in case
it's been missed.
Apologies if there's some "obvious" resource I should be checking for
things like this but I couldn't find anything apparently related in
Le 2025-01-25 19:22, Julien Plissonneau Duquène a écrit :
Wayback Machine
FTR this project [1], according to this interview [2] (transcript [3]
search for "discussions") now aims to also archive the discussions
happening on merge requests and issues. So there is some hope for
future-proof ar
On 25/01/25 16:23, Rene Engelhard wrote:
I am maintaining a package which does only have debian/ in git, so gbp
stuff does not really apply, but still.
Hi,
just for the record: gbp supports debian/-only repositories.
Just set `overlay = True` and `export_dir = ../build-area/` in
debian/gbp.co
Le 2025-01-25 19:02, Simon McVittie a écrit :
(I assume the Salsa admins do have a way to permanently redact a
discussion thread that contains something illegal or abusive, if it
becomes necessary.)
It is also possible for the creator of a merge request (and probably for
the repository owners
Le 2025-01-25 17:04, Richard Lewis a écrit :
I think that sounds like a lot of work in order to duplicate a subset
of
the existing functionality -- is another bespoke system what debian
needs?
A more affordable option could be to implement some of the features in
the salsa CLI from `devscri
On Sat, 25 Jan 2025 at 17:40:26 +0100, Jonas Smedegaard wrote:
> When I post to a discussion at Salsa, then for how long is my post
> publicly available?
In general: until the project containing the discussion is deleted.
A "project" in Gitlab jargon is the thing that wraps a git repository;
more
Quoting Philipp Kern (2025-01-25 16:05:25)
> On 1/23/25 8:46 PM, Simon Josefsson wrote:
> > Jonas Smedegaard writes:
> >> Are discussions at Salsa preserved years down the line?
> > That is a good point. Are there any mirrors of Salsa at all? Having
> > continous replication to a couple of addit
Julien Plissonneau Duquène writes:
> Le 2025-01-24 13:00, Andrea Pappacoda a écrit :
>> Same for me. In addition, on the topic of making things easier for
>> new
>> contributors, when I first started using Salsa I felt lost in the
>> myriad
>> of features and options enabled by default. Not only
On Sat, Jan 25, 2025 at 03:34:45PM +, Richard Lewis wrote:
> Crypticverse writes:
>
> > Package: wnpp
> > Severity: wishlist
> > Owner: Crypticverse
> > X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
> >
> > * Package name: linux-os-updater
> > Version :
Crypticverse writes:
> Package: wnpp
> Severity: wishlist
> Owner: Crypticverse
> X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
>
> * Package name: linux-os-updater
> Version : 1.0.0
> Upstream Contact: Crypticverse
> * URL : https://github.co
On Fri Jan 24, 2025 at 4:49 PM GMT, Fabio Fantoni wrote:
I recently saw this project that seems good to slightly improve some
things, for example: https://fabre.debian.net/
This looks interesting!
The BTS has (or had) a SOAP(!) API. 17 years ago I tried writing a
desktop tool to try and mak
Hi,
Am 24.01.25 um 02:06 schrieb Otto Kekäläinen:
I would be curious to hear why people are *not* adopting 'debian/latest'?
Why does the majority of Debian packages still use 'master' or
'debian/master' branch as the main development branch?
Is it simply because git-buildpackage does not to de
Package: wnpp
Severity: wishlist
Owner: Crypticverse
X-Debbugs-Cc: debian-devel@lists.debian.org, crypticvers...@gmail.com
* Package name: linux-os-updater
Version : 1.0.0
Upstream Contact: Crypticverse
* URL : https://github.com/CrypticVerse/linux-os-updater
* Licens
On 1/23/25 8:46 PM, Simon Josefsson wrote:
Jonas Smedegaard writes:
Are discussions at Salsa preserved years down the line?
That is a good point. Are there any mirrors of Salsa at all? Having
continous replication to a couple of additional read-only instance would
be useful, in case Salsa bu
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: python-minijinja
Version : 2.5.0
Upstream Contact: Armin Ronacher
* URL : https://github.com/mitsuhiko/minijinja
* License : Apache-2.0
Prog
Package: wnpp
Severity: wishlist
Owner: Danial Behzadi
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: showtime
Version : 47.0
Upstream Contact: Laura Kramolis
* URL : https://apps.gnome.org/Showtime
* License : GPLv3+
Programming Lang: Python
Le 2025-01-25 10:37, Phil Morrell a écrit :
On 25 January 2025 08:07:04 GMT, "Julien Plissonneau Duquène"
wrote:
That's one thing, but going one step further, NOT pushing upstream
branches to the packaging repositories may help here as well.
I'm going to have to disagree with this part, the w
On Sat, Jan 25, 2025 at 09:07:04AM +0100, Julien Plissonneau Duquène wrote:
> Le 2025-01-24 22:43, tho...@goirand.fr a écrit :
> > What you experience shows one thing: having the default branch being
> > set correctly should be what we mandate.
>
> That's one thing, but going one step further, NOT
On 25 January 2025 08:07:04 GMT, "Julien Plissonneau Duquène"
wrote:
>Le 2025-01-24 22:43, tho...@goirand.fr a écrit :
>> What you experience shows one thing: having the default branch being
>> set correctly should be what we mandate.
We already do "If no branch is specified, the packaging sh
Hi,
Le 2025-01-24 22:43, tho...@goirand.fr a écrit :
What you experience shows one thing: having the default branch being
set correctly should be what we mandate.
That's one thing, but going one step further, NOT pushing upstream
branches to the packaging repositories may help here as well.
33 matches
Mail list logo