Re: Any volunteers for lintian co-maintenance?

[Lucas Nussbaum]

On 09/05/24 at 13:57 -0700, Soren Stoutner wrote:
> First, I should say that I am painfully aware of how long it takes to run 
> lintian on large 
> packages.  When working on qtwebengine-opensource-src it takes my system 
> (Ryzen 7 
> 5700G) about 2 hours to build the package and about half an hour to run 
> lintian against it.  
> I would be completely in favor of any efforts that could be made in the 
> direction of making 
> lintian more efficient, either within lintian itself or in other packages 
> that replicate some or 
> all of lintain’s functionality in more efficient ways.

If someone wants to work on lintian performance: the runtimes for the
UDD lintian importer (behind https://udd.debian.org/lintian/ ) are
available in the lintian_logs table:

udd=> select distinct ts, source, version, duration from lintian_logs order by 
duration desc limit 30;
 ts | source  |  
version  | duration 
+-+---+--
 2024-04-05 16:54:20.437828 | acl2| 8.5dfsg-5   
  |32879
 2024-04-26 06:20:59.082471 | linux   | 6.7.12-1
  |16472
 2024-02-29 10:39:52.6379   | gcc-14-cross-ports  | 4   
  |14616
 2024-02-29 10:39:16.350521 | gcc-14-cross-ports  | 5   
  |14580
 2024-02-29 10:35:17.939875 | gcc-11-cross-mipsen | 6+c1+nmu1   
  |14341
 2024-02-29 10:35:06.549735 | gcc-13-cross-mipsen | 2+c1
  |14330
 2024-02-29 10:34:54.908736 | gcc-14-cross| 4   
  |14318
 2024-02-29 10:34:44.720364 | gcc-12-cross-mipsen | 4+c1
  |14308
 2024-02-29 10:33:50.035058 | gcc-10-cross-mipsen | 3+c6
  |14253
 2024-05-09 11:24:34.446854 | llvm-toolchain-17   | 1:17.0.6-12 
  |13086
 2024-02-29 10:04:42.241127 | gcc-14-cross| 3   
  |12505
 2024-05-03 23:10:27.416567 | libreoffice | 4:24.2.3-1  
  |12238
 2024-02-29 09:59:52.604453 | gcc-9-cross-mipsen  | 4+c2
  |12216
 2024-05-07 01:51:54.054889 | llvm-toolchain-16   | 1:16.0.6-27 
  |11180
 2024-04-25 10:31:07.753175 | llvm-toolchain-snapshot | 
1:19~++20240421021844+e095d978ba47-1~exp1 | 9881
 2024-05-05 04:30:01.133898 | llvm-toolchain-18   | 1:18.1.5-2  
  | 9811
 2024-02-29 12:48:09.931447 | gcc-arm-none-eabi   | 15:13.2.rel1-2  
  | 9773
 2024-02-29 13:22:32.331297 | gcc-10-cross| 23  
  | 9118
 2024-05-06 22:16:07.781017 | llvm-toolchain-15   | 1:15.0.7-15 
  | 8976
 2024-04-30 10:12:54.498582 | openblas| 0.3.27+ds-2 
  | 8787
 2024-04-04 10:04:55.49545  | gcc-14  | 14-20240330-1   
  | 8307
 2024-05-07 10:03:49.089649 | ghc | 9.6.5-1~exp1
  | 8246
 2024-05-02 10:03:49.545502 | gcc-14  | 14-20240429-1   
  | 8242
 2024-02-29 12:54:28.975384 | gcc-13-cross-ports  | 17  
  | 7753
 2024-04-14 21:54:48.554806 | ghc | 9.4.7-5 
  | 7702
 2024-02-29 14:38:08.333028 | gcc-13-cross| 14  
  | 7321
 2024-02-29 15:22:27.15095  | gcc-10-cross-ports  | 24  
  | 7192
 2024-04-14 09:46:15.411926 | gcc-11  | 11.4.0-9
  | 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

Re: Validating tarballs against git repositories

[Lucas Nussbaum]

On 29/03/24 at 23:29 -0700, Russ Allbery wrote:
> Antonio Russo  writes:
> > But, I will definitely concede that, had I seen a commit that changed
> > that line in the m4, there's a good chance my eyes would have glazed
> > over it.
> 
> This is why I am somewhat skeptical that forcing everything into Git
> commits is as much of a benefit as people are hoping.  This particular
> attacker thought it was better to avoid the Git repository, so that is
> evidence in support of that approach, and it's certainly more helpful,
> once you know something bad has happened, to be able to use all the Git
> tools to figure out exactly what happened.  But I'm not sure we're fully
> accounting for the fact that tags can be moved, branches can be
> force-pushed, and if the Git repository is somewhere other than GitHub,
> the malicious possibilities are even broader.
> 
> We could narrow those possibilities somewhat by maintaining
> Debian-controlled mirrors of upstream Git repositories so that we could
> detect rewritten history.  (There are a whole lot of reasons why I think
> dgit is a superior model for archive 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

Re: Validating tarballs against git repositories

[Lucas Nussbaum]

On 29/03/24 at 23:29 -0700, Russ Allbery wrote:
> The sad irony here is that the xz maintainer tried to do exactly what we
> advise people in this situation to do: try to add a comaintainer to share
> the work, and don't block work because you don't have time to personally
> vet everything in detail.  This is *exactly* why maintainers often don't
> want to do that, and thus force people to fork packages rather than join
> in maintaining the existing package.

Yes. In that specific case, the original xz maintainer (Lasse Collin)
was socially-pressed by a likely fake person (Jigar Kumar) to do the
"right thing" and hand over maintenance.

https://www.mail-archive.com/xz-devel@tukaani.org/msg00566.html

I wonder if "Dennis Enn" is also a fake person. In retrospect, that
email looks suspicious:

On 2022-06-21 Dennis Ens wrote:
> Why 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

Bug#1065505: ITP: parsyncfp2 -- Multihost parallel rsync wrapper

[Lucas Nussbaum]

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 : GPLv3
  Programming Lang: Perl
  Description : Multihost parallel rsync wrapper

Description: Multihost parallel rsync wrapper
 parsyncfp2 is a tool to efficiently transfer 10s of gigabytes across a network
 by running several instances of rsync in parallel. It aggregates files into
 chunks (or partitions) of a specified size, and then transfers each chunk
 using parallel runs of rsync. It needs to be installed only on the source end
 of the transfer.

A preliminary package is available at
https://salsa.debian.org/debian/parsyncfp2

Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]

[Lucas Nussbaum]

Hi,

I finally got time to perform those archive rebuilds.

Results are available at http://qa-logs.debian.net/2024/01/11/
I did a first archive rebuild (all packages on arm64, armhf, armel), and
then did a second one, restricted to packages that failed at on at least
one architecture.

Results in terms of packages counts are:
384 FAIL.all # failing on three architectures
423 FAIL.arm64
 29 FAIL.arm64.but.OK.armhf
   1062 FAIL.armel
668 FAIL.armel.but.OK.arm64
237 FAIL.armel.but.OK.armhf
851 FAIL.armhf
462 FAIL.armhf.but.OK.arm64
 25 FAIL.armhf.but.OK.armel

Let me know if you need more information.

Best,

Lucas

Re: Bug#1042428: lintian.debian.org off ?

[Lucas Nussbaum]

On 22/11/23 at 09:09 +0100, Aurélien COUDERC wrote:
> Any chance to get back a front page with the complete list of tags, linking 
> to the individual tag pages ?
> 
> The best I could find for now is [1] but it's not very practical.
> 
> 
> [1] https://salsa.debian.org/lintian/lintian/-/tree/master/tags

Hi,

Done at https://udd.debian.org/lintian-tag.cgi

(and sorry for the delay)

Lucas

Re: Bug#1042428: lintian.debian.org off ?

[Lucas Nussbaum]

On 28/11/23 at 13:00 -0700, Otto Kekäläinen wrote:
> > >> I finally fixed this. Sorry for the delay.
> > >>
> > >> https://udd.debian.org/lintian?packages=entr has a link for each lintian
> > >> tag, that points to (e.g.) 
> > >> https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern
> > >> That page includes a description of the tag as well as all packages
> > >> affected by the tag.
> > >
> > >Thanks!
> > >
> > >Could you consider setting up also redirects from old url, as it seems
> > >that search engines had it indexed pretty well and tend to offer links
> > >to lintian.debian.org as the primary result on searches for various
> > >Lintian errors?
> > >
> > >https://lintian.debian.org/tags/([a-z-]*)/?$
> > >->
> > >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

Re: Bug#1042428: lintian.debian.org off ?

[Lucas Nussbaum]

On 19/11/23 at 23:49 -0700, Otto Kekäläinen wrote:
> > > This issue still exists. I would now have the need to send the url
> > > https://lintian.debian.org/tags/service-file-is-not-a-file to upstream
> > > developers to learn about this Lintian issue, but the URL does not
> > > serve any contents nor does it redirect to a new location.
> > >
> > > I am still willing to contribute the Apache/Nginx rewrite rules if
> > > somebody can point me to a code repository where I can read/contribute
> > > at like I announced on September 27th in this thread.
> >
> > I finally fixed this. Sorry for the delay.
> >
> > https://udd.debian.org/lintian?packages=entr has a link for each lintian
> > tag, that points to (e.g.) 
> > https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern
> > That page includes a description of the tag as well as all packages
> > affected by the tag.
> 
> Thanks!
> 
> Could you consider setting up also redirects from old url, as it seems
> that search engines had it indexed pretty well and tend to offer links
> 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

Re: Bug#1042428: lintian.debian.org off ?

[Lucas Nussbaum]

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, Otto Kekäläinen wrote:
> > > I know Lintian tag info is available via command line, but I
> > > frequently need to educate upstreams about Lintian rules, and thus
> > > really also need a URL 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.
> 
> This issue still exists. I would now have the need to send the url
> https://lintian.debian.org/tags/service-file-is-not-a-file to upstream
> developers to learn about this Lintian issue, but the URL does not
> serve any contents nor does it redirect to a new location.
> 
> I am still willing to contribute the Apache/Nginx rewrite rules if
> somebody can point me to a code repository where I can read/contribute
> at like I announced on September 27th in this thread.

I finally fixed this. Sorry for the delay.

https://udd.debian.org/lintian?packages=entr has a link for each lintian
tag, that points to (e.g.) 
https://udd.debian.org/lintian-tag.cgi?tag=superfluous-file-pattern
That page includes a description of the tag as well as all packages
affected by the tag.

Lucas

Re: Enabling -fstack-clash-protection for trixie [armhf rebuild]

[Lucas Nussbaum]

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,
> > but failed with the custom build.
> 
> Thank you so much, this is great! There's not much fallout.
> 
> I'm not sure how the deal with AWS is (how many credits we have
> available and such) but would it be possible to repeat the experiment
> for armhf too?  The Neoverse cpus can run 32 bit code natively, so at
> least from the point of view of the underlying hardware this shouldn't
> be a problem.
> 
> I've tried the following on a m6g.medium and it did the right thing:
> 
>  sbuild-createchroot --arch=armhf 
> --components=main,contrib,non-free,non-free-firmware sid /srv/sid-armhf

Hi,

Sorry for the delay in answering your email.
Is this still of interest? Yes, that would be possible.

Lucas

Re: lintian.debian.org off ?

[Lucas Nussbaum]

Hi,

#1042428 is the bug for "no explanation for lintian tags on UDD"

On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> I know Lintian tag info is available via command line, but I
> frequently need to educate upstreams about Lintian rules, and thus
> really also need a URL 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

Re: lintian.debian.org off ?

[Lucas Nussbaum]

On 26/09/23 at 21:35 -0700, Otto Kekäläinen wrote:
> Hi!
> 
> Thanks for the context - so there is no need technical incompatibility
> at play, but mostly a matter of having resources and time to do it.

I think it's worth adding that the new implementation (as part of UDD)
is less ambitious on the technical level and shares a lot of
code/infra/logic with other bits of UDD that are useful in other
contexts (such as https://udd.debian.org/bugs/, or the scanner for new
upstream versions).

So the chances of long term maintainability are a bit higher than with
the previous standalone implementation.

Lucas

Re: lintian.debian.org off ?

[Lucas Nussbaum]

On 24/09/23 at 12:16 -0700, Otto Kekäläinen wrote:
> > I don't know if it is just me, but even udd gives me a 500
> > when I try to check lintian output for any (existing) package.
> >
> > For example: https://udd.debian.org/lintian/?packages=nim
> 
> I also just 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

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

On 15/08/23 at 01:29 -0400, Michael Stone wrote:
> On Mon, Aug 14, 2023 at 09:40:52PM +0100, Wookey wrote:
> > Yes. You are right. I (and most of the others who expressed an
> > interest in having this working) mostly care about doing a binary
> > build repeatedly. But doesn't this amount to much the same thing?
> 
> no, not really. a lot of benign changes (like copying in new autoconf stuff)
> can happily be made multiple times, which doesn't affect building at all but
> causes busy work to undo.
> 
> > dpkg-source will moan if the source has changed and tell you about the
> > nice patch it has made. OK, it will let some things slide as just
> > warnings, so 'builds binary twice' is a somewhat less stringent target
> > than 'leaves exactly the original pristine source'. I would have to check
> > the details, but I'm not sure how much difference this makes in
> > practice?
> 
> we don't know, since the test was "regenerate source"--a thing very few
> people care about--rather than "build twice" which is the thing people do
> seem to care about. It seems likely that the difference is thousands of
> packages.
> 
> I'm somewhat concerned we magically went from "should we do an MBF" to "I
> just did an MBF" without any real consensus in the middle. This being so
> painfully obvious that the MBF itself basically says there's no consensus.

I agree that the distinction between "fails to build source after
successful build" and "fails to build binary packages after successful
build" is useful. My initial test covered both, but I separated both
issues later on to provide more specific bug reports, so the MBF only
covered the first case. I also plan to do a MBF for "fails to build
binary packages after successful build" (there are about 700 packages
failing this).

What policy says is even stricter (and inadequate?), because it says:

  clean (required)

 This must undo any effects that the build and binary targets may
 have had, except that it should leave alone any output files
 created in the parent directory by a run of a binary target.

I think that the consensus might be something like:
- after 'clean', it _must_ be possible to perform a successful binary build
  again
- after 'clean', it _should_ be possible to build source again (so
  recommended by not required)

But unless we go further than that and decide that we don't care at all
about 'source builds after successful builds', the bugs (which where
filed severity:minor) remain valid.

Looking at the number of bugs fixed since the MBF (200 closed, + 125
pending, out of 5658, in less than two days [1]), it also looks like many
people think this is worth fixing.

[1] UDD queries:
select count(*) from bugs where id in (select id from 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

Testing archive-wide changes (Was: __pycache__ directories (Re: Potential MBF: packages failing to)) build twice in a row)

[Lucas Nussbaum]

On 14/08/23 at 22:09 +0200, Michael Biebl wrote:
> Could maybe dh_clean automatically clean up such __pycache__ directories or
> do we really expect that each individual package does such a clean up
> manually?
> Or is there maybe a way to avoid the creation of the __pycache__ directories
> altogether.

Hi,

As a reminder, if someone needs to test a change over a large number of
packages, I can run custom rebuilds (typically pulling specific
packages from experimental or an external repository).

See https://lists.debian.org/debian-devel/2020/10/msg00097.html

It involves some 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

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

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 patches for this?
> 
> My reading of the discussion is that there's sufficient interest for
> ensuring that building-source-after-successful-binary-build works.
> 
> Also, for most packages, fixes are trivial, and can be implemented as
> durable fixes (not requiring changes for each upstream release).
> 
> So my proposal would be to file bugs against affected packages, with
> severity:minor for now (even it is a clear policy violation).
> The bugs would be properly usertagged to allow tracking, and point to a
> wiki page where we can share recipes for specific issues.
> 
> The rate at which packages are fixed could be useful input to determine
> if we can just live with that requirement, or 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.

Hi,

I prepared this wiki page:
https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild

And I plan to use the following bug template:
--
From: {{ fullname }} <{{ email }}>
To: sub...@bugs.debian.org
Subject: {{ package }}: Fails to build source after successful build

Source: {{ package }}
Version: {{ version }}
Severity: minor
Tags: trixie sid ftbfs
User: lu...@debian.org
Usertags: ftbfs-sab-{{ date_without_slashes }} ftbfs-source-after-build

Hi,

This package fails to build a source package after a successful build
(dpkg-buildpackage ; dpkg-buildpackage -S).

This is probably a clear violation of Debian Policy section 4.9 (clean target),
but this is filed as severity:minor for now, because a discussion on
debian-devel showed that we might want to revisit the requirement of a working
'clean' target.

More information about this class of issues, included common problems and
solutions, is available at
https://wiki.debian.org/qa.debian.org/FTBFS/SourceAfterBuild

Relevant part of the build log:
{% for line in extract %}> {{ line }}
{% endfor %}

The full build log is available from:
http://qa-logs.debian.net/{{ date }}/{{ filename }}

If you reassign this bug to another package, please mark it as 'affects'-ing
this package. See https://www.debian.org/Bugs/server-control#affects

If you fail to reproduce this, please provide a build log and diff it with mine
so that we can identify if something relevant changed in the meantime.
--

I will first focus on packages where 'dpkg-buildpackage -S' fails after
a successful build.

I might do the same work for packages where 'dpkg-buildpackage -b' fails
after a successful build.

Lucas

Re: Enabling -fstack-clash-protection for trixie

[Lucas Nussbaum]

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:
> 
> sbuild --chroot-setup-commands='printf "APPEND CFLAGS 
> -fstack-clash-protection\nAPPEND CXXFLAGS -fstack-clash-protection\n" > 
> /etc/dpkg/buildflags.conf'
> 
> Would a script with just that printf command work for collab-qa-tools?

Apparently yes.

Results:
http://qa-logs.debian.net/2023/08/11.stackclash-arm/

I only included logs for builds that succeeded in a vanilla build,
but failed with the custom build.

Lucas

Re: Issues in the Patch Tagging Guidelines

[Lucas Nussbaum]

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 some
> other issues there, it looked like the guidelines could do with some
> fixes and updates.
> 
>   [P]  also part of DMD.
> 
> The following list are some of the issues or things that might deserve
> to be clarified, fixed or updated (for reference the current guidelines
> can be found at ):

For context, there are several bugs about UDD's implementation of patch parsing:
#1028503 UDD: Unknown "yes" value for Forwarded field in patch metadata
#1031381 UDD/dmd: Incorrectly considers patches needing work
#1043043 UDD patches: marks Forwarded as invalid if not 'no', 'not-needed', 
'yes' or URL

The UDD parser of DEP3 metadata is
https://salsa.debian.org/qa/udd/-/blob/master/rimporters/patches.rb#L163

The issues listed below fall in two categories:
1/ general issues about DEP3
2/ issues about computation of the "Forwarded" field value

1/ General issues about DEP3


> * dpatch complicates parsing, it is deprecated, probably worth dropping
>   support for it.

I believe this is solved: dpatch is no longer available in
stable/testing/unstable, and we don't have any packages build-depending
on it. There are still some patches that are dpatch-formatted but do not
depend on dpatch-specific features, so this is not a big issue.

See:
select source, patch from sources_patches inner join patches using (hash, file)
where release='trixie' and headers ~* 'dpatch' order by 1,2;
=> 96 source packages, 295 patches

> * Although the guidelines seem to intend for git formatted patches to be
>   supported, the actual specification of the format is not very clear
>   on its usage and a strict reading does not really allow it.
> 
>   - There is a requirement for the first field to appear on the first
> line, but git formatted patches start with «From ».

That's OK, since From is an alternative to Author, so it's a valid DEP3
field.

>   - You cannot easily add custom Patch Guideline patches into the first
> git stanza, those need to go into the git trailers in the commit
> message, separated by whatever text is found in the description,
> which does not follow the deb822 format.

That's OK. You can have random text before the next DEP3 headers. See
the first example in the DEP3 specification.

>   - Having to store the patch guideline fields in git commit trailer
> fields might mean these pollute the patch which might need to be
> removed before submitting upstream.

In practice, supporting both git-formatted patches and custom-formatted
patches was a non-issue when writing a parser.

> * For Applied-Upstream it is not easy to predict what will be the
>   future upstream version that the patch will be included in. I've opted
>   for stuff like «3.2.1+, commit:» when 3.2.1 is the last release,
>   but that does not seem optimal.
> 
> * The git Date field could somehow be used in place of Last-Update (even
>   though the Committer Date instead of the Author Date is what matches
>   here more closely, but which is not available from «git format-patch»).

Yes, the UDD implementation does that.

> * Add new metadata to track single-debian-patch autogenerated patches,
>   perhaps a new «Autogenerated: yes» or perhaps better something like
>   «Origin: autogenerated, by:dpkg-source» (or similar descriptive thing)?
>   These should in general not be warned as needing to be forwarded
>   upstream, at least not as-is (dpkg-source in 1.22.0 will add a
>   «Forwarded: not-needed» for these though).

A default of 'Forwarded: no' would be more appropriate, since some of
individual changes could be relevant for upstream...

I was surprised to see that there are only 144 packages in testing using
single-debian-patch, according to
 select source, patch, headers
 from sources_patches inner join patches using (hash, file)
 where release='trixie' and patch ='debian-changes' order by 1 ,2;

> * The language could use some clarification and standardize on the field
>   and stanza naming used in other parts of the deb822 ecosystem instead
>   of headers and sets of headers and similar.

> * It is not clear, but I think «Origin: vendor» should be clarified to
>   state that the actual vendor name should be included if there is no
>   other reference (such as an URL) as in say «Origin: vendor, Debian»?
>   Otherwise an undefined vendor is not really distinguishable from the
>   «other» value as it could be any vendor. Also because if a «vendor»
>   maintainer has created the patch then there might be no URL to point
>   to except for the VCS it is kept in (if any at all).

2/ issues about computation of the "Forwarded" field value

Re: Enabling -fstack-clash-protection for trixie

[Lucas Nussbaum]

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.debian.net/2023/05/24/
> 
> Can we do the same for arm64? As far as I understand the archive rebuild
> system runs on AWS, so that should be possible I think? I don't expect
> big differences compared to the amd64 results, but still it would be
> a nice test to perform.

Yes. What I would need is a script that customizes a chroot. See
https://salsa.debian.org/lucas/collab-qa-tools/-/blob/master/modes/stackclash 
and other examples in
https://salsa.debian.org/lucas/collab-qa-tools/-/tree/master/modes

Then I will do two archive rebuilds (one with customization, one
without)

Lucas

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

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 patches for this?

My reading of the discussion is that there's sufficient interest for
ensuring that building-source-after-successful-binary-build works.

Also, for most packages, fixes are trivial, and can be implemented as
durable fixes (not requiring changes for each upstream release).

So my proposal would be to file bugs against affected packages, with
severity:minor for now (even it is a clear policy violation).
The bugs would be properly usertagged to allow tracking, and point to a
wiki page where we can share recipes for specific issues.

The rate at which packages are fixed could be useful input to determine
if we can just live with that requirement, or 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

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

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...
> >>
> >> 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.
> >
> > I still depend on this in my workflow, and it's very frustrating that
> > a large fraction of packages are broken in this way. I'd love it if we
> > had a bit of automation to tell people it's bust so they can fix
> > it. Sometimes it is hard because build systems mess up your source
> > tree, but a lot of the time it isn't. I have some sympathy for people
> > who would have to do a lot of work to fight a build system that
> > doesn't care about clean source trees if they don't care about them either.
> >
> > On the other hand it is a massive PITA when you build a package, and
> > something breaks, and you try to build it again and it won't because
> > the source tree has changed and the clean target doesn't actually clean.
> > This happens way too often these days.
> 
> It might be worth to consider changing your workflow a bit and work with
> a git repository. It does not have to be a clone of the repository (if
> any) where the package is maintained, you can start with a fresh import,
> e.g. with "gbp import-dsc".
> 
> Then before building the package for the first time, commit or at least
> stash your changes, and you can go easily back to a clean state with
> "git reset --hard; git clean -fdqx".

While this works in practice (and I do that as well), I find it hard to
explain to new contributors that hacking on random packages requires
them to create a temporary git repository so that they revert the
package' source to a clean state.

We already have a large pile of tools and worflows that need to be
mastered when contributing to Debian. It would be better to avoid adding
an additional one...

Lucas

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

On 05/08/23 at 21:29 +0200, Andrey Rakhmatullin wrote:
> On Sat, Aug 05, 2023 at 07:20:19PM +0300, Adrian Bunk wrote:
> > What packages are failing, and why?
> > 
> > I would expect some debhelper machinery being responsible for most of 
> > these, e.g. perhaps some dh-whatever helper might be creating this 
> > issue for all 1k packages in some language ecosystem.
> I've checked one of my Python packages and it fails because the contents
> of $name.egg-info were modified. I expect all Python packages that ship
> $name.egg-info and don't 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

Re: Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

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%)
> > .. failing somehow: 5048 (17%)
> >...
> > I wonder what we should do, because 5000+ failing packages is a lot...
> 
> I doubt these are > 5k packages that need individual fixing.
> 
> What packages are failing, and why?

Did you see http://qa-logs.debian.net/2023/08/twice/ ?

> I would expect some debhelper machinery being responsible for most of 
> these, e.g. perhaps some dh-whatever helper might be creating this 
> issue for all 1k packages in some language ecosystem.

Maybe, but I did not detect such a common root cause by randomly looking
at log files. Same when going through dd-lists: of course teams that
maintain many packages have many packages failing, but I did not
identify a team with a very large proportion of failing packages.

> > 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.
> 
> You are mixing two related but not identical topics.
> 
> Your subject talks about "failing to build twice in a row",
> but the contents mostly talks about dpkg-source.
> 
> Based on my workflows I can say that building twice in a row, defined as
>   dpkg-buildpackage -b --no-sign && dpkg-buildpackage -b --no-sign
> works for > 99% of all packages in the archive.

That's true. However, if the 'clean' target doesn't work correctly,
there are chances that the second build might not happen in the same
conditions as the first one (for example because it will re-use
left-overs from the first build).

Lucas

Potential MBF: packages failing to build twice in a row

[Lucas Nussbaum]

Hi,

Debian Policy section 4.9 says:
  clean (required)
 This must undo any effects that the build and binary targets may
 have had, except that it should leave alone any output files
 created in the parent directory by a run of a binary target.

I looked at what happens when doing 'dpkg-buildpackage ;
dpkg-buildpackage ; dpkg-buildpackage -S' over most source packages in
sid. The resultats are the following:

Packages tested: 29883 (I filtered out those that take a very long time to 
build)
.. building OK all times: 24835 (83%)
.. failing somehow: 5048 (17%)
 failing during the first build: 238 (not relevant for this mail)
 failing because the 'clean' target fails: 52
 failing because dpkg-source fails: 4740
.. dpkg-source detects changes to binary files: 1595
.. dpkg-source detects unwanted binary files: 117
.. dpkg-source detects deletions: 101
.. dpkg-source detects other local changes: 2929
 failing for other reasons: 22

Logs, lists, and dd-lists are available at
http://qa-logs.debian.net/2023/08/twice/

An example sbuild invocation to reproduce failures is:
sbuild -n -A -s --force-orig-source --apt-update -d unstable -v 
--no-run-lintian \
--starting-build-commands="cd %SBUILD_PKGBUILD_DIR && runuser -u $(id -un) -- 
dpkg-buildpackage --sanitize-env -us -uc -rfakeroot" \
--finished-build-commands="cd %SBUILD_PKGBUILD_DIR && runuser -u $(id -un) -- 
dpkg-buildpackage --sanitize-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

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

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 every package
> > > is capable of repacking its source.  Ie, if you can unpack it, (possibly
> > > modify), and pack again.
> > > 
> > > Putting aside packages that are broken in other ways as well (B-Depends
> > > non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> > > of breakage that haven't been fixed in 2020.
> > > 
> > > This leaves one big set: packages that fail the clean step due to
> > > undeclared B-Depends.  According to the Policy:
> > > 
> > > # "clean"
> > > #Only the "Build-Depends" and "Build-Conflicts" fields must be
> > > #satisfied when this target is invoked.
> > > 
> > > ... which makes sense as you might be interested in only an arch:all or
> > > arch:any build, and we have no clean-indep/clean-arch targets.
> > > 
> > > For sbuild, the incantation is:
> > > alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> > > --no-arch-any --no-run-autopkgtest'
> > > 
> > > As 291 packages fail this requirement, I'm posting here before (instead?)
> > > filing bugs.  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:
> 
> please do not abuse sbuild to produce source packages. Source packages are the
> input to sbuild and not its output. Sbuild has some convenience features that
> let it create the source package for you from an unpacked directory so that 
> you
> do not have to do that step manually but that doesn't change the fact that to
> operate it still needs to create a dsc first.
> 
> Instead of trying to use the -s or --source option, use the
> --source-only-changes option instead which will not re-create the source
> package but gives you a .changes file ready to a source-only upload anyways in
> addition to the arch-all or arch-any .changes file.

My point is: if the issue raised by Adam is something we want to fix, it
would be great if we could come up with a way to detect this issue on a
regular basis, rather than with one-off QA checks.  One way to achieve
that would be to extend sbuild so that it is able to check for that
while also checking for rebuildability of binary packages. (and then I
would integrate that into my regular archive rebuilds)

> > - install B-D
> > - run clean
> > - install B-D-I
> > - build the binary packages
> 
> This will be tricky to implement because sbuild doesn't run the clean target.
> Instead it runs dpkg-buildpackage which then runs the clean target. But feel
> free to try and implement it and file a merge request on salsa. Maybe it's not
> as bad as I fear.
> 
> Changing salsa-ci.yml to test for this would not be easy either, because
> "apt-get build-dep" only exposes the --arch-only and --indep-only options. So
> there is no way to tell apt "only the dependencies for the clean target,
> please".

... but I see your point.

Lucas

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

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 every package
> is capable of repacking its source.  Ie, if you can unpack it, (possibly
> modify), and pack again.
> 
> Putting aside packages that are broken in other ways as well (B-Depends
> non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> of breakage that haven't been fixed in 2020.
> 
> This leaves one big set: packages that fail the clean step due to
> undeclared B-Depends.  According to the Policy:
> 
> # "clean"
> #Only the "Build-Depends" and "Build-Conflicts" fields must be
> #satisfied when this target is invoked.
> 
> ... which makes sense as you might be interested in only an arch:all or
> arch:any build, and we have no clean-indep/clean-arch targets.
> 
> For sbuild, the incantation is:
> alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> --no-arch-any --no-run-autopkgtest'
> 
> As 291 packages fail this requirement, I'm posting here before (instead?)
> filing bugs.  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

Re: FTBS bugs -- MBF?

[Lucas Nussbaum]

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 every package
> is capable of repacking its source.  Ie, if you can unpack it, (possibly
> modify), and pack again.
> 
> Putting aside packages that are broken in other ways as well (B-Depends
> non-installable, FTBFS or a RC bug), there seems to be no new fancy types
> of breakage that haven't been fixed in 2020.
> 
> This leaves one big set: packages that fail the clean step due to
> undeclared B-Depends.  According to the Policy:
> 
> # "clean"
> #Only the "Build-Depends" and "Build-Conflicts" fields must be
> #satisfied when this target is invoked.
> 
> ... which makes sense as you might be interested in only an arch:all or
> arch:any build, and we have no clean-indep/clean-arch targets.
> 
> For sbuild, the incantation is:
> alias sbuild-source='sbuild -s --source-only-changes --no-arch-all 
> --no-arch-any --no-run-autopkgtest'
> 
> As 291 packages fail this requirement, I'm posting here before (instead?)
> filing 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

Re: Lintian breaks existing lintian-overrides due to added []

[Lucas Nussbaum]

On 29/06/22 at 15:49 +0200, Axel Beckert wrote:
> Correct, except that it happened for quite a while (7 months at least)
> and was (and maybe still is — see below) a continuous transition. It
> is present since at least 2.114.0 from November 2021. According to the
> git history, the implementation started shortly before the 2.114.0
> upload, but the bug report which requested this is actually from 2014:
> https://bugs.debian.org/743226
> 
> And yes, 2.115.0 (but not 2.115.1 or 2.115.2 from today) had more such
> changes as there were over 200 commits from Felix included which he
> did after 2.114.0, but which weren't uploaded since then.

Hi Axel,

Just a note that since the last version of lintian to migrate to testing
was 2.111 (which was also the last one to be backported to stable), some
of us might not have updated since 2.111 and might be hit 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

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

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 were includined in the MBF, despite the fact that they are 1.0
> >> native packages with Debian revision:
> >>
> >>its-playback-time
> >>spigot
> >>vm
> >>vtwm
> >>chroma
> >>
> >> Clearly the it makes no sense to have filed bugs saying "please switch
> >> to this other source format" when the other source format cannot
> >> represent the package.
> >
> > Those five packages:
> > - are indeed native packages with Debian revisions
> > - are not maintained in a VCS (or the VCS is not advertized using
> >   Vcs-*).
> >
> > So there's no easy way to understand how the package differs from
> > upstream (no patch serie, no VCS history). I don't think that it's
> > something desirable.
> > (if the packages had declared a VCS, they would have joined cachefilesd,
> > userv-utils, and vde2 in the "native package with a Debian revision
> > maintained in a VCS" category.)
> 
> They have detailed history on dgit-repos.
> E.g. <https://browse.dgit.debian.org/its-playback-time.git/>.

Yes, my point is that those packages don't have Vcs-* headers, so it's
impossible to discover the above URL.

Lucas


signature.asc
Description: PGP signature

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

Hi,

On 15/03/22 at 09:29 -0700, Sean Whitton wrote:
> > What the are the packages for which you are surprised that bugs were
> > filed? I wonder which part of the criteria was too loose.
> 
> It looks like the query didn't do quite what was intended, indeed:
> src:userv-utils is maintained in git but a bug was filed.  Before I go
> ahead and close the bug, would you mind confirming this was an error
> rather than a disagreement about what counts as VCS-maintained?

Taking src:userv-utils:
- it is not maintained by Debian X
- it is maintained in a VCS
- the VCS is OK
- there are no direct changes in diff.gz, because there's no diff.gz,
  because the package is a native package. => the filter evaluates to
  true

So the limit of the query above is that it does not indeed account for
So the query works as intended, but indeed does not properly take into
account native packages, since direct_changes is always false.

There are 16 packages in that case:
- with a Debian revision:
  cachefilesd
  userv-utils
  vde2

- without a Debian revision:
  daptup
  dgit
  games-thumbnails
  gimp-plugin-registry
  gitpkg
  ifupdown-extra
  lpr
  postal
  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

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

Hi,

On 15/03/22 at 15:36 +, Ian Jackson wrote:
> At least the following packages of which I am the maintainer or
> sponsor were includined in the MBF, despite the fact that they are 1.0
> native packages with Debian revision:
> 
>its-playback-time
>spigot
>vm
>vtwm
>chroma
> 
> Clearly the it makes no sense to have filed bugs saying "please switch
> to this other source format" when the other source format cannot
> represent the package.

Those five packages:
- are indeed native packages with Debian revisions
- are not maintained in a VCS (or the VCS is not advertized using
  Vcs-*).

So there's no easy way to understand how the package differs from
upstream (no patch serie, no VCS history). I don't think that it's
something desirable.
(if the packages had declared a VCS, they would have joined cachefilesd,
userv-utils, and vde2 in the "native package with a Debian revision
maintained in a VCS" category.)

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

On 15/03/22 at 10:36 +, Ian Jackson wrote:
> Answers were given, including by a former DPL (whom you may observe
> is not someone I am on speaking terms with).
> 
> But I see now that the MBF has gone ahead anyway.
> 
> I spent some time trying to help by setting out the factual
> background, but it seems that Debian is not interested in facts.  I
> don't know why I bother.

Hi Ian,

As explained in https://lists.debian.org/debian-devel/2022/03/msg00165.html
I proceeded with the MBF for packages that match
not (debian_x or (vcs and vcs_status != 'ERROR' and direct_changes))
or, maybe easier to read:
(not debian_x) and ((not vcs) or vcs_status == 'ERROR' or (not direct_changes))

I did not file bugs for packages that are likely to use a VCS-based
workflow (category (2) in the mail pointed above, or in
https://udd.debian.org/cgi-bin/format10.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

Re: proposed MBF: packages still using source format 1.0 [revised proposal]

[Lucas Nussbaum]

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:
> > 
> > -->8
> > Subject: please consider upgrading to 3.0 source format
> > Severity: wishlist
> > Usertags: format1.0
> > 
> > Dear maintainer,
> > 
> > This package is among the few (1.9%) that still use source format 1.0 in
> > bookworm.  Please upgrade it to source format 3.0, as (1) this format has 
> > many
> > advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; 
> > (2)
> > this contributes to standardization of packaging 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
> >...
> 
> josch already has tested patches for more than half of the packages, 
> starting by submitting bugs for these packages with these patches will 
> avoid work for maintainers and result in faster fixing of the bugs.

I just sent a followup to the relevant bugs (it's the "trivial fix"
column on https://udd.debian.org/cgi-bin/format10.cgi )

Thanks

Lucas

Re: proposed MBF: packages still using source format 1.0 [revised proposal]

[Lucas Nussbaum]

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
(1.2): 431 packages
(2): 135

(There was a logic error in the queries)

Lucas

Re: proposed MBF: packages still using source format 1.0 [revised proposal]

[Lucas Nussbaum]

Hi,

Based on the discussion, I propose the following:

Let's split the 626 packages in bookworm that use source format 1.0 into
three categories (1.1), (1.2), (2):
(1) packages with are very unlikely to use a VCS-based workflow (not
maintained by Debian X; not using a VCS; or referring to a broken VCS
repository; or using a VCS but not having any direct changes outside
patches)
  (1.1) Those in (1) that are key packages
  (1.2) Those in (1) that are not key packages
(2) packages which might be using a VCS-based workflow

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

Packages in (2) need a deeper analysis to understand how VCS-based
workflows, or 3.0 (quilt), can be adapted to better support each other.
So let's not do anything about them for now, and focus on (1.1) and
(1.2).


For packages in (1.1) and (1.2), I propose to file Severity: wishlist
bugs using the following template:

-->8
Subject: please consider upgrading to 3.0 source format
Severity: wishlist
Usertags: format1.0

Dear maintainer,

This package is among the few (1.9%) that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging 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

Thanks

Lucas
-->8

Then, I propose that we do not discuss upgrading the severity for bugs in
(1.2) before all packages in (1.1) are fixed (or there's a good reason
not to fix the remaining ones). That way,
1/ people motivated to do the work can do it using the normal NMU
procedure (and use the bugs for coordination).
2/ nobody is forced to do work packages until the packages that we
absolutely need to fix are fixed.

I will file bugs against the 53 packages in (1.1) soon as the number is
reasonably low, and I don't think this is controversial (with wishlist
severity). I will wait a few more days before filing the bugs for
packages in (1.2).

My main motivation for filing bugs against packages in (1.2) ASAP is
that I hope that filing the bugs will trigger some maintainers to fix
their packages, if they had not realized that their packages were still
using 1.0.

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

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 think this category was one of the ones Russ
> and I were talking about.

My limited understanding of the landscape of git workflows is that a
workflow that is quite popular among packages still using the 1.0 format
is the one used by the Debian X strike force. Julien Cristau described
it as follows when I asked about it on IRC:

< jcristau> [...]  basically, for upstream patches we cherry-pick
commits directly, and we use quilt for changes that aren't upstream

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

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:

can we find a middleground where the git workflows don't require staying
with 1.0? Even if that means switching to 3.0 (quilt) using the
single-debian-patch approach?

Also, how would that work with packages that combine direct changes to
upstream, and quilt for Debian-created patches? Examples of such
packages are:

package| quilt patches
---+--
 xdm   | 8
 xorg-server   | 7
 xorg-server   | 7
 libx11| 6
 mesa  | 4
 xorg-docs | 3
 xserver-xorg-video-ivtvdev| 2
 xserver-xorg-input-synaptics  | 2

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

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 source packages produce bit-by-bit reproducible binary packages after
> applying this change:
> 
> [..]
> 
> An additional 223 source packages produce bit-by-bit reproducible binary
> packages after applying this change:

Thanks a lot for this analysis.

I went a bit further and investigated a few packages that are not
in your list, just to provide examples of where issues could arise.

There are 266 packages not in your lists.

101 packages are native packages, and thus should probably be converted
to 3.0 (native). However some use a patch system (examples: mgetty,
libapache2-mod-auth-plain, vde2) or have a debian revision (example:
vanessa-socket).

Out of the 165 other packages, some fail to build (before the change),
such as gsfonts. Others are known to be unreproducible (example:
sofia-sip) and thus cannot be tested that way.

Finally, some result in different binary packages due to a GCC issue
that embeds the build path. If they are built in the same directory,
they result in the same binary packages after migration to 3.0.
(examples: mpclib3, libcompface, netselect, opus-tools)

Other that the known conflict with git workflows, I did not find any case
where migration would result in significant problems.

Lucas


signature.asc
Description: PGP signature

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

On 08/03/22 at 16:11 +0200, Adrian Bunk wrote:
> On Tue, Mar 08, 2022 at 11:39:04AM +0100, Andreas Tille wrote:
> > Hi Adrian,
> 
> Hi Andreas,
> 
> > Am Mon, Mar 07, 2022 at 11:42:42PM +0200 schrieb Adrian Bunk:
> >...
> > > lintian already warns or has info tags that should be upgraded to warning,
> > 
> > I absolutely agree here.
> > 
> > > and then there will be slow migrations usually happening when someone
> > > anyway does (and tests!) larger packaging changes.
> > 
> > This "someone anyway does larger packaging changes" did not seem very
> > probable for the packages I've touched (see my other mail in this
> > thread).
> > 
> > > Ensuring that all relevant lintian tags are warnings would be the 
> > > appropriate action (which is not yet true[1]), but there is no urgency 
> > > on getting everything "fixed" immediately.
> > 
> > I agree that there is no real urgency for immediate action - but this
> > seemed to be the case for other bugs on the packages I've touched the
> > case as well.
> 
> what time frame do you have in mind when you write "no real urgency"
> and "did not seem very probable"?
> 
> For me a reasonable time frame for changes that are neither urgent nor
> supposed to create user-visible changes in the binary packages would be
> to ensure it is a lintian warning now, and then wait 10 years.
> 
> Many maintainers touch their packages at least once per release cycle 
> and also check lintian warnings, so many packages will get fixed within 
> the next 1-2 years.
> 
> Most packages will get a new maintainer or a new team member in an 
> existing maintainance team within the next 10 years, and with the
> help of a lintian warning this is the natural time for doing such
> changes.

Hi,

I believe that the arguments in favor of this MBF fall in three
categories:

1/ the arguments about using patches to track changes to upstream code.
Among the ~600 packages in that potential MBF, there are still many that
make changes to upstream code, which are not properly documented. I
believe that it is widely accepted that seperate patches in 
debian/patches/ are the recommended way to manage changes to upstream code 
(good way to help with those changes getting reviewed, getting merged 
upstream, etc.)

2/ the arguments about other advantages of the 3.0 (quilt) format: newer
compression algorithms, multi-tarball support, debian/ dir in upstream 
code, etc. (but I agree that those arguments don't work well here, 
because the packages in question don't seem to need those improvements)

3/ the arguments about standardization/simplication of packaging 
practices, that make it easier (1) for contributors to contribute to any
package (think security support, NMUers, 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 we are talking about here is the "end game": there are less than 2%
of packages in testing that are still using 1.0, and many of those look
abandonned or of relatively low interest (see
https://people.debian.org/~lucas/format1.0/packages.txt ).

I'm pushing for it now because I believe that it is a good timeframe to
finish that transition before the release of bookworm. Yes, it requires
some effort, and some maintainers might make mistakes and introduce bugs
in the process. However (1) if we start that work now, we still have
plenty of time to uncover issues before the bookworm freeze; (2) if the
maintainers use this opportunity to modernize the packaging, switch to
the best current practices, and for example add tests to their packages,
it also means less bugs in the future.

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

Hi,

On 06/03/22 at 22:24 +, Holger Levsen wrote:
> So I'd rather propose to file these bugs with severity 'normal' and then wait
> and then get policy updated, and then raise the severity further.

For reference, there's a debian-policy bug about deprecating 1.0 +
dpatch/quilt: #850157 (no activity since 2018)

Lucas

Re: proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

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.debian.org/Projects/DebSrc3.0 ; (2) this contributes to
> > standardization of packaging practices, lowering the bar for contributors to
> > contribute to those packages.
> inn is a bit peculiar. It uses a patch system, has no direct changes and 
> is maintained in a VCS. But the build process is from a different age 
> and quite arcane, and I remember that switching to 3.0 would have 
> required significant work, so I see no compelling reason to do it.

So I looked into inn and it made me realize that there was a bug in my
analysis of the current status. We have packages using format 1.0 with
dpatch or quilt, but also with direct changes to files outside debian/
not tracked in the patch system.

So the correct breakdown is:
 patch_system | direct_changes | direct_changes_and_patch_system | vcs | count 
--++-+-+---
 dpatch   | N/A| no  | no  | 2
 dpatch   | N/A| yes | no  | 1
 quilt| N/A| no  | no  |17
 quilt| N/A| no  | yes |34
 quilt| N/A| yes | no  | 9
 quilt| N/A| yes | yes |62
 none | no | N/A | no  |   185
 none | no | N/A | yes |78
 none | yes| N/A | no  |   166
 none | yes| N/A | yes |74

I also updated https://people.debian.org/~lucas/format1.0/packages.txt

And inn is in quilt / N/A / yes / yes: there are files added in extra/
that are not tracked in a patch.

I tried to port inn to 3.0 (quilt), and after adding a patch for those
files using dpkg-source --commit, I could successfully build it. Do you
remember more details about the problems you ran into?

Lucas

proposed MBF: packages still using source format 1.0

[Lucas Nussbaum]

Hi,

There are 629 packages in bookworm that use source format 1.0. That's 1.9% of
bookworm packages.

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.debian.org/Projects/DebSrc3.0 ; (2) this contributes to
standardization of packaging practices, lowering the bar for contributors to
contribute to those packages.

Looking at:
- the patch system in use by those packages
- for those with no patch system, whether they include changes to files
  outside debian/ in diff.gz
- whether the packages are maintained in a VCS or not

The breakdown in terms of packages count is:

 patch_system | direct_changes | vcs | count 
--++-+---
 dpatch   | no | no  | 3
 quilt| no | no  |26
 quilt| no | yes |96
 none | no | no  |   185
 none | no | yes |78
 none | yes| no  |   166
 none | yes| yes |74

I propose to file bugs for packages in all categories above, except for
packages in the last category that are maintained in an active VCS repository,
because those are the most likely to be be using a git workflow that makes it
hard to use the 3.0 format (even if I don't fully understand the arguments
against using single-debian-patch in that case).

I created a table with all packages and information such 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 to 3.0 source format
Severity: important
Usertags: format1.0

Dear maintainer,

This package is among the few (1.9%) that still use source format 1.0 in
bookworm.  Please upgrade it to source format 3.0, as (1) this format has many
advantages, as documented in https://wiki.debian.org/Projects/DebSrc3.0 ; (2)
this contributes to standardization of packaging 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@:


The severity of this bug will be upgraded to 'serious' after a month.

Thanks

Lucas
-->8

dd-list follows (excluding the packages in the last category -- I will review
them manually and then discuss them separately).

Lucas



"Steinar H. Gunderson" 
   amoeba-data

A Mennucc1 
   hp-ppd
   libprintsys
   xmorph

Adam Majer 
   lpr

Adam Sloboda 
   gkrellm-thinkbat
   gkrellm-xkb

Adi Zaimi 
   gkrelltop

Adrian Bunk 
   gkrellmoon
   xserver-xorg-input-aiptek
   xserver-xorg-input-elographics
   xserver-xorg-input-mutouch
   xserver-xorg-video-neomagic
   xserver-xorg-video-r128
   xserver-xorg-video-savage
   xserver-xorg-video-siliconmotion
   xserver-xorg-video-sisusb
   xserver-xorg-video-tdfx

Agustin Henze 
   binutils-arm-none-eabi (U)

Alejandro Garrido Mota 
   libdansguardian-perl

Alexander Wirt 
   grub-imageboot
   libdata-validate-domain-perl

Alexander Zangerl 
   intel2gas
   libcrypt-smbhash-perl
   libyaml-shell-perl

Alf Gaida 
   lxqt-metapackages (U)

Andrea Capriotti 
   umview (U)
   vde2 (U)

Andreas Barth 
   mgetty

Andreas Barth 
   debfoster (U)
   netpbm-free

Andreas Boll 
   mesa (U)
   pixman (U)

Andreas Boll 
   mesa-demos (U)

Andreas Bombe 
   simh

Andreas Rottmann 
   chase

Andres Salomon 
   gplaycli (U)
   msr-tools

Andrzej Urbaniak 
   vonsh

Anibal Monsalve Salazar 
   xfsdump (U)

Anton Zinoviev 
   cbedic
   console-cyrillic
   fortunes-bg
   scalable-cyrfonts

Ari Pollak 
   gav
   gav-themes

Arnaud Quette 
   powerman

Atsushi KAMOSHIDA 
   libjcode-pm-perl
   rcconf

Ayatana Packagers 
   libunity

Barry deFreese 
   pixbros (U)

Bartosz Fenski 
   redet

Bas Wijnen 
   z80asm

Bastian Blank 
   sysconfig (U)

Bdale Garbee 
   pforth

Bernd Zeimetz 
   gimp-plugin-registry (U)

Brandon Barnes 
   komi

Brendan O'Dea 
   vile

Breno Leitao 
   fortunes-br

Brian Nelson 
   aspell-el

Carsten Hey 
   pal

ChangZhuo Chen (陳昌倬) 
   lxqt-metapackages (U)

Chris Boyle 
   aewm++-goodies
   crack-attack

Chris Halls 
   python-ooolib (U)

Chris Lawrence 
   makexvpics

Christoph Martin 
   crypt++el (U)

Christophe Prud'homme 
   madlib

Chuan-kai Lin 
   mdm

ClamAV Team 
   clamsmtp

Colin Tuckley 
   cd-circleprint

Craig Sanders 
   dlocate

Cyril Bouthors 
   libapache2-mod-log-slow
   libdevice-usb-pcsensor-hidtemper-perl
   pgreplay
   watchcatd (U)

Cyril Bouthors 
   pgreplay (U)

Cyril Bouthors 
   libapache2-mod-log-slow (U)
   libdevice-usb-pcsensor-hidtemper-perl (U)
   pgreplay (U)
   watchcatd

Cyril Brulebois 
   debian-installer (U)
   libxxf86dga 

Re: Proposed mass bug filing: packages without support for build-arch and build-indep

[Lucas Nussbaum]

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,
> released in 2012.
> https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules
> 
> There are 421 affected packages in unstable (389 in testing as of
> 2021-10-01).
> The list of affected packages according to lintian is
> https://lintian.debian.org/tags/debian-rules-missing-recommended-target
> A dd-list is included below.
> 
> Unfortunately this is only a warning in lintian, which might explain
> why so many packages are still affected.
> 
> I have no strong feelings about this requirement, but I see it as a good
> opportunity to identify packages whose packaging probably need a
> refresh. Therefore it is a good target, especially at the beginning of a
> release cycle, to either update old cruft or get it removed from the
> next stable release.
> 
> This topic was raised back in April on debian-qa@, and saw no
> objection back then. See
> https://lists.debian.org/debian-qa/2021/04/msg00014.html (the thread
> included other topics).
> 
> The bug template I plan to use is included 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

Bugs have been filed:
https://bugs.debian.org/cgi-bin/pkgreport.cgi?tag=missing-build-arch-indep;users=debian...@lists.debian.org

https://udd.debian.org/bugs/?release=na=ign=7=7=only=missing-build-arch-indep=debian-qa%40lists.debian.org=1=1=1=1=1=1=1=id=asc=html#results

- Lucas


signature.asc
Description: PGP signature

Proposed mass bug filing: packages without support for build-arch and build-indep

[Lucas Nussbaum]

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,
released in 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

There are 421 affected packages in unstable (389 in testing as of
2021-10-01).
The list of affected packages according to lintian is
https://lintian.debian.org/tags/debian-rules-missing-recommended-target
A dd-list is included below.

Unfortunately this is only a warning in lintian, which might explain
why so many packages are still affected.

I have no strong feelings about this requirement, but I see it as a good
opportunity to identify packages whose packaging probably need a
refresh. Therefore it is a good target, especially at the beginning of a
release cycle, to either update old cruft or get it removed from the
next stable release.

This topic was raised back in April on debian-qa@, and saw no
objection back then. See
https://lists.debian.org/debian-qa/2021/04/msg00014.html (the thread
included other topics).

The bug template I plan to use is included 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 debian/rules targets build-arch and/or build-indep

Source: x
Version: x
Severity: serious
Justification: Debian Policy section 4.9
User: debian...@lists.debian.org
Usertags: missing-build-arch-indep

Dear maintainer,

Your package does not include build-arch and build-indep targets in
debian/rules. This is required by Debian Policy section 4.9, since 2012.
https://www.debian.org/doc/debian-policy/ch-source.html#main-building-script-debian-rules

Please note that this is also a sign that the packaging of this software
could benefit from a refresh. For example, packages using 'dh' cannot be
affected by this issue.

This mass bug filing was discussed on debian-devel@ in [url]

Best,

=== dd-list ===

"Steinar H. Gunderson" 
   amoeba-data

A Mennucc1 
   libppd
   printfilters-ppd

Adam Majer 
   lpr
   sc

Adam Sloboda 
   gkrellm-thinkbat
   gkrellm-xkb

Adi Zaimi 
   gkrelltop

Adrian Bunk 
   gkrellmoon

Alan Baghumian 
   myspell-fa (U)
   myspell-hy

Alberto Capella Silva 
   squidtaild

Alessandro De Zorzi 
   phamm (U)

Alex Pennace 
   dircproxy
   pentium-builder

Alexander Gordeev 
   madwimax

Alexander Wirt 
   libmail-verify-perl
   libmp3-info-perl
   mp3burn

Alexandre Ratchov 
   midish

alice ferrazzi (aliceinwire) 
   abr2gbr

Amaya Rodrigo Sastre 
   perforate

Andrew McMillan 
   whereami

Angel Ramos 
   hunt

Anibal Monsalve Salazar 
   bootp
   xfsdump (U)

Antoine Jacquet 
   fapg

Anton Zinoviev 
   console-cyrillic
   fortunes-bg
   scalable-cyrfonts

Antonin Kral 
   minisapserver

Ari Pollak 
   gav
   gav-themes
   gltron
   jnettop

Arjan Oosting 
   hugs98 (U)

Armando Segnini 
   gpsim-doc

Arne Goetje 
   libsnmp-multi-perl

Arthur Loiret 
   gcc-m68hc1x

Asheesh Laroia 
   cue2toc

Atsuhito Kohda 
   jtex-base (U)

Atsushi KAMOSHIDA 
   libjcode-pm-perl

Aurelien Jarno 
   fortunes-fr

Aurélio A. Heckert 
   ink-generator

Barry deFreese 
   hawknl (U)

Bartosz Fenski 
   libuninum

Benjamin Mako Hill 
   libtext-wikiformat-perl
   libwww-mediawiki-client-perl

Benoit Mortier 
   vncsnapshot

Bill Allombert 
   libjpeg6b
   libjpeg9
   menu
   menu-l10n
   menu-xdg
   pari-elldata
   pari-galdata
   pari-galpol
   pari-seadata
   toppler

Boyuan Yang 
   abr2gbr

Bradley Smith 
   libview
   plib-doc

Brandon Barnes 
   xevil

Breno Leitao 
   cappuccino

Carlos Laviola 
   bplay

Chris Boyle 
   aewm++
   sapphire

Chris Butler 
   xinv3d

Chris Halls 
   myspell (U)
   python-ooolib (U)

Chris Hanson 
   libapache2-mod-lisp

Christian Bayle 
   libibtk

Christoph Egger 
   cl-irc (U)

Christopher James Halse Rogers 
   gtk-nodoka-engine

Craig Small 
   lprng-doc

Dale E. Martin 
   pccts

Dave Holland 
   floatbg

David Banks 
   sisc

David Nusinow 
   discover (U)

David Symons 
   plait

Davide Puricelli (evo) 
   gnuboy

Debian CLI Applications Team 
   graphmonkey

Debian CLI Libraries Team 
   log4net

Debian Common Lisp Team 
   cl-irc
   cl-pg

Debian freesmartphone.org Team 
   literki

Debian Games Team 
   doom-wad-shareware
   geki3
   hawknl
   plib-doc (U)
   spacearyarya
   uqm-russian (U)

Debian Install System Team 
   discover

Debian LibreOffice Maintainers 
   mythes

Debian LibreOffice Team 
   python-ooolib

Debian OCaml Maintainers 
   pagodacf

Debian OpenOffice Team 
   myspell

Debian QA Group 
   apsfilter
   cfingerd
   cldump
   convlit
   crip
   dbmix
   dh-kpatches
   docbook-simple
   efax
   esekeyd
   fbpager
   galib
   glbsp
   hashcash
   iog
   kic
   

Re: Automated backports based on Janitor work?

[Lucas Nussbaum]

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 also implies the promise to keep maintaining that
> backport until the next release is out... I'm not sure that part of the
> upload should be automated nor forgotten ;)

Oh I wasn't thinking about uploading to the official backports suite.
In the same spirit as the fresh-{releases,snapshots} suites provided by
janitor, I was thinking about an automatically-generated backports
suite.

Lucas

Automated backports based on Janitor work?

[Lucas Nussbaum]

Hi,

I'm really amazed by all the great work done around the Debian Janitor
project. It's great to see how it focuses the maintainer's work on where
there's some actual value with having humans in the loop.

Watching the talk[0] on automatically providing packages for new
upstream releases and new upstream git snapshots, I wondered if the same
tooling could be used to automatically provide stable backports
for packages in unstable/testing.

There's probably a large number of packages that just require a
rebuild (+ test with autopkgtest) to be backported.

Additionally, 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 could help
you?

Lucas

[0] https://debconf21.debconf.org/talks/7-fresh-upstreams-daily-builds/

https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/debconf21-110-fresh-upstreams-daily-builds.webm

Re: Have the watch file checks stopped?

[Lucas Nussbaum]

On 23/08/21 at 13:45 +0200, Gard Spreemann wrote:
> 
> Mattia Rizzolo  writes:
> 
> > On Mon, Aug 23, 2021 at 12:59:39PM +0200, Gard Spreemann wrote:
> >> Have the uscan watch file checks that feed qa.debian.org stopped? Is it
> >> on purpose? Perhaps a 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

Proposed mass-bug filing: missing support for build-arch or build-indep

[Lucas Nussbaum]

Hi,

I would like to propose a mass bug filing on source packages that miss
support for build-arch or build-indep targets in debian/rules.

Those targets were made mandatory in Debian Policy 3.9.4 (released in
August 2012). From the changelog:
  * build-arch and build-indep are now mandatory targets in debian/rules,
implementing the Technical Committee ruling in #629385.  Wording
review by Jonathan Nieder, Jakub Wilk, and Roger Leigh.
(Closes: #374029)

There are currently 411 packages in testing that do not include those
targets, according to lintian's debian-rules-missing-recommended-target
tag.  (I will also file a bug against lintian to reflect that those
targets are now required).

I do not particularly care about those targets, but I believe that it is
a good idea to use this old policy change as a way to identify packages
whose packaging should be upgraded to newer practices.

Here is the template I plan to use:
-->8

Source: SOURCE
Version: VERSION
Severity: serious
Tags: bookworm sid
Usertags: build-arch-indep

Hi,

According to lintian, this package does not implement
build-arch/build-indep targets in debian/rules. Those are mandatory
since Debian Policy 3.9.4, released in 2012.

This mass bug filing was discussed on the debian-devel mailing list. See
URL

While fixing this bug, please also consider upgrading this package's
packaging to newer standards or best practices (such as using dh,
maintaining the 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 
   lpr
   sc

Adam Sloboda 
   gkrellm-thinkbat
   gkrellm-xkb

Adi Zaimi 
   gkrelltop

Adrian Bunk 
   gkrellmoon

Alan Baghumian 
   myspell-fa (U)
   myspell-hy

Alberto Capella Silva 
   squidtaild

Alberto Furia 
   wbox

Alex Pennace 
   dircproxy
   pentium-builder

Alexander Gordeev 
   madwimax

Alexander Wirt 
   libmail-verify-perl
   libmp3-info-perl
   mp3burn

Alexandre Ratchov 
   midish

alice ferrazzi (aliceinwire) 
   abr2gbr

Amaya Rodrigo Sastre 
   perforate

Andreas Barth 
   netpbm-free

Andrew McMillan 
   whereami

Angel Ramos 
   hunt

Anibal Monsalve Salazar 
   bootp
   elida
   xfsdump (U)

Antoine Jacquet 
   fapg

Anton Zinoviev 
   console-cyrillic
   fortunes-bg
   scalable-cyrfonts
   trscripts

Antonin Kral 
   minisapserver

Ari Pollak 
   gav
   gav-themes
   gltron
   jnettop

Arjan Oosting 
   hugs98 (U)

Armando Segnini 
   gpsim-doc

Asheesh Laroia 
   cue2toc

Atsuhito Kohda 
   jtex-base (U)

Atsushi KAMOSHIDA 
   libjcode-pm-perl

Aurelien Jarno 
   fortunes-fr

Aurélio A. Heckert 
   ink-generator

Barry deFreese 
   hawknl (U)
   pixbros (U)

Bartosz Fenski 
   libuninum

Bastian Blank 
   sysconfig (U)

Benjamin Mako Hill 
   libtext-wikiformat-perl
   libwww-mediawiki-client-perl

Benoit Mortier 
   vncsnapshot

Bill Allombert 
   menu
   menu-l10n
   menu-xdg
   pari-elldata
   pari-galdata
   pari-galpol
   pari-seadata
   popularity-contest (U)
   toppler

Bradley Smith 
   libview
   plib-doc

Brandon Barnes 
   xevil

Breno Leitao 
   cappuccino

Carlos Laviola 
   bplay

Chris Boyle 
   aewm++
   sapphire

Chris Butler 
   xinv3d

Chris Halls 
   myspell (U)
   python-ooolib (U)

Chris Hanson 
   libapache2-mod-lisp

Christian Bayle 
   gatos
   libibtk

Christoph Egger 
   cl-irc (U)

Christopher James Halse Rogers 
   gtk-nodoka-engine

Craig Small 
   lprng-doc

Cyril Lacoux (Yack) 
   digitools

Dale E. Martin 
   pccts

Dave Holland 
   floatbg

David Banks 
   sisc

David Nusinow 
   discover (U)

David Symons 
   plait

Debian CLI Applications Team 
   graphmonkey

Debian CLI Libraries Team 
   log4net

Debian Common Lisp Team 
   cl-irc
   cl-pg

Debian Games Team 
   geki3
   hawknl
   pixbros
   plib-doc (U)
   spacearyarya

Debian Install System Team 
   discover

Debian LibreOffice Maintainers 
   mythes

Debian LibreOffice Team 
   python-ooolib

Debian OCaml Maintainers 
   pagodacf

Debian OpenOffice Team 
   myspell

Debian QA Group 
   abicheck
   apsfilter
   cfingerd
   cldump
   convlit
   crip
   dbmix
   docbook-simple
   doschk
   efax
   esekeyd
   fbpager
   gaim-themes
   galib
   glbsp
   hashcash
   iog
   libapache-mod-encoding
   libapache2-mod-encoding
   mp3rename
   ncdt
   osdclock
   partimage-doc
   playmidi
   poppassd
   pppconfig
   quickml
   scribus-template
   sendfile
   sgml-base-doc
   snmptrapfmt
   sntop
   stfl
   stymulator
   swish++
   tegaki-zinnia-simplified-chinese
   tmexpand
   xfonts-bolkhov
   xgammon
   xstarfish

Debian S/390 Team 
   sysconfig

Debian VDR Team 
   libmdsp

Debian VoIP team 
   asterisk-prompt-fr-armelle
   asterisk-prompt-fr-proformatique

Debian X Strike Force 
   xfonts-100dpi
   xfonts-75dpi
   xfonts-base
   xfonts-cyrillic

Re: Debian Trends updated

[Lucas Nussbaum]

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

Debian Trends updated

[Lucas Nussbaum]

[ M-F-T set to -qa@ ]

Hi,

I just updated Debian Trends: https://trends.debian.net/

I wonder if we should use the start of the next release cycle to decide
that we no longer want to accept some packaging practices, such as:
- debhelper compat level << 9
- source format 1.0 with direct changes in .diff.gz (no patch system)
- no support for build-arch and build-indep

Lucas

Re: About lintian

[Lucas Nussbaum]

Hi,

On 17/01/21 at 22:00 +0900, Norbert Preining wrote:
> On the infrastructure side, you mentioned on #debian-qa that in your
> opinion, lintian is best run in a CI pipeline instead of on the
> lintian.d.o service. While this is certainly true, do you plan to keep
> the functionality on your rework of lintian.d.o?
> 
> As part of this rework and the ongoing development, you said you have plans
> to set up a test version of the Lintian web application on non-Debian
> infrastructure. How is that going, Felix? Please if you need help or support,
> don't hesitate to reach out.

I agree that a service that provides an overview of the status regarding
lintian for the whole archive would be useful (for example, to identify
packages that need some area of work inside a team).

If there's a lack of interest/motivation to redesign lintian.d.o as 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

Archive rebuilds as a service

[Lucas Nussbaum]

Hi,

FYI:
I'm able to run archive rebuilds on a quite regular basis. I do that to
find (and file) FTBFS bugs, but it's also possible to test candidate
changes in Debian (for example, new versions of compilers, interpreters,
or other packages that are common build-depends).

If that'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 if it's not trivial to determine the exact set of packages to
test-build, building all of unstable is of course possible)

I usually factor a few of those rebuilds together, so you might have to
wait a few weeks. There's some manual process involved, so please also
provide a small explanation of why that's useful.

Lucas

Re: https://trends.debian.net/ - is this 20000 source packages since 2006?

[Lucas Nussbaum]

Hi,

On 04/07/20 at 13:24 +0200, Steffen Möller wrote:
> Hello,
> 
> I just skimmed through https://trends.debian.net/ and am impressed. Many
> thanks for these figures.

Thanks

> Do you accept wishes for additional graphs? 

Sure

> Mine would be on the number of build dependencies as a scale for
> software complexity and how this evolved over time. My hunch is that
> later software has more dependencies than earlier ones. Would of course
> be cool to also have other software metrics over time. Anyway -
> fanstastic plots already!

I use lintian as the source 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

Debian Trends updated

[Lucas Nussbaum]

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

Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

[Lucas Nussbaum]

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 about where to find information about such images,
> > and where to report problems.
> > 
> > And I don't think that pointing to github for our tooling, and for bug
> > reporting, is really an acceptable solution for something that is
> > officially endorsed by Debian.
> 
> Official *Docker* images come from
> https://github.com/docker-library/official-images
> 
> It might be possible to pull git repositories from the outside of git
> hub in there, though, but I doubt it is. At least you'll have to use
> github pull requests.
> 
> Of course you are free to run your own registry even under a debian.org
> domain and provide official Debian images for docker there, but as long
> as you want to have them in the docker hub, I think the current practice
> is just fine. And: its an image from DOCKER, maintained by Debian
> developers - its not an image from DEBIAN. It says 'Docker official
> images', not 'Debian official images'.
> 
> To be honest, I fail to understand why this needs discussion at all.

I don't see what would be the problem with:
- tracking problems using a BTS pseudo-package
- maintaining the tooling (debuerreotype) on salsa
- mirroring the tooling to github, if that's a requirement
- maintaining the metadata in
  https://github.com/docker-library/official-images/blob/master/library/debian
  using github (which means that only the "release" process involves
  github)

Lucas

Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

[Lucas Nussbaum]

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
> > images.
> 
> Whether it does or not, I've been told that the docker image maintainers 
> prefer
> to keep their current organization and workflow.  I'd welcome their
> participation in the team, if they were interested.  But I don't think they
> need to be.

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 about where to find information about such images,
and where to report problems.

And I don't think that pointing to github for our tooling, and for bug
reporting, is really an acceptable solution for something that is
officially endorsed by Debian.

Solving this for Docker or Vagrant sounds very similar to solving it for
cloud images; so it's probably best if the same people are in charge.

> Maybe it could be nice, if the people building those images want to use our
> tools and work with us.  Some would raise concerns in my mind, but I don't
> think it's useful to discuss before someone wants to build e.g. raspberry pi
> images in cloud-team.

I'm surprised by this. I thought of the delegation as a (soft) hammer to
enforce some rules, even when people are not nice and don't want to work
with the cloud team (I'm not saying it's the case here).


I've seen people saying "oh look, the official Debian images for docker
point to github! that's funnny!". If those images are not official,
then this should be clarified. If they are, then they should probably
conform to standard ways of maintaining stuff in Debian.

Lucas

Bug#925530: cloud.debian.org: Debian docker images pointing to github for bug tracking

[Lucas Nussbaum]

[Note: re-sending to the correct bug address... ]

(Cced: docker images maintainers ; cloud team delegates)

Hi,

As this was reassigned to 'general', it's probably time to do a status
update.

First, I would like to acknowledge the work done by those maintaining
those images, and 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 images still point to github
for bug tracking. I would expect the BTS to be used for bug tracking
(and salsa for maintaining the generation tools)

One could argue that the Cloud team delegation does not cover Docker
images. The delegation says:

> With the Debian Trademark Team, establish policies and procedures
> for the Debian Cloud Team regarding "Official Debian Cloud
> Images" for both open and proprietary platforms.

The current version of those policies is, AFAIK,
https://wiki.debian.org/Teams/DPL/OfficialImages

But I think that it would be a nice addition to change the delegation to
also include official images for virtualization environments such as
Docker, LXC, Vagrant, as well as official images for SBC such as the
Raspberry Pi (where it's often more convenient to boot a pre-built image
than use the Debian installer).

Lucas

Re: UDD/dmd: fails to load when debci data is missing

[Lucas Nussbaum]

On 25/05/20 at 09:57 +0100, Rebecca N. Palmer wrote:
> Control: retitle -1 UDD/dmd: fails to load when debci data is missing
> 
> The problem isn't the number of packages, but some specific packages that
> can't be displayed even when they are the only package requested:
> https://udd.debian.org/dmd/?email1node-file-entry-cache==html#todo
> 
> These packages appear to be the ones that have a debci result (any result)
> in testing but no debci data in unstable:
> https://ci.debian.net/packages/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

Re: trends.debian.net updated

[Lucas Nussbaum]

On 14/04/20 at 19:40 +0200, Adam Borowski wrote:
> > I think we should be rebuilding everything at least once per release
> > cycle, so we don't have a nasty surprise when these "mature" packages
> > need bug fixes.
> 
> There's enough automated testing 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

Re: trends.debian.net updated

[Lucas Nussbaum]

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 broken packages are removed
> 
> And interesting to see that this hardly happened during the last freeze.
> 
> > - second, it's surprising to see how the number of packages has been
> >   quite stable since the beginning of the buster freeze
> 
> I expect this to be the result of the Python2 support removal which has
> caused lots of packages to be removed from the archive.
> 
> > I keep wondering if we should 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)...
> 
> Is there something wrong with those packages? If so, what is it exactly?
> You can file RC bugs for real issues obviously.

Well, no, there doesn't seem to be any serious user-visible issues.

That's why I keep wondering whether it makes sense to just keep all this
technical debt around.

Lucas


signature.asc
Description: PGP signature

trends.debian.net updated

[Lucas Nussbaum]

Hi,

https://trends.debian.net/ was just updated (with data until April 1st).

The main change is that graphs are now displayed by default for Debian
'testing' (thus hiding broken packages in unstable only). Graphs for
'unstable' are still available.

There are a few things that strike me:

- first, one can see how the number of package in testing decreases
  slowly during freezes, as broken packages are removed

- second, it's surprising to see how the number of packages has been
  quite stable since the beginning of the buster freeze

I keep wondering if we should 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

Re: MBF? ftbs

[Lucas Nussbaum]

On 22/03/20 at 20:32 +0100, Adam Borowski wrote:
> Hi!
> There's a bunch of packages that fail to repack their sources.  That is,
> "dpkg-buildpackage -S" fails in a clean environment.
> 
> I've tested the entire archive, invoking:
> sbuild -s --source-only-changes --no-arch-all --no-arch-any
> 
> The list below includes all packages which fail the repack but don't FTBFS
> on a binary-only build (on amd64).
> 
> I wonder what would be the appropriate severity: the Policy is clear, but no
> one filing bugs for failure to repack suggests it's nowhere bad enough to
> brandish the RC stick.

Hi,

If it's considered severity: serious, I could add this to my archive
rebuilds to detect future regressions.

However, in several cases, it seems that the problem is that
sbuild does not install packages in Build-Depends-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

Debian Trends updated

[Lucas Nussbaum]

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

Re: archive test rebuilds and reports for bullseye?

[Lucas Nussbaum]

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 graphs on the bottom of
> https://tests.reproducible-builds.org/debian/index_performance.html
> 
> So, for unstable/amd64 it's currently once a month, but we also were at
> twice a month in the past.
> 
> > Do you have an estimate of how many failures without a corresponding bug
> > there currently is?
> 
> no.

UDD uses
https://tests.reproducible-builds.org/debian/reproducible-tracker.json,
but that only includes results for suite='bullseye'. Is that expected?

Anyway, UDD sees 387 source packages that are failing to build on
bullseye, but don't have an open bug with 'FTBFS' in the title:

select distinct source from reproducible
where status = 'FTBFS' and architecture='amd64'
and source not in (
   select source from bugs where title ~ 'FTBFS'
   and status='pending');

(It might be OK if the bug has been closed and the package hasn't
migrated yet, hence my question about the results above.)

Lucas

Re: archive test rebuilds and reports for bullseye?

[Lucas Nussbaum]

On 03/11/19 at 15:24 +, Holger Levsen wrote:
> On Sun, Nov 03, 2019 at 03:14:38PM +0100, Matthias Klose wrote:
> > As part of general QA we did some test rebuilds during the last release
> > cycle, and filing the ftbfs reports as RC issues.  Afaics there were no such
> > test rebuilds and RC filing for bullseye after the release of buster.
> 
> FWIW (and I mean that very literally), reproducible.debian.net does
> continous rebuilds of experimental, sid and bullseye. And some people
> even file bugs based on this.

Hi Holger,

How often do packages get test-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

Re: virtualbox, backports, and fasttrack

[Lucas Nussbaum]

Hi,

On 02/10/19 at 23:23 +0200, Bernd Zeimetz wrote:
> > Given that backports are a no-go, I hope that
> > http://fasttrack.debian.net/ will make quick progress and turn into an
> > official service soon.
> 
> basically a good idea, but
> - what are your requirements 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

virtualbox, backports, and fasttrack

[Lucas Nussbaum]

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-buster/
[2] https://wiki.debian.org/VirtualBox#Debian_10_.22Buster.22

On the above web page, I added:
> Note: if you use this, please let me know, so I know if I should
> continue maintaining it.

I wasn't sure what to expect, but since then, I received at least 15
"thank you" emails.

I don't want to reopen the debate about policy for backports and
inclusion into testing, that was already discussed at length.
But it saddens me a bit that Debian is not providing a solution to our
users other than to install unofficial packages (from me, or directly
from upstream).

Given that backports are a no-go, I hope that
http://fasttrack.debian.net/ will make quick progress and turn into an
official service soon.

Lucas


signature.asc
Description: PGP signature

Accepted kanif 1.2.2-3 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 18 Jul 2019 16:10:33 +0200
Source: kanif
Architecture: source
Version: 1.2.2-3
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum 
Changed-By: Lucas Nussbaum 
Changes:
 kanif (1.2.2-3) unstable; urgency=medium
 .
   * Move to salsa; update Vcs-*
   * Switch DH compat level to 12
   * Switch to dh
   * Add more spelling fixes to fix_spelling.patch
   * Drop useless b-dep on cdbs
   * Bump Standards-Version to 4.3.0
   * debian/changelog: remove trailing whitespace
   * debian/copyright: switch to dep5 copyright format
   * Touch pod files to make sure that docs are regenerated
   * Point to /usr/share/common-licenses/GPL-2, not just GPL
   * Use https in debian/watch
Checksums-Sha1:
 8a3e9eb9a36c243f9a32aa9f697992816a44b79e 1834 kanif_1.2.2-3.dsc
 b4c2b45112f97003e918aa5be97570fb47b78a2a 3632 kanif_1.2.2-3.debian.tar.xz
 392d28b2b556ded15461514d159a367b5ec63961 5082 kanif_1.2.2-3_source.buildinfo
Checksums-Sha256:
 bfd6e13bff9f9abadfb54648b2f6751b261bc872ead23659977e9d98e033442e 1834 
kanif_1.2.2-3.dsc
 681877d073b0ad3dd164fc3cf43beb478233f1bf48fdda232d6c066ec9f8a984 3632 
kanif_1.2.2-3.debian.tar.xz
 b4c360c073c2d92853039b273e0bcbd52cf6d160bf188ff1f98469281df0ab2e 5082 
kanif_1.2.2-3_source.buildinfo
Files:
 d79bf53a009ebddb0267e2a5fe4a87cb 1834 net optional kanif_1.2.2-3.dsc
 6a48ec877ead8a74c9c6fc426f6aefab 3632 net optional kanif_1.2.2-3.debian.tar.xz
 a7146433017cd63dbd01e63e6f02 5082 net optional 
kanif_1.2.2-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAl0wfzEACgkQORS1MvTf
vplHfRAApCxdu7E+DA4JKeoK/5zuTB8G+uIX0r9nxo/QlpKKF7khw8kYeyQ2BFyy
3+k1nr3Di0N4yHKvEMQa7quGwSeTBoignQG1DD+VWPqOzqBgoPJmYBmBe+eSNFNh
EQMAoFklxYPVXwe+wBaGYS1apo/GCarajwewzmmrlzzdGel1iJtBfoyEn3nDs61V
i7ojRR703hABiy57YxScR2Gi+ymQ31+lo5HZIiOTUjBiDtbWgAeKVsjHh5lwjMmV
JFygmIbCRRmL82Ip5dRdqt12GEUX080erTMg+qb52BV+7M2lg0I9gZdz7pUUHuSM
BoczltwV7bUCcw/R+kPGOzljHVbKYSxkYDNmwkja0NcAV/BgYCMChMXjr30BJixL
gd/jAyNKyvUNC4hINWsPr2X0NGnoxXgfThV4hd7bnNpoEDy5m+z+Ig9gBmqejK97
w2XnwNVoJHHO/9Yzb7Bx/2o8JY1ckd6zU9yXNAHpvjxSMuRLliTkwwm7/K+Zplvc
rktf/yxgTUzUlGZ4mDJ1kZhmvjp4IopYYRD8qFICx5gIDJGLtBDaCah25X4L6Dz8
74avvZbC60cipIJQXOLpr7vJkLhMhCJzXKAOjIRuAlfC/PZONKqxfwHHc+ltbTTe
kuukribisfPcOgHzIUNsd4QAsQIV6hMlxCh94iQ5D/+BSW24M5k=
=VeA8
-END PGP SIGNATURE-

Accepted taktuk 3.7.7-2 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 18 Jul 2019 15:38:45 +0200
Source: taktuk
Architecture: source
Version: 3.7.7-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Danjean 
Changed-By: Lucas Nussbaum 
Changes:
 taktuk (3.7.7-2) unstable; urgency=medium
 .
   * debian/rules: remove trailing whitespace
   * debian/copyright: Switch to HTTPS
   * debian/control: update Vcs-* to point to salsa
   * Bump Standards-Version to 4.3.0
   * Bump dh compat level to 12
   * Drop dh --with autotools_dev
   * Use dh_missing
   * Drop b-dep on autotools-dev
   * debian/watch: use https
Checksums-Sha1:
 949c80382aa7cc93f0ec373204a0c016d5995569 2073 taktuk_3.7.7-2.dsc
 3a53191e9647cfcb51aa916dc23506b8a5312471 8136 taktuk_3.7.7-2.debian.tar.xz
 b4a7b1de23589ae7568abb72fc56e96ff711001b 5129 taktuk_3.7.7-2_source.buildinfo
Checksums-Sha256:
 2aa64975d81ce16a698a39e906e808cad9cf0304cef8c33ebbca940f69e6436c 2073 
taktuk_3.7.7-2.dsc
 39fba9ac753e39206a10de5f59af696b0f5833c91cc0c8a203665e79b3a6f43d 8136 
taktuk_3.7.7-2.debian.tar.xz
 760d0314dc1e1230b795a8bbfd48353c52cf521e74c88e43c309982c23edc10a 5129 
taktuk_3.7.7-2_source.buildinfo
Files:
 4716653e2c548962af28e049f0b32ac3 2073 net optional taktuk_3.7.7-2.dsc
 a77100276539f0525d58035894aef76d 8136 net optional taktuk_3.7.7-2.debian.tar.xz
 5225a8f67bb8f9bf20b4862a54152e07 5129 net optional 
taktuk_3.7.7-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAl0wdwwACgkQORS1MvTf
vplBrA/9HoPLgdioN2xQL6GWEDSu4kQ3IBfeSjUVCRKyTxluIxgDFr5aS0B/4Ia+
7hzvPWEDvWnBd1UU7WNLedgLO5hMEOMqd1nPRKMv7o24bGk4Ds1w3crVxE91TIDF
zt7iEQMd1UVlW4qmcvj1LLxcbPztpcl/ONyD1A7kOwEr6DmQJQ/aC8pAG4YRIH3E
UeO1BETmG9J7MZkQJNLftE+6IAgz6OSiuN1T1dGrHxNBjdxufOFAWUbD34Jy7ULC
d+krtfUjxEeMFLKEjnTGOxJkrTV9JcInbelQqjNXhT8VhPDxGhTeqDEfI6zkaUTq
XHHkDGI4HBBRXsHab5gVlQYsQtfZxvblhxvFCR62/IsC5LFpAjzJezszbYqSwKEt
+dViT4O6t9j6W8mNBB8Rh4nB6aO06Evn489ZFGW3Vd4qRpPJzpeHT6k6/aB74Cof
XvR9sBF3Mr5osTYQPhoIJS3nkSkQ2MxPE4twKjbxOFo45vEczIyvY+p0GO1zJfYl
hBPbD0+MHLH/KLwUC0X8OwawMxQFZB/brOvAP6su79ragG6LnBvHvbWvdfmNZAyi
XTJwnn7C4olV9prKXNrUv8wG2vAtJDo/xSnECmjNAAF+gpxPPN/JG5ztqV3og6QO
S1hwLaehopbfDFQBDIv5vzaqOZXwTgGiXQEskB4pHwmC+LeAWh0=
=RtPX
-END PGP SIGNATURE-

Accepted hpcc 1.5.0-2 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 18 Jul 2019 15:13:54 +0200
Source: hpcc
Architecture: source
Version: 1.5.0-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Science Maintainers 

Changed-By: Lucas Nussbaum 
Changes:
 hpcc (1.5.0-2) unstable; urgency=medium
 .
   * Fix debian/watch to ignore alpha/beta releases
   * Bump Standards-Version to 4.3.0
   * Change Priority: to optional
   * Use https URL in debian/watch
   * Update Vcs fields to point to salsa
   * Bump dh compat level to 12
   * Switch to DEP5 copyright format
Checksums-Sha1:
 317ab7ba5f01de701d0694699f89ab6bf0d24d6b 1921 hpcc_1.5.0-2.dsc
 0eda383671788fc1f0f3db951ed9143e926fa41d 5584 hpcc_1.5.0-2.debian.tar.xz
 91bab651f820b35352190c47c2adffed8e6774e7 6415 hpcc_1.5.0-2_source.buildinfo
Checksums-Sha256:
 9064f4fa74044a39304669c6c9dc01f9be5380e5ab17db9aa06a3d14e1a911fb 1921 
hpcc_1.5.0-2.dsc
 9c589d8971c7758eab619e04fd7d5e69d0c7e9350ae4c8fc663585976910b52b 5584 
hpcc_1.5.0-2.debian.tar.xz
 7efcb04560ecd99e909b4b1582cf37983e596297350f0bb962438b8641a11e01 6415 
hpcc_1.5.0-2_source.buildinfo
Files:
 452edbadd0ee5fc13a9d841724138006 1921 science optional hpcc_1.5.0-2.dsc
 d19bed230e996fac025b08c1fca1b21a 5584 science optional 
hpcc_1.5.0-2.debian.tar.xz
 e54b74ced89c9cd49df9103dfcd95401 6415 science optional 
hpcc_1.5.0-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAl0wcNAACgkQORS1MvTf
vpkLxA//V+U7ZMnjra6Yqtt4hjqUit5n8OB8+m7qZWMYwMl+4jgdEDmu7sCBfF4Q
Q70f/4Xvt8xsoBItassLpFX839Gxrp/UV6MVxs7ObyLbE2xAceYfnJRa1dykSdbx
XJdiHCALfFbC/bdfmQQOFrT5/aIKVGQxp5DEyu1syr0SS5Ss+uwhAM7hcCiY/udt
QnXJ9r3s0x86Ykg3VnyaSo8Mq3hFS0/FtB3Z+jcQDRqBC9gweCOHvDC10Uuu3RtK
bTyNhif0mBJK0th7KfwSeX+NrP5M2fNtn1TFnTu09z2znUQ4nKJ7QL/HIBsWDvRL
q+itZhRJcb484dTTHlX/AP6RDyuDzkwNhoIHGfF8Pz+17EXFijP1oAIo0EoRiiJz
EMrim0XsckgTGo6g5koicGBz7dKoJaXfXaZBlmj15kfIoxeXOAwlQiMfpNLqY5Iz
Ph7u5s6gnSScqc2wCDOvQWhAs/Kv2WRs//eGdGe9pYXvis3+XZYr8uJOR7NJ5dzo
5hUJf2YjGNIVF0B5uhmXV8VOPRNDwB8333kC4ePm0vu+dCT4wycgCeKdEgvM+p00
mya7io+pom5mrWyB74ueJolLdoJ39SmM0n+cRz+kTvu4KaNR0gFcy0kQZ1LnvRVb
drNh41YQL6w9xdTJKSs93T8NlOOAO4w7QpNkFiFNTA48MSPJEik=
=l9BS
-END PGP SIGNATURE-

Accepted vmtouch 1.3.1-1 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 18 Jul 2019 14:18:41 +0200
Source: vmtouch
Architecture: source
Version: 1.3.1-1
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum 
Changed-By: Lucas Nussbaum 
Changes:
 vmtouch (1.3.1-1) unstable; urgency=medium
 .
   [ Ondřej Nový ]
   * d/control: Set Vcs-* to salsa.debian.org
 .
   [ Lucas Nussbaum ]
   * Bump dh compat level to 12.
   * Bump Standards-Version to 4.3.0
   * Remove debian/compat
   * Add support for Pre-Depends
   * New upstream version 1.3.1
Checksums-Sha1:
 3e10dae067f1bbf75bab43d04046646c98eb225c 1902 vmtouch_1.3.1-1.dsc
 f2c1e580ff2f1a19b070b24dae64476e6f98f3b1 20311 vmtouch_1.3.1.orig.tar.gz
 db5c2df2f36580ce5a8e79f141fec30cdea869d4 3404 vmtouch_1.3.1-1.debian.tar.xz
 e61701c75be7e59188f275672cdc311154c128f0 5092 vmtouch_1.3.1-1_source.buildinfo
Checksums-Sha256:
 f956d26651321ac42afcb6526da8ba3f93a866efd88902b55d8cb81bea461aee 1902 
vmtouch_1.3.1-1.dsc
 d57b7b3ae1146c4516429ab7d6db6f2122401db814ddd9cdaad10980e9c8428c 20311 
vmtouch_1.3.1.orig.tar.gz
 4aab011afefbec638a0e3ffc9960922455d99675c4dbca3021c88161b233b639 3404 
vmtouch_1.3.1-1.debian.tar.xz
 d5afc8db51eceb0b29b410e034ecc5a10cc6bff8244b2348dd8fc3fb417e8468 5092 
vmtouch_1.3.1-1_source.buildinfo
Files:
 7037becb162cbf727ac462919cd4cc8e 1902 admin optional vmtouch_1.3.1-1.dsc
 46c153c48ab035d37d16e8bc1587e8d8 20311 admin optional vmtouch_1.3.1.orig.tar.gz
 1b565c3332c37607e34312cd6ceb9cfc 3404 admin optional 
vmtouch_1.3.1-1.debian.tar.xz
 833d462471e82978059eec20a16e56e2 5092 admin optional 
vmtouch_1.3.1-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAl0wY8EACgkQORS1MvTf
vpnUFBAAgmewKYEkEL9R8irXmLyDBif9Eu4M0u21e0+9/Gyfpb+9DSmtNG3NBeD5
3tDAEK5LKFDIN9gkHw5JQC3uWJgUpzZPWme+go6EqBt+taUz2mk8EBJ9xnMxoiLW
NHbjL48wXkAraABx6mzgTOlILSyRv+sfGidSY72iXT2eb5t1dNu42bsyXd+ZAoAZ
YDtEFA5cSquJH74pkrmkkwme6ixSsBX2pka/YisgP9cDd0xWgKXtCKGjhmg0VJl9
hhUtYRvZOzY4L/orCw/nQ0mHpdQ5KBLjdWw2H/jXJo9hgmPwAJS7O5BoQFPHDlk3
79uhYtDE0AzK0vQWjtOYqZQDiQcB+Fe1r+LjEyl9xnbv1u4pZmULU+K7gvKSoBNa
1M9f5gwKywwrLuPl0JjSw1dk+vWdjaiPU6HP23u/HwwnE1ilzrfyu3amXEliT6i9
TIulGUruNh0L78mcFWaWqYK5uupoteN3843HP4uWGy4OVvzfZFbE3wHPvO8Rrt44
ToVbnwgAttwtdPQV6y7jVuIM/bG1Skq2Shhnz++GFMJeQJkhb0qI5MxQkNyZyxmk
MnSEXUUs9+XyOsAaHhQI/nCe7TURFnycwsKu53haPloaacNLJ7PK0qz7+mgwKQ4D
E/PVp5ugv15K8+EMYbxpAhLBePkXCNz3ODQ7WOCfsIrKPlQpPCQ=
=wIax
-END PGP SIGNATURE-

trends.debian.net updated

[Lucas Nussbaum]

Hi,

I updated https://trends.debian.net .

Main changes:
* Refreshed data (up to July 2019)
* Added data about DEP5 copyright format adoption
* Added data about autopkgtest adoption
* Various minor changes

Now is probably a good time to go through smells in your packages and
update them to newer standards. As a reminder, there's a dd-list at
https://trends.debian.net/smells-dd-list.txt :-)

As another reminder, the dh discussion summary[1] includes the following
points which could be useful in that case as well:

> Best Practices for Testing DH Conversions
> =
> 
> * 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

Re: NMUs: Do we want to Require or Recommend DH

[Lucas Nussbaum]

Hi,

On 14/05/19 at 14:30 -0400, Sam Hartman wrote:
> I think there's a fairly clear consensus emerging that it's worth having
> things to check when making a build system conversion.  Looking at
> debdiff, ditherscope and reproducibility of the build all appear to be
> important things to consider in such a case.
> 
> So, I think there is an emerging consensus against the idea of people
> NMUing a package simply to convert it to dh.
> 
> First, I'd like to explicitly call for any last comments from people who would
> like to see us permit NMUs simply to move packages toward dh.  Are there
> any cases in which such an NMU should be permitted?

Our NMU policy (Sec 5.11.1 of developers-reference[1]) tries hard to
give some standards of when and how it's acceptable to do an NMU. It is
complex, but in the end, I think that it boils down to:
  NMUs are always permitted, but discouraged in some (many?) cases, and
  extensive use of the DELAYED queue is recommended.

It also explicitely discourages NMUs for packaging style changes:
> Fixing cosmetic issues or changing the packaging style (e.g. switching
> from cdbs to dh) in NMUs is discouraged.

Do you want to change this and explicitely forbid NMUs for converting to
dh? I think that the current policy is quite balanced (but I'm biaised
since I contributed to its adoption a long time ago :) ). I also think
that we should trust the judgement of DDs, and that completely
forbidding some changes via NMUs would be a regression compared to the
current policy.

- Lucas

[1] https://www.debian.org/doc/manuals/developers-reference/ch05.en.html#nmu

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

On 16/04/19 at 15:55 +0200, Enrico Weigelt, metux IT consult wrote:
> On 13.04.19 10:20, Lucas Nussbaum wrote:
> > TL;DR: see https://trends.debian.net and
> > https://trends.debian.net/#smells
> > 
> > Hi,
> > 
> > Following this blog post[1] I did some work on setting up a proper
> > framework to graph historical trends about Debian packaging practices.
> > The result is now available at [2], and I'm confident that I will be
> > able to update this on a regular basis (every few months).
> 
> Just a quick idea:
> 
> For packages using git, can you also trace how they're using it ?
> 
> There're several approaches used, some only track debian/ subtree,
> some track source tree plus debian/, some w/ extra text-based patches,
> some w/ patches already applied in git.

I'm outsourcing all the package analysis, which only uses the package's
files (source and binary -- only source in my case).

What you are suggesting would be super-interesting, but maybe it would
be better to plug this into vcswatch -- see
https://qa.debian.org/cgi-bin/vcswatch

Lucas

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

On 16/04/19 at 08:52 +0200, Andreas Tille wrote:
> On Mon, Apr 15, 2019 at 05:35:40PM +0200, Bastian Blank wrote:
> > On Mon, Apr 15, 2019 at 04:55:12PM +0200, Andreas Tille wrote:
> > > biococoa (U) does not use Debhelper (no compat level found) 
> > > (source version: 2.2.2-4)
> > > biococoa (U) should switch to dh. Current build system: cdbs 
> > > (source version: 2.2.2-4)
> > 
> > | % grep cdbs -r biococoa-2.2.2 
> > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/rules/gnustep.mk
> > | biococoa-2.2.2/debian/rules:include /usr/share/cdbs/1/class/gnumakefile.mk
> > | biococoa-2.2.2/debian/control:Build-Depends: cdbs,
> > | biococoa-2.2.2/debian/changelog: dh_installsystemd instead -> that's 
> > a cdbs issue)
> > | biococoa-2.2.2/debian/changelog:  * debian/control (Build-Depends): Add 
> > cdbs and quilt.  Drop gnustep-make
> 
> This explains the cdbs smelling (and I loved to get rid of this but
> this needs to be fixed by gnustep.mk).  But in how far is
> 
> "no compat level found"
> 
> sensible?

That's because, once lintian sees that the package does not use debhelper
or cdbs, it returns from debhelper.pm and thus doesn't reach the point
where the tag for debhelper-compat-level (which is an addition in my
lintian fork) is emitted.

L.

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

On 15/04/19 at 16:55 +0200, Andreas Tille wrote:
> Are you sure that you are not tricked by false positives from lintian?

I might be, but if lintian reports something incorrectly about your
package, it's probably worth fixing in lintian.

Lucas

Re: Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

On 13/04/19 at 09:28 +, Holger Levsen wrote:
> Hi Lucas,
> 
> On Sat, Apr 13, 2019 at 10:20:53AM +0200, Lucas Nussbaum wrote:
> > TL;DR: see https://trends.debian.net and
> > https://trends.debian.net/#smells
> 
> that's beautiful! thank you!
> 
> > [4] https://trends.debian.net/smells-dd-list.txt
> 
> for me there are two smelly packages, src:tuxtype should use source 3.0
> indeed, but for src:piuparts I really don't see why. Though I would
> quite probably agree that src:piuparts should not be native, and then
> 3.0 would make more sense.

Well you could switch to 3.0 (native). Are there good reasons to stay
with 1.0 for a native package ? Even if I agree that there's probably
not much to gain, there's also even less to lose.

> But you don't consider native packages as smelly, which I think you maybe 
> should.

I'm not sure we have ever had a real discussion about that. But yes that
might be true. It would make it easier to expose changes in derivatives.

Lucas


signature.asc
Description: PGP signature

Re: Introducing Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

On 13/04/19 at 10:24 +0200, Sebastiaan Couwenberg wrote:
> On 4/13/19 10:20 AM, Lucas Nussbaum wrote:
> > Additionally (and much more controversially I guess :-) ) I also added
> > an analysis of "package smells"[3], such as "not using dh", "not using a
> > recent debhelper compat level", "not using a 3.0 source format", etc. I
> > understand that in some cases there might be good reasons to keep those
> > "smells", but I find it valuable to have them presented in a more
> > actionable way to fix the cases that should be fixed. So there's a list
> > of smells, sorted by maintainer/uploader [4].
> 
> You should check if those issues present in unstable are not already
> fixed in experimental.

Yeah. Currently my code uses a partial mirror of snapshot.debian.org,
and I ran a custom lintian myself on 339491 source packages.

Ideally all the needed additional tags will be added to lintian, and
doing a more detailed and "real-time" analysis will be possible just by
looking at the lintian results on https://lintian.debian.org. (Once it's
available on lintian.d.o, it's easy to generate the DD list using UDD,
for example).

Lucas


signature.asc
Description: PGP signature

Introducting Debian Trends: historical graphs about Debian packaging practices, and "packages smells"

[Lucas Nussbaum]

TL;DR: see https://trends.debian.net and
https://trends.debian.net/#smells

Hi,

Following this blog post[1] I did some work on setting up a proper
framework to graph historical trends about Debian packaging practices.
The result is now available at [2], and I'm confident that I will be
able to update this on a regular basis (every few months).

Additionally (and much more controversially I guess :-) ) I also added
an analysis of "package smells"[3], such as "not using dh", "not using a
recent debhelper compat level", "not using a 3.0 source format", etc. I
understand that in some cases there might be good reasons to keep those
"smells", but I find it valuable to have them presented in a more
actionable way to fix the cases that should be fixed. So there's a list
of smells, sorted by maintainer/uploader [4].

Given that Debian is currently frozen to prepare the buster release,
this is a bad time to start fixing those smells, but I will send a
reminder to debian-devel@ once buster is released. (It's interesting to
see how the number of smells plateaued during previous freezes).

- Lucas

[1] https://www.lucas-nussbaum.net/blog/?p=945
[2] https://trends.debian.net/
[3] https://trends.debian.net/#smells
[4] https://trends.debian.net/smells-dd-list.txt


signature.asc
Description: PGP signature

Accepted packaging-tutorial 0.24 (source all) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 13 Mar 2019 13:06:01 +0100
Source: packaging-tutorial
Binary: packaging-tutorial
Architecture: source all
Version: 0.24
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum 
Changed-By: Lucas Nussbaum 
Description:
 packaging-tutorial - introduction to Debian packaging
Changes:
 packaging-tutorial (0.24) unstable; urgency=medium
 .
   * Update Chinese translation. Thanks to "SZ Lin (林上智)" !
Checksums-Sha1:
 0f2b24bc7e6ca91690dcd2fa0d2280d1a93b93a8 1903 packaging-tutorial_0.24.dsc
 a59f58abe7f64e24f1e5c6969634fa2f2aa8fa1f 287840 packaging-tutorial_0.24.tar.xz
 79fe1fa9049b9d233f459e1a864fbd6da14764c8 2951938 
packaging-tutorial_0.24_all.deb
 f5f585902a0060cfdfdd5c5d5c726bdc478f61b2 11620 
packaging-tutorial_0.24_amd64.buildinfo
Checksums-Sha256:
 90177f8f0d414487fdc2efb5943b04335f7086a1bcd5ce26f94967b1ae2d9e5f 1903 
packaging-tutorial_0.24.dsc
 89d812b52200594af0f5f7e85aaacc522850ae96745fc6d3d9038dbd497fd659 287840 
packaging-tutorial_0.24.tar.xz
 f6c2a7e26faa5c8a9b1168d72234188d61179c0c6e5fb02c4490ef043c768c89 2951938 
packaging-tutorial_0.24_all.deb
 39ffcb1024b0d23907c38f550bc3269d01f79a193144b082c25089d7533e6c92 11620 
packaging-tutorial_0.24_amd64.buildinfo
Files:
 253b51e0d5068cf9fdf5e1f944f940ac 1903 doc optional packaging-tutorial_0.24.dsc
 a3c7eb0e1988cf04b814a50da71a8085 287840 doc optional 
packaging-tutorial_0.24.tar.xz
 19a6de8a4870346b7c3d8b018a806cef 2951938 doc optional 
packaging-tutorial_0.24_all.deb
 7cdddaf804d46bc64720272f97876dfe 11620 doc optional 
packaging-tutorial_0.24_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlyI83MACgkQORS1MvTf
vplx9A//a8LQDlvChUw6rkq9/qgbZGe84hspaNQju/HlrU1br+w7POt8FZba7ISK
djkXkUv+QvwuTXcpkR61g/gkfQn15oytgpflf9irFtKwtKsDjwq98JySQDEvRkVh
9HcA7kPdhy6+OHF+40LhbbOEfQau1W+u+gtC2OPntP/k+5nUCYoSOCtoAXryxhfM
yawq0rm/adfEPDbGHKyll0mcYb5aJM9jHaJcTg9KGH11vM5Cvzlxtb9CEBQZvHLE
SRWi01Ts0Qj+eX0ClsmIN2v0W/+Fh32IZA1+OUmWrQOksMyQ/IlE8BRA/gNyTYyM
kE57TGhxV7KgHgpxnQXyxcWY1R5WvFK7rcNCGGTqg0DSoB9kJqQehFCC3rK++6/E
ZslG0sxKbyPO7yqX9VVnOWZ4IjGULTHqurP175ALIcEL2F9iJK8inVrwhlM803BK
3wLNsVUWqR67ent0O4VbhuR5fHq8YMfJpRMDWZqgGvoV6nnva6fU347wtXH5jYdp
6tCbCXHkTw2IjZOom3blkDYdiTFi2A1iQ13Iq4bYbi1+PGQ4Wppatcf2kTtUp4WF
Hiy5TRq/DtWLIFntSvW9tZSqFRKWPyzowsyEk/7pSPq0JN7zrKZCTwZXvA0GArdT
HoAnakjMwWUWNSUmH/XT6r8AFP12OffnlcsEiY06ll/IH9orsVg=
=Smiq
-END PGP SIGNATURE-

Accepted packaging-tutorial 0.23 (source all) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 04 Mar 2019 21:46:26 +0100
Source: packaging-tutorial
Binary: packaging-tutorial
Architecture: source all
Version: 0.23
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum 
Changed-By: Lucas Nussbaum 
Description:
 packaging-tutorial - introduction to Debian packaging
Closes: 923366 923622 923680
Changes:
 packaging-tutorial (0.23) unstable; urgency=medium
 .
   [ Helge Kreutzmann ]
   * Update German translation.
 .
   [ Lucas Nussbaum ]
   * Fix typo and manually unfuzzy translations. Thanks to Leandro Pereira
 for the report, and to Judit Foglszinger for the patch. Closes: 923622
   * Add Brazilian Portuguese translation. Thanks to Tassia Camoes Araujo.
 Closes: #923680
   * Update copyright.
   * Add note about how to use mutt to contact translators.
   * Fix two minor bugs. Thanks Tassia for noticing.
   * Update pt translation. Thanks to Américo Monteiro. Closes: #923366
Checksums-Sha1:
 ffa8c8d743c8d0802c2af27e70f12499fa2aaea0 1903 packaging-tutorial_0.23.dsc
 e6e7b23274d63380aa3d3d61a11847d9463fa872 286980 packaging-tutorial_0.23.tar.xz
 684df1b9f4b982fdc065eb632341119ed6effa9d 2783792 
packaging-tutorial_0.23_all.deb
 8fefed7f3b6f3e9af1eb54e92e3dfed29eb2eb27 9618 
packaging-tutorial_0.23_amd64.buildinfo
Checksums-Sha256:
 9c43e0c4598acabcfbf2e326057ef898f5221ee040f87291763e54313c0914be 1903 
packaging-tutorial_0.23.dsc
 8677312dd3bc68d470a982888d0ec8cb0cc4eda8aa91bcb678c5f7de8680ffcc 286980 
packaging-tutorial_0.23.tar.xz
 e2f2b3b33abccfc112dc5c43b1848a09f468a33e0404f72e9e2adb0203ef5c62 2783792 
packaging-tutorial_0.23_all.deb
 7434e10bd5ef1a1c1b4ab5ab3e93b289209a08d0d9c31312972679eab83d755e 9618 
packaging-tutorial_0.23_amd64.buildinfo
Files:
 a93b86f20f49ec9ba22f592bd62361c6 1903 doc optional packaging-tutorial_0.23.dsc
 85670b1c6bc4fb2d39b644c078e092a4 286980 doc optional 
packaging-tutorial_0.23.tar.xz
 c56989ff0bdab10f2d6b1db7d36e835d 2783792 doc optional 
packaging-tutorial_0.23_all.deb
 aaa75d027f0eda196e3efc3ae572bc1c 9618 doc optional 
packaging-tutorial_0.23_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlx9klIACgkQORS1MvTf
vpk5MQ/+Mm00M4FF2Jw3f1ecFv4ehC0MGD4bbh7zEdwRgkmnstrg1hNK+aa5tQ61
xYfL1P96iggvHRLvWiHtu0c2HZfYILmUF05euyh6IYV3pQFoUigVsidywSS0Qnjx
k73M2rG1u+iEJ3IfLF9+xGuttmkDA3aWH3OfwV2AZaUzuh4ok2GA8gZLa9f7nUF9
Ch0aufjMNZtfpdbLjOS8401+9aQQrgBkCMLv9X0cI0N/sJbIoXMDYfI9m3ehUHFG
V/z2GBjkPDg6XMd6Om3G95fxASqF8awWvSlqTrpmSCLKI34i+33nl8koHFF9y1XN
4Tflwt7RJG7PljxVFC7rTzVYkZNcyLf+kQNOCuzqED0wsXHWS7HBXF1mzx1rH7b3
HA8bTse+9scDgB784OXB8oDlpsIDJmrwSMZsYD9+P1md+Ect6f6y8yqgrDYZKhZi
URi/v1/QAeiN9DUqJK9V5MLuJ/H/C+HUjahoeS5PrUecoVp1VPOhFRGVikvhu1qX
BccACJPkzZZ8tkRewOeFarGRKVNT7k0oBt31eGZaDqC4pCZ8U9qUg7pq23Yq8H5T
C/32KIARKMeLthcEeimPnHuZLk6/Cmhk1LnVvxjPOxdb4T26X5HOO4E4lWx5Vgfj
OSeoUVYT7QMoien0D9kLXtDQGK/S+DL31YGSKneQt15gTKqZhvs=
=CLWt
-END PGP SIGNATURE-

Accepted packaging-tutorial 0.22 (source all) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 21 Feb 2019 14:50:21 +0100
Source: packaging-tutorial
Binary: packaging-tutorial
Architecture: source all
Version: 0.22
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum 
Changed-By: Lucas Nussbaum 
Description:
 packaging-tutorial - introduction to Debian packaging
Closes: 887422 904353 921801
Changes:
 packaging-tutorial (0.22) unstable; urgency=medium
 .
   [ Helge Kreutzmann ]
   * Update German translation.
 .
   [ Ondřej Nový ]
   * d/copyright: Change Format URL to correct one
   * d/control: Deprecating priority extra as per policy 4.0.1
   * d/rules: Remove trailing whitespaces
   * d/control: Set Vcs-* to salsa.debian.org
 .
   [ Lucas Nussbaum ]
   * Replace ProvidesPackageRCS with ProvidesPackage. Closes: #921801
   * Do not complain about the version if the target is UNRELEASED
   * Add slides about archive suites. Closes: #887422
   * Drop "not covered" part of conclusions slide. Those are mostly minor 
things.
   * Fix links to alioth. Closes: #904353
   * Update PO files.
   * Update French translation.
Checksums-Sha1:
 08977d45afe5917c95d2616c4b524da3bf955c0d 1903 packaging-tutorial_0.22.dsc
 c7b50ad010098665e104dd1e373a10b8586dfa1b 280176 packaging-tutorial_0.22.tar.xz
 0af61adc4e06ff31e6784d1a48d8c7cc019de363 2577860 
packaging-tutorial_0.22_all.deb
 45d62d31d4c48b68465f954b514d65c09aa4c558 9650 
packaging-tutorial_0.22_amd64.buildinfo
Checksums-Sha256:
 a23cb8ab0877fdb1a18ae3749d873a8e7548560374c7e8a43e97980922943753 1903 
packaging-tutorial_0.22.dsc
 a1bfd230ee301bf2910e86daa44ee5ad20e12075656065e57054fefc5c0c87e6 280176 
packaging-tutorial_0.22.tar.xz
 89ccf0932a4ed3c879d4f6a3ee9c9f236a0ef97288dad49f01c9e9ae43bf28b8 2577860 
packaging-tutorial_0.22_all.deb
 8f493c4958d27c8111e23f50d031f5b2417ef4d947670ee20811bc952ba0ef5f 9650 
packaging-tutorial_0.22_amd64.buildinfo
Files:
 dcd380b672fa24e79f448c77fa4e089f 1903 doc optional packaging-tutorial_0.22.dsc
 b32f25d2517a0dcb7af836aaf0bbdaf4 280176 doc optional 
packaging-tutorial_0.22.tar.xz
 9098baedfb124936f3b5cc015aec1356 2577860 doc optional 
packaging-tutorial_0.22_all.deb
 56f74554f63169265b57081c981688ae 9650 doc optional 
packaging-tutorial_0.22_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlxur/8ACgkQORS1MvTf
vpkwzQ//f2evD8mut2/fEBY8cF61RgK+LVibPLU7nUa0mSlDQgt2YL8xSjuY/Utx
OwpyqGIaVkLJUsCSZ72vfeKpRwtMEXkxIOaJ34dKfXaX4nu+8s8IOJNlf7D6OGJW
1DCSdQ0DM6kMwPRq1Nx+8HgRv9Sr12PQK1qak5hgb02828WZn/InJ/kZOpqXHaYT
gnfA8inihbrDWYeSoPUzrvhxiyb5Q1TMQcytNRMJ3+t5ph+sN3D6UbRkL3OA5r/x
gt+pm7HmdDUBPtzBHUAd43QYCKJsh3a0B+li6Yx2+VmmmiuBMmcah6j6qMqAl2rD
EziJpqR//VWnEe08QPce1/AtsnSDwWFpfdTQfDIdTr+XDBFUDM9iTBHzdkph6fNb
DrzVo3DnC1Wg9rX6H/b3jNt2UZBNkhyBPjREPkYYtI6QjDkkPi/4Ws9R5dODUPjD
koDTP7lbQwSeroxj6CjWDpZUqsjp88nwurgBb5a4kUx2f88sdBCfwOv/jm3RnmLS
qPrxkC+Q2AC5oYAV/MDlGkr8PYbVBUe/hUiEsLoqzsgN8tlXzTjSCGou/qd+8uE/
1i+vBNinNhiavAbOzI6ygZoCfJNqlUA4o4ihEDXU21igB7fKG4In9e+kRH4oipBK
qqbZeBiRLXTv41XSGfr4L7/3cmdBirwOS323fIxIO/lIl4bjC2k=
=FPRZ
-END PGP SIGNATURE-

Re: Remainings of old versions of packages in UDD / tracker

[Lucas Nussbaum]

On 08/01/19 at 13:25 +0100, Andreas Tille wrote:
> Hi,
> 
> I was seeking for remaining references to anonscm in packages in UDD.
> I've found the following strange hit:
> 
> udd=> select  source, version, maintainer, vcs_browser, release from sources 
> where source = 'r-bioc-deseq2' and release = 'sid' ;
> source |version|maintainer
> | vcs_browser 
>  | release 
> ---+---+--+--+-
>  r-bioc-deseq2 | 1.16.1-1  | Debian Med Packaging Team 
>  | 
> https://anonscm.debian.org/cgit/debian-med/r-bioc-deseq2.git | sid
>  r-bioc-deseq2 | 1.22.2+dfsg-1 | Debian R Packages Maintainers 
>| 
> https://salsa.debian.org/r-pkg-team/r-bioc-deseq2| sid
> (2 Zeilen)
> 
> 
> which means the source package r-bioc-deseq2 exists twice in sid.  There
> is also an entry in tracker[1] mentioning version 1.16.1-1 which should
> have gone since a long time.  The situation is similar for:
> 
>  r-bioc-genefilter
>  r-bioc-shortread
>  r-bioc-variantannotation
>  r-cran-dplyr
>  r-cran-haplo.stats
>  r-cran-luminescence
>  r-cran-phylobase
>  r-cran-purrr
>  r-cran-raster
>  r-cran-rsqlite
>  r-cran-scales
>  r-cran-surveillance
>  r-cran-tibble
>  r-cran-tidyr
>  r-cran-tidyselect
>  r-other-mott-happy
> 
> 
> Any idea why old versions of these packages might remain in UDD (and
> thus probably in tracker since it is reading UDD)?

Did you check the extra_source_only column?

Lucas

Accepted charliecloud 0.9.0-1 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 16 Jul 2018 20:10:38 +0200
Source: charliecloud
Binary: charliecloud charliecloud-doc
Architecture: source
Version: 0.9.0-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HPC Team 
Changed-By: Lucas Nussbaum 
Description:
 charliecloud - user-defined software stacks (UDSS) for HPC centers
 charliecloud-doc - user-defined software stacks (UDSS) for HPC centers 
(documentatio
Closes: 903354
Changes:
 charliecloud (0.9.0-1) unstable; urgency=medium
 .
   [ Lucas Nussbaum ]
   * Add missing changes to changelog entry for 0.2.5-1
 .
   [ Peter Wienemann ]
   * changelog: Correct contributor of Russian translation
   * changelog: Remove duplicate entries
   * New upstream version 0.9.0
 .
   [ Adriano Rafael Gomes ]
   * Add Brazilian Portuguese translation of debconf template (closes: #903354)
Checksums-Sha1:
 5b8269381d95d931d4231420b505f7d28cf865e5 2128 charliecloud_0.9.0-1.dsc
 8d937ced594df47a42b2d3bebd0d6d56ed10090e 195146 charliecloud_0.9.0.orig.tar.gz
 61c3ceec2f80faf7fc3d9bf87512679d72cd9819 6928 
charliecloud_0.9.0-1.debian.tar.xz
 2480a599bd2dca5b2f605ef706777e854525370d 7141 
charliecloud_0.9.0-1_source.buildinfo
Checksums-Sha256:
 5f956539cb78218b13b2c81ef8ad7134ea05df5515577cd8bc45a1c0535ff254 2128 
charliecloud_0.9.0-1.dsc
 7e74cb16e31fd9d502198f7509bab14d1049ec68ba90b15e277e76f805db9458 195146 
charliecloud_0.9.0.orig.tar.gz
 cb340c9f66eba88e5156023cf69736269f6703acab118e2b54a041849367830f 6928 
charliecloud_0.9.0-1.debian.tar.xz
 b4f28bd0de2fcb02d5b5cbbcc3e05d103f5e86eb6595d43ecd112c992aea7cf7 7141 
charliecloud_0.9.0-1_source.buildinfo
Files:
 49652441b3f2a3bbbc407865937e2211 2128 admin optional charliecloud_0.9.0-1.dsc
 1acd931563422de8211cfac148506cf7 195146 admin optional 
charliecloud_0.9.0.orig.tar.gz
 e4ec68693a9ec7ade1fb95c1452d77db 6928 admin optional 
charliecloud_0.9.0-1.debian.tar.xz
 969785ec315cc0d87176f3f6e73eb6e3 7141 admin optional 
charliecloud_0.9.0-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAltM4AkACgkQORS1MvTf
vpnRVBAAnVTMcoXoU4HpjroyI9RtoNH4XEyZ2QeSUnxCZgRC2KgUN3zyqT/K+eFy
RaLxShbMTDYLxuyDvWhZtAzsyO38Pk3Ez3kvkC9Uo/1Q1+imwlLEg5ORnc/PZfmC
hW9qkTNsbmprB8HVGuKyDy4WlV0ob4hwOO2m5o4XqOlkP3m30CX+BHVhrduE7B8B
1QNJWZt279WNnuzrCsVv16PdrbItXnMdGk25+ye98GDZlVT3T4hnRYdhySv9Fnjv
5OzhHcH57Cs16Ow39KCJuqHFYVD8TQUjxo6TQSbVb9UHnFDabqd5TvRYdZ7yJTkF
VdiCO5T3NzCrq38w1T1fuNd26Inv6mvQbpo5f7lo/6I1wOGcUDzd3a5bTd3iqM5U
uhxAycIKgGc+X8CFBeoRPW3fXOR0BdfK3THHVB4shluO+hfQFfCKCp3ywv64Z43F
QUZNMcwh7SJz5dD3AwyUHD+1elR42QFhh6GFuNXjyzwoHAe0kmnFnpHNqHIVdOmh
zI56YTJOvnUqa4/MxNabNxPdVdcjj04iCZhvaFpYbGUHoPR2YxaprjMJAQhgQ3UX
+pR8zvYUgC/7S8l6NQec+tu/xbh9SeblhK4DzUtXsMcNRFT7xpK3UU35g347t/M4
UV9/nEryw1GY5sLpeUlj5H6QxCHiqV3JGliLnTLE5wLZ1pg2cU8=
=l9Wg
-END PGP SIGNATURE-

Accepted charliecloud 0.2.5-1 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Thu, 14 Jun 2018 16:27:40 +0200
Source: charliecloud
Binary: charliecloud charliecloud-doc
Architecture: source
Version: 0.2.5-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HPC Team 
Changed-By: Lucas Nussbaum 
Description:
 charliecloud - user-defined software stacks (UDSS) for HPC centers
 charliecloud-doc - user-defined software stacks (UDSS) for HPC centers 
(documentatio
Closes: 900715
Changes:
 charliecloud (0.2.5-1) unstable; urgency=medium
 .
   [ Alban Vidal ]
   * Change po-debconf service by systemctl
   * Update all po-debconf files with systemctl
 .
   [ Jonathan Bustillos ]
   * Add Spanish translation of debconf template (closes: #900715)
 .
   [ Peter Wienemann ]
   * Update po files due to update of debconf template
   * Update README.Debian to get description in sync with debconf template
   * Add debconf-updatepo to "clean" target in debian/rules file
   * charliecloud-doc: Mark package Multi-Arch: foreign
   * New upstream version 0.2.4
   * Adapt debian/rules file to upstream's removal of COPYRIGHT file
   * Remove duplicate doc-src clean-up in debian/rules
   * Add pv to the list of suggested packages for charliecloud
   * Switch to Standards-Version 4.1.4 (no changes required)
   * Update es.po file: Use systemctl to restart procps
   * New upstream version 0.2.5
Checksums-Sha1:
 bcc3f9d998cd4bbd275a887200879c12186a4200 2128 charliecloud_0.2.5-1.dsc
 830b17dac65121d832ae7bef117f880dc671f0d0 188049 charliecloud_0.2.5.orig.tar.gz
 d61398682f90b793c16c61ecf4d9039ce8ac63bd 6548 
charliecloud_0.2.5-1.debian.tar.xz
 b5021abc4ff1d0fdca95590a0eedde5441e0eb3e 7141 
charliecloud_0.2.5-1_source.buildinfo
Checksums-Sha256:
 5fc1c8f10e7ab62621285bc8c0f3b5de54071a1c0e663e48c7be219b7f941d8c 2128 
charliecloud_0.2.5-1.dsc
 6029ac7fc8f260598a3846a72feb0ec5ad6dd68985efbde88f1bda2c6d08faf8 188049 
charliecloud_0.2.5.orig.tar.gz
 93395386460acfeb91ecb2e977aec1116425be7dfe970b02b6c75db63df402cf 6548 
charliecloud_0.2.5-1.debian.tar.xz
 d8823d6c2a438e21e83e8982723f5bad22a5cc66303f213ba46184228e58c90b 7141 
charliecloud_0.2.5-1_source.buildinfo
Files:
 0df79bf48985d0aef8b365cff7dafc15 2128 admin optional charliecloud_0.2.5-1.dsc
 7a55be3811dc49abc5f7d13c6fc6155f 188049 admin optional 
charliecloud_0.2.5.orig.tar.gz
 056d93bbf484800ebd68fb194f3acad2 6548 admin optional 
charliecloud_0.2.5-1.debian.tar.xz
 81c965891b750aebc354b03c9aa56b0c 7141 admin optional 
charliecloud_0.2.5-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlsj1s8ACgkQORS1MvTf
vpmxGBAArnFIfH3vuug3XVy3ea/g6eji0fjHwuYGhbGIlkKKJc8JOU1p/vpfAGN+
X7YUUz22JzuC+7kjNa7EGzXnDUtgQ6PVFy6vzQWszm6VatZDV6w23Y0WfWKLPjN7
ZCBP681BrJbZ3RMlonsWa8mr4eWHdIyiBUiNTPY1b1Fq0L4UrQj92Orz2+3mbmq9
ByR/EujGpvvgBkdOxyidKuFQr+a6JUQzq8dcGxkHc9nBMBqUeKvb+HlV8GpyPc34
2Xl0iR8Sd59V6GsU/CDO8p52k97xUIdRGtaRYx8F1nj7LdziD6VtpPWBpti8jymN
zL3t/264YwgyOiDXdsznSMcTO9TwuCjq+zmOIsTjJlwoHPSdD30fHOk5xHV89W6j
Ekyjmi4/8ezMiQD0E/Q5W16AgcMhQydNAjUmZF1YT1SYl/Y+KyD9YFzm2brUE2Wu
dkAQf388AKAyh39PFtP+GcxPLJ7TtG5SiUKyBxk3L7uIxLCEFMOzwZu28bM1F06r
uZPpuODqMg681iMgHTXoUDkmi9RZ3RX3xdbdlKABWTfRgV1TL2ypRYiSSRy1Buc3
IYgEN5+YM25EzEAATFubWl2vtvcljQPf1iVUMTQWMw0JYh5JhN5t9JuvpVmx/+Bv
BoCGr6y05k/MVczvGJG+fiC3c+Fe4btGeSJXW6H5zWC0+fcdVJQ=
=Ce5c
-END PGP SIGNATURE-

Accepted charliecloud 0.2.3-2 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 30 Apr 2018 15:41:33 +0200
Source: charliecloud
Binary: charliecloud charliecloud-doc
Architecture: source
Version: 0.2.3-2
Distribution: unstable
Urgency: medium
Maintainer: Debian HPC Team <debian-...@lists.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 charliecloud - user-defined software stacks (UDSS) for HPC centers
 charliecloud-doc - user-defined software stacks (UDSS) for HPC centers 
(documentatio
Changes:
 charliecloud (0.2.3-2) unstable; urgency=medium
 .
   [ Peter Wienemann ]
   * Check unprivileged_userns_clone kernel setting with cat instead of sysctl
 .
   [ Lucas Nussbaum ]
   * Prepare changelog for upload.
Checksums-Sha1:
 3c82f33497c5445fa57f686d335088e55c49a6b0 2125 charliecloud_0.2.3-2.dsc
 57b9e02691081537dd6d3182a082eb0e288a069c 4568 
charliecloud_0.2.3-2.debian.tar.xz
 09b3cc0ad9978a6dbfd9d1faf574c2b818a8208e 7141 
charliecloud_0.2.3-2_source.buildinfo
Checksums-Sha256:
 a81f17d49f497eebbd480329be41a2885dc79100934fc1695436963997a8b697 2125 
charliecloud_0.2.3-2.dsc
 21ab35a0cf334d4a52122917a02d75b917392f7242634cbd94fe9ea78777b5f7 4568 
charliecloud_0.2.3-2.debian.tar.xz
 96baedf3128914c2269134fa3fa0a90eb472767ddd6536b1b506b4db7e8c8ff7 7141 
charliecloud_0.2.3-2_source.buildinfo
Files:
 d551bd6cffa01595193cbe613843cddc 2125 admin optional charliecloud_0.2.3-2.dsc
 97232b3b5600f16a9f96550be7b25c4b 4568 admin optional 
charliecloud_0.2.3-2.debian.tar.xz
 4d8e68e54177a83d423fb6ba70436a54 7141 admin optional 
charliecloud_0.2.3-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlrnHrwACgkQORS1MvTf
vpn8pg/+II5WMei/H6aqpr3QGwxrtYcrrbvQgyxsrX8rtZBgY8Eel9qxUPd0xN26
NlZ8UrPCcbwJ7Qj/3Xo07NlUN9ui7LEH28EF0OmEq37+IazefbTeFLrPmWADDztn
6cneT3ADYeMop0OK11qmhaGdyA07sY50DghpxeUF7Oi/jfxeWjGxHWJrTC7+Rc7N
hZNHtz+d1f8S2BxvDE4E5W9jdodBm7ajcSWHyNJ1bECs9ykwpBXF++MFVygBfKv4
m0W9qqweXPVTGmw/IlYQ0rCS/x7KprtO22rQPrSd27b1jBgB+oJUTebEyJJiFEQV
kaT/l/be8WzWOnSdW19YTOgZE38DQ1vNPmjPnVDO3SMjm3lTT9gx8nxQSDL4TbbB
hGHGZssAprwK4eHpVIz6ubLJOGL6j5oFwl0uaQvE4PetMCwU6b+nTz5CIe5aqr3K
LRj80uY8jEoOTa/S0qakR6EZl1jUdTF3oE0ekFaTRcKvPBvleALd7LYQkdWe0KHV
KOH1D87eDP/t8b/oFhOlxkVsA+4lvB3ZhThA45Hrr7iPKUjjrrPpSR38ZHsavpf2
H/SW0xpc9bRoGf26fd/5ubTP1x0CpfsBGTvSkJdR3fGMT1Eqptw/FbevberWWy4l
1TrcFq8di4qn5raC2RGsQzv3/NONwrlSqFzjKvAG5LSsCh8KpGg=
=T7kA
-END PGP SIGNATURE-

Accepted charliecloud 0.2.3-1 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 24 Apr 2018 21:22:33 +0200
Source: charliecloud
Binary: charliecloud charliecloud-doc
Architecture: source
Version: 0.2.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian HPC Team <debian-...@lists.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 charliecloud - user-defined software stacks (UDSS) for HPC centers
 charliecloud-doc - user-defined software stacks (UDSS) for HPC centers 
(documentatio
Closes: 888395
Changes:
 charliecloud (0.2.3-1) unstable; urgency=medium
 .
   [ Peter Wienemann ]
   * Restrict architecture to linux-any. Closes: #888395
   * Extend list of uploaders.
   * New upstream version 0.2.3.
   * Add man pages.
   * Display a warning if unprivileged user namespaces are disabled.
 .
   [ Lucas Nussbaum ]
   * Prepare changelog for upload.
Checksums-Sha1:
 d97b8f4e02ad3e9f65663c0b0006c04f0fe2c433 2125 charliecloud_0.2.3-1.dsc
 41a898ed3357e82ea9f5ddf7e5685974f0f53699 90810 charliecloud_0.2.3.orig.tar.gz
 6f7bfc7d3c8006679960ca2bbc4ae34631e42ac5 4500 
charliecloud_0.2.3-1.debian.tar.xz
 a26ae5204354f5d8ebdc6d025ccc715850b13ab7 7141 
charliecloud_0.2.3-1_source.buildinfo
Checksums-Sha256:
 b0c7f8fe4859f5699b9c9d6b3ea3233248f3a7a7b9a8cae7d4dd80332a490320 2125 
charliecloud_0.2.3-1.dsc
 40ce740e4fbf77c3f0ca7d5f63cfa5bd3b3cad5529d79b565748016218af6942 90810 
charliecloud_0.2.3.orig.tar.gz
 8606a9d73fb3b56e23b30409c45c83e620abb9bf729c1b5cfb175a279e1a52a6 4500 
charliecloud_0.2.3-1.debian.tar.xz
 824c74ab88a7bbe6e255ab60de3096bd810e9d4632505d21228874d1e0061cd6 7141 
charliecloud_0.2.3-1_source.buildinfo
Files:
 f08712d3e871b7fdd8c50356e5570d76 2125 admin optional charliecloud_0.2.3-1.dsc
 18cb2bde4b6f73c9aa2900d89448d2e4 90810 admin optional 
charliecloud_0.2.3.orig.tar.gz
 e154e2520c9a9a743588a370e10f0955 4500 admin optional 
charliecloud_0.2.3-1.debian.tar.xz
 b851f4ac32e6cf70fae4af990ada42ba 7141 admin optional 
charliecloud_0.2.3-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlrfhEQACgkQORS1MvTf
vplM3w//dQFqp1gkDPh+Ymzi2xFbxnWYOcW6gkbDcWavd6Tx87ovR6gCMTe17nNY
wtRBELFv2urLG08PutUEoZw8Cp9N78MtJx+0Bz7JoNHlvc7zwUHa7EUlMTDN5+Ra
hcKYV+JNAdlEcOxMu7YcAf068heR6P2KpfKQupi9L5GXrWcLbuXjRmtxhrQulNRE
zs3ylx9w8R6/izyqDBQL+R4Afzqz6iEpoItlDtBoKg7NbFJcOZqh12J9BmQVpvpj
YnBP0qVnaUg3PqujaWWvBDYBW1MdCyXx9jXDEGqKzZwy7ZEVZmfSGuGV20iz30EP
+mT3al6TxCltgbKXEuEivvWQQOI++Vd3090gbixd6taEGQVYpXRvsgh0Ct8tYOsQ
dlnCbKg2G58Fn+yigMjKPypDERi5OyiNExG+jh5Q7oAJvWlID7xkvovyQYxFCn9k
NhCYKgkzXPc7iHjX6z+08Cfr6YB8dg+bTbX7oB5ijQz/XVDshULTref6oVxVKbS8
yrDpzkOAPB7rNj88FsuxLgbfrdjKdK15gs1M8hpON0pxOHCpSG7kK1tSOqUaHdd+
N2wW9okraDHYJewi1RPOj8Yy8bLRusCYHWOYdo4h+4Ab1E8JYl4IRJ5iIdpSyhbB
fLikAOaDtLWZW2irj26QPbxvZwNkvPEIDSc2iQTFJlw7mogdZ0g=
=Eldz
-END PGP SIGNATURE-

"my package" vs "a package I maintain"

[Lucas Nussbaum]

Hi,

On 16/04/18 at 08:28 +0800, Rolf Leggewie wrote:
> Lucas and Atheros hijacked my package [...]

I know I'm late to the thread, but I wanted to make another point.

You write "my package". I think that as Debian maintainers, we should
try to avoid talking about "*my* package", but rather use e.g. "a
package I maintain inside Debian", "a package I take care of", etc.

That's more convoluted, but I think that it does a better job at
conveying that we are not owners of the packages we maintain, but rather
that we are taking care of a small part of a greater whole, governed by
rules and processes that enable it to be resilient to maintainers being
away/busy or leaving the project, or to technical disagreements. And
actually many of the hardest things we have done over the years have
been about building those balanced rules and processes, maybe more than
solving technical issues.

And note that it's also why we have rules or strong recommendations
such as using Debian infrastructure to maintain Debian packages, and
thus why you should not be using GitHub for the packages you maintain.

Lucas

Re: Auto-update for sid? Auto-backport?

[Lucas Nussbaum]

On 15/11/17 at 16:43 +0100, Steffen Möller wrote:
> Hello,
> 
> my QA page or our blend's task page (like
> https://blends.debian.org/med/tasks/bio-ngs) regularly informs me about
> updates that should be performed to packages I alone maintain or (more
> likely) with the help of my blend. The updates are often (but now
> always, admittedly) easy to do.
> 
> I would really like to see updates performed in some automated fashion.
> Maybe into a different section of Debian like sid-auto? The problem with
> that obviously is the missing scrutiny by the human maintainer, so it
> cannot go straight into sid. Or can it? Maybe with an auto-created bug
> report against the package so it does not auto-migrate into testing?
> 
> A similar situation I see with backports. Most commonly all that is
> needed is a recompilation. Would an automation of that process be
> acceptable? Would it be acceptable for packages that offer some means of
> automated testing and are in backports already?

Hi,

FYI: I proposed a GSOC project to play with some aspects of the above
ideas:
https://wiki.debian.org/SummerOfCode2018/Projects/AutomaticPackagesForEverything

Co-mentors welcomed (as well as applicants of course)!

Lucas

Accepted charliecloud 0.2.3~git20171120.1a5609e-2 (source amd64 all) into unstable, unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sun, 07 Jan 2018 16:56:19 +0100
Source: charliecloud
Binary: charliecloud charliecloud-doc
Architecture: source amd64 all
Version: 0.2.3~git20171120.1a5609e-2
Distribution: unstable
Urgency: medium
Maintainer: Debian HPC Team <debian-...@lists.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 charliecloud - user-defined software stacks (UDSS) for HPC centers
 charliecloud-doc - user-defined software stacks (UDSS) for HPC centers 
(documentatio
Changes:
 charliecloud (0.2.3~git20171120.1a5609e-2) unstable; urgency=medium
 .
   * Switch Maintainer to Debian HPC team
Checksums-Sha1:
 20b00ba91167158de4e9febb51fbec8c5c56a33b 2196 
charliecloud_0.2.3~git20171120.1a5609e-2.dsc
 a58834962dde698cccfbd174e02f1c79e7d3c0a0 100321 
charliecloud_0.2.3~git20171120.1a5609e.orig.tar.gz
 a818a107b60e96ae34f57c1b31a3684410446085 3544 
charliecloud_0.2.3~git20171120.1a5609e-2.debian.tar.xz
 67497cfb6d99f907a168594ee2db60f688cbc635 20596 
charliecloud-dbgsym_0.2.3~git20171120.1a5609e-2_amd64.deb
 9bd7cc1d52f2826d0f02ec12daea291bbc9a9c5c 1411120 
charliecloud-doc_0.2.3~git20171120.1a5609e-2_all.deb
 ae9ee4c99358966d8d77e965038a8e71c1474a2b 7743 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.buildinfo
 f01535ed2d6e5d98574da68d613a586bd9ce462d 15084 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.deb
Checksums-Sha256:
 72176e1ba9ebde5c61fda83d7c1c14a5a8b0fba72a8bb49c7ddc71fdb169f6f5 2196 
charliecloud_0.2.3~git20171120.1a5609e-2.dsc
 597c84a876f8a1ce2d947fdbe5813f8c0573a3524dd32727c9b79f07c3e012d2 100321 
charliecloud_0.2.3~git20171120.1a5609e.orig.tar.gz
 f2028814e74017baa8e54d70849b668c61b65608aa779a59cab64cb5043a8151 3544 
charliecloud_0.2.3~git20171120.1a5609e-2.debian.tar.xz
 70b19db30f3bc9ca4648810d776639f7d478cd2cd859415a29141ae46795 20596 
charliecloud-dbgsym_0.2.3~git20171120.1a5609e-2_amd64.deb
 7edbe841abad2d95b50b21be976ea9e0389172647163fc43a967f9e035b38534 1411120 
charliecloud-doc_0.2.3~git20171120.1a5609e-2_all.deb
 de6de1807b8115546d2050be926d221ee7c6cfcf0fba4fba4c55b03799f3d1b6 7743 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.buildinfo
 770a412d7f2948c88f6a98d99202fc2dc361ba91cd9e8c82182e1e6d2be8aff4 15084 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.deb
Files:
 57da15bd26629f459dde8ed64e5959af 2196 admin optional 
charliecloud_0.2.3~git20171120.1a5609e-2.dsc
 1c34180084548bca798e1115029c0f77 100321 admin optional 
charliecloud_0.2.3~git20171120.1a5609e.orig.tar.gz
 14ee1bde3eea9e5fe1cf7844be9293f4 3544 admin optional 
charliecloud_0.2.3~git20171120.1a5609e-2.debian.tar.xz
 a39088c82de3e9adc2e3083b3c062382 20596 debug optional 
charliecloud-dbgsym_0.2.3~git20171120.1a5609e-2_amd64.deb
 38b91ec2827dff74c173ca05c55dfd11 1411120 doc optional 
charliecloud-doc_0.2.3~git20171120.1a5609e-2_all.deb
 4ec51efb3ca57280b57405881b460a63 7743 admin optional 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.buildinfo
 73820c75db1bb2063bc4b45e5a7be420 15084 admin optional 
charliecloud_0.2.3~git20171120.1a5609e-2_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlpSR78ACgkQORS1MvTf
vpnpXg/+K5dMQchenbBcrBnn3UL005+hdhRltkSF2Dcv7mc/O0mZ76WXG15Z0h5w
1r7/Brxuh3gEpEF7SHuPI88ELZ5+zxSlyJLsK2E+7jCWWelBBv5bW7mJRudPMY0m
NT21rjH0Q+tubBltBMNz7SWyYv8CEaKEAUIhmw3MmpkW9WOAXD/rIU0ZBYSukZQZ
pxVUKIMFzOoYjd1HkR/iTTZENu+JUR8NUqswn3olLVXglN/roTEcxI7ph3jFj5Fl
t2X3uMdJCQX69laAgpQOlAya0SuMTE+Il50QiPTvVU/XLYMXm7d+mgYMHbFsZKZF
U1WR7BXt7fC2kwvjlI+D2aYnNkL1e1RebAh+l3V8mje+QreUthRsXDowzG7BB3Yh
MX+shA6u+GRkxmWRK+NwtjDnflBRlGiJeCE+3iISnj5EzMXZ3if8cr9i3Ic6RmAw
o2ND0zmY34dk45/AR0ugNUV+ZWPq98OxlrckFfhx99Xe9gn45eNulzVxvb8SF+nK
KjomEeLu/yFpnHjOpY+cSsL7u2JzjgjVRFU0Y+pCdP9DSDwboFWsFhVK+5Nc9zlt
Vs2ouGcoK13bszZuvKxLmo92pcreJn7xLEC2lqmYuyFiFnXZHlnJF+ohNsf3XH4p
meB2l2irv7U7DvTNnHFz9P+lAIrg/P4om3RVekbQSecYUB43b9I=
=WYcv
-END PGP SIGNATURE-

Accepted taktuk 3.7.7-1 (source amd64 all) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 31 Oct 2017 11:34:02 +0100
Source: taktuk
Binary: taktuk libtaktuk3 libtaktuk-1-dev libtaktuk-perl
Architecture: source amd64 all
Version: 3.7.7-1
Distribution: unstable
Urgency: medium
Maintainer: Vincent Danjean <vdanj...@debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 libtaktuk-1-dev - C bindings for taktuk (development files)
 libtaktuk-perl - Perl bindings for taktuk
 libtaktuk3 - C bindings for taktuk
 taktuk - efficient, large scale, parallel remote execution of commands
Changes:
 taktuk (3.7.7-1) unstable; urgency=medium
 .
   * New upstream version 3.7.7
   * Refresh patch: 0002-Fix-some-typos-in-docs.patch
   * Bump Standards-Version to 4.1.1
Checksums-Sha1:
 e3cb546e3c3d8f8618aebd227684a33a3b380e7a 2128 taktuk_3.7.7-1.dsc
 305bc6102b13d760bc7c8d92445ed882e60edcc4 585990 taktuk_3.7.7.orig.tar.gz
 fde0cb17d455da157687dcc971a9b569a9bbcd7a 8100 taktuk_3.7.7-1.debian.tar.xz
 cc60bdac504433afcdf7fb7279306e59c48d4ead 16104 
libtaktuk-1-dev_3.7.7-1_amd64.deb
 a602c35aba24a9b127844f98ea957654fed66095 27108 libtaktuk-perl_3.7.7-1_all.deb
 bf1f1501842d5296a9dcadc06d6c5612f8429879 15360 
libtaktuk3-dbgsym_3.7.7-1_amd64.deb
 97b6c07e49129e7b6e72bc93166ebe4a722be1a3 14200 libtaktuk3_3.7.7-1_amd64.deb
 f1b7efa113acbab21dcd403a3fbc36c2f2e6a119 73872 taktuk_3.7.7-1_all.deb
 8bcd54bb5deef099779d0b9867c7d10926367bd9 6441 taktuk_3.7.7-1_amd64.buildinfo
Checksums-Sha256:
 af9b4d3d173a17bbffeeb61b284bb9548b4dc885105914536e7845f6b672957a 2128 
taktuk_3.7.7-1.dsc
 56a62cca92670674c194e4b59903e379ad0b1367cec78244641aa194e9fe893e 585990 
taktuk_3.7.7.orig.tar.gz
 1da388fff10ca2b8493f1d88ba75879a68e7642139b2d90b90fb57f2d8aab5cf 8100 
taktuk_3.7.7-1.debian.tar.xz
 c5bacd1e06c30082517c68bc6a8f4430777ba89b04bed21a487f2ca8bcbaaed5 16104 
libtaktuk-1-dev_3.7.7-1_amd64.deb
 6adf1d8f814442218e29543ef9900b4cb2a322a30a4788dcf8220a8eb79a14f7 27108 
libtaktuk-perl_3.7.7-1_all.deb
 8294b877ab64971376f9bbc9b39691c925de81bfcb90a710f85cc884a0a3dcad 15360 
libtaktuk3-dbgsym_3.7.7-1_amd64.deb
 0cbdcf2756a06fc4bb72995c0481eaf58354a946cfb6b0a31ebfc1e96ae9dfbd 14200 
libtaktuk3_3.7.7-1_amd64.deb
 732fd01bb217594408370ae95bc880e43519e8fd6fd6dfe8364ae5e6d509f195 73872 
taktuk_3.7.7-1_all.deb
 178b29ebee4d2bae893998867cd07fdb9d6241b9d929c5e7ec5c8eb4901b38bb 6441 
taktuk_3.7.7-1_amd64.buildinfo
Files:
 02e037079b05a153505490878889142b 2128 net optional taktuk_3.7.7-1.dsc
 9914d9c22245d888b1cb3f4a6d606cd2 585990 net optional taktuk_3.7.7.orig.tar.gz
 374d9a88d13250f082a551a08019b8ac 8100 net optional taktuk_3.7.7-1.debian.tar.xz
 56b317b4b163f142ba048db7833ff507 16104 libdevel optional 
libtaktuk-1-dev_3.7.7-1_amd64.deb
 2505daa229541148dab09b2574dda316 27108 perl optional 
libtaktuk-perl_3.7.7-1_all.deb
 f73e662435ab18fd484767749b1d08ff 15360 debug optional 
libtaktuk3-dbgsym_3.7.7-1_amd64.deb
 297f9721c3c36d97e8841e5d0c48bf80 14200 libs optional 
libtaktuk3_3.7.7-1_amd64.deb
 ac77735119d7bb46b201e20a7a7628fd 73872 net optional taktuk_3.7.7-1_all.deb
 85923a4d238d694bf82f569fe9cd5aa9 6441 net optional 
taktuk_3.7.7-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAln4VdoACgkQORS1MvTf
vplL6Q/+JcZvHloeUftzJIjAgsIzyr7nhTvKc2U79SJYq8Mn+flVVe1UuIpxmLD/
TuOeIYz1h18cxiNVN4kQE4U+I1mSeXbk0fkFSjmcQ3/QRYZ85L2fpA3UQNzCYu14
bNtX9llrO8j+66WmomJO929ni11b3O3uoP3+yG54aFt+981PlRunJUaBanaW08Au
Ox6ZBHTPC5y4fkXz0bnc5d5G89IW1hRBZrYwjwrhypLov4vvd8DdEoV4BwxwuKmw
3GzYa86+05p0abe75NPaU5ovzfEB5uKJotzSO+KdKg31FQZBIhM21eF5fYKcta3T
tMaabm0TSdsnGfDhTGukx8CqYFJ6pi3EQ/Umw816j279q3kRHPbaQr7h4Emtti9X
GIBSHuSwIbVmbTEiaCElWhfh300U4wPclXmBgIfseM4BxFume8sSZ8cM90dut0tb
61EhnAi+vPVTnTjvHiq4V2Zd9B4n+ANSfCbkQEP1JwZhDo1vzQ73LbVwyhwfmzCx
RVz4ltIybiig1knj1798GhAkMvANVriaEn6YF2u4a/xqeMy7d69FS8CVn5sSxypg
dZNuRqaxBDX/x3jQE6IUOLa2i0ZEwuKe7IFO2NtVUFB2EAAo2p4dXZpp9hBTsJ52
q5E/mMV4vMacHHBPuENyOIbSvm7/sstV8Bc9zLEgUMHWMZk/ve8=
=DwDw
-END PGP SIGNATURE-

Accepted ruby-rest-client 2.0.2-3 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 31 Oct 2017 11:21:55 +0100
Source: ruby-rest-client
Binary: ruby-rest-client
Architecture: source
Version: 2.0.2-3
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
<pkg-ruby-extras-maintain...@lists.alioth.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 ruby-rest-client - simple REST client for Ruby
Closes: 873576
Changes:
 ruby-rest-client (2.0.2-3) unstable; urgency=medium
 .
   * Add patches from Steve Langasek <steve.langa...@ubuntu.com> to fix
 network-dependent tests. Closes: 873576
 + proxy-proof-tests.patch
 + disable-network-tests.patch
Checksums-Sha1:
 fe7ef89002bf15824c64f3e34a9998f778ddcb9e 2283 ruby-rest-client_2.0.2-3.dsc
 e60a5f3c0d14e9aad61ae8f0ef37076e8a95401f 6500 
ruby-rest-client_2.0.2-3.debian.tar.xz
 9483078c8df0d26844b5818cfdecda73500fad8a 8156 
ruby-rest-client_2.0.2-3_source.buildinfo
Checksums-Sha256:
 85def6a16df49acfdccd6acbe36b8f5719e9ec9005306cbe13c450d3d233e530 2283 
ruby-rest-client_2.0.2-3.dsc
 ce64e9ba81d0e6bafe58add004fed9ef1029e3d6193a77c6315f828c36a32605 6500 
ruby-rest-client_2.0.2-3.debian.tar.xz
 3639d053de02ad9e6bcdac3d1bd8b2f7bfd5de01293fa60d824e178e9f5d3e99 8156 
ruby-rest-client_2.0.2-3_source.buildinfo
Files:
 04221a085f5facf2d91e73f03623ef96 2283 ruby optional 
ruby-rest-client_2.0.2-3.dsc
 dc21aeb428030d9e56d3eea78e91f3fe 6500 ruby optional 
ruby-rest-client_2.0.2-3.debian.tar.xz
 2491cfb3c3f2413dc7725374b83a9a1c 8156 ruby optional 
ruby-rest-client_2.0.2-3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAln4T1cACgkQORS1MvTf
vpmgvA//Wj3p1FGtnZdmGBl0NIURhG9vMS71xpTyXv5jkl37ObiwSrOyKi+dWlIT
yp+CkOOHudZlzEutwRfHbFFYSH6gsvJyLjWc40dLqQNJEQH99YQ8zDLjj7+Q1hZ+
cWgTxn/3uA7+N/851+FUDwOC9Ep72h2mL1epvRvi+mXgL/6unOFVum0GWXZSFR4Y
t0f+cOECIrWf8Zkb5I2lSxgDdIACoPV1176OhL0G/wiSNrEoQ5COYt2RbaBuNy4a
5jED/KvGnWEM+h8Ff0ZIke1+jqan0MRknTSw4BPc7PiRC/6MSEt9jr+ifi8kc4mS
nVsNCpF7UaqyKZVCDnv5lHnNe9sLDeISSEM1UUXg6Io2BRsrB5iCfzYjwb3S8lhW
nKi5GgXSxD8/b+aw3kP8J/aXifQ92Y7FnPQPzPAYt1bAkaAeS2l04nG4dc5VGPdl
dTmQDVKRBRja9oWFOVWZAySKZZ/L3E83GEN6U2iWf2QHRoD6jhr0+NEgKwqWS5zM
PL+9L5W0l4AEDegipEdlW8uM6CrsQc34m4WiBtS148DJg9aTXmwf2iHgQDwai3v0
RFTZ8B/lrSsuco53Vj+hWSTBK0900q5K4TEr0rXLvtry3Wpj3IaXpjDbKsSWY0Ms
UhB/QrzxPEFjxRck0d+tsUNB+M/x4O8tNkZtSl9ubVoL7HStQ1U=
=qqro
-END PGP SIGNATURE-

Accepted ocamlbricks 0.90+bzr456-1 (source amd64) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 30 Oct 2017 23:05:33 +0100
Source: ocamlbricks
Binary: libocamlbricks-ocaml-dev
Architecture: source amd64
Version: 0.90+bzr456-1
Distribution: unstable
Urgency: medium
Maintainer: Debian OCaml Maintainers <debian-ocaml-ma...@lists.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 libocamlbricks-ocaml-dev - Miscellaneous utility functions in OCaml for 
Marionnet
Closes: 876734
Changes:
 ocamlbricks (0.90+bzr456-1) unstable; urgency=medium
 .
   * Refresh patches.
   * Add ocamlbuild to build-depends
   * Run wrap-and-sort -a
   * New upstream version 0.90+bzr456
   * Add breaks on older marionnet
   * Bump debian/compat to 9
   * Bump Standards-version to 4.1.1. No changes needed.
   * Fix FTBFS. Closes: #876734
Checksums-Sha1:
 2eba9c4198ac707d8062a7e57af386530f6a1caf 2182 ocamlbricks_0.90+bzr456-1.dsc
 a9f96022243f8735e061192301efa28e1f799177 268438 
ocamlbricks_0.90+bzr456.orig.tar.gz
 cbffbb94ef27e4cfee713eaa74c9e3e5ebea8b1f 5432 
ocamlbricks_0.90+bzr456-1.debian.tar.xz
 f9c6f5ffc211fa17328a6f2533d3fcb31899c457 2432 
libocamlbricks-ocaml-dev-dbgsym_0.90+bzr456-1_amd64.deb
 6cf27f90bcf3a610880a617dd112d91e5e77a384 1668588 
libocamlbricks-ocaml-dev_0.90+bzr456-1_amd64.deb
 648243d5a58f0d52e6e56f864bea81e53edf1651 11691 
ocamlbricks_0.90+bzr456-1_amd64.buildinfo
Checksums-Sha256:
 84c5c4bf219465510b57506d368669a5c271d77d11e19bce1ea9df80874c291c 2182 
ocamlbricks_0.90+bzr456-1.dsc
 afbaa7503b85317a86665c0b330b6eb9f3e3b6c02d9b60542cdff5866911f253 268438 
ocamlbricks_0.90+bzr456.orig.tar.gz
 ef95ec3387ed6574e21f4d2c9e5c83d3421eedbd85eb307d168be5da9b446443 5432 
ocamlbricks_0.90+bzr456-1.debian.tar.xz
 afad45a7a541224146921dcd7ff40b39281e0f33099d9c5bbdd5ad14c1acbef2 2432 
libocamlbricks-ocaml-dev-dbgsym_0.90+bzr456-1_amd64.deb
 826ad76da63f01c14b992c607ca8e4577e2bc4b11667b703b16d85a04d6fd3a6 1668588 
libocamlbricks-ocaml-dev_0.90+bzr456-1_amd64.deb
 95c6e7083f986c5180f0c2fc7562cedf7124148739cf37ddf7174927b6cd815f 11691 
ocamlbricks_0.90+bzr456-1_amd64.buildinfo
Files:
 a3ea36b8ed9a425000f8939e2e358ad3 2182 ocaml optional 
ocamlbricks_0.90+bzr456-1.dsc
 dea5410e590b0751b14ed9b34c011009 268438 ocaml optional 
ocamlbricks_0.90+bzr456.orig.tar.gz
 1cc09356d04a3195527048d0176a7a26 5432 ocaml optional 
ocamlbricks_0.90+bzr456-1.debian.tar.xz
 f3414586f2d95a75b99969caae21443b 2432 debug optional 
libocamlbricks-ocaml-dev-dbgsym_0.90+bzr456-1_amd64.deb
 66f8aa12b84cd8484903e86cf0addd29 1668588 ocaml optional 
libocamlbricks-ocaml-dev_0.90+bzr456-1_amd64.deb
 4fa5e1caf9c9d0510e20c6abe939e1f4 11691 ocaml optional 
ocamlbricks_0.90+bzr456-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAln3p6QACgkQORS1MvTf
vpn7rg//ZBsQnSbB86/hM7HuN8f/h8TlmJtDzwQs1SpVBApbVRODTubTxDk3ero6
FTjp7ps1rNH9Y1WwbYBcsY3Rp+PKLEb//nu2NKY67uVgXnMCbOMWjxoO+J9lSzm8
BGPsCFsRAUlJaBg40L9cR3dI/eM3i579KST0R03dIYGhhp4laKnKI0dwVpFn9mic
ERmvaBSZIJCukCehqhxkrkaAV6zsmnd9qFm785xpu/eJ6qF84IqvjnRslIml6uuF
d8LnOiQfhbFfCw03U/EGtSD83U/0kyJmrK6SCIFh+8ZkgnvW18Pk9XS8zrsyQdQ6
5kNPAd/1yLK77c3a9/2qt0BnQQgUi64aJVKVtvZlVoiImXdpo4SSqEPk86ij2B8Q
hM8vBj9VFQpC2MgX2MYiv+hw3fIw8wIufkRyk2pyevTFEhd0jUKJp/BbE91rSFcS
Z26Uh3X3tk7NO8oxbsnUIBkT3mKndHBOVbESQ3XiSwjT3I/vY5QZcTia4VnutKxT
a+x5IT5H+5sGQoVplaD3AW6FB0IsbHZCNm114tDMlElQdcHACWbs9dMA62qe+Cl/
BqEYsAQJfk8iiaIL3oDaEgmQV6IWynNak4g9k2hyVqIfJ2Bb/NUfG9x7gz1l3J5i
IxkUUYvaQ8P3n46imOAJW2h1EePq7eTT8ZgFOHRicDZavVqKldw=
=V/1q
-END PGP SIGNATURE-

Accepted marionnet 0.90.6+bzr508-1 (source amd64) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 30 Oct 2017 23:22:35 +0100
Source: marionnet
Binary: marionnet
Architecture: source amd64
Version: 0.90.6+bzr508-1
Distribution: unstable
Urgency: medium
Maintainer: Debian OCaml Maintainers <debian-ocaml-ma...@lists.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 marionnet  - Virtual network laboratory
Closes: 818952 866606 866607
Changes:
 marionnet (0.90.6+bzr508-1) unstable; urgency=medium
 .
   * New upstream version 0.90.6+bzr508
   * Add stricter dep on ocamlbricks.
   * Add symlink to port-helper in $PATH.
   * Add xterm to Depends. Closes: #866606
   * Mention Multiarch in README.Debian. Closes: #866607
   * Add patch from ceridwen.debian.b...@gmail.com to support building 
reproducibly. Closes: #818952
   * Remove obsolete b-dep on dh-systemd
   * Bump debian/compat to 9
   * Bump Standards-version to 4.1.1. No changes needed.
   * Remove duplicate license in debian/copyright
   * Run wrap-and-sort -a
Checksums-Sha1:
 b354d1d71c2a7021cfb887988ea0ac36afbd8dfa 2230 marionnet_0.90.6+bzr508-1.dsc
 4c34183c4f7639c40ab1a2cd2df7b155fbae4642 3417722 
marionnet_0.90.6+bzr508.orig.tar.gz
 862a6ac702ad69c3b80c816afe9540d3b97594ab 9276 
marionnet_0.90.6+bzr508-1.debian.tar.xz
 b9ff22395df9f7daf6eee7c47374188f581ad5cc 744224 
marionnet-dbgsym_0.90.6+bzr508-1_amd64.deb
 96a4219907901487f09a129b811441f95b10d072 11752 
marionnet_0.90.6+bzr508-1_amd64.buildinfo
 8438da8a26b25213c4b6d59b34f455b9428aef11 3350904 
marionnet_0.90.6+bzr508-1_amd64.deb
Checksums-Sha256:
 6cd33e4fb75c11dbe64e6ad3eb6d8abd1fd6ebc451a4e20275a335f7638938b3 2230 
marionnet_0.90.6+bzr508-1.dsc
 7ecee266f3931d3b2d91bac1c93540d24c208a88d73641f3060ca9e42c02e93b 3417722 
marionnet_0.90.6+bzr508.orig.tar.gz
 47203ea9cf5acdf58bcf23f40713f141f8dc17fcdc3f7fd9fb9f355aec1dba65 9276 
marionnet_0.90.6+bzr508-1.debian.tar.xz
 21700c998338a5ca36e0f66d6b0f1170d0751cd6c61edddebeb62a010d37e8b7 744224 
marionnet-dbgsym_0.90.6+bzr508-1_amd64.deb
 d899eb394a9cdb67a86094545af1b344fd4862b99163f98c69626a55f94adfa3 11752 
marionnet_0.90.6+bzr508-1_amd64.buildinfo
 fb72aa62996de0f7708970fd2d6edd6e7ac8133c073ea53355e5e98f1271a091 3350904 
marionnet_0.90.6+bzr508-1_amd64.deb
Files:
 e628fcc680d791a50d487c0fc9ff8623 2230 net extra marionnet_0.90.6+bzr508-1.dsc
 bd9383982c600cabc06c040c011c6921 3417722 net extra 
marionnet_0.90.6+bzr508.orig.tar.gz
 2f2a2dfd49777233c90158b826588ad2 9276 net extra 
marionnet_0.90.6+bzr508-1.debian.tar.xz
 922f3d47a31b7d1d761eb8bf8d82386b 744224 debug optional 
marionnet-dbgsym_0.90.6+bzr508-1_amd64.deb
 3d4a91f8c1939ddb53dde4902f8aab5c 11752 net extra 
marionnet_0.90.6+bzr508-1_amd64.buildinfo
 0c9fa6d8c76aac4d77d3b7df84609be3 3350904 net extra 
marionnet_0.90.6+bzr508-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAln3p24ACgkQORS1MvTf
vpl1Vw//Y+evuMWX4adqOcs7A5vdI2joqjX7Eu6eh0KGoCm90i9XAKA2kLQOkS0p
3ba6St5I1NQNoBsKsR6D9WECkSfLXE9f/nuhE1DDUCx+FzYXsnt1qtbMTybEGh8T
6nzSsjRylFWWM9CQzMtU7bPHh7o1Ux+BnB6kfvkUe5JTZ3gB7iLA1GjQVn4XD0QX
buVPCSqw+8ZrivEfXtdzDIRon5JC6LfAyEZOUHbKjb009hOFw12e/OtuVScExdZP
ou1wgljw4rPc7olU5t52fgcZYJ0K8D7oNeP0hwOBkLR3Y/nL5mbO5wBKzpPUvaP/
//fav3zEpFGKXOjIbzDGjHGeDQJ5jefv3QdoJ3viV5VorXIvyQHWj7A0gJY+DwIe
JTcK07S/7Ka1pjQb9c8c3vF+6cnbD3oMIoq/oaFX5jggngv/7STDt04TfC7PKSMq
EpVt4z8aEcQiYS+AM5HYYm9Hv5OSL8JNwg81ie8wefD9QX64ArL7nLTeZT1R2y7K
fRq1im5Vr4jHpkiiiXoT95fsRC7bYalEWnYgxRiWJ3LbKj0udJHPwZu/RQImc4eM
wFmMWccOM1aRG4cEITT/sci5GAu0VL13GtUEyvdHvYj07chJXIYp/2/1aXmQ6PFk
a1Yq+lBLxSh8jds/V9PxlLIDdD54OaFT8OKJMyMvbNxNDXLbyp8=
=8+zG
-END PGP SIGNATURE-

Accepted vmtouch 1.3.0-1 (source amd64) into unstable, unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Mon, 07 Aug 2017 10:16:28 -0400
Source: vmtouch
Binary: vmtouch
Architecture: source amd64
Version: 1.3.0-1
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum <lu...@debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 vmtouch- Portable file system cache diagnostics and control
Closes: 871268
Changes:
 vmtouch (1.3.0-1) unstable; urgency=medium
 .
   * Initial upload to Debian, based heavily on upstream's packaging work.
 Closes: #871268
Checksums-Sha1:
 f3a0e98957ad3500e12d672d4e730e351c023835 1926 vmtouch_1.3.0-1.dsc
 6cf9d82d19e06610e79fbd1dcc38b882c2f270c4 18733 vmtouch_1.3.0.orig.tar.gz
 a54297b45083169f263d28fee2524102798b125f 3588 vmtouch_1.3.0-1.debian.tar.xz
 4bd632f6deba34226eecaa68321210ea9b659799 19978 vmtouch-dbgsym_1.3.0-1_amd64.deb
 9b8f2f727c47020a40c1ae1e1761e197b3070812 5560 vmtouch_1.3.0-1_amd64.buildinfo
 fd3850ac9d4a58d0b03192affaf86f0457209bd9 21508 vmtouch_1.3.0-1_amd64.deb
Checksums-Sha256:
 b55b908caba3e5c24907639ed235acdf47912e9dfa7aee9c97fb4bde2654c835 1926 
vmtouch_1.3.0-1.dsc
 4615980b8f824c8eb164e50ec0880bcb71591f4e3989a6075e5a3e2efd122ceb 18733 
vmtouch_1.3.0.orig.tar.gz
 cebdef0ba795465ddd499d362c0a160ce0ae1434b3ff0d299ff3de9203677252 3588 
vmtouch_1.3.0-1.debian.tar.xz
 a8cb26ace2e52cdf68400940c569ad82446ff124124c2ae0c37c505b1ba7429e 19978 
vmtouch-dbgsym_1.3.0-1_amd64.deb
 79e15024eaa96568f0857adbd3214955df8a007bfed64eebedd7edf11a6a28c8 5560 
vmtouch_1.3.0-1_amd64.buildinfo
 a29b80b4ab161803e067e9d2a1aec52b9e618fc18f52581d2fb1357968f3d79a 21508 
vmtouch_1.3.0-1_amd64.deb
Files:
 6dacdb86034390ee372b1789bc057b20 1926 admin optional vmtouch_1.3.0-1.dsc
 deaa76af2cadfde293547f1940208b0f 18733 admin optional vmtouch_1.3.0.orig.tar.gz
 4d7f1c5ecae1bedc396b4887f82d6248 3588 admin optional 
vmtouch_1.3.0-1.debian.tar.xz
 22ed2cb18df9fa0ace9afba2f0d8400d 19978 debug extra 
vmtouch-dbgsym_1.3.0-1_amd64.deb
 9058d1824e2a4ca97475e288f26733b6 5560 admin optional 
vmtouch_1.3.0-1_amd64.buildinfo
 7a9bc595d239900ebf1eff95a8fee16b 21508 admin optional vmtouch_1.3.0-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlmIdsoACgkQORS1MvTf
vploMRAAjdjm7Q7Wbe6z7cjaOcSUvSs3HXLmtRfb0mhiUM2ctUYn99F+HEUuKf4W
ugGC2tY2x7iAo2sq1E99O7+4XRz9OrMfO5oKIPkGvnY8U/hTm9sfDFa6inBLEEXE
SRyw8t9jCZAeVKD8IylK5OnUpc+YqslXrNrMDfyQxV1hNKNK1ozlF8gymrGQawZ0
ruE2d6bC1YZ2J1Jg1FB04uPmuWbCc340tOd2Dhm6SqOuWuqjwKfDh8FTgz+p3wlO
kA/7hZG1deN+pf+78CQJ7vxsZjhT6Y+qxxHkJ8jCKOmsYLfRaczP86d7VkfBGV3Y
pAbrciMJwFvZvqkg3YGqUfB60OJc+5eOTFASjVTXIwM670kRYTVCVNZs86i9OVjk
z9McCbXpI2gRlomACJa16FG/8pTZG3DGhNEbxE0lfx1Nnr3R3uFtI5C0SNKYq3Ab
HY1XWgM/Gq0KfQDIPgxEkx/9t8L5I8NmZg7bwcEcbtTGQzfNbQWpojdtHAL2IsxV
v7S1nkYBE+5CvNxcO2x3q1UTwFg6djjjlRB/vuYz1zybuJbx1AoRTNVbK9YSCPSm
s+2DwrJ/20i7GP9YjvgqIYKZI4pQEIea8jJ0bSOhmzjlZpvvcN8LQPTriY/aDfgd
r00h1Rcp+B8Se1sdWnAMx7G0fQj0RqPHPs70R/jXzs4iJu9fa5c=
=64R0
-END PGP SIGNATURE-

Accepted packaging-tutorial 0.21 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Tue, 15 Aug 2017 12:06:37 +0200
Source: packaging-tutorial
Binary: packaging-tutorial
Architecture: source
Version: 0.21
Distribution: unstable
Urgency: medium
Maintainer: Lucas Nussbaum <lu...@debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 packaging-tutorial - introduction to Debian packaging
Closes: 871357
Changes:
 packaging-tutorial (0.21) unstable; urgency=medium
 .
   * Point to Guide for Debian Maintainers.
   * Fixes "FTBFS: Unescaped left brace in regex is illegal here in regex":
 escape braces in addendums. (Closes: #871357)
 Patch from gregor herrmann <gre...@debian.org>
Checksums-Sha1:
 8e036766d016a6166327fc167da6d85be1791284 1944 packaging-tutorial_0.21.dsc
 5a141e3f929090f53fc3612da18e3a2e5932fc5c 276032 packaging-tutorial_0.21.tar.xz
 56e07cbfb168524ed9e37b4262475d9f45d17888 10700 
packaging-tutorial_0.21_source.buildinfo
Checksums-Sha256:
 751ec4c454fa6f2e8fa55693d3db2baa72ff46e0960c9302c4b9d7c099e080de 1944 
packaging-tutorial_0.21.dsc
 11d886bae0078b369e36bb31bf8327ba038a5da827f18adaa8a72ea7ca4fbaf8 276032 
packaging-tutorial_0.21.tar.xz
 334471930429e5c49bde32a266ca179b08455cd425856dc0546aea4a509c411d 10700 
packaging-tutorial_0.21_source.buildinfo
Files:
 6e30f280eb6799769c4d1945ea178fe7 1944 doc extra packaging-tutorial_0.21.dsc
 b2d3ae58d33827d1fb5295c7b532911a 276032 doc extra 
packaging-tutorial_0.21.tar.xz
 6bbf25d505d1e20d775d129029f371f5 10700 doc extra 
packaging-tutorial_0.21_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAlmSzw8ACgkQORS1MvTf
vpkIHhAAjWTL2R8tjImQu3fVOSQkvzUpvjkUzzQzU+O8WkGV2CP7SYW9LYnMnpKH
fzisMyuQoTyslbKjUTHKvR1VBrgRUAaySvyKiD2VFcZkSehjr+rFR1b2IKW6NhAx
sQaYNZ63Z7NUE1wpJZUeQQsdZMoqhi3e4pNPXP12VX0VAHGMe2hWz/EIlJeFPQ4O
4yLEKaiJOo6hntTVzOFCV2acbnX+/FcEc+X2A6QzDCjU5jWj0xa6+ceF1Rok4TR1
JLyIDPnoyeeBd1o9lg3NEULw1TX2Vv98dZRW+NanSqd07aVS6sySwNtnX1u1uA5Y
isOe7KNVuxZCHnn3tREcUHpL83NcnZsLDnRoxKS65vO3JuV7NXB4q3+HqRD8EzLt
qvkklbEBJOdpqLzTe0ojzYj+yBgNcgmLM9LZfmrNN2CHQeEhnGG69nJs6WZjMOwR
vwS3UHZMnofLi4YdiG8QvofqCSdnlSpJnGK1svgLXEucnKSKQZvqhdYydlKWkxL5
VlFlaLUlOwxRhnznQ5gcvB7V2lbTNf0bjwsjegEh2CLa/wCrJbJCqsOMp3l7g1aw
A0EP1UUUyfra7bDK7IHV/fCR+napyqxBAg9V0Gv1w/YAKcCMBuWxilVdU9FOdlpH
h2eHgcA6iJyAUyi78cRc75NJ6OI2OSXeqDAx1ix+OxGb9CkAwQs=
=jrmB
-END PGP SIGNATURE-

Bug#871268: ITP: vmtouch -- Portable file system cache diagnostics and control

[Lucas Nussbaum]

Package: wnpp
Severity: wishlist
Owner: Lucas Nussbaum <lu...@debian.org>

* Package name: vmtouch
  Version : 1.3.0
  Upstream Author : Doug Hoyte <d...@hcsw.org>
* URL : https://hoytech.com/vmtouch/
* License : BSD-3-clause
  Programming Lang: C
  Description : Portable file system cache diagnostics and control

vmtouch is a tool for learning about and controlling the file system cache of
unix and unix-like systems. It can discover which files the OS is caching, tell
the OS to cache or evict some files or regions of files, lock files into memory
so the OS won't evict them, and more.

Accepted ruby-minitest 5.10.3-1 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 26 Jul 2017 09:11:21 +0200
Source: ruby-minitest
Binary: ruby-minitest
Architecture: source
Version: 5.10.3-1
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
<pkg-ruby-extras-maintain...@lists.alioth.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 ruby-minitest - Ruby test tools supporting TDD, BDD, mocking, and benchmarking
Changes:
 ruby-minitest (5.10.3-1) unstable; urgency=medium
 .
   * New upstream version 5.10.3.
   * Bump Standards-Version to 4.0.0. No changes needed.
Checksums-Sha1:
 80b33686b32a72c7c6a9de6df21a26868bc6c23a 2108 ruby-minitest_5.10.3-1.dsc
 4bd6c4e7f5815841427edf1bf9bf891af9f34006 71985 ruby-minitest_5.10.3.orig.tar.gz
 6eb8c82f96611f17530ffcde02e9e80a9e82e396 5896 
ruby-minitest_5.10.3-1.debian.tar.xz
 f975854bdae121a7f826917e184a9a8964de0ecb 6425 
ruby-minitest_5.10.3-1_source.buildinfo
Checksums-Sha256:
 1ac69ced508ff381548389c70722e559855132984d2f042eae0a83663ee37cb9 2108 
ruby-minitest_5.10.3-1.dsc
 f3943005d5e3f501dfb8598ca78cf472456b3112fa7c725b4f72737b7ab6327d 71985 
ruby-minitest_5.10.3.orig.tar.gz
 fd1bc4d622969d0ceb32115d33b562cd5f99a5230f5b9541d9bc4a04c05ceb6c 5896 
ruby-minitest_5.10.3-1.debian.tar.xz
 0b139ded2edc7dca917b3b779e17beb101b1a46818f6d2526ef682afb74aa799 6425 
ruby-minitest_5.10.3-1_source.buildinfo
Files:
 bd77927d14dcaee2955fb08c78c8510b 2108 ruby optional ruby-minitest_5.10.3-1.dsc
 a546562f7e33d90266abf8adfd46725a 71985 ruby optional 
ruby-minitest_5.10.3.orig.tar.gz
 77c252bbe07d67142cffd4b7f33c1349 5896 ruby optional 
ruby-minitest_5.10.3-1.debian.tar.xz
 c4a11b6ba54e6ff3b3a0158de2a862f2 6425 ruby optional 
ruby-minitest_5.10.3-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAll4QV4ACgkQORS1MvTf
vpnIRQ/9FvhN2SoK+TVRyq4p2+fxrabvmOYvLGWGfkSiuRcKPMWUxPQOptZhna5s
5t3lYta079lscuFwTzzNDzqcLQwVN+lkQZsc0FfQCU2PF8Vgal8PlpEhp51lHOqU
+k090CmqRVR+fkRW8p1KQ8CJWBtCLEtVi2bcwZmktLUdU+Zumo0Oj/xLZAvoVS8Y
Ne6/oo/0oWL0ShB0MM9Wwjs/nbNyZ97Dwx5VlmZMebHDMQu10dV44OOMV3dBVWwN
YsMfbU8TIUNEthF4YLZBBc0EX9KbrOvJ21GhKzKK8KvkWep8vHxg1FLFuHPxwjn1
eGJcZf/poIeT21542qouqxH6DkQzMhOEC6mlNSws+PFyV7ZQgt2xc2TGphcJPP57
QG/FgCTrFIAjyiCqpoQMEXpLHdENrjvdCOuy3VP+vIZ/rzHqWYGHSkF9vV5WiKzs
wNqkJeXThZs2YEHkV2gYaMeFgx+xHw+q42XeQTPOwnZUMmCL0ViZ3G32nKMi1qtM
EuGov0usUuhZBHZ8sfo2I9yhh9ztoEN23JboJzK0/LB0pZiqzTUHl8aNtcrGale4
4aDpn4Lr3htd0xKfUrnMaxfYqLxXovu3RwHqg1oTMKMxxzimFj98kzPvTNXCt2Hc
WUQ4Ql5K4GmNF1dIBELtCN5UHseJUtzZxaU+VwGow3Gl3lZH5Xg=
=nMzO
-END PGP SIGNATURE-

Accepted ruby-rest-client 2.0.2-2 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 26 Jul 2017 08:24:23 +0200
Source: ruby-rest-client
Binary: ruby-rest-client
Architecture: source
Version: 2.0.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian Ruby Extras Maintainers 
<pkg-ruby-extras-maintain...@lists.alioth.debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 ruby-rest-client - simple REST client for Ruby
Changes:
 ruby-rest-client (2.0.2-2) unstable; urgency=medium
 .
   [ Antonio Terceiro ]
   * Team upload.
   * Specify which gemspec to use via debian/gemspec (requires gem2deb >= 0.35)
Checksums-Sha1:
 9dc960dc503b697e1f1fc7cda1d0436fc51b9453 2283 ruby-rest-client_2.0.2-2.dsc
 33d7d21754a85d9189e7fe700162f01bfdfa5e44 5452 
ruby-rest-client_2.0.2-2.debian.tar.xz
 60683ac86e0e1ac34662396db7af1ee2ef71fcc0 8019 
ruby-rest-client_2.0.2-2_source.buildinfo
Checksums-Sha256:
 aafafab404f9d7572fd830527400619fc47738d26f34ab73cdadb058a24257fe 2283 
ruby-rest-client_2.0.2-2.dsc
 334114423d0deca8a45187bee3c5f910632d962cbd0e9c93430529df417f8366 5452 
ruby-rest-client_2.0.2-2.debian.tar.xz
 f61b546169d1281637d8ee1f69fbeeded4cdcbc1b41bb2f8542e8287f7591de4 8019 
ruby-rest-client_2.0.2-2_source.buildinfo
Files:
 b219837b0ae78c45bc5eb2d6432ae22f 2283 ruby optional 
ruby-rest-client_2.0.2-2.dsc
 c807ae8250356a09e36b22fb9512e8bd 5452 ruby optional 
ruby-rest-client_2.0.2-2.debian.tar.xz
 7efa69e6e87a2246e04b85b0b7fd0e08 8019 ruby optional 
ruby-rest-client_2.0.2-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAll4OPwACgkQORS1MvTf
vpkDihAAp+h9hI0R5yij3zFJWsdUebrkoam/iZaoSXDWRbq9m4KDk/JrtTNJBkzA
QYyk1tLWKsU/QdwgLKUf74aYXFeGmugDFKtw7DhF2FxzKnhLSMr7htW8V2mKqNuD
MTLDqN8+5lF/yp/dQOXCC9Ucvcx8Jye2cCVYrlFBecEJB673bQmaTXcX15HYmDoe
ao5PpoJauiTz6wrUk/g3wT6ic9HuuPFT0B0q9J6n5oYb0znc5v9LLCYrZqEFn390
IjTci+nsrLgoFyXjw5liRjlJPqKgLmKqZSxbwBFCYLgUgEt79ozGojhLlmlIX/BQ
S7HkrJb7O/UW/b1wz/jUAtQg9ADMc45bnOdjQzj6IjFy6eX3FdWUAghgrkLdkp+8
5POaCC4+jcAgVqPGyJGUmsMfnolsRVwWza6I399imR49ifq5XTskilDC8g6suqPG
J98nBnTtttPuPNyn9VcLdxs6HF3dtnnLcw1fIMAqa+znVQeHTagVHXvBZUU9b+Ya
FOy0r3I4zqoQGqF9GHzTs3IC1p6oCTujXk7I4wIXTz2gj7PbiRz6lTuWsqzDUa6q
2YfGWgWJddcNaT/yo56PiQNfa36sVwNV8a/BiAiqVQQSM9XN/n03XeH3hFb4nM9e
ooKKzrDYvDV3Hklc6hs+YvaviZMcMqADifx5h57x9bjMogb3s1w=
=C9S9
-END PGP SIGNATURE-

Accepted taktuk 3.7.6-2 (source) into unstable

[Lucas Nussbaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 26 Jul 2017 08:15:39 +0200
Source: taktuk
Binary: taktuk libtaktuk3 libtaktuk-1-dev libtaktuk-perl
Architecture: source
Version: 3.7.6-2
Distribution: unstable
Urgency: medium
Maintainer: Vincent Danjean <vdanj...@debian.org>
Changed-By: Lucas Nussbaum <lu...@debian.org>
Description:
 libtaktuk-1-dev - C bindings for taktuk (development files)
 libtaktuk-perl - Perl bindings for taktuk
 libtaktuk3 - C bindings for taktuk
 taktuk - efficient, large scale, parallel remote execution of commands
Changes:
 taktuk (3.7.6-2) unstable; urgency=medium
 .
   * Fix VCS fields to use secure URIs
   * Bump Standards-Version to 4.0.0
   * Add patch 0002-Fix-some-typos-in-docs.patch
   * Add patch metadata in force-perl-directories.diff
Checksums-Sha1:
 2d65939fb9e7ffea89dfeab6b58833538f6c6c3e 2128 taktuk_3.7.6-2.dsc
 2717a11afd0313f2c598fc4c9db412c08fa26e02 8228 taktuk_3.7.6-2.debian.tar.xz
 4320c15926afbc7e2ef5cb5c33aeb302879290ec 5338 taktuk_3.7.6-2_source.buildinfo
Checksums-Sha256:
 c5e985ad075a6a180491f6744dfda16a2b0bfe978d7aa810b018f2a846d0cbff 2128 
taktuk_3.7.6-2.dsc
 b09d1f646719c12d40691418c56184433fab5fca4b61b1de06d1693b3edde28b 8228 
taktuk_3.7.6-2.debian.tar.xz
 11e03002def4c86b0c85e3ffa7950c5a9334b596fa2ebdffd12f2bb3049879f6 5338 
taktuk_3.7.6-2_source.buildinfo
Files:
 cd2d29826aeaa5407d7b44bb776c4ea7 2128 net optional taktuk_3.7.6-2.dsc
 c8be4320e473e5c458ef549b384303f8 8228 net optional taktuk_3.7.6-2.debian.tar.xz
 9c8dc39f283ce25c8222f1ea5e169490 5338 net optional 
taktuk_3.7.6-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEE/t7ByzN7z1CfQ8IkORS1MvTfvpkFAll4NDkACgkQORS1MvTf
vpnE2w//Vzl04A1aCdYSpJnrwkWpxUwdfVRehR9beFQLQYjT/58a9ExlLLOFV7sc
ketNw4j1VPqT1UjfbswSTQrLLHEMWbys9p8j7Gb8EFj/ttD2DyI+M/fsHWMSLR0A
reI4cAGYLHTb5yNcZIBlgPE1tcRY+6WD/VgBg1ZVJp57Qq28nIcz3Q/GtFk3zNiZ
BJ+F5+DrZhpWAQktE94TfOFYb5HGG3sE9VQwNKJLmtqIgU58BzycR9ilDh3OxhAN
yWGy9hloWFVDuGro/ciVRQp36Gn5mKi3b12Jlrvw9iOD00Nn4Po2kPPJqY7Pf1sL
3wID8UPLm3pPeiS03vxCCiScwEBogQVhdWXWwNhcUN937u3Ec2znfiYZN1tOJlR3
s+3SQ7CNKUYYRD4A2uMElOFruermAVj20QN0eBaEtKPf191BdeOfu0QEmz6kdtYu
hIygf+lDnaR+CFeaB6k90jgaAP6JHa4qTwXO0ZINuDWOCNmRHY8sXIEk8qY5vyg+
7pnH93slOF98UueOQEoMNvsNEQnC88vgHEScN//qB/foS7F6XByzrAhXF71NReaD
FyVr/0mlRC/I9WlTuv6Nh0Kten8j9enQgNd3EIPd7Oaulz/65tENuDzzK7PBjfyp
773rRrQdkNH/nez8Zyow5N//PC4mV8o1in5xyjbHVC342LGmcOw=
=aMxn
-END PGP SIGNATURE-