> "Luca" == Luca Boccassi writes:
Luca> Wouldn't a pre-depends solve the ordering problem in this
Luca> case?
No.
At least it's really hard to prove that it does, we have a bad track
record of getting it wrong, and if it were to work in a
specific instance it would depend on implem
On Tue, Aug 17, 2021 at 09:15:24PM -0400, Boyuan Yang wrote:
> Besides, will the new "which" tool be installed in Debian by default? Since
> debianutils is Essential:yes, not providing "which" tool by default could
> probably break some existing packages.
My personal opinion is that no one should
Apparently something went wrong with the bug report and this wasn't sent to
the list...
-- Forwarded message -
From: Phil Bellalouna https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-sugar-devel>>
Date: Sun, Aug 15, 2021 at 12:32 PM
Subject: ITP: opensmalltalk-vm -- High
On Wed, Aug 18, 2021 at 2:08 AM Hideki Yamane wrote:
> blhc test on salsa-ci fails as below but it seems that blhc's fault
> to me. How can I avoid this failure?
It looks correct to me, -D_FORTIFY_SOURCE=2 is indeed missing from the
c++ command-line. The standard build command for C++ programs
Simon,
Thanks so much for your comprehensive answer. It's a great summary
that I think would be really useful for those of us who are package
maintainers who don't have a strong position one way or another
vis-a-vis usrmerge vs merged-/usr-via-symlink-farms, but just want to
do what is best for o
On Tue, Aug 17, 2021 at 12:17 PM Simon Richter wrote:
> This is also an additional burden on package maintainers: explaining how
> they arrived at that particular "upstream" package in a reproducible way
Debian explaining how we arrived at a particular orig.tar.gz is well
established; use a debia
On Tue, Aug 17, 2021 at 10:39 AM admin4 wrote:
> today was the day trying out the new Debian 11 with LTS (LTS is a reason for
> users consider switching to Ubuntu, so good choice there)
Debian 11/bullseye is not in LTS mode yet. Debian 10/buster will be in
LTS mode in a year's time when regular
Hi,
blhc test on salsa-ci fails as below but it seems that blhc's fault
to me. How can I avoid this failure?
> $ blhc --debian --line-numbers --color ${SALSA_CI_BLHC_ARGS}
> ${WORKING_DIR}/*.build || [ $? -eq 1 ]
>
> 94:CPPFLAGS missing (-D_FORTIFY_SOURCE=2): /usr/lib/ccache/c++ -dM -E -c
>
Hi all,
I just noticed that the "which" command provided by debianutils has been
declared as deprecated in Debian Sid:
% /usr/bin/which test
/usr/bin/which: this version of 'which' is deprecated and should not be used.
/usr/bin/test
Obviously it was caused by the upload of debianutils/5.0-1 onto
On Tue, 17 Aug 2021 at 20:17, Simon Richter wrote:
>
> Hi,
>
> On 8/17/21 8:02 PM, Simon McVittie wrote:
>
> > However, some people (most notably the dpkg maintainer, who has thought
> > about this more than most) argue that merged-/usr's "aliasing" symlinks
> > /bin -> usr/bin, etc. are unsupport
On Tue, 17 Aug 2021 at 15:08, Sam Hartman wrote:
>
> > "Luca" == Luca Boccassi writes:
>
> Luca> On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
> Luca> If src:usrmerge is made transitively-essential, from that
> Luca> point onward it wouldn't matter if a package is n
Package: wnpp
Severity: wishlist
Owner: Andreas Henriksson
* Package name: golang-github-mendersoftware-progressbar
Version : 0.0.3-1
Upstream Author : Mender
* URL : https://github.com/mendersoftware/progressbar
* License : Apache-2.0
Programming Lang: Go
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero
* Package name: flake8-builtins
Version : 1.5.3
Upstream Author : Gil Forcada Codinachs
* URL : https://github.com/gforcada/flake8-builtins
* License : GPL2
Programming Lang: Python
Description :
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero
* Package name: flake8-blind-except
Version : 0.2.0
Upstream Author : Elijah Andrews
* URL : https://github.com/elijahandrews/flake8-blind-except
* License : MIT
Programming Lang: python
Description
Package: wnpp
Severity: wishlist
Owner: Jose Luis Rivero
* Package name: ignition-plugin
Version : 1.2.0
Upstream Author : Open Robotics
* URL : https://github.com/ignitionrobotics/ign-plugin/
* License : Apache-2
Programming Lang: C++
Description : Lib
Hi,
On 8/17/21 8:02 PM, Simon McVittie wrote:
However, some people (most notably the dpkg maintainer, who has thought
about this more than most) argue that merged-/usr's "aliasing" symlinks
/bin -> usr/bin, etc. are unsupportable, and the only correct way to
consolidate static files to be physi
On 2021-08-16, Paul Wise wrote:
> While discussing PyPI with the Python team, it was pointed out that
> sometimes the tarball contains things that cannot be regenerated from
> just the VCS snapshot, such as information stored in the VCS history,
> so perhaps the recommendation should be to prefer
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 which
On Tue, Aug 17, 2021 at 05:56:15PM +0100, Simon McVittie wrote:
> tl;dr: I would prefer it if the usrmerge variation continues to be
> exercised for the testing suite for the foreseeable future.
ack, thanks (for the long version especially :) & agreed.
--
cheers,
Holger
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒
Quoting Marc Haber (2021-08-17 18:56:59)
> On Tue, 17 Aug 2021 15:52:27 +0200, Jonas Smedegaard
> wrote:
> >Quoting Simon Richter (2021-08-17 14:17:05)
> >> Rather than accept defeat, I'd like Debian to push upstreams more
> >> aggressively for higher quality releases, and also to make
> >> judg
Hi,
again, I'm planning an small mass bug filing against obsolete transitional
packages
which are at least marked "dummy transitional" since the buster release, IOW,
they have been transitional for both the buster and bullseye release and thus
can definitly go now.
There are just 137 bugs to be
On Mon, 16 Aug 2021 16:56:34 +0200, Wouter Verhelst
wrote:
>There is pushback against having usrmerge as the "default" thing,
>because it confuses dpkg. Therefore some people would prefer a solution
>that does not require all systems to have /bin etc be symlinks unless
>and until the transition is
On Tue, Aug 17, 2021 at 05:19:06PM +0100, Simon McVittie wrote:
> 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
On Tue, 17 Aug 2021 15:52:27 +0200, Jonas Smedegaard
wrote:
>Quoting Simon Richter (2021-08-17 14:17:05)
>> Rather than accept defeat, I'd like Debian to push upstreams more
>> aggressively for higher quality releases, and also to make judgement
>> calls on whether a particular package is even s
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 2021-08-17, Holger Levsen wrote:
> On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
>> The failure mode we have sometimes seen is packages that were built in
>> a merged-/usr chroot not working on a non-merged-/usr system, although
>> that's detected by the reproducible-builds inf
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 r
On Tue, Aug 17, 2021 at 06:51:35AM +, Paul Wise wrote:
> On Mon, Aug 16, 2021 at 1:19 AM Paul Wise wrote:
>
> > 1. the ecosystems I'm talking about include cargo, npm, browser
> > extensions, rubygems, pypi, CPAN etc.
>
> Examples of what current Debian practices are for these ecosystems:
[..
> "Luca" == Luca Boccassi writes:
Luca> On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
Luca> If src:usrmerge is made transitively-essential, from that
Luca> point onward it wouldn't matter if a package is no longer
Luca> compatible with the legacy split-usr setup
Quoting Simon Richter (2021-08-17 14:17:05)
> Rather than accept defeat, I'd like Debian to push upstreams more
> aggressively for higher quality releases, and also to make judgement
> calls on whether a particular package is even suitable for a stable
> release instead of assuming that by defau
Hi,
On 8/16/21 3:18 AM, Paul Wise wrote:
I'd like to suggest that we standardise on the upstream VCS for our
orig.tar.gz files and phase out use of upstream packaging ecosystems.
This is also an additional burden on package maintainers: explaining how
they arrived at that particular "upstrea
On Mon, Aug 16, 2021 at 07:18:03PM +0200, Wouter Verhelst wrote:
> Well, then we disagree (and that's fine). Personally, I'd rather have my
> CI system try to find as many problems as possible, so I can fix them
> *before* I upload, rather than after.
I didn't try to build a CI system here, but ra
Dear Debian Team,
*1) first (always) say something positive*
being a big fan of Debian since aprox 10 years
thanks for all your efforts making Debian a easy to install (universal)
reliable system, that lowers the bar for users trying to go Open Source
and GNU Linux and FreeSoftware (a migration
On Tue, 2021-08-17 at 12:07 +0200, David Kalnischkies wrote:
> On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote:
> > On Aug 16, David Kalnischkies wrote:
> > > Is perhaps pure existence not enough, do I need to provide an upgrade
> > > path as simple as possible as well?
> > If you hav
On Mon, Aug 16, 2021 at 03:13:48PM +0200, Marco d'Itri wrote:
> On Aug 16, David Kalnischkies wrote:
> > Is perhaps pure existence not enough, do I need to provide an upgrade
> > path as simple as possible as well?
> If you have specific ideas about how the upgrade path could be improved
> then I
On Tue, 2021-08-17 at 14:07 +0530, Pirate Praveen wrote:
>
> 2021, ഓഗസ്റ്റ് 17 12:18:00 PM IST, Paul Wise ൽ എഴുതി
> > On Mon, Aug 16, 2021 at 8:25 PM Pirate Praveen wrote:
> >
> > > Many node modules don't tag their releases so its really hard to get
> > > exact source code corresponding to an np
On Mon, Aug 16, 2021 at 03:08:24PM +0100, Simon McVittie wrote:
> I would like to add the same 1: epoch to the steam package in Debian
> and all of its binary packages, so that all of our version numbers
> (Valve's, Debian's and Ubuntu's) are directly comparable again.
ACK, I'm also fine with addi
On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote:
> The failure mode we have sometimes seen is packages that were built in
> a merged-/usr chroot not working on a non-merged-/usr system, although
> that's detected by the reproducible-builds infrastructure and is already
> considered t
2021, ഓഗസ്റ്റ് 17 12:18:00 PM IST, Paul Wise ൽ എഴുതി
>On Mon, Aug 16, 2021 at 8:25 PM Pirate Praveen wrote:
>
>> Many node modules don't tag their releases so its really hard to get
>> exact source code corresponding to an npmjs.com release.
>
>It is probably worth filing upstream issues when yo
Hi,
Problem: Currently uploading new upstream versions to unstable during freeze is
discouraged. It means users using unstable don't get new updates and developers
are forced to upload to experimental. Using experimental directly is risky as
it can have changes not ready for unstable also.
Prop
On Tue, Aug 17, 2021 at 4:05 AM Daniel Lewart wrote:
> That leaves two candidates for the canonical URI:
> * http://deb.debian.org/debian-security
> * http://security.debian.org/debian-security
>
> Is there consensus as to which one is preferred?
Both of these URLs point at the Fastly CDN, so
Package: wnpp
Severity: wishlist
Owner: Yadd
X-Debbugs-Cc: debian-devel@lists.debian.org,
pkg-javascript-de...@lists.alioth.debian.org
* Package name: node-minipass
Version : 3.1.3
Upstream Author : npm, Inc. and Contributors
* URL : https://github.com/isaacs/minipass
On 16/08/2021 16:08, Simon McVittie wrote:
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 remove
43 matches
Mail list logo
