Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: apt-suggest-auto
Version : 0.1
Upstream Contact: Lucas Nussbaum
* URL : https://salsa.debian.org/lucas/apt-suggest-auto
* License : GPL-2.0-or
On 27/08/25 at 11:15 +0200, Lucas Nussbaum wrote:
> Maybe what dep14-migrate does should be integrated into the salsa(1)
> tool. Currently salsa(1) does not have really have multi-steps
> processes, but could have. The reason why multi-steps processes are
> required in that contex
On 01/09/25 at 10:24 -0400, Jeremy BÍcha wrote:
> On Mon, Aug 18, 2025 at 4:25 PM Lucas Nussbaum wrote:
> > I updated the vendorized copy of devscripts in UDD to version 2.25.18,
> > and then forced a refresh of version:5 packages.
> > Everything works fine.
> >
>
endpoint do you scrape and how often?
> Ping?
Hi Alex,
AFAIK¹, the CI pipeline provided by the salsa-ci-team team² is
instrumented to collect data. See
https://salsa.debian.org/salsa-ci-team/pipeline/-/blob/master/salsa-ci.yml?ref_type=heads#L223
That's why people are rightfully saying that the name is not correct and
should be salsa-ci-stats.debian.net (or even
salsa-ci-team-pipeline-stats.debian.net)
I suppose that when the statistics collector endpoint learns about a
pipeline, then it polls salsa about that pipeline's status.
Lucas
¹ I'm not involved with status-status.d.n
² https://salsa.debian.org/salsa-ci-team/pipeline
On 27/08/25 at 02:15 +0200, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Lucas Nussbaum (2025-08-26 09:52:42)
> > On 26/08/25 at 09:33 +0200, Simon Josefsson wrote:
> > > Are your scripts to do these mass-commits available somewhere?
> > >
> >
oth scripts should be largely applicable to other teams, and I can help
if needed.
Lucas
On 25/08/25 at 23:20 +0200, Lucas Nussbaum wrote:
> On 25/08/25 at 13:43 -0700, Otto Kekäläinen wrote:
> > Hi,
> >
> > > On 24/08/25 at 12:18 -0700, Otto Kekäläinen wrote:
> > ...
> > > > I just noticed one developer pushed git commits to 493 diffe
lutes the
> > git history?
>
> Indeed, it seems to be the case that the API does not offer to pass
> git options. I added my vote in
> https://gitlab.com/gitlab-org/gitlab/-/issues/26422 now. Maybe if you
> add your "user story" they might have more interest in implementing
> it.
Note that it my case, some pipelines were triggered by adding/changing
debian/gbp.conf, but others were triggered by branch renames. So even
using a custom commit message would not work.
Lucas
t push -o ci.skip
I'm using the GitLab REST API through python-gitlab to automate those
commits. Do you know if there's a way to do the same thing in that case,
other that using "[skip ci]" in the commit message, which pollutes the
git history?
Lucas
looks like your involvement in teams that maintain a large number of
packages is limited to the Go team. Maybe you should try to get involved
in other teams (maybe reviewing open MRs would be a good entry point) as
a way to understand how MRs could best fit into those teams' workflows?
Lucas
roject move on salsa).
Several people have expressed that their understanding of the rules of
the 'debian' group were different from those usual in a Debian team. So
even if you insist on using the 'debian' group as a team, you would
probably need an opt-out mechanism and a grace period to let those move
their packages elsewhere.
Lucas
On 21/08/25 at 11:45 +0200, NoisyCoil wrote:
> On 21/08/25 11:26, Lucas Nussbaum wrote:
> > but if they can't get commit access before they are
> > DDs, it makes it inconvienent for them to contribute. A dedicated team
> > would allow to give access to non-DDs wi
ribute. A dedicated team
would allow to give access to non-DDs with limited privileges (for
example using protected branches).
Lucas
On 20/08/25 at 10:35 +0200, Andreas Tille wrote:
> Hi Jörg,
>
> Am Tue, Aug 19, 2025 at 11:15:36PM +0200 schrieb Joerg Jaspert:
> > On 17691 March 1977, Lucas Nussbaum wrote:
> >
> > > Maybe, instead than retrofitting a policy on the debian salsa group, a
>
On 19/08/25 at 21:59 +0200, Andreas Tille wrote:
> Hi Lucas,
>
> Am Sun, Aug 17, 2025 at 11:37:42PM +0200 schrieb Lucas Nussbaum:
> > > One point raised during the BoF was the need to better document the role
> > > of the Debian/ group on Salsa. Not all developers are
On 16/08/25 at 23:40 +0200, Yadd wrote:
> On 8/16/25 06:41, Lucas Nussbaum wrote:
> > On 15/08/25 at 23:53 +0200, gregor herrmann wrote:
> > > On Thu, 14 Aug 2025 10:25:32 +0200, Xavier wrote:
> > >
> > > > I propose to release it to unstable, then backpor
way to
measure support for your ideas.
Please note that a similar initiative from a long time ago, described in
https://wiki.debian.org/LowThresholdNmu, has "If the package maintainer
or maintainer group is active, it is polite to let them have a stab at
fixing the problem first." which I
a vendorized uscan version to get uscan. See
https://salsa.debian.org/qa/udd/-/blob/master/rimporters/upstream.rb?ref_type=heads
Is there a package already in the archive that uses version 5, so I can
test that updating devcripts in UDD works?
Lucas
in (e.g. each time a new package gets added to the
XXX team salsa group)?"
Lucas
On 15/08/25 at 19:02 +0900, Simon Richter wrote:
> Hi,
>
> On 8/15/25 6:26 PM, Lucas Nussbaum wrote:
>
> > All this is reasonable and meets real needs. As you care about better
> > integration of Salsa in Debian workflows, I think that you should review
> > what is
;ignpackages=&format=html&branches=on&gitlabci=on&gbpconf=on&pipeline=on
, which is still a bit experimental/WIP at the moment). I understand the
salsa CLI tool also helps with that. It would be useful to survey
current practices by teams, and share good ideas, tooling, etc.
What is the recommended way of using Salsa MRs for changes that involve
several branches (such as packaging a new upstream version)?
Lucas
rojects | jq '.[].name'`
> (or `/groups//projects`) (or `'.[].id')
> - glab (GitLab CLI): AFAIK it doesn't have a "porcelain" command for that,
> and the "plumbing" command (`glab api`) is essentially just calling the API
If you want to get the list of `owner/project` where MRs should be
disabled, you could easily script something around
https://udd.debian.org/salsa/:
curl
'https://udd.debian.org/salsa/?email1=ltworf%40debian.org&format=json' |
jq -r '.status[] | select (.mrs_enabled==true) | .project'
Lucas
Hi,
I will be looking into doing some mass updates/cleanup in the context of
the Ruby team, and was wondering: what are the useful tools in that
case?
I'm aware of:
- the salsa CLI tool (in devscripts)
- the glab package
- mr (multi repo)
- lintian-brush
What are teams typically using?
Lucas
rride this release team decision, see Constitution[2],
4.1.3: https://www.debian.org/devel/constitution.en.html
Best,
Lucas
Package: wnpp
Owner: Lucas Kanashiro
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org,
debian-p...@lists.debian.org
* Package name: libcvss-perl
Version : 1.14
Upstream Author : Giuseppe Di Terlizzi
* URL : https://metacpan.org/release/CVSS
* License
Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Lucas Kanashiro
Severity: wishlist
* Package name: liburi-packageurl-perl
Version : 2.22
Upstream Contact: Giuseppe Di Terlizzi
* URL : https://metacpan.org/dist/URI-PackageURL
* License
Package: wnpp
X-Debbugs-Cc: debian-devel@lists.debian.org
Owner: Lucas Kanashiro
Severity: wishlist
* Package name: libcsaf-perl
Version : 0.25
Upstream Contact: Giuseppe Di Terlizzi
* URL : https://metacpan.org/pod/CSAF
* License : Artistic-2.0
it to give better results than what it does out-of-the-box.
Right, aider.chat came up in another discussion, and looks promising.
There was an ITP about it (#1082026, abandonned).
Another Free Software alternative is Zed
(https://github.com/zed-industries/zed), but it looks less open in the
spirit than Aider.
Other closed-source products are WindSurf, Augment Code.
Lucas
On 05/06/25 at 11:38 +, Holger Levsen wrote:
> On Wed, Jun 04, 2025 at 05:04:34PM +0200, Lucas Nussbaum wrote:
> > OpenAI has an Open Source fund. Maybe Debian should apply[1] for a grant
> > so that Debian contributors could get hands-on experience on how this
> > co
tributors could get hands-on experience on how this
could help their Debian activities?
I'm willing to handle the paperwork and apply on behalf on Debian (and
then handle giving access to DDs), but of course this would need DPL
approval (Cced).
[0] https://github.com/openai/codex
[1] https://openai.com/form/codex-open-source-fund/
Lucas
p
> though.
Even if I'm their original author and like that they are popular
services, most of what https://udd.debian.org/bugs/ and
https://udd.debian.org/cgi-bin/bts-usertags.cgi do should really be
provided by the BTS itself.
Lucas
just BTS tags
(add 'patch' if the bug has a MR; add 'pending' if the MR has been
merged)
[0] https://bts-link-team.pages.debian.net/bts-link/
Lucas
id not look into gwh, but if there are good reasons not to modify gbp
directly (such as the willingness to maintain a stable interface), maybe
a better alternative is to design & develop an alternative to gbp (and
then see how it gains traction or not).
Lucas
without even searching for it, it just happened to show up on one of
> > > my specific “important for the release” radars…)
> >
> > Hi. Discussing about the right time to report those bugs does not make
> > much sense anymore, because Lucas already reported them :-)
>
Hi,
On 14/05/25 at 13:50 +0300, Adrian Bunk wrote:
> On Tue, May 06, 2025 at 08:48:29AM +0200, Lucas Nussbaum wrote:
> > On 05/05/25 at 22:14 +0200, Santiago Vila wrote:
> > > In some cases, the bug is already known, because debian/rules
> > > has --max-parallel=1.
On 11/05/25 at 22:36 +0200, Lucas Nussbaum wrote:
> On 09/05/25 at 12:43 +0200, Lucas Nussbaum wrote:
> > I would love to see data about the actual acceptance of DEP-14 among
> > packages in the archive: my feeling is that it is currently being a bit
> > ignored by maintainers
cknowledge that it will probably never be adopted by some
maintainers or source packages.
Regarding "I don't want a gbp.conf", I think that we should aim for DRY,
and that adding a gbp.conf in every package doesn't sound too great for
teams that maintain hundreds or thousands of packages...
Lucas
On 11/05/25 at 23:40 +0200, Bálint Réczey wrote:
> While this is accurate considering the latest DEP-14 version, it
> should be noted that the first DEP-14 draft allowed 'master' as the
> main branch for native packages and up to 2020-11-29 DEP-14
> recommended debian/master instead of debian/lates
On 09/05/25 at 12:43 +0200, Lucas Nussbaum wrote:
> I would love to see data about the actual acceptance of DEP-14 among
> packages in the archive: my feeling is that it is currently being a bit
> ignored by maintainers and teams (but maybe I'm wrong).
I started working on a salsa i
https://lists.debian.org/debian-devel/2025/01/msg00080.html
So I wouldn't say that is "widely accepted".
I would love to see data about the actual acceptance of DEP-14 among
packages in the archive: my feeling is that it is currently being a bit
ignored by maintainers and teams (but maybe I'm wrong).
Lucas
On 09/05/25 at 06:10 +0200, Andreas Tille wrote:
> Am Thu, May 08, 2025 at 09:56:47PM +0200 schrieb Lucas Nussbaum:
> > > The point of this sentence is to define what is non-consensual in the
> > > first place. Changing the packaging style means the NMU diff will be
>
On 08/05/25 at 18:50 +, Bill Allombert wrote:
> Le Thu, May 08, 2025 at 08:24:57PM +0200, Lucas Nussbaum a écrit :
> > On 08/05/25 at 16:56 +0200, Bálint Réczey wrote:
> > > I agree with using existing processes and I also appreciate Andreas'
> > > initiat
gt; Other NMUs: 10 days
maybe change to:
> Other NMUs: 10 days to 28 days, depending on the changes
(that also requires increasing the delayed queue's max delay to more
than the current 15 days)
Lucas
in parallel on purpose, vs those that just happen not to build in
parallel (yet).
Lucas
Hi,
On 05/05/25 at 21:53 +0200, Santiago Vila wrote:
> El 5/5/25 a las 21:26, Lucas Nussbaum escribió:
> > [...]
>
> Thanks a lot for this. I was never brave enough to go ahead
> and announce a MBF.
>
> May I know what kind of machines did you use to found those bugs
ng dependency in
debian/rules or an upstream Makefile.
More information about this mass bug filing is available at
https://wiki.debian.org/qa.debian.org/FTBFS/Shuffle
[...]
--->8
- Lucas
On 19/02/25 at 13:55 +0100, Santiago Vila wrote:
> 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
&g
if anyone wants to give it a go.
there are some list of failures in
http://qa-logs.debian.net/2025/02/16/
that looks useful:
$ curl http://qa-logs.debian.net/2025/02/16/00res.amd64exp | grep "multiple
definition of \`QtPrivate::IsFloatType_v<_Float16>'"
Lucas
ntly gbp picked the IMO unwieldly name in the meantime?
>
> Meh. But what's done is done, I guess. We'll see who will adopt that
> name.
Maybe before moving it to ACCEPTED, it would be useful to design a
dashboard of some kind to track adoption, not just in tooling, but in
actual packages?
This could probably be built as an extension to vcswatch.
Lucas
project, can be very biased). Also ignore some
stupid comments, expected in those public discussions.
And yes, this is something that Debian as whole needs to do better.
--
Lucas Kanashiro
On 03/09/24 at 16:56 -0400, Louis-Philippe Véronneau wrote:
> On 2024-09-03 14:05, Lucas Nussbaum wrote:
> > On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:
> >> FYI, I opened an RT ticket asking DSA for a VM to host all of this.
> >
> > Hi,
> >
&
On 03/09/24 at 20:49 +0200, Fabio Fantoni wrote:
> Il 03/09/2024 20:05, Lucas Nussbaum ha scritto:
> > On 03/09/24 at 12:31 -0400, Louis-Philippe Véronneau wrote:
> > > FYI, I opened an RT ticket asking DSA for a VM to host all of this.
> > Hi,
> >
> > I
engines, see for example
https://www.google.com/search?q=archive-liberty-mismatch
(it will probably take some time to get indexed by other search engines)
What is the point in duplicating efforts?
Lucas
Hi,
On 20/08/24 at 07:28 +0200, Helmut Grohne wrote:
> There are various QA-related teams looking at packages from other
> maintainers. When it trips a check, that often incurs time from some QA
> person investigating a report or failure. Examples:
> * Lucas Nussbaum, Santiago Vi
On 09/08/24 at 07:54 +, Bastien Roucariès wrote:
> Le vendredi 9 août 2024, 06:39:04 UTC Lucas Nussbaum a écrit :
> > On 08/08/24 at 18:40 +, Bastien Roucariès wrote:
> > > > > It is not meant to replace the corresponding UDD link, in fact I
> > > >
ted in the list of all affected packages.
The crux of the issue is that there isn't sufficient interest from DSA
to provide something on https://lintian.debian.org, so I don't think
it's worth comparing the merits of UDD-based vs standalone or static vs
dynamic implementations.
Lucas
rg?
>
> In the meantime I added some features and hosted it on its own domain to
> make the custom 404 page work correctly: <https://lintian.club1.fr/>. So, do
> you think it could be used to make the lintian.debian.org website back up?
>
> P.S. I'm not subscribed to this list, so please CC me.
Hi,
If there is interest in providing a page that only list the tag
description (without the affected packages), it would be easier to add
it to the existing UDD page (with an additional parameter for example)
than to create a separate service.
However I haven't seen any interest from DSA in setting a redirect from
lintian.debian.org to somewhere else. As I wrote in #1042428, if
lintian.d.o was served by ullmann and managed by the uddadm group, I
would be willing to manage those redirects.
Lucas
,
Are you aware of https://trends.debian.net/ ?
Best,
Lucas
e new version has a new binary
package named hardinfo2
is no problem.
I had mentioned that with upstream, but no response from Debian actual
maintainer.
There's some ways to solve that.
Regard,
atzlinux
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070830
在 2024/5/20 23:01, Lu
Package: wnpp
Severity: wishlist
Owner: Lucas Castro
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: hardinfo2
Version : 2.1.2
Upstream Contact: Name
* URL : https://hardinfo2.org/
* License : GPL-2
Programming Lang: C
Description
| 7186
2024-02-29 15:22:21.577515 | gcc-9-cross-ports | 27
| 7156
2024-05-06 09:45:44.77244 | llvm-toolchain-14 | 1:14.0.6-20
| 7155
(30 rows)
That's the time for testing the source and all binary packages on all
architectures.
Lucas
ive management. One of them is that it
> captures the full Git history of upstream at the point of the upload on
> Debian-controlled infrastructure if the maintainer of the package bases it
> on upstream's Git tree.)
I wonder if Software Heritage could help with that part?
Lucas
not pass on maintainership for XZ for C so you can give XZ for
> Java more attention? Or pass on XZ for Java to someone else to focus
> on XZ for C? Trying to maintain both means that neither are
> maintained well.
Lucas
Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: parsyncfp2
Version : 2.59+git20240305.b2ef136
Upstream Contact: Harry Mangalam
* URL : https://github.com/hjmangalam/parsyncfp2/
* License
Let me know if you need more information.
Best,
Lucas
org/lintian/lintian/-/tree/master/tags
Hi,
Done at https://udd.debian.org/lintian-tag.cgi
(and sorry for the delay)
Lucas
> >->
> > >https://udd.debian.org/lintian-tag.cgi?tag=$1
>
> I noticed today that Google is returning results from
> http://lintian.debathena.org/tags/bad-distribution-in-changes-file.html
> instead of old lintian.debian.org, so we have this functionality now
> back online but not hosted by Debian officially.
"Page last updated: Mon, 08 May 2017 19:00:03 + using Lintian
2.5.12-19-g5f64894."
Lucas
s
> to lintian.debian.org as the primary result on on searches for various
> Lintian errors?
>
> https://lintian.debian.org/tags/([a-z-]*)/?$
> ->
> https://udd.debian.org/lintian-tag.cgi?tag=$1
That would be something for DSA to do.
@DSA: alternatively, maybe you could setup lintian.debian.org as served
by an apache on ullmann.debian.org, and managed by the uddadm group?
Then I could handle redirects myself.
Lucas
Hi,
On 17/11/23 at 15:11 +0800, Otto Kekäläinen wrote:
> Hi!
>
> On Wed, 27 Sept 2023 at 13:27, Lucas Nussbaum wrote:
> >
> > Hi,
> >
> > #1042428 is the bug for "no explanation for lintian tags on UDD"
> >
> > On 26/09/23 at 21:35 -0700,
On 14/08/23 at 14:53 +0200, Emanuele Rocca wrote:
> Hi Lucas,
>
> On 2023-08-12 08:18, Lucas Nussbaum wrote:
> > Results:
> > http://qa-logs.debian.net/2023/08/11.stackclash-arm/
> >
> > I only included logs for builds that succeeded in a vanilla build,
>
RL to share to them. Perhaps I could implement
> that later in the year.
That's indeed a good rationale for adding a web interface to lintian
tags explanations. Thanks.
I still plan to work on adding that eventually.
Lucas
evious standalone implementation.
Lucas
t get error 500 when trying to look up LIntian errors for my
> own packages..
Hi,
Sorry about that, it was caused by a change I pushed a few hours ago to
https://udd.debian.org/dmd/
It's fixed now
Lucas
om bugs_usertags where
email='lu...@debian.org' and tag = 'ftbfs-source-after-build');
select count(*) from bugs where id in (select id from bugs_usertags where
email='lu...@debian.org' and tag = 'ftbfs-source-after-build') and
status='done';
select count(*) from bugs where id in (select id from bugs_usertags where
email='lu...@debian.org' and tag = 'ftbfs-source-after-build') and id in
(select id from bugs_tags where tag='pending') and status!='done';
Lucas
manual work on my side, so please ask only for things
you really want to push to Debian, and when the number of affected
packages exceeds what you can build in a couple of days locally.
(But I don't think I have every declined any such request)
Lucas
On 10/08/23 at 14:38 +0200, Lucas Nussbaum wrote:
> On 08/08/23 at 10:26 +0200, Helmut Grohne wrote:
> > Are we ready to call for consensus on dropping the requirement that
> > `debian/rules clean; dpkg-source -b` shall work or is anyone interested
> > in sending lots of patc
Hi Emanuele,
On 10/08/23 at 16:57 +0200, Emanuele Rocca wrote:
> Hi,
>
> On 2023-08-10 02:43, Lucas Nussbaum wrote:
> > What I would need is a script that customizes a chroot.
>
> This is what I'm passing to sbuild --chroot-setup-commands for my
> builds:
>
Hi,
On 08/08/23 at 01:25 +0200, Guillem Jover wrote:
> Hi!
>
> Lately I've been updating metadata in patches in packages I maintain and
> noticed several issues with the Patch Tagging Guidelines, and after Lucas
> created the new great patches UDD service [P] and we discussed
On 10/08/23 at 10:49 +0200, Emanuele Rocca wrote:
> Hi,
>
> On 2023-08-06 11:25, Moritz Mühlenhoff wrote:
> > I worked with Lucas a while back and he made an archive rebuild on amd64,
> > only a minimal list of packages will need to be adapted:
> > http://qa-logs.debi
r if we needed to change
policy.
After some time, when enough bugs are fixed, the severity could be
increased to release-critical. And to ensure that we don't regress again
on this, this check could easily be added to archive rebuilds.
Lucas
Hi,
On 05/08/23 at 21:01 +0200, Sven Joachim wrote:
> On 2023-08-05 19:31 +0100, Wookey wrote:
>
> > On 2023-08-05 17:06 +0200, Lucas Nussbaum wrote:
> >>
> >> I wonder what we should do, because 5000+ failing packages is a lot...
> >>
> >> Shou
remove it in clean and don't exclude it via
> extend-diff-ignore (all of which is unneeded busywork even if recommended)
> to behave the same.
Good point.
This seems to affect 1325 packages:
http://qa-logs.debian.net/2023/08/twice/python-egginfo.txt
http://qa-logs.debian.net/2023/08/twice/python-egginfo.txt.dd-list
Lucas
On 05/08/23 at 19:20 +0300, Adrian Bunk wrote:
> On Sat, Aug 05, 2023 at 05:06:27PM +0200, Lucas Nussbaum wrote:
> >...
> > Packages tested: 29883 (I filtered out those that take a very long time to
> > build)
> > .. building OK all times: 24835 (83%)
>
itize-env -us -uc -rfakeroot -S" \
ruby-highline
I wonder what we should do, because 5000+ failing packages is a lot...
Should we give up on requiring a 'clean' target that works? After all,
when 17% of packages are failing, it means that many maintainers don't
depend on it in their workflow.
Lucas
Em 28/09/2021 03:29, Richard Laager escreveu:
On 9/27/21 9:15 PM, Marco d'Itri wrote:
On Sep 28, Noah Meyerhans wrote:
Should it be mentioned what the new recommended DHCP server for general
use will be?
ISC Kea?
I haven't converted to it, but that's their replacement for dhcpd.
I had ne
On 02/10/22 at 22:21 +0200, Johannes Schauer Marin Rodrigues wrote:
> Hi,
>
> Quoting Lucas Nussbaum (2022-10-02 21:51:52)
> > On 02/10/22 at 04:23 +0200, Adam Borowski wrote:
> > > Nǐmen hǎo!
> > > I did another _source_ rebuild of the archive -- checking if
s. There's also a question of severity.
>
> Raw list and dd-list attached.
All those source packages are Architecture: all.
To make this easier to detect (and avoid regressions in the long term),
I wonder if sbuild should have an option that would make it do, for a
source+all build:
- install B-D
- run clean
- install B-D-I
- build the binary packages
Lucas
g bugs. There's also a question of severity.
Hi,
Are you saying that those 291 packages fail when only
Build-Depends/Build-Conflicts are satisfied, but do not fail when
Build-Depends-Indep is also satisfied?
FWIW, when I do archive rebuilds, I rebuild the source, but that's with
Build-Depends-Indep installed.
Lucas
Carsten,
It seems like a good project,
Tell me if you need on this.
Em 13/08/2022 04:59, Carsten Schoenert escreveu:
Package: wnpp
Severity: wishlist
Owner: Carsten Schoenert
X-Debbugs-Cc: debian-devel@lists.debian.org
* Package name: netbox
Version : 3.2.8
Upstream Author
by changes
that happened since then.
(I'm not arguing whether it should be kept or reverted, but I'm just
mentioning this as other disruptive changes might be discovered in the
coming days)
Lucas
signature.asc
Description: PGP signature
On 28/03/22 at 16:03 -0700, Sean Whitton wrote:
> Hello,
>
> On Tue 15 Mar 2022 at 06:26PM +01, Lucas Nussbaum wrote:
>
> > On 15/03/22 at 15:36 +, Ian Jackson wrote:
> >> At least the following packages of which I am the maintainer or
> >> sponsor wer
al
svn-buildpackage
uphpmvault
vim-scripts
whalebuilder
xmorph
Indeed, it would have been better to look at whether those packages
include a Debian revision, to deal separately with those three special
cases.
Lucas
cachefilesd,
userv-utils, and vde2 in the "native package with a Debian revision
maintained in a VCS" category.)
Lucas
ormat10.cgi)
What the are the packages for which you are surprised that bugs were
filed? I wonder which part of the criteria was too loose.
Also, feel free to close those bugs with a short explaining message.
I'll try to summarize the reasons for not migrating packages in a couple
of months.
Lucas
On 10/03/22 at 23:23 +0200, Adrian Bunk wrote:
> On Thu, Mar 10, 2022 at 09:49:50PM +0100, Lucas Nussbaum wrote:
> >...
> > For packages in (1.1) and (1.2), I propose to file Severity: wishlist
> > bugs using the following template:
> >
> > ---
On 10/03/22 at 21:49 +0100, Lucas Nussbaum wrote:
> https://udd.debian.org/cgi-bin/format10.cgi provides the list of
> packages for each category. The packages count is currently:
> (1.1): 53 packages
> (1.2): 424 packages
> (2): 149 packages
Actually it's:
(1.1): 60 packages
ing practices.
Please note that this is also a sign that the packaging of this software
could maybe benefit from a refresh. It might be a good opportunity to
look at other aspects as well.
This mass bug filing was discussed on debian-devel@:
https://lists.debian.org/debian-devel/2022/03/msg00074.html
On 09/03/22 at 08:52 -0700, Sean Whitton wrote:
> On Wed 09 Mar 2022 at 01:08pm +01, Lucas Nussbaum wrote:
> > Also, how would that work with packages that combine direct changes to
> > upstream, and quilt for Debian-created patches?
>
> Could you expand? I didn't thin
On 08/03/22 at 17:33 -0700, Sean Whitton wrote:
> Lucas, as I've had a lot to do with these git workflows and have
> probably done the most work documenting them, I can help with any
> specific follow-up questions you might have.
Thanks!
So the main question I think I have is:
On 08/03/22 at 17:10 +0100, Johannes Schauer Marin Rodrigues wrote:
> I did exactly that and rebuilt all the packages found by Lucas with the
> following changes:
>
> $ mkdir -p debian/source
> $ echo '3.0 (quilt)' >debian/source/format
>
> 141
1 - 100 of 707 matches
Mail list logo
