dpkg-buildpackage -B
Note: I tried that (once) and unfortunately it built ok for me,
so maybe it's a makefile bug. You might want to try
GNUMAKEFLAGS=--shuffle, which sometimes amplifies the
probability that an existing makefile bug manifests itself.
If it's a makefile bug, dh --no-parallel mig
El 21/4/25 a las 15:39, G. Branden Robinson escribió:
original-awk's man page admits to one area of POSIX-nonconformance:
BUGS
...
POSIX‐standard interval expressions in regular expressions are not
supported.
...which I think weakens the case for your proposal helping us to have
AWK
El 21/4/25 a las 14:02, Chris Hofstaedtler escribió:
I would suggest you hit up some of the current maintainers of Essential: yes
packages, and leave the naysayers on d-devel to themselves.
Note that there might be some overlap in those two sets of people.
The set of currently essential packa
Hi.
Given that the buildds are able to build the Arch:all packages
but not the arch:amd64 packages, the way to reproduce this
would be to do this in a regular directory chroot:
dpkg-buildpackage -B
In particular, I see that debian/rules does different things
depending on the type of build:
ove
El 20/4/25 a las 13:56, Adrian Bunk escribió:
The former without the latter is just a lot of wasted work without any
benefits.
I also agree that removing awk in the normal Debian distribution is a waste
of time.
If somebody wants to create a minimal container based on Debian, static
in nature,
El 17/4/25 a las 21:03, Colin Watson escribió:
On Thu, Apr 17, 2025 at 08:40:42PM +0200, Santiago Vila wrote:
Installed size of mawk is 263 MB which is really small for today's standards.
KB rather than MB, thankfully!
Big oops! I wonder how small they want images to be to
consider 2
El 17/4/25 a las 20:27, Russ Allbery escribió:
Simon Josefsson writes:
I noticed that Fedora 42 was released and their docker images lack a
'awk' tool. Debian trixie images ship with 'mawk' pre-installed right
now. While I'm not convinced the removal game is necessarily a good
one, I can see
El 17/4/25 a las 9:21, Paul Gevers escribió:
Hi,
On 16-04-2025 19:59, Santiago Vila wrote:
I wish reproducible-builds people would activate DEB_BUILD_OPTIONS=nocheck
for the second build, I think it would help. I don't think anybody will
use that as an excuse to file more RC bugs.
Simon wrote:
it would be better if future bug reporting for this scenario didn't
encourage maintainers to implement nocheck incorrectly.
You are absolutely right and I apologize for my mistake. Not just future
but also *present*, so I've now added a clarification note to all the
bugs I reported
El 16/4/25 a las 18:52, Simon McVittie escribió:
the bug template should be more like
The contents of the resulting package are meant to be identical to
the package produced by a normal build, but this was not checked
during this particular mass-rebuild
or something along those l
El 13/4/25 a las 15:22, Simon McVittie escribió:
I think there are two subtly different things that you could mean by "with
nocheck":
1. DEB_BUILD_OPTIONS=nocheck, but no special build profiles
- therefore build-dependencies are still installed
2. DEB_BUILD_OPTIONS=nocheck DEB_BUILD_PROFI
El 13/4/25 a las 15:22, Simon McVittie escribió:
On a personal note, I consider those bugs interesting to fix because I think
there
should be a safe procedure to build all packages in the archive in a way which
minimizes
build failures as much as possible.
If that's what you want, I think sce
Hello.
After building all the archive (trixie/sid) with nocheck, I only found 33 new
packages which fail to build with nocheck that were not reported before.
Admittedly
a little bit more than I expected, but certainly not "hundreds" as some people
feared.
(The main reason there are not so many
[ Thanks for this. Awesome work! ]
El 10/4/25 a las 11:43, Helmut Grohne escribió:
My thinking here was to reduce the annoyance for users by degrading the
dependency softly. I was told that some users expect to be able to build
perl extensions without installing libperl-dev (which is why libperl
El 5/4/25 a las 8:44, Paul Gevers escribió:
Remember, if you really think a bug shouldn't be RC (particularly if you are
the maintainer),
downgrade it with an explanation.
Does this include the case where a Release Manager previously raised the
severity from important to serious?
Thanks.
it would be great to solve in the
meantime. Please, don't hesiteate to jump in to help maintaining it!
Cheers,
-- Santiago
signature.asc
Description: PGP signature
El 20/3/25 a las 15:29, Jeremy Bícha escribió:
Thank you for this wonderful project and for raising the severity to
serious since it's clearly easier to fix the bugs in Unstable now
rather than as Stable Updates later.
Thanks go to the Release Managers, more specifically Paul Gevers,
who allowe
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org, 1089...@bugs.debian.org
* Package name: python-packageurl
Version : 0.16.0
Upstream Contact: https://gitter.im/package-url/Lobby
* URL : https://github.com
El 19/2/25 a las 12:42, Holger Levsen escribió:
On Tue, Feb 18, 2025 at 06:19:45PM +0100, Lucas Nussbaum wrote:
that looks useful:
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple definition of
\`QtPrivate::IsFloatType_v<_Float16>'"
qa-logs.debian.net! never heard
El 16/02/25 a las 21:15, Marco d'Itri escribió:
> On Feb 14, Colin Watson wrote:
>
> > But it doesn't. Santiago's using the data from the security tracker to
> > determine whether CVEs are open.
> And in the case of one of my own packages these CVEs have not yet been
> fixed upstream, not even
ts who just compare version numbers and
> > > flag our stable versions as vulnerable regardless whether we have
> > > patched vulnerabilities or not.
> >
> > But it doesn't. Santiago's using the data from the security tracker to
> > determine whether CVEs
El 13/02/25 a las 21:57, Paul Gevers escribió:
> Hi,
>
> On 13-02-2025 20:21, Santiago Ruano Rincón wrote:
> > Any thoughts?
>
>
> You might also want to somehow take activity on the package into account.
> E.g. cacti (that I am nearly the only uploader for) has seen
El 15/2/25 a las 10:44, Paul Gevers escribió:
Can the Release Managers suggest a calendar for raising those bugs,
first to important, then to serious?
What I had in mind was that you'd file the bugs and after some time (say, one
or two months) raised them, giving maintainers a bit more time th
now there could be "false positives", such as nginx or openjdk*,
but please take this as a draft list (and a draft script).
Attached you can find the script that produces this list.
Any thoughts?
Cheers,
-- Santiago
975 newer packages available
num of open CVEs in sid, num of historic
El 16/1/25 a las 21:01, Soren Stoutner escribió:
Is there a canonical way for a package to set an environment variable?
You should try to find another way, because Debian Policy 9.9 says this:
Programs installed on the system PATH (/bin, /usr/bin, /sbin, /usr/sbin, or similar directories) must
Hi. Since this is standard procedure, I've just filed the bugs:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=debian...@lists.debian.org;tag=gettext-0.23
but with the caveat that I don't know when I will able to do the upload
for unstable. At this moment I don't want to think about NMUs ye
[ moving technical discussion to -devel, as -release was
just to ask RM for a calendar to raise severities ]
[ Bcc to Holger on this one ]
El 5/1/25 a las 23:59, Holger Levsen escribió:
so what did you use?
I still change the system clock. So, the same you did.
El 5/1/25 a las 21:07, Otto Kekäläinen escribió:
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which
Em 5 de janeiro de 2025 15:28:24 GMT-05:00, Santiago Vila
escreveu:
>El 5/1/25 a las 21:07, Otto Kekäläinen escribió:
>>> This is an update for my previous MBF announcement here:
>>>
>>> https://lists.debian.org/debian-devel/2024/05/msg00414.html
>>>
&
El 5/1/25 a las 19:15, Guillem Jover escribió:
I think this indicates a problem in the upstream autotools support,
and it might be better to try to fix that instead of adding what seems
like a workaround that might end up causing problems too due to the
(silenced) version mismatch.
I already di
Hello.
This is an update for my previous MBF announcement here:
https://lists.debian.org/debian-devel/2024/05/msg00414.html
I did another test rebuild and found 11 new packages failing
in the not-so-distant future. I also found another package
for which the fix was lost and the bug had to reope
Greetings.
I've just uploaded gettext 0.23.1-0.1 for experimental.
[ This is preliminary, don't worry for the changelog, there will be a
proper one in unstable. Also please don't close any bugs yet, I want
to close them in unstable ].
There is a list of upstream changes here:
https://savannah.
Em 20 de dezembro de 2024 23:11:55 GMT-03:00, Sean Whitton
escreveu:
>Hello,
>
>On Thu 12 Dec 2024 at 10:43am +01, Gioele Barabucci wrote:
>
>> an alternative that I was thinking of, is making this "everybody is onboard"
>> policy more explicit by having a special email to use for the Maintain
all
> uses of eval have been removed.
>
> Thanks
>
> Mark
>
> [1] https://bugs.debian.org/1086847
>
> [2] https://bugs.debian.org/1089015
>
There are not point releases for the LTS release, so if this warrants an
fix, it should be done via a DLA. Emilio, since
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: py-serializable
Version : 1.1.2
Upstream Contact: https://github.com/madpah/serializable/issues
* URL : https://py-serializable.readthedocs.io
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: cyclonedx-python-lib
Version : 8.5.0
Upstream Contact: https://github.com/CycloneDX/cyclonedx-python-lib/issues
* URL : https://github.com
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org, team+freex...@tracker.debian.org,
team+pyt...@tracker.debian.org
* Package name: python-spdx-tools
Version : 0.8.3
Upstream Contact: https://github.com/spdx/tools-python
This is awesome work! I hope you can start the MBF soon.
One minor comment:
* 862 failures
- Of these 217 failed with an error related to this change
- The remaining failed for other reasons (including running
out of memory on the host, etc.)
I'd like to look at those "remaini
p 5 is not just a drop-in
replacement, and some work on the upstream side may be needed.
https://getbootstrap.com/docs/5.3/migration/
https://getbootstrap.com/docs/4.6/migration/
Please, consider migrating to bootstrap 5.
---
Cheers,
-- Santiago
fonts-glyphicons-halflings
Reverse Depends: knot-resolve
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org, team+freex...@tracker.debian.org
* Package name: opentelemetry-proto
Version : 1.3.2
Upstream Contact: https://github.com/open-telemetry/opentelemetry-proto/issues
* URL
Adding team+network...@tracker.debian.org to the loop.
El 13/09/24 a las 12:31, Martin-Éric Racine escribió:
> pe 13. syysk. 2024 klo 12.16 Sean Whitton (spwhit...@spwhitton.name)
> kirjoitti:
> > Hello Santiago,
> >
> > What are your current intentions in this area?
tion.
>
> --- 8< ---
>
> On 20.08.24 12:58, Lukas Märdian wrote:
> > Hi network maintainers!
> >
> > After our [Networking BoF] at DebConf24 in Busan I had the impression that
> > Santiago is primarily interested in sunsetting classic ifupdown while
> &g
x27;t appear there is
because of my preferred way to configure the pipeline in a package is
adding the debian/salsa-ci.yml file. The Gitlab setting makes
customisations more difficult, and more difficult for others that don't
have read access to those settings. (Yes, this is not wh
ebian bubble, sharing the responsibility for their continued existence
> among *considerably* more people.
ACK. This is a sound argument. Thanks.
-- Santiago
signature.asc
Description: PGP signature
El 09/07/24 a las 11:25, Daniel Gröber escribió:
> Hi Santiago,
>
> On Mon, Jul 08, 2024 at 12:23:16PM -0300, Santiago Ruano Rincón wrote:
> > > > Santiago, how do you feel about ifupdown's future maintainability and
> > > > feature development? I honestl
El 07/07/24 a las 18:02, Martin-Éric Racine escribió:
> su 7. heinäk. 2024 klo 16.56 Daniel Gröber (d...@darkboxed.org) kirjoitti:
> > On Sun, Jul 07, 2024 at 12:38:34PM +0300, Martin-Éric Racine wrote:
> > > While discussing pending issues with Santiago (ifupdown's de-fact
Package: wnpp
Severity: wishlist
Owner: Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org, team+freex...@tracker.debian.org
* Package name: opentelemetry
Version : 1.16.0
Upstream Contact: https://github.com/open-telemetry/opentelemetry-cpp/issues
* URL
Greetings.
After we make a stable release, there is usually a constant flow
of packages which start to FTBFS due to "time bombs", i.e. expired
SSL certificates used in tests and other similar reasons.
This is not fun for anybody trying to keep stable free of FTBFS bugs,
but fortunately we can do
Package: wnpp
Severity: wishlist
Owner: Emmanuel Arias , Santiago Ruano Rincón
X-Debbugs-Cc: debian-devel@lists.debian.org, t...@security.debian.org,
debian-ker...@lists.debian.org, debian-...@lists.debian.org, eam...@debian.org
* Package name: linux-livepatching
Version
El 31/03/24 a las 00:53, Christian Kastner escribió:
> On 2024-03-30 22:59, Santiago Ruano Rincón wrote:
> > The backdoor was discovered by someone using the compromised xz-utils *in
> > their own machines*. So we are lucky we have people eating our own sid
> > stuff before
Em 30 de março de 2024 13:00:26 GMT-03:00, Marco d'Itri
escreveu:
>On Mar 30, Jonathan Carter wrote:
>
>> Another big question for me is whether I should really still
>> package/upload/etc from an unstable machine. It seems that it may be prudent
>If we do not use unstable for development the
; On Fri, Jul 7, 2023 at 12:55 PM Martin-Éric Racine
> > > wrote:
> > > >
> > > > On Thu, Jul 6, 2023 at 3:06 AM Santiago Ruano Rincón
> > > > wrote:
> > > > >
> > > > > El 22/06/23 a las 09:57, Santiago Ruano Rincón e
El 16/01/24 a las 17:43, Simon Josefsson escribió:
> Bastian Blank writes:
>
> > On Tue, Jan 16, 2024 at 10:59:30AM +0100, Simon Josefsson wrote:
> >> Rebuilding a bit more than what is strictly needed sounds fine as a
> >> first solution to me.
> >
> > Building maybe. But how do you want to pub
El 17/12/23 a las 22:40, Steven Robbins escribió:
On Saturday, December 16, 2023 12:23:46 P.M. CST Paul Gevers wrote:
Another topic we covered is the volume and purpose of our mail list
(debian-devel@lists.debian.org). We recognize that that list mostly just
mirrors BTS traffic. The BTS already
El 26/10/23 a las 2:11, Vincent Lefevre escribió:
This seems to be due to a bug in the BTS
[...]
Hello. This is a bug or a feature depending on how you look at it.
Reopening a bug is known to clear the version on which it was closed
(I think this normally makes sense and the cases where it doe
supporting
nested-virtualisation (such as N1 or N2, instead of E1). I cannot say if
that is possible/feasible.
Thanks to the Salsa Admins for their work, BTW!
I can talk for some of the debci *ARM* runners, and the current setup
doesn't support nested virtualisation either.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
El 10/07/23 a las 14:52, Helmut Grohne escribió:
> On Sun, Jul 09, 2023 at 05:58:07PM +0100, Luca Boccassi wrote:
> > On top of that, a minimal installation chroot doesn't need a
> > fully-featured dhcp client. As Simon said already, busybox is there
> > for any reason for a minimal one. For the re
El 22/06/23 a las 09:57, Santiago Ruano Rincón escribió:
> El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> > On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> > wrote:
> > > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > > Greetings
El 20/06/23 a las 08:29, Martin-Éric Racine escribió:
> On Mon, Jun 19, 2023 at 9:11 PM Santiago Ruano Rincón
> wrote:
> > El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> > > Greetings,
> > >
> > > Seeing how the ISC DHCP suite has reached EOL upst
Hi,
El 19/06/23 a las 13:54, Martin-Éric Racine escribió:
> Greetings,
>
> Seeing how the ISC DHCP suite has reached EOL upstream, now might be a
> good time to re-visit Debian's choice of standard DHCP client shipping
> with priority:important.
>
> I hereby propose bin:dhcpcd-base:
>
> 1) alre
El 18/3/23 a las 4:00, Ilari Jääskeläinen escribió:
There is a new upstream release available.
We already know. It's already reported (twice) in the BTS:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1029106
If you absolutely need to use make 4.4.1, you can try this,
which is what I did:
El 08/03/23 a las 11:37, Philipp Hahn escribió:
> Hello Santiago,
>
> Am 08.03.23 um 11:17 schrieb Santiago Ruano Rincón:
> > El 08/03/23 a las 10:45, Philipp Hahn escribió:
> > > Am 07.03.23 um 20:26 schrieb Ansgar:
> > > > On Tue, 2023-03-07 at 11:55 +0100,
ofessional support services"
> to get future patches we can apply?
>
> Do we do our users a service by keeping that dead horse alive for another 2+
> years? While being quite stable it had a steady stream of security issues:
> <https://security-tracker.debian.org/tracker/source-package/isc-dhcp>
>
> Philipp
>
-- Santiago
signature.asc
Description: PGP signature
El 10/2/23 a las 3:18, Johannes Schauer Marin Rodrigues escribió:
So the chgrp call in Makefile.am worked correctly and set the group owner to
"mail" but after dh_install moved mutt_dotlock from debian/tmp/ to debian/mutt/
using 'cp -a' (if I'm reading the code correctly) the group ownership
info
El 10/2/23 a las 3:18, Johannes Schauer Marin Rodrigues escribió:
I do not understand what makes you think that only packages using dh_fixperms
-X are affected? I think what makes the two packages that I found fail to have
correct permissions is that they both use dh_install which in turn uses 'c
El 9/2/23 a las 15:37, Johannes Schauer Marin Rodrigues escribió:
I wanted to bring fakeroot bugs #1023286 and #1030638 to the attention of a
wider audience because even though I filed these bugs,
Thanks for bringing this up!
Can you confirm if all this is correct?
- Only packages uploaded af
El 6/2/23 a las 11:26, Brian Thompson escribió:
I understand that the usual way to close out bug reports is having the
original author do it themselves. What's the policy on closing bug reports
that haven't had activity in over 6 months?
Let the maintainers handle their bugs.
Old bugs should n
El 30/1/23 a las 14:05, Guillem Jover escribió:
Given the number of packages that currently declare a dependency on
tzdata (34~), the ones that seem to have the most potential to pull it
for others are language bindings such as python3-dateutil, python3-tz
ruby-tzinfo, etc, which handle timezone
El 30/1/23 a las 13:41, Santiago Vila escribió:
Note: I've downgraded the bugs in dispute to important,
so they are not RC anymore, per request of Sebastian Ramacher.
I mean: Sebastian started to downgrade them, and I've downgraded
the remaining open bugs which were not downgraded
El 27/1/23 a las 22:37, Adrian Bunk escribió:
Speaking as someone who is doing a lot of QA work, [...]
Note: I've downgraded the bugs in dispute to important,
so they are not RC anymore, per request of Sebastian Ramacher.
I just wanted to point out that the "it's more work for me"
argument goe
El 29/1/23 a las 9:56, Sebastian Ramacher escribió:
On 2023-01-28 15:55:05 -0800, Russ Allbery wrote:
Historically, we have not treated FTBFS bugs as falling into the category
of mass bug filing or requiring this pre-discussion. Various folks have
been mass-filing FTBFS bugs near the release fr
El 28/1/23 a las 14:41, Ansgar escribió:
Johannes Schauer Marin Rodrigues writes:
I think the much more interesting question is in what environment we want to
build our packages in. Currently, on buildds, we build them in a chroot that
has Priority:required and build-essential because of (what I
El 28/1/23 a las 22:18, Adrian Bunk escribió:
On Sat, Jan 28, 2023 at 09:45:14PM +0100, Santiago Vila wrote:
...
The other one: There are a bunch of packages whose unit tests rely on tzdata.
The tzdata
package changes often during the lifetime of stable, and as a result, some
package might
El 28/1/23 a las 20:44, Sebastian Ramacher escribió:
On 2023-01-28 15:03:04 +0200, Adrian Bunk wrote:
On Sat, Jan 28, 2023 at 12:24:47PM +0100, Santiago Vila wrote:
...
* Those bugs are RC by definition and have been for a long time.
...
Please provide a pointer where a release team member
El 28/1/23 a las 20:35, Adrian Bunk escribió:
I have so far not seen any technical arguments why removing tzdata from
the build essential set would be better for Debian than keeping it there.
Removing tzdata reduces the size of a chroot that has the build
dependencies for the hello package instal
El 28/1/23 a las 13:59, Adrian Bunk escribió:
Policy 4.2 also says
Source packages should specify which binary packages they require to
be installed or not to be installed in order to build correctly.
We are not following the "not to be installed" part,
which is the can of worms you would
El 28/1/23 a las 12:50, Andreas Henriksson escribió:
Policy is not a religion. Policy has many bugs. Policy is very outdated.
buildd is not a religion. buildd has bugs, etc.
Claiming there's no point to free software when the problem is simply
that you are using an *unsupported* setup?!?!
U
El 28/1/23 a las 10:11, Vincent Bernat escribió:
On 2023-01-28 00:20, Santiago Vila wrote:
Release Policy exists as a canonical list of what should be RC and > what not,
and it's intended to avoid stupid discussions like this one.
Extending build-essential is easier than asking man
El 27/1/23 a las 22:37, Adrian Bunk escribió:
On Fri, Dec 16, 2022 at 02:15:13AM +0100, Santiago Vila wrote:
Greetings.
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-ess
El 26/12/22 a las 20:29, Theodore Ts'o escribió:
I: The directory does not exist inside the chroot.
This is really a problem with schroot. I guess that this will not work either:
schroot -c the-chroot-name
This usually works when you are in your $HOME because this file:
/etc/schroot/default/
El 16/12/22 a las 18:55, Andreas Metzler escribió:
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
I'd like to apologize to Andreas for my previous answer, as I b
El 16/12/22 a las 18:55, Andreas Metzler escribió:
I am wondering if there is point to this or whether policy should be
changed? Is there some value in investing work in having packages
buildable without Prioriry required packages?
Please do not misrepresent what I said.
I never proposed such
El 16/12/22 a las 4:39, Johannes Schauer Marin Rodrigues escribió:
I think truly fixing this problem is a bit more tricky because most build tools
like the sbuild schroot backend require apt being installed in the chroot. As
of today, the sbuild schroot backend is unable to function with a chroot
Greetings.
I'm doing archive-wide rebuilds again.
I've just filed 21 bugs with subject "Missing build-depends on tzdata"
in bookworm (as tzdata is not build-essential).
This is of course not fun for the maintainers, but it's also not fun
for people doing QA, because those bugs could be caught
El 12/11/22 a las 13:16, Otto Kekäläinen escribió:
> Hi!
>
> On Wed, 9 Nov 2022 at 01:08, Santiago Ruano Rincón
> wrote:
> > Aiming to reduce the space used in the salsa infrastructure by the
> > salsa-ci artifacts, and to avoid exceeding the size limit in build jobs,
&g
is: should `DEB_BUILD_OPTIONS=noautodbgsym` be opt-in
or enabled by default?
For the Salsa CI Team,
-- Santiago
P.S. If you are interested on the development of Salsa CI, don't
hesitate to subscribe to
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/debian-salsa-ci
signature.asc
Description: PGP signature
3. Next I would
> choose 1 because I think /etc belongs to the sysadmin not packages.
5. transitional packages along with a helper package (that fails or
success during install) to prompt the user so they add non-free-firmware
section when needed.
Is there any reason why you are not considering 5.?
Cheers!
-- Santiago
signature.asc
Description: PGP signature
because the new
> > component isn't enabled.
Good point!
> Maybe and idea would to do something like isa-support does for e.g
> sseX-support
> on CPUs that does not have that feature: It fails on installation with an
> debconf message, IIRC.
> So that would allow something like "new package" |
> "you-need-to-enable-nonfree-firmware-reminder-package"
And this could solve the issue, indeed. Picking up my other mail in the
thread, the transitional packages could be summarised like this:
bullseye:
firmware-linux-nonfree (non-free)
bookworm:
firmware-linux-nonfree (non-free) - empty
Depends: firmware-linux-nonfree-bookworm* (non-free-firmware) |
non-free-firmware-needed-warning-package
trixie:
firmware-linux-nonfree-bookworm (non-free-firmware) - empty
Depends: firmware-linux-nonfree (non-free-firmware)
trixie+1 (forky):
firmware-linux-nonfree (non-free-firmware)
and so on.
* find a better name/suffix
Would this make sense?
I could volunteer to test this and propose the needed new package,
unless someone else wants to do it.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
El 13/10/22 a las 10:48, Joerg Jaspert escribió:
> Am 2022-10-13 10:13, schrieb Andreas Tille:
>
> > my Russian is a bit rusty but I can understand what I can read here:
> >https://salsa.debian.org/science-team/cimfomfa/-/jobs/3372898#L1249
>
> > I'm just a bit astonished to see this locale s
El 03/10/22 a las 19:40, Shengjing Zhu escribió:
> On Mon, Oct 3, 2022 at 7:31 PM Didier 'OdyX' Raboud wrote:
> >
> > 3 octobre 2022 11:11 "Santiago Ruano Rincón" a
> > écrit:
> > > El 02/10/22 a las 20:42, Michael Biebl escribió:
> > >
El 03/10/22 a las 11:31, Didier 'OdyX' Raboud escribió:
> 3 octobre 2022 11:11 "Santiago Ruano Rincón" a écrit:
> > El 02/10/22 a las 20:42, Michael Biebl escribió:
> >> Am 02.10.22 um 20:14 schrieb Luca Boccassi:
> >> On Sun, 2022-10-02 at 10:52
I have the same
> fear as Russ that this particular change might go unnoticed.
>
Couldn't we handle this via transitional firware* non-free packages,
that depend on bookworm non-free-firmware packages?
Cheers,
-- Santiago
signature.asc
Description: PGP signature
El 08/05/22 a las 11:24, Michael Stone escribió:
> [apologies to package aliases getting this twice due to autocomplete fail]
>
> I've been trying to make sense of the NEWS item in isc-dhcp-client (that
> alternatives are needed) in combination with the functionality of ifupdown
> and what the imp
On April 15, 2022 2:24:33 PM GMT+02:00, Luca Boccassi wrote:
>On Fri, 2022-04-15 at 00:17 -0400, M. Zhou wrote:
>> Hi,
>>
>> I just noted this problem recently. Our model for team collaboration
>> (specifically for
>> package maintenance) is somewhat primitive.
>>
>> We are volunteers. Nobod
s (thing that I needed at work). It is a pity that ISC
is giving less love to it. That said, the EOL date is still TBA
(https://www.isc.org/dhcp/)
-- Santiago
signature.asc
Description: PGP signature
A port:
https://solokeys.com/products/somu-tiny-security-key-two-factor-authentication-u2f-and-fido2-usb-a
(similar to one of the yubikey versions)
However, AFAIKS, OpenPGP support is still on development.
Cheers,
-- Santiago
signature.asc
Description: PGP signature
Package: wnpp
Severity: wishlist
Owner: "Santiago Ruano Rincón"
* Package name: vega-datasets
Version : 0.7
Upstream Author : Jake Vanderplas
* URL : https://github.com/altair-viz/vega_datasets
* License : MIT and others.
Programming La
Package: wnpp
Severity: wishlist
Owner: "Santiago Ruano Rincón"
* Package name: altair
Version : 3.2.0
Upstream Author : Jake Vanderplas, Brian Granger, the UW Interactive Data
Lab, et al.
* URL : https://altair-viz.github.io/
* License : BS
On Mon, May 13, 2019 at 11:32:36AM +, Holger Levsen wrote:
> hi,
>
> so there is "#928172 debian-security-support: fails to upgrade from 'testing':
> dpkg: error: error executing hook" which happens when base-files is upgraded
> before debian-security-support (but doesnt happen if d-s-s is upg
El 10/04/18 a las 10:50, W. Martin Borgert escribió:
> Quoting Paul Wise :
> > I think we need a privacy team. Such a team could verify the privacy
> > status of packages and record that information centrally.
>
> I agree. And volunteer.
>
> (Messages with the word "volunteer" in the body are nev
1 - 100 of 616 matches
Mail list logo
