Re: Validating tarballs against git repositories

[Antonio Russo]

There are many important and useful things here, but I want to address
this one point:

On 2024-03-30 00:29, Russ Allbery wrote:
> Antonio Russo  writes:
> 
>> If that's the case, could make those files at packaging time, analogous
>> to the DFSG-exclude stripping process?
> 
> If I have followed this all correctly, I believe that in this case the
> exploit is not in a build artifact.  It's in a very opaque source artifact
> that is different in the release tarball from the Git archive.  Assuming
> that I have that right, stripping build artifacts wouldn't have done
> anything about this exploit, but comparing Git and release tarballs would
> have.
> 
> I think you're here anticipating a *different* exploit that would be
> carried in build artifacts that Debian didn't remove and reconstruct, and
> that we want to remove those from our upstream source archives in order to
> ensure that we can't accidentally do that.

In this case, as Guillem walks through in a later email, build-to-host.m4
would be generated by autotools under different circumstances (not Debian
today, because of differences in versions).

I therefore consider that file a build artifact, perhaps incorrectly given
Simone's comment that autoreconf cannot be used to reliably re-bootstrap all
of these files.

I was (before Simone's point) arguing to ALWAYS re-bootstrap it all, or at
least always rebootstrap on a Debian machine.  A prerequisite to this, more
generally then, is that we can always rebootstrap from auditable source.

I appreciate that, unless that binary process happens reproducibly, that
just shifts the trustee to a different person, and doesn't actually address
this kind of carefully-orchestrated attack. I also appreciate the Ken
Thompson "trusting trust" nightmare scenario makes the compiler another
major issue.

What I'm hoping for is more limited: assume our existing infrastructure is
sound, but develop hygiene and tooling that prevents accepting binary and
build-artifact Trojans into Debian.

Best,
Antonio

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Validating tarballs against git repositories

[Antonio Russo]

On 2024-03-29 22:41, Guillem Jover wrote:
> Hi!
> 
> On Fri, 2024-03-29 at 18:21:27 -0600, Antonio Russo wrote:
>> This is a vector I've been somewhat paranoid about myself, and I
>> typically check the difference between git archive $TAG and the downloaded
>> tar, whenever I package things.  Obviously a backdoor could have been
>> inserted into the git repository directly, but there is a culture
>> surrounding good hygiene in commits: they ought to be small, focused,
>> and well described.
> 
> But the backdoor was in fact included in a git commit (it's hidden
> inside a test compressed file).
> 
> The part that was only present in the tarball was the code to extract
> and hook the inclusion of the backdoor via the build system.

Yes. The "test compressed file" needs to be massaged via:

  >  tr "\-_" " _\-" | xz -d

That code comes out of the m4 file, which is not present in git source
code.  I'm unaware at this point of any direct evidence that the git
source code alone is in any way dangerous (aside from the fact that we
cannot trust the developer at all!).

>> People are comfortable discussing and challenging
>> a commit that looks fishy, even if that commit is by the main developer
>> of a package.  I have been assuming tooling existed in package
>> maintainers' toolkits to verify the faithful reproduction of the
>> published git tag in the downloaded source tarball, beyond a signature
>> check by the upstream developer.  Apparently, this is not universal.
>>
>> Had tooling existed in Debian to automatically validate this faithful
>> reproduction, we might not have been exposed to this issue.
> 
> Given that the autogenerated stuff is not present in the git tree,
> a diff between tarball and git would always generate tons of delta,
> so this would not have helped.

I may not have been clear, but I'm suggesting scrubbing all the
autogenerated stuff, and comparing that against a similarly scrubbed
git tag contents.  (But you explain that this is problematic.)

>> Having done this myself, it has been my experience that many partial
>> build artifacts are captured in source tarballs that are not otherwise
>> maintained in the git repository.  For instance, in zfs (which I have
>> contributed to in the past), many automake files are regenerated.
>> (I do not believe that specific package is vulnerable to an attack
>> on the autoconf/automake files, since the debian package calls the
>> upstream tooling to regenerate those files.)

(Hopefully the above clears up that I at least have some superficial
awareness of the build artifacts showing up in the release tarball!)

>> We already have a policy of not shipping upstream-built artifacts, so
>> I am making a proposal that I believe simply takes that one step further:
>>
>> 1. Move towards allowing, and then favoring, git-tags over source tarballs
> 
> I assume you mean git archives out of git tags? Otherwise how do you
> go from git-tag to a source package in your mind?

I'm not wed to any specific mechanism, but I'd be content with that.  I'd
be most happy DD-signed tags that were certified dfsg, policy compliant
(i.e., lacking build artifacts), and equivalent to scrubbed upstream source.
(and more on that later, building on what you say).

Many repositories today already do things close to this with pristine-tar,
so this seems to me a direction where the tooling already exists.

I'll add that, if we drop the desire for a signed archive, and instead
require a signed git-tag (from which we can generate a source tar on
demand, as you suggest), we can drop the pristine-tar requirement.  If we
are less progressive, but move to exclusively with Debian-regenerated
.tar files, we can probably avoid many of the frustrating edge cases that
pristine-tar still struggles with.

>> 2. Require upstream-built artifacts be removed (instead, generate these
>>ab-initio during build)
> 
> The problem here is that the .m4 file to hook into the build system was
> named like one shipped by gnulib (so less suspicious), but xz-utils does
> not use gnulib, and thus the autotools machinery does not know anything
> about it, so even the «autoreconf -f -i» done by debhelper via
> dh-autoreconf, would not regenerate it.

The way I see it, there are two options in handling a buildable package:

1. That file would have been considered a build artifact, consequently
removed and then regenerated.  No backdoor.

2. The file would not have been scrubbed, and a difference between the
git version and the released tar version would have been noticed.
Backdoor found.

Either of these is, in my mind, dramatically better than what happened.

One automatic approach would be run dh-autoreconf and identify the
c

Validating tarballs against git repositories

[Antonio Russo]

Hello everyone,

As I'm sure we're all aware of at this point, Debian has been a victim
of a relatively sophisticated first-party attack whereby a backdoor
of the XZ package was smuggled into sshd via a systemd dependency.
This backdoor, at a minimum, attacked key verification. As far as I
understand, it is not yet understood what exactly the effects of
these backdoors are. (There are two versions 5.6.0 and 5.6.1 that are
affected, and investigation is ongoing.)

There are many things to talk about here, but one that involves the
task of package maintainers, and that I would like to discuss now, is
the way the backdoor was distributed.  The code in the xz git
repository does not build a vulnerable version, while the code in the
5.6.0 and 5.6.1 source tarballs do.

This is a vector I've been somewhat paranoid about myself, and I
typically check the difference between git archive $TAG and the downloaded
tar, whenever I package things.  Obviously a backdoor could have been
inserted into the git repository directly, but there is a culture
surrounding good hygiene in commits: they ought to be small, focused,
and well described.  People are comfortable discussing and challenging
a commit that looks fishy, even if that commit is by the main developer
of a package.  I have been assuming tooling existed in package
maintainers' toolkits to verify the faithful reproduction of the
published git tag in the downloaded source tarball, beyond a signature
check by the upstream developer.  Apparently, this is not universal.

Had tooling existed in Debian to automatically validate this faithful
reproduction, we might not have been exposed to this issue.

Having done this myself, it has been my experience that many partial
build artifacts are captured in source tarballs that are not otherwise
maintained in the git repository.  For instance, in zfs (which I have
contributed to in the past), many automake files are regenerated.
(I do not believe that specific package is vulnerable to an attack
on the autoconf/automake files, since the debian package calls the
upstream tooling to regenerate those files.)

We already have a policy of not shipping upstream-built artifacts, so
I am making a proposal that I believe simply takes that one step further:

1. Move towards allowing, and then favoring, git-tags over source tarballs
2. Require upstream-built artifacts be removed (instead, generate these
   ab-initio during build)
3. Have tooling that automatically checks the sanitized sources against
   the development RCSs.
4. Look unfavorably on upstreams without RCS.

In the present case, the triggering modification was in a modified .m4 file
that injected a snippet into the configure script.  That modification
could have been flagged using this kind of process.

While this would be a lot of work, I believe doing so would require a
much larger amount of additional complexity in orchestrating attacks
against Debian in the future.

Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

time_t transition and bugs

[Antonio Russo]

Hello!

I decided to jump into unstable to see the status of the time_t transition.
There is currently an issue that seems to have not made any progress in the
last few upload cycles.  Specifically, some of the t64 renames
are being reverted by several packages (e.g. util-linux), leaving *versioned* 
dependencies
on the t64 libraries unsatisfiable.  This breaks transitioned packages.

There's a similar issue with versioned dependencies by un-transitioned
packages have on non-t64 libraries (e.g., libqt5sql5).

The end result is that unstable totally broken right now, doubly so
if you're using kde/qt5 (I am holding packages in older versions in aptitude
right now).

My questions are:

1. Is the time_t transition team aware of these issues?
2. Where should these kinds of bugs be reported?  I feel like reporting to
individual packages might get lost, and also these may represent less 
package-specific
issues.

Best,
Antonio Russo

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Hyphens in man pages

[Antonio Russo]

Hello,

I discovered a new pet peeve today: if you search for a command in a manual 
page,
say -e in man 1 zgrep, it's a crapshot whether just searching for '-e' will find
the command or not.  The reason is that "-" may been accidentally encoded as ‐
instead of -.

Now, depending on your email client and settings, the above will appear to be 
the
ravings of an unhinged lunatic who wrote the same thing twice, or an unhinged
lunatic who slammed their fists onto the keyboard.

The reason is that man(1) convert bare dashes (0x2D) to hyphens (U+2010).  These
are not the same symbol: searching for one does not find the other without some
kind of normalization, pasting commands with one vs. the other does different
things.  New users who do not understand this will be discouraged trying to read
manual pages.  Chances are, they will fill forums with mundane questions that
could and should have been addressed by a simple search of a manual page.

I recently fixed a ton of these in another upstream package with this vim 
"one-liner":

:%s/--\([a-z]\+\)\(-[a-z]\+\)*/\=substitute(submatch(0), '-', '\\-', 'g')/g

However, this requires manual review and does not fix the '-e' example from 
zgrep.
There are also a whole host of this kind of problem, e.g., dashes in URLs that 
get
naievely pasted into man pages (another live example I just addressed).

I come here with several questions:

 - Am I off-base thinking this is a problem?
 - Should we really be using troff to typeset anything in this year 2023?
   (In particular, if we can make the source text more human-readable, we might
   be able to leverage LLMs on this wealth of information in the future and 
automate
   support.  Are LLMs "fluent" in troff? I have not investigated at all.)
 - Are there any alternatives that actually produce nice looking man pages?
   (My experience with pandoc is that the source is still awkward, I literally
   just found another example of this bug in my own man page, and it looks 
pretty
   ugly in man. But maybe I just didn't find good examples/documentation.)
 - Should we try to come up with some lintian rules to flag this behavior?
   (This one: /--\([a-z]\+\)\(-[a-z]\+\)*/ finds long GNU-style commands, I'd
   have to think for at least a little bit about finding short ones.  This would
   ultimately be fragile. For example, the above doesn't find partially broken
   tokens; i.e., only one unescaped dash.)
 Automated tooling around this, more generally, seems fragile.  HTML might 
have
   been a nice compromise, but writing that appears to be out of vogue these 
days,
   despite being a pretty OK thing to read and write
   by hand. But seriously, I would love to be writing HTML 
instead
   of troff for manual pages.

Antonio

OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1041718: ITP: keepassxc-proxy-client -- Library to access a running KeepassXC instance

[Antonio Russo]

Package: wnpp
Severity: wishlist
Owner: Antonio Russo 
X-Debbugs-Cc: debian-devel@lists.debian.org

* Package name: keepassxc-proxy-client
  Version : 0.1.6
  Upstream Contact: Henrik Böving
* URL : https://github.com/hargoniX/keepassxc-proxy-client
* License : ISC
  Programming Lang: Python
  Description : Library to access a running KeepassXC instance

 KeepassXC is a password manager which exposes an interface to allow
 access-controlled retrieval of passwords from its secure storage.
 keepassxc-proxy-client is a Python library that can speak this
 protocol, allowing programmatic access to passwords in the
 database.  This packages also includes a simple CLI client built
 using the library.

Best,
Antonio Russo

Re: Dependency for pre-configure script

[Antonio Russo]

On 3/18/23 09:19, Russ Allbery wrote:
> Antonio Russo  writes:
> 
>> Indeed, trying to install a package with a pre-depends on certbot that
>> has a debconf debian/config file does not have certbot installed by the
>> time the debconf script starts.  This is on testing.
> 
> See section 8 of the debconf specification:
> 
> The config-file contains a new element, which I call the
> configmodule. This is a program that will determine the configuration
> before the package is unpacked. This means it is usually run before
> the preinst, and before the package is unpacked!
> 
> This could definitely be clearer (and easier to find), but yes, this is
> expected behavior.
> 
>> My question: is there a way to ensure a package is installed *before*
>> getting debconf input from the user?  Alternatively, is there a way to
>> run debconf questions during a preinst script?
> 
> The tripwire package prompts in preinst, so that worked at some point, but
> it's for an old upgrade so I don't know if it's still working.  I think
> it's more common to prompt in postinst during configure.  I know of
> several packages that do that, although it's not considered ideal if you
> can avoid it.
> 

I was using db_get instead of db_input in the preinst script (doh!).

Everything works fine if you just do the (correct) action in preinst or
(better still) in postinst.  I.e., if you need any dependencies, do not
try to use them in the preconfigure scripts.

Thanks,
Antonio

Dependency for pre-configure script

[Antonio Russo]

Hello,

I'm trying to perform a task during debian/package.config which
requires another package to be installed.  I initially thought
pre-depends would be strong enough, because [1] describes it by:

This field is like Depends, except that it also forces dpkg to
complete installation of the packages named **before even starting
the installation of the package which declares the pre-dependency,**
as follows:

(my emphasis).  However, reading the next paragraphs does not appear to
indicate any requirements are attempted to be satisfied before debconf/
pre-configure questions are asked (only preinst, unpack, and configure
are explicitly mentioned).

Indeed, trying to install a package with a pre-depends on certbot that
has a debconf debian/config file does not have certbot installed by
the time the debconf script starts.  This is on testing.

My question: is there a way to ensure a package is installed *before*
getting debconf input from the user?  Alternatively, is there a way to
run debconf questions during a preinst script?  Just doing

  db_get package/template
  db_go

doesn't seem to work (it does nothing?). Am I doing something wrong? Is
there a preferred way to do this?

Best,
Antonio

[1] https://www.debian.org/doc/debian-policy/ch-relationships.html

Re: Question Re: Advertising in Packages

[Antonio Russo]

On 8/15/21 9:06 PM, Paul Wise wrote:
> On Mon, Aug 16, 2021 at 2:22 AM Antonio Russo wrote:
> 
>>"Can one advertise non-free services in a Debian package?
>> Is doing so a violation of some Debian policy?
> 
> There is no specific rule against this, but I feel that culturally
> Debian generally doesn't like this.

+1

> 
>> The details are filed against firefox[-esr], #992208 [1] (which was
>> summarily closed without very much discussion).  The non-free services in
>> question are Amazon, YouTube, Facebook, Reddit, and Twitter.
> 
> I'd like to see those removed too, but ...
> 
> I expect removing these might violate the Firefox trademark license,
> which would mean we would have to go back to the Iceweasel branding.

I feel like if we are forced to rebrand Debian's browser to ensure user
freedoms, then we simply must do so.  I'd rather support Firefox/Mozilla,
but I don't think we should allow ourselves to be bullied.

> The Debian users who are aren't against non-free services would likely
> get confused/annoyed if standard web services for their country were
> to disappear.

I agree; we should try to find localized equivalents in other regions,
or simply provide no suggestions.

People who will miss something, would know how to get to it.

>> I would propose we replace these with things like lemmy, mastadon, peertub,
>> matrix, framasoft, fsf.org, and debian.org.
> 
> These are mostly names of software rather than services, unless you
> suggest to point at specific hosted instances of these software
> projects.

https://joinpeertube.org/
https://join-lemmy.org/
https://joinmastodon.org/
https://view.matrix.org/

All provide some listing of instances (in fact, my preliminary patch points
to these).  They're relatively sparse, but that's more of a chicken-or-egg
problem:

  If even Debian doesn't bother referring people to our FOSS allies, how
  are they supposed to grow?

- Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Question Re: Advertising in Packages

[Antonio Russo]

Hello,

I have a question that I originally posed in debian-vote, but was directed
here instead:

   "Can one advertise non-free services in a Debian package?
Is doing so a violation of some Debian policy?

Again, if this is the wrong venue, I'm sorry.

The details are filed against firefox[-esr], #992208 [1] (which was
summarily closed without very much discussion).  The non-free services in
question are Amazon, YouTube, Facebook, Reddit, and Twitter.

I would propose we replace these with things like lemmy, mastadon, peertub,
matrix, framasoft, fsf.org, and debian.org.  However, if those become
contentious (and please don't consider this an endorsement by me of every
single one of them), we could just remove all of these pre-seeded
"top sites".

- Antonio


[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992208


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

[OFFTOPIC] partially-trusted debs (was Bug#990521: I wonder whether bug ...)

[Antonio Russo]

On 7/1/21 7:38 PM, Jeremy Stanley wrote:
> On 2021-07-02 01:24:09 + (+), Paul Wise wrote:
>>
>> For sophisticated users it isn't very hard to verify that packages
>> don't do anything malicious as root. `apt install --download-only`,
>> `dpkg-deb --raw-extract`, read the maintainer scripts and check which
>> files are installed into the package.
> [...]
> 
> On each machine where you install it, unless you confirm the
> checksum hasn't changed from one to the next. Also each and every
> time you upgrade it. And it goes without saying, if you're worried
> about this, don't enable unattended upgrades for anything from that
> repository.
> 

I actually do this (for the wine and google-chrome [1] packages from
their upstreams).

You (at least) need to also check for any setuid binaries.

Don't forget that .desktop files can trigger execution, and files
under /etc can also cause unsafe behavior.  (I have been hoping that
there are no major security bugs in man(1) opening unsafe pages).

Best,
Antonio

[1] Significantly more needs to be done for chrome, since it does,
indeed, include a setuid wrapper script.


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature

Kernel building question (Is -j8 safe and correct?)

[Antonio Russo]

Hello,

I'm trying to build a Debian bullseye kernel (with KASAN enabled, but that's 
irrelevant).
I'm following [1], and the critical command

$ fakeroot make -f debian/rules.gen binary-arch_i386_none_real

does not suggest using -j8 (or -jnumber_of_cores).

1. Is it safe to add -j8 ?
2. Will this indeed give me the speed up I want and expect on my multi-core 
processor?
3. If both of the above are true, why isn't something like that suggested on 
[1]?

Best,
Antonio

[1] 
https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-official

Re: dovecot-antispam rebuild (or is there a way to automatically rebuild a package)

[Antonio Russo]

On 1/27/21 12:58 AM, Sebastian Ramacher wrote:
> 
> For step 2 someone needs to request a binNMU
> 
> reportbug release.debian.org -> binNMU
> 
> See also https://wiki.debian.org/binNMU
> 
> Best
> 

Thank you (for the info, and processing the binNMU)!

Antonio


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

dovecot-antispam rebuild (or is there a way to automatically rebuild a package)

[Antonio Russo]

Hello,

I'm watching dovecot's progress through unstable [1] and it's blocked by
dovecot-antispam [2].  If I understand correctly, it's because
dovecot-antispam depends on dovecot-abi-2.3.abiv11, which is not provided
by the new version of dovecot-core (which instead provides a new abi
virtual package dovecot-abi-2.3.abiv13).  That dependency, however, is
determined at dovecot-antispam build time, so it should naturally
resolve itself.

It seems to me that what should ideally happen is:

1. New version of dovecot gets uploaded
2. dovecot-antispam gets rebuilt (automatically?)
3. enough time passes
4. dovecot and dovecot-antispam migrate to testing together

Is this correct?  If so, what mechanism triggers the rebuild of 
dovecot-antispam,
and why hasn't it already happened?  If not, what action should be taken?

More importantly, where is this all documented? 

Thanks,
Antonio


[1] https://tracker.debian.org/pkg/dovecot
[2] https://tracker.debian.org/pkg/dovecot-antispam


OpenPGP_0xB01C53D5DED4A4EE.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature

Re: [FIXED] Re: Network and KDE lost after testing upgrade

[Antonio Russo]

On 1/11/21 9:52 PM, Xavier wrote:
> 
> Hi,
> 
> bug is fixed with libx11-6 2:1.7.0-2 (I don't know why)
> 
> Cheers,
> Xavier
> 

Can you check your apt logs if libx11-xcb1 got out of sync?  I ran into
massive problems with almost everything X-related when libx11-xcb got
ahead of libx11-6.

Antonio

Accepted kcollectd 0.10.2-2 (source) into unstable

[Antonio Russo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Sat, 30 Nov 2019 22:01:59 -0700
Source: kcollectd
Architecture: source
Version: 0.10.2-2
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Antonio Russo 
Changes:
 kcollectd (0.10.2-2) unstable; urgency=medium
 .
   * Bump Standards-Version to 4.4.1, no changes needed.
Checksums-Sha1:
 c5af51af09d014d26c60a9603a857c0fb462c7fe 2268 kcollectd_0.10.2-2.dsc
 02b1f9fd8b80561236c4a1055f51e8795a36fe5e 9024 kcollectd_0.10.2-2.debian.tar.xz
 26a97477b0e6004d71f99a55fbfd35f775120b2b 16596 
kcollectd_0.10.2-2_source.buildinfo
Checksums-Sha256:
 769eea7e27ba29053ef15fa0d430ef9c88f103fd305b046a2be99a7f8dc824a7 2268 
kcollectd_0.10.2-2.dsc
 13c586bcf43d19efe4e649d93fbcad233606f03522d05be70f43290be5b1563f 9024 
kcollectd_0.10.2-2.debian.tar.xz
 7993a8ff597eaa1216c0c8aa6c18368f892044a02c63eee319e4cd24c6def512 16596 
kcollectd_0.10.2-2_source.buildinfo
Files:
 3871a2036bf58f168a0f074efb355cb6 2268 utils optional kcollectd_0.10.2-2.dsc
 a72d6825049958d5137e4e4561a14b54 9024 utils optional 
kcollectd_0.10.2-2.debian.tar.xz
 847601b77710ebc77527ee790e36b5e3 16596 utils optional 
kcollectd_0.10.2-2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEOewRoCAWtykmSRoG462wCFBgVjYFAl3jhGMRHGhlZmVlQGRl
Ymlhbi5vcmcACgkQ462wCFBgVjZdyw//RTiDrlv0p8thpVBEIuMNBWk8ieSkcwVX
/lONA/57u2tLSpJP4XsOJ9UEdkKUbBzCa7hxskeQc2GJzhMtC8qXSof0NhoxK1Yx
vmy5SYePsn+jCX3GDI4TPZT9u8cH3Sdwx62YALvTGAbYePraUXf1Q5dhOBjiLrPm
3WecUlUa3VsPYvlgwl68fehBJTl2d60uFSc4guR2dhd9uIE1voUBTOmNtJ0JYf5E
GHzC5UhD/gmb7m6Y5LkCmIIXaxFOVE4rzQYI26R0mYQ08i6ErVhHlDJMC8QgOok1
4n/qk2sSCW0W28KwNYceqnu5h/SEEDYaJXWlhaviIxaPq56lkaWDhFumGnIG7Cyz
NXKCoHAUUJK2xo5fhWA9ABA/fuBwRxqKXDVg5Jn260Gxc/HP2NK7l9RRfRPUPv+q
JJOjYLqwKQt0HKyRG9OoED7yPvz/Dkr9i7d4QxQ6OS906Dd/DcYWSotQ1t2mb41y
hI5Sbdy67iXcrE1Qd4UjP4F4hA4WqD7wfyGmggnqMhFDS11HZovz+MuqQsaBOFSl
/NtNMp5vB+v5GqSkCadm9dTZ8juVW0n3W6R03smuLipMtfpjd5vM4rKqBV9GbJYa
wSwZz2MOEgZPzKIfQaZWTsQWgWkm9ZJSjYxUyHdqSqSCwEqUF+vU+DBxfVgUxflZ
h+sMiUFJopc=
=LSTm
-END PGP SIGNATURE-

Accepted kcollectd 0.10.2-1 (source amd64) into unstable, unstable

[Antonio Russo]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Format: 1.8
Date: Wed, 04 Sep 2019 19:27:10 -0600
Source: kcollectd
Binary: kcollectd kcollectd-dbgsym
Architecture: source amd64
Version: 0.10.2-1
Distribution: unstable
Urgency: medium
Maintainer: Debian/Kubuntu Qt/KDE Maintainers 
Changed-By: Antonio Russo 
Description:
 kcollectd  - simple collectd graphing front-end for KDE
Closes: 814935 874938 912460 927455 935485 939293
Changes:
 kcollectd (0.10.2-1) unstable; urgency=medium
 .
   * Update debian/control for inclusion in Qt/KDE.
   * Squash and clean up changelog/unreleased versions.
   * Reference both sponsorship-requests and WNPP bugs.  (Closes: #939293)
   * Tidy up debian directory.
   * Move to Qt/KDE team.
   * Add missing build-dependencies.
   * New upstream release.  (Closes: #814935, #874938, #912460)
   * Change upstream to myself.  (Closes: #927455)
   * Change maintainer to myself.  (Closes: #935485)
   * Enable hardening.
   * Bump Standards-Version to 4.4.0.
   * Build-Depends on pkg-kde-tools.
   * Make copyright machine-readable.
   * Add upstream/metadata file.
   * Remove trailing whitespace.
   * Fix other lintian errors.
   * Change priority to optional.
   * Directly watch for git tags.
   * Drop Debian patches included upstream.
Checksums-Sha1:
 41d56a6c076804c2c107e7abe3635448ad6aec94 2268 kcollectd_0.10.2-1.dsc
 973f0b99aea0c34c6fc32335d04b5277a119599f 89368 kcollectd_0.10.2.orig.tar.xz
 9b67de2597d96cacbacc01359add7e59361f4dde 9068 kcollectd_0.10.2-1.debian.tar.xz
 41dd5406691f1af6c34d16cab03ea1861fdebdf6 762592 
kcollectd-dbgsym_0.10.2-1_amd64.deb
 23bb81ebcc1db232dd55759a8c92c79ac43041d6 20291 
kcollectd_0.10.2-1_amd64.buildinfo
 6beab6e7e119f317aaf65a4f6970aabda8360cc0 76620 kcollectd_0.10.2-1_amd64.deb
Checksums-Sha256:
 4b0ee1c296820f4fcb33b0e2b4ec7bdf32c86c0f31b0879fb8ba84746c9587c4 2268 
kcollectd_0.10.2-1.dsc
 ab35895faa7520e556d3ac8d417654ae27e044b0588f9938cd9eef7fc02e151c 89368 
kcollectd_0.10.2.orig.tar.xz
 2d6ce9c18f64622f6bd590802c2796ba14e58c97482e2a1bb2eeb95a0e1bd7e9 9068 
kcollectd_0.10.2-1.debian.tar.xz
 cc56aebbec74233718ca2d2e02278a3f9c1a505d5923cfdf1e148173c9e20c74 762592 
kcollectd-dbgsym_0.10.2-1_amd64.deb
 ce3974440f03abadc9050b4197a3e0f70047585c077558920efdf84afeb50fa9 20291 
kcollectd_0.10.2-1_amd64.buildinfo
 742693e3477d3218f8a94108938d83b06780f40d7b54056521f2846a802233d4 76620 
kcollectd_0.10.2-1_amd64.deb
Files:
 ed3a82e72f41903b9965b325468bcb34 2268 utils optional kcollectd_0.10.2-1.dsc
 6a31542a89094aecf13778f532244efe 89368 utils optional 
kcollectd_0.10.2.orig.tar.xz
 ef9537258a9033b5c4b94295455ea831 9068 utils optional 
kcollectd_0.10.2-1.debian.tar.xz
 f5d3e7adf3d3dbd8995b2bc310cecfeb 762592 debug optional 
kcollectd-dbgsym_0.10.2-1_amd64.deb
 8067ede6436e5c66fd68e2ebcb69e6f6 20291 utils optional 
kcollectd_0.10.2-1_amd64.buildinfo
 cbdef766d28a1bc94d138da788782009 76620 utils optional 
kcollectd_0.10.2-1_amd64.deb

-BEGIN PGP SIGNATURE-

iQJFBAEBCgAvFiEEOewRoCAWtykmSRoG462wCFBgVjYFAl1zXvQRHGhlZmVlQGRl
Ymlhbi5vcmcACgkQ462wCFBgVjY7Gg//ZK2l8RSWc1oLMQBi+Nif4MNWoUyJK45t
e+3L3AlmQ1N4n1GRe5fUviTVYsAdNd5Kbq9OqWM+xFVVnReIUka66tEJVZqCJVu9
ynIfJXXHotXLfQ4oximr8eoSrN8QtbZDWjw2gj/OKchRsVCvNam+G9lQDh9F6tpw
z48VOTctDvAp5KY08ObgxNKfMW9JZMoVo/4u4H5s+bk6Un3Wx4a18FoNfVi88i/z
/BsQc2RATTMDAX36rUTB9IkSZtCYgKP/qys+D0HUss5pD8cbTv2V68hltuvqRktK
GP52PHk0I8FKL6hztSHbAELKhgczXqdYkkDELrfFrFzSQl0InQ08GTbjMWDdYLfN
YL1F/UnozJTl6FBp1sokanLV7aFiPJz6x1BIg1E/47Tqhm7wD0XymQBVAz3r3B2L
qv1FZUJiUrRpRx6vWrwVmK+k00QktsOUUvxthyi66v15DsTpMhNtXxWyEtfjZoKz
Scxd2nuUmL+zlvxCJKMqGOmV9N0PXJ90boGU4+Tr2uySrRohuWV5cpKBV9jHGeYv
XLsI5Rp0ePaPkARyVXmXdvGdj7dyFDl3vWjOz5+4sdFiy4eRg+J84C8PG4sSnDl0
ezF8mPjQMhPfdJ+BMpbp2Q+eRgU9NNGohIlNXeqEX9c9Tqov3pjJa0Q0wc9q+IA1
miTPKm/T57U=
=j6l9
-END PGP SIGNATURE-

Bug#942249: ITP: inkscape-ext-textext -- Re-editable LaTeX graphics for Inkscape

[Antonio Russo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

 * Package name: inkscape-ext-textext
   Version : 0.12.0~git36-gbbb55e6-1
   Upstream Author : Jan Winkler 
 * URL : https://textext.github.io/textext
 * License : AGPL
 * Vcs : https://github.com/textext/textext
   Section : graphics
   Description : Re-editable LaTeX graphics for Inkscape

TexText is a Python plugin for the vector graphics editor Inkscape
providing the possibility to add and re-edit LaTeX generated SVG
elements to your drawing.

 Key features
 . Windows/Linux/MacOS support
 . LaTeX generated SVG elements can be re-edited later
 . Multi-line editor with syntax highlighting
 . Compilation with PdfLaTeX, XeLaTeX or LuaLaTex
 . Interoperable scaling in TexText and Inkscape
 . Font size match with Inkscape text
 . Customizable TeX preamble (additional packages, parskip, parindent, etc.)
 . Colorization via TeX commands/Inkscape is kept after re-editing
 . Alignment anchor of the produced output
 . Preview images


The packaging [1,2] works (though I haven't tested it in pbuild yet, so there
might be some missing build dependencies).  I'm also confused why py3compile
isn't being added by dh_python3 to the postinst script, so at least one
significant thing needs to be fixed.

Also, this is using upstream's "develop" branch, git commit febf8f7. Earlier
versions don't work with Inkscape 1.0 (beta), which has fully transitioned
to Python 3. There's no reason to waste time packaging things for Python 2,
so I suppose this is targeted at experimental, at least until upstream and
Inkscape make another release.

[1] https://mentors.debian.net/package/inkscape-ext-textext
[2] 
https://mentors.debian.net/debian/pool/main/i/inkscape-ext-textext/inkscape-ext-textext_0.12.0~git32-gfebf8f7-1.dsc

Bug#941708: ITP: nextcloud-server -- Nextcloud folder synchronization tool (server)

[Antonio Russo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

 * Package name: nextcloud-server
   Version : 0.1.7
   Upstream Author : Antonio Russo 
 * URL : https://gitlab.com/aerusso/nextcloud-server-deb
 * License : AGPL
 * Vcs : https://gitlab.com/aerusso/nextcloud-server-deb
   Section : net
   Description : Nextcloud folder synchronization tool (server)

Nextcloud is an increasingly popular software package.  A first-class
integration of Nextcloud into Debian is desirable, but represents
a significant challenge because upstream development is unlikely to
produce long-cycled supported releases compatible with the Debian
release cycle.

This packaging sidesteps that issue by providing version-independent
tools to download, install, configure, update, and manage the server.
Although unconventional, such tools are not unheard of in Debian [1,2].

The current version is suitable for beta testing, and should eventually
reach maturity compatible with Debian stable.

Thank you,
Antonio Russo

[1] ttf-mscorefonts-installer
[2] libdvd-pkg

Bug#891890: ITP: zfs-linux-git -- zfsonlinux packaging tracking git master

[Antonio Russo]

Package: wnpp
Severity: wishlist
X-Debbugs-CC: debian-devel@lists.debian.org

--- Please fill out the fields below. ---

   Package name: zfs-linux-git
Version: 0.8~
Upstream Author: Brian Behlendorf 
URL: http://www.zfsonlinux.org/
License: CDDL
Description:
 ZFS is an advanced file system and volume manager which was originally
 developed for Solaris. It provides a number of advanced features like
 snapshots, clones, live integrity checksums, deduplication, compression,
 encryption, and much more. The port to the Linux kernel includes a
 functional and stable SPA, DMU, ZVOL and ZFS Posix Layer (ZPL).
 .
 This package is a very close fork of the existing zfs-linux package
 already in Debian, but aims to track git master and the ntrim2-next
 patch set adding trim support by Tim Chase.
 .
 BEWARE: THIS VERSION OF ZFS IS EXPERIMENTAL. IT MAY EAT YOUR DATA.



Just like the parallel packaging of wine-unstable and wine, I have
packaged [1] a -git version of zfs (and spl). Actually, the version is
a rebase of a PR [2] by Tim Chase [3] to add trim/unmap support to ZFS.
This appears to be getting close to a mainline inclusion, and there has
gathered much interest. The git mainline already includes encrypted
datasets.

I am proposing adding this package to the experimental repository (as
it definitely does not meet the quality and stability requirements for
any Debian release). The exposure of these experimental features to
the broader Debian community provides a better test-bed for the
zfsonlinux mainline (and for this ntrim2-next PR especially). This
testing improves the quality of the released version, protecting
Debian users not as willing to test out the newest features
filesystems.

Moreover, because the packaging is---and will remain, to the best of my
ability---close to the released-version ZFS packaging, changes
migrating into the release version from master that require adaptations
to the Debian packaging will have already been addressed (by myself).
This should alleviate some of the demands on the already overburdened
maintainers of zfs-linux.

There are a few considerations I'd like to highlight:

1. The packages should be difficult to accidentally pull in, but
still satisfy any dependencies by third-party packages for zfs. I've
done this by changing the name, and adding both a Conflict: and
Provides: dependency on the original zfs-linux package name.

2. ZFS and SPL are relatively tightly coupled software. I have
opted for a tight release schedule, where both the ZFS and SPL
commit hashes are tracked for both ZFS and SPL packaging. This
avoids strange bugs with out-of-date SPL versions, but will
require re-releasing SPL versions for every ZFS release.

This can be adjusted if it is decided that it is important.

3. I'm tracking a not-yet-mainlined patch set, and its role is
expected to become more stable once that patch set is mainlined.
The package name anticipates this outcome.

[1] https://github.com/aerusso/pkg-zfsonlinux-git
[2] https://github.com/dweeezil/zfs/tree/ntrim2-next
[3] https://github.com/dweeezil