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
but also derivatives); (2) to
develop tools that process all packages.
You argue that it's fine to wait 10 years for a transition such as the
switch to 3.0 (quilt). Actually, it has already been 11 years, since 3.0
(quilt) was introduced around 2011 (see
https://trends.debian.net/#source-formats ).
What
dpatch/quilt: #850157 (no activity since 2018)
Lucas
On 06/03/22 at 22:25 +0100, Marco d'Itri wrote:
> On Mar 06, Lucas Nussbaum wrote:
>
> > I think that we should reduce the number of packages using the 1.0 format,
> > as
> > (1) format 3.0 has many advantages, as documented in
> > https://wiki.debia
ch as last maintainer
upload and popcon installations at
https://people.debian.org/~lucas/format1.0/packages.txt
I propose to file bugs using the following template, and make them Severity:
serious after a month (minimum).
-->8
Subject: upgrade
Hi,
On 05/11/21 at 21:22 +0100, Lucas Nussbaum wrote:
> Hi,
>
> I'd like to propose a MBF with severity:serious for the above issue.
> build-arch and build-indep are required targets according to Debian
> Policy section 4.9. This rule was introduced in Policy version 3.9.4
luded below.
I would prefer to file bugs directly with severity:serious, but I'm fine
with starting with severity:important and bumping severity after a month
or two if the release team prefers it, of course.
- Lucas
== bug template
Subject: x: missing required de
On 27/08/21 at 12:54 +, Holger Levsen wrote:
> On Thu, Aug 26, 2021 at 11:39:06AM +0200, Lucas Nussbaum wrote:
> > There's probably a large number of packages that just require a
> > rebuild (+ test with autopkgtest) to be backported.
>
> uploading to -backports a
ally, one could imagine a DSL to:
- make minor changes to the source package before building (adjust
dependencies, apply an additional patch, etc.)
- tell sbuild that some build-dependencies must be pulled from backported
packages
Jelmer, did you already think about that? Is there a way one c
consequence of the recent release?
> >
> > That's one part that's included in the UDD downtime reported here:
> > https://lists.debian.org/debian-qa/2021/08/msg0.html
>
> Thanks, and sorry for the noise - I should have checked the QA list.
FYI: it's now fixed.
Lucas
signature.asc
Description: PGP signature
he package in git on salsa, using a newer source format,
etc.)
-->8
I attached a dd-list.
To limit the noise on the debian-bugs-rc list, I will wait until after
the bullseye release to file those bugs.
Any comments?
Lucas
A Mennucc1
libppd
Adam Majer
On 13/04/21 at 11:18 +0200, Bastian Blank wrote:
> Hi Lucas
>
> I would like to add:
>
> - Removing Berkeley DB.
To clarify, I was focusing on stuff that is already tracked via Trends.
Lucas
ges in .diff.gz (no patch system)
- no support for build-arch and build-indep
Lucas
a
standalone service, maybe a simpler architecture to explore would be to
build it on top of UDD (with lintian runners feeding a table in UDD
directly). That would make it possible to simplify most of the web stuff
(and of course would still allow exporting to other services that need
the data). I would be quite motivated to work on that.
Lucas
27;s useful for you or your team, please get in touch with me.
I'll ask you to provide:
1) a script that customizes a chroot. Examples are available at:
https://salsa.debian.org/lucas/collab-qa-tools/-/tree/master/modes
2) a list of source packages to test-build. (if there are many of them
and
of data. So basically you need to get the
information you want in a lintian classification tag, and then I take
care of adding the graphs :)
For your above example, do you mean "direct build-deps listed in
debian/control", or "transitive build-deps" ? The latter would require a
lot more analysis.
Lucas
Hi,
I just updated https://trends.debian.net/
Debian Trends provides historical graphs about Debian packaging
practices. It is built by running lintian on the data from
snapshot.debian.org.
Lucas
On 28/06/20 at 23:38 +0200, Bernd Zeimetz wrote:
>
>
> On 6/28/20 10:58 PM, Lucas Nussbaum wrote:
> > Well, I think that it would a good thing for Debian to enforce some
> > consistency on Debian images for clouds and software that require
> > VM images, at least abou
On 28/06/20 at 10:54 -0700, Ross Vandegrift wrote:
> [removing serpent@d.o from CC, he's resigned as delegate]
>
> Hi Lucas,
>
> On Sun, Jun 28, 2020 at 05:26:41PM +0200, Lucas Nussbaum wrote:
> > One could argue that the Cloud team delegation does not cover Docker
&
thank them for that.
However ...
On 26/03/19 at 12:25 +0100, Lucas Nussbaum wrote:
> On https://hub.docker.com/_/debian, there's:
>
> > Where to file issues:
> > https://github.com/debuerreotype/docker-debian-artifacts/issues
This hasn't changed. The Debian official im
Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro
* Package name: golang-github-anacrolix-stm
Version : 0.2.0-1
Upstream Author : Matt Joiner
* URL : https://github.com/anacrolix/stm
* License : Expat
Programming Lang: Go
Description : Software
Package: wnpp
Severity: wishlist
Owner: Lucas Kanashiro
* Package name: golang-github-benbjohnson-immutable
Version : 0.2.0-1
Upstream Author : Ben Johnson
* URL : https://github.com/benbjohnson/immutable
* License : Expat
Programming Lang: Go
Description
ges/n/node-file-entry-cache/
Hi,
Thanks for pointing to the cause! It finally motivated me to look into
this. I fixed the bug in DMD.
Lucas
ng to spot FTBFS, thus rebuilding would only
> recompile against updated toolchain. That's a good idea, but I say we need
> a human look once in a longer while.
Those packages are also unlikely to have a test suite. They might build,
but the resulting binaries might not work.
Lucas
On 04/04/20 at 08:09 +0200, Paul Gevers wrote:
> Hi Lucas
>
> On 03-04-2020 22:41, Lucas Nussbaum wrote:
> > There are a few things that strike me:
> >
> > - first, one can see how the number of package in testing decreases
> > slowly during freezes, as bro
make an effort to remove from testing
packages whose packaging 'style' is clearly outdated, such as packages
not updated since 2004 ('beav' is an example)...
Lucas
signature.asc
Description: PGP signature
ds-Indep when doing a
source-only build, and then fails when doing 'debian/rules clean'.
I wonder if that should be fixed in sbuild.
Lucas
Package: wnpp
Owner: Lucas Kanashiro
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org
* Package name : ruby-ffi-libarchive
Version : 1.0.0
Upstream Author : John Bellone ,
Jamie Winsor ,
Frank Fischer
* URL : https
Hi,
I just updated https://trends.debian.net with recent data and some more
graphs. Thanks go to Peter Wienemann and Niels Thykier for patches and
ideas.
Lucas
signature.asc
Description: PGP signature
On 08/11/19 at 16:39 +, Holger Levsen wrote:
> On Fri, Nov 08, 2019 at 05:29:33PM +0100, Lucas Nussbaum wrote:
> > How often do packages get test-built thanks to that? (It looks like the
> > answer is: "once per month"?)
>
> it depends - see the
t-built thanks to that? (It looks like the
answer is: "once per month"?)
Do you have an estimate of how many failures without a corresponding bug
there currently is? Actually this question could probably be answered by
UDD.
Lucas
for packages that are being uploaded there?
> - how do you want to avoid that this service becomes a mess? who removes
> packages when, who makes sure maintainers actually take care of what
> they upload? how are bugs being reported? What about security issues?
To clarify: I'm not involved in fasttrack myself.
Lucas
Hi,
Back in the beginning of September, because I needed to run VirtualBox
on Debian 10, I created an unofficial backport of the Debian unstable,
published it[1], and mentioned it on [2] (I don't think it was
advertised elsewhere).
[1] https://people.debian.org/~lucas/virtualbox-buste
versions
> =
>
> * Run a debdiff of the binaries to see what has changed
>
> * Use diffoscope
>
> * Run autopkgtests
>
> * Test piuparts
>
> Generally look at the packaging and explain any changes carefully.
Lucas
[1] https://lists.debian.org/debian-devel-announce/2019/06/msg4.html
1 - 100 of 674 matches
Mail list logo
