Re: Firmwares (was Re: Bits from the DPL)

[Gunnar Wolf]

Andrey Rakhmatullin dijo [Mon, Apr 01, 2024 at 10:41:45PM +0500]:
> Why is updating the firmware packages not trivial? Is it because of
> licensing issues? I always thought it's just copying a bunch of files from
> the linux-firmware repo (but I also often wondered why is the package
> often not up to date).

There are many firmware packages that don't come from the linux
sources. i.e., I maintain raspi-firmware, the blob needed to boot the
Raspberry Pi family of computers.

And not even following upstream is always enough --- as a data point,
up until a year ago, the Raspberry Pi foundation used to regularly tag
releases in their Github repo¹, but they no longer do that. Of course,
I am not inclined to ship to Debian an unsanctioned what would amount
to just a random snapshot (of course, impossible to review or bugtrack
in any meaningful way) of their blob :-\

¹ https://github.com/raspberrypi/firmware


signature.asc
Description: PGP signature

Re: Questionable Package Present in Debian: fortune-mod

[Gunnar Wolf]

Dominik George dijo [Fri, Aug 18, 2023 at 11:43:03PM +0200]:
> > So, let's at least be consistent.
> 
> Totally agree with that.
> 
> Debian is not a collection of harmful content, it is an operating system.
> 
> But, unfortunately, there are too many people in the project who think, in the
> name of "free speech", protecting racists, nazists, and anarchists is more
> important than protecting PoC, jews, or other minorities.

As a Jew myself, I often find that quoting bits of Mein Kampf _protects_
Jews. Why? Because it is full of contradictions.

(And... Yes, I have a printed copy of the book at home; I was curious to read
it. It is an easy read, but I'd never consider it high literature or even
instrumental to the third reich's raise to power... but that's a completely
different topic)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Gunnar Wolf]

Simon McVittie dijo [Thu, Jun 08, 2023 at 10:33:45AM +0100]:
> - For game-related use cases in particular, 2030 GPU models aren't going
>   to work with 2023 user-space graphics drivers (typically Mesa or
>   NVIDIA-proprietary) because the 2030 GPU didn't exist yet at the time
>   the 2023 driver was written, so if we don't compile a modern Mesa
>   for i386, all i386 programs will eventually lose the ability to do
>   accelerated graphics and end up using the 2023 version of llvmpipe.

This makes the case for an ideal GPU paravirtualized implementation!

(yes, yes, I know it's not doable... Just had to say it!)

Re: 64-bit time_t transition for 32-bit archs: a proposal

[Gunnar Wolf]

Simon McVittie dijo [Tue, Jun 06, 2023 at 11:45:26AM +0100]:
> On Tue, 06 Jun 2023 at 09:33:22 +0200, Helmut Grohne wrote:
> > Judging from the conversation, killing i386 quite obviously is desired
> > by some participants, but evidently not by all. How quickly we want to
> > kill it is not obvious to me.
> 
> When considering the future of i386, a factor that we need to bear in
> mind is that there are two major use-cases for i386, with requirements
> that sometimes conflict:
> 
> 1. i386 as a fully-featured architecture that you can run independently
>on 32-bit x86 systems from roughly the 2000-2010 era
> 
> 2. i386 as a multiarch foreign architecture to run legacy binaries on
>modern x86_64 systems
>2a. legacy native Linux i386 binaries
>2b. legacy Windows i386 binaries via Wine (which requires a somewhat
>complete i386 Linux library stack)
> (...)

I completely agree with your analysis here, and I agree we should
strive to keep 2a and 2b covered, as they are (and they will be, every
time by a bigger margin) by far more common and productive than 1.  I
agree with your assessment that date woes will be minor for the i386
user than incompatibility woes going forward; there is the possible
case of people running I-don't-know-which proprietay productivity tool
provided as a binary that cannot be convinced of a 64-bit time_t that
will receive errors when the timeocalypse approaches, but I guess the
gaming use cases will be much more frequent than that; even though
your vision might be somewhat skewed by the fact that you work in
Steam, it makes complete sense.

Of course, given our i386 users would be running (>10 years for now) a
Debian architecture used mostly for compatibility with old non-free
binaries, we'd have to think whether it makes sense to provide a full
Debian experience (i.e. you don't want i386 users to have a PostgreSQL
with a known-borked time implementation storing important information
in it -- and of course, this is only the first of too many examples
that comes to my mind, but won the race to get to my fingers )

But anyway, back to what matters here: I support Helmut's idea. I have
long thought we fear the GR process too much, and we should excercise
it more. Not every GR has to be a flamefest. Having a clear statement
of what is being voted on, and the possible consequences on each of
the options, can lead to a civil, useful way to measure the opinion of
project members interested in the subject.

Right now, I imagine a ballot similar to:

The future of i386 in Debian from Trixie onwards

   A. Drop support of i386 completely
   B. Keep support of i386 as a multiarch-foreign arch, with 32-bit time_t
   C. Keep support of i386 as a multiarch-foreign arch, with 64-bit time_t
   D. Commit to supporting i386 as a full-featured arch, with 32-bit time_t
   E. Commit to supporting i386 as a full-featured arch, with 64-bit time_t
   F. Further discussion

I know this woul conflate two decisions in one ballot, but arguably
they are part of the same issue. I do not feel qualified to draft the
full vote, as I have not followed the discussion as closely as I'd
like to and I'm not directly affected anyway, but would be very happy
to second it.

FWIW, I believe the only real danger in having non-controversial GRs
would be that a vote does not reach quorum (48 voters in the last GR),
but I don't believe it is a real danger to worry about; in any case,
failure to reach quorum would mean the project does not _mandate_ a
decision, but it can be anyway implemented by porters / RT.

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

John Goerzen dijo [Wed, May 31, 2023 at 07:29:38AM -0500]:
> (...)
> I guess the question is: is this use case too niche for Debian to
> continue supporting?  I would suggest that as long as we have 32-bit
> ARM, are the challenges for 32-bit x86 really worse?

Do note, however, the ARM64 started appearing in consumer devices
maybe around 2015, ten years later than AMD64. And nowadays there are
still (although few) ARM32 systems being produced --- I know it's even
funny to refer to them giving the stock shortage that's been biting
them for already too long, but i.e. the lowest Raspberry Pi models
(Zero, 1A, 1B -- the ones that need armel) have "obsolescence
statements" committing to have them produced at least until January
2026¹.


¹ https://www.raspberrypi.com/products/raspberry-pi-zero-w/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-a-plus/
  https://www.raspberrypi.com/products/raspberry-pi-1-model-b-plus/
  (end of page)

Re: i386 in the future (was Re: 64-bit time_t transition for 32-bit archs: a proposal)

[Gunnar Wolf]

Alexandre Detiste dijo [Wed, May 31, 2023 at 01:00:42PM +0200]:
> Le mer. 31 mai 2023 à 12:44, Wouter Verhelst  a écrit :
> > 20+ year old machines are typically more power hungry, more expensive,
> > less performant, and less reliable than an up-to-date raspberry pi.
> 
> Embedded systems and medical one can be crazily expensive to maintain
> and even more to replace but some will run on i386 for a long time more
> (had to manage some still running on DOS recently ...),
> there's also much of amd64 HW running on i386 because of lazyness/cost
> for hybrid fleets; energy efficiency is there the least of concerns.

You point out a valid and important use case. However... how should I
name this for the sake of the argument... "Large embedded" systems
(i.e. systems that act as embedded because they are the
general-purpose computer that lives inside a very purpose-specific bit
of equipement) are very unlikely to be a compelling use case to keep
producing i386 install media.

Medical equipment is usually tied to a very old computer because it
sports an ancient installation and set of binaries. Those systems are
(thankfully!) most often not internet-connected, so as long as you can
deal with DOS or Win9x quirks, and the gaping security holes won't be
of great importance.

Oh, did your medical imaging system ship with Debian 3.1 Sarge? Sweet!
Beautiful! However, it's quite unlikely you will want to upgrade it to
current-day Debian. Not only you will have to get enough memory for
the very hungry 6.x Linux kernel (I once built a boot floppy disk to
use a given system as an X terminal, and it all fit in 2MB
RAM... Nowadays that would be plainly impossible), but quite likely,
the specialized drivers for the vey one-of-a-kind imaging device would
not work.

And if you manage to replace the old install for said i386 system with
a recent one, I'm sure you would be able to replace the i386 system
with an ARM-based or AMD64-based system as well -- After all, the old
computer is not only needlessly power-hungry, but much more likely to
break.

Re: Problem with detection of hard disks on a hub

[Gunnar Wolf]

Ralf Lehmeier dijo [Mon, Apr 10, 2023 at 06:43:42PM +0200]:
> No problem.
> I already moved the part with the hub alternative to
> linux.debian.user.german.
> But the part with the question why Debian does not recognize the hub,
> although Manjaro does, should interest the Debian developers.
> Therefore I would also like to have an answer, if someone knows it.
> 
> Is Debian not able to detect the hub or is there a way to install it and if
> so how?

It will surely interest Debian developers -- but this is not the right
list to ask. Please ask in one of the user support lists (where Debian
developers will surely answer to your question). Your question is not
about Debian development (which is the purpose of this list), but
about Debian usage.

Re: Problem with detection of hard disks on a hub

[Gunnar Wolf]

Ralf Lehmeier dijo [Mon, Apr 10, 2023 at 03:21:38PM +0200]:
> Andrey Rakhmatullin schrieb:
> > The user support list is debain-user@
> > 
> 
> Thanks for the tip.
> I will ask the question again on linux.debian.user.german.
> 
> But one question remains unanswered.
> Why are the disks recognized under Manjaro and under Debian they make
> problems?

Please move the question to the proper list, as it has better chances
of being answered :-) This mailing list serves other purposes.

Re: Introducing Declarative Debian

[Gunnar Wolf]

Didier 'OdyX' Raboud dijo [Sun, Apr 02, 2023 at 03:54:55PM +0200]:
> > For example:
> > * httpserver-is-apache
> > * imapserver-is-dovecot
> 
> You need to think larger!
> 
> * christoph-got-you-to-think-about-this-seriously
> * april-s-fool-is-less-and-less-fun-in-an-era-of-fakenews
> * I-genuinely-giggled-though

However, I insist on consistent naming. At least we should require all
declarative-named packages to follow a proper foo-is-bar name until
the secret project to include ChatGPT as a dependency for apt is
finally ready to be announced.

Re: my package uploads silently rejected

[Gunnar Wolf]

Jonas Smedegaard dijo [Wed, Nov 30, 2022 at 03:03:14PM +0100]:
> Hi,
> 
> I am unable to succesfully dput packages.  Most likely the cause is my
> too late updating my PGP key expiry date - but that should be solved by
> now, and I am unable to figure out how to debug the problem or whom to
> contact about it.
> 
> I patiently waited until debian-archive-keyring package was updated with
> my refreshed key in it, and since then I have regularly tested
> re-uploading the package rust-criterion where I receive the initial
> confirmation that the upload was received but the seconed confirmation
> (typically appearing ~10 minutes later) that the package was accepted
> does not appear.

While I cannot comment on the DAK side of this, I can confirm that
your key was updated in this month's upload, three days ago:


https://salsa.debian.org/debian-keyring/keyring/-/commit/f12a437730fc5f1f5ac72a0b914ef97a78d7f7a9

https://salsa.debian.org/debian-keyring/keyring/-/commits/master/debian-keyring-gpg/0x2C7C3146C1A00121

Your currently active key is set to expire on 2023.11.13.

So, that _should_ not be the problem.


signature.asc
Description: PGP signature

RFH: Packaging Intel's userspace tools for Data Streaming Accelerator

[Gunnar Wolf]

Hi all,

I was recently approached by Intel engineers Miguel and Jair (Cc:ed on
this mail). They asked for my help in getting Debian Bookworm and
higher to support the Data Streaming Accelerator, and we have
exchanged a couple of messages about this. I'm reproducing next part
of our conversation.

The purpose of this mail is to help find interested people in Debian
that can help review and sponsor uploads of the userspace tools; the
kernel-side modules have been enabled as of bug #1021337 (thanks for
the quick reply!)

It is quite probable Miguel and Jair can be the package maintainers,
and I'd be more than happy to welcome them in Debian, but they will
surely need some guidance to get the package (for which the work is
already started¹) in a state that can be uploaded to Debian. I've been
meaning to start helping them, but am quite time-strained and have
been unable to do so, so... anybody interested in getting this
technology supported in our distribution will be a good candidate to
help!

¹ The proposed debian/control file can be found at
  https://github.com/intel/idxd-config/blob/stable/debian/control

I asked them for a description of Intel DSA. They say that:

The driver enables the Data Streaming Accelerator or DSA
capability for the 4th generation of the Intel Scalable Xeon
processor family, with code name Sapphire Rapids, and for future
Intel processors.

As stated in the DSA specification (which can be found at


https://software.intel.com/en-us/download/intel-data-streaming-accelerator-preliminary-architecture-specification

):

Intel DSA is a high-performance data copy and transformation
accelerator that will be integrated in future Intel® processors,
targeted for optimizing streaming data movement and transformation
operations common with applications for high-performance storage,
networking, persistent memory, and various data processing
applications.

Intel DSA replaces Intel® QuickData Technology, which is a part of
Intel® I/O Acceleration Technology.

I was also pointed at this very clear blog post in Intel Open Source's
space:

https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator

The userspace software is already available in Fedora / CentOS / RHEL
under the name "accel-config" and "libaccel-config". They propose the
following description:

Utility for configuring the DSA subsystem

Intel Accelerator Utilities (accel-config) provides a user
interface to the Intel Data Streaming Accelerator (DSA). DSA is a
high-performance data copy and transformation accelerator
integrated into Intel Xeon processors.  .  This package contains a
utility for configuring the DSA (Data Stream Accelerator)
subsystem in the Linux kernel.

The first processor family to support the capability is Intel's fourth
generation of Scalable Xeon server processors, code-named Sapphire
Rapids. Currently some SPR products are planned to be launched on 2022
calendar week 42 and 2022 calendar week 45. High volume SPR processors
have a planned launch window on 2023 calendar week 6 to 9 (Feb. 6,
2023 to March 3, 2023).

The document at
https://01.org/blogs/2019/introducing-intel-data-streaming-accelerator
is a good introduction to the accelerator feature.

From it, we can extract additional details about the accel-config
tool's architecture and features:

accel-config is a utility that allows system administrators to
configure groups, work queues and engines. The utility parses the
topology and capabilities exposed via sysfs and provides a command
line interface to configure resources. Some of the capabilities of the
accel-config are listed below:

> Display the device hierarchy.
> Configure attributes and provide access for kernel or applications.
> Use API library (libaccel) that applications can link to to perform
> operations through a standard ‘C’ library.
> Control devices to stop, start interfaces.
> Create VFIO mediated devices to expose virtual Intel® DSA instances
> to Guest OSes.

So... Is anybody among debian-devel readers interested in helping
Debian support this hardware feature? Extra points for people that
_have_ the suitable hardware! (I don't)

Greetings,


signature.asc
Description: PGP signature

Re: Keep both images but stop pretending no-free is unofficial

[Gunnar Wolf]

Hakan Bayındır dijo [Thu, Apr 21, 2022 at 09:21:07PM +0300]:
> A further evolution of this idea might be adding another question to
> Debian Installer regarding to non-free software.
>
> If the users choose “No” for enabling non-free repositories, another
> question might ask “Your system seems to need some firmware packages
> to operate correctly, do you want to enable only the firmware
> packages, but not the other non-free software?”
> 
> Normally, the installer asks for “firmware.zip” file if it can’t
> continue, but it’s already noted that making it work is very very
> hard (I only succeeded once in my 15 years of Debian use). Maybe
> making this process easier helps?

And this still does not get us all the way there -- There are many
computers that can run Debian that won't even try to boot in the
absence of a non-free firmware on the boot media.

Yes, I'm one of the maintainers for raspi-firmware... :-/

Re: Keep both images but stop pretending no-free is unofficial

[Gunnar Wolf]

Marc Haber dijo [Tue, Apr 19, 2022 at 06:56:54PM +0200]:
> On Tue, 19 Apr 2022 08:21:10 -0600, Sam Hartman 
> wrote:
> >One valuable suggestion was to make sure users could easily select
> >freedom if that's what they wanted.
> >So I think a free installation image is important.
> 
> Would that not be possible by having an image WITH firmware and an
> installer asking whether the user wants a free or a usable system?

Up to a certain point, I guess. But users do get confused by Debian, a
stubbornly-free distribution, having multiple images –some official,
some unblessed– on different places.

Maybe if the free image finds (important? i.e. the only connectivity
option, or required for enabling a video card beyond framebuffer?)
hardware for which firmware is required, it could display a prominent
message, suggesting the user to download the
official-but-firmware-carrying images from a simple debian.org URL.

Re: getting pinta updated in Debian

[Gunnar Wolf]

Timotheus Pokorra dijo [Wed, Mar 02, 2022 at 10:35:36PM +0100]:
> Hello Mike,
> 
> I have some experience with Mono packaging in Fedora.
> I know of the dotnet SIG in Fedora. They made a massive effort, involving
> Microsoft employees, to get dotnet core built according to the Fedora rules
> (build from source, not using external files, etc).
> (...)
> It is really difficult to package dotnet packages, because of all the nuget
> dependancies. We have not figured that out for Fedora. Or did not have the
> volunteers yet to do that.
> 
> Alternatives to dotnet: Mono, dotgnu
> https://www.gnu.org/software/dotgnu/
> "As of December 2012, the DotGNU project has been decommissioned."
> 
> Mono: it is the alternative to .NET Framework, which Microsoft will support
> for many years to come. But the new stuff is happening in dotnet, so
> projects like Pinta are moving from Mono to dotnet.

Uff... .NET -- A reimplementation of the "write once, debug
everywhere" fiasco :-(

Re: developers-reference "vs" wiki.debian.org/DebianMaintainer

[Gunnar Wolf]

Holger Levsen dijo [Thu, Feb 10, 2022 at 11:49:05AM +]:
> hi,
> 
> so Stephan Lachnit submitted an MR for developers-reference on Monday to
> document how to grant DM upload permissions, which I gladly merged, even
> though I was aware of "#653399: developers-reference: Please include a 
> paragraph about Debian Maintainers (DM)" still being unresolved.
> (...)
> I'm leaning towards explaining the basics in devref (mostly by copying bits
> from the wiki page) and adding a pointer to the wiki page, but if there's 
> consensus that the wiki page is supposed to be made obsolete by *moving*
> the contents to src:devref and leaving a pointer on the wiki page, I could
> also do that.

I agree with Stephan's and Sam's reasoning, I think the detailed
information should be in the devref.

A wiki is by definition open to edition by any (authorized?) user; the
devref has named editors (as you are very well aware ;-) ) and can be
seen as verified and curated information. I think the information
should be concisely explained in the devref, leaving the Wiki for more
full/detailed information on specific points, examples, or documenting
changes as they are discussed or implemented, while waiting for them
to arrive to the devref's next edition.


signature.asc
Description: PGP signature

Re: Debian's branches and release model

[Gunnar Wolf]

Thomas Goirand dijo [Wed, Oct 20, 2021 at 10:51:59PM +0200]:
> >> That's obviously what I'm doing. But when there's 2 releases during the
> >> freeze, it means one of them will never reach Unstable.
> > 
> > Right, which makes perfect sense.
> (...)
> > I guess very few will, but if it's needed, it's available -- and
> > the work for you when the freeze is done is much smaller (just
> > re-target changelog, re-build, re-upload).
> > 
> > What do you lose by those uploads not reaching unstable?
> 
> Very simple: an upgrade path. In most OpenStack projects, you cannot
> skip an OpenStack release, at least because of the db schema upgrades.

Uff, that sounds quite ugly :-(

...And what about providing Openstack packages whose name includes the
version, as Linux or PostgreSQL do? that way, if OpenStack releases
twice a year and Debian every two years, Debian X can include the four
OpenStack releases that have happened since Debian X-1... Or you can
continue running your previous OpenStack release if you so want, for
some extra years. It would be up to the sysadmin to jump from
OpenStack a→b→c→d before upgrading to Debian X+1 (which ships with e,
f, g, h).

It seems as very little gain for the huge framework that OpenStack
is. Now, OTOH, distribution maintainers could work together to pick
migrations. If you can pick all the needed bits from the d→e migration
and apply them in your postinst (if upgrading from d to f), you can
effectively skip going through e.

Of course, picking the migrations for every OpenStack release could
allow you to build intelligent (although probably obese) maintainer
scripts able to perform the needed updates you have, a→d, d→g, etc.

I guess I'm just stating obvious bits... and that the OpenStack
complexity would make this obviously harder. But if the process is
automatizable, it is doable (of course, with enough developer
resources). And fleshing out the needed migrations would benefit not
only Debian, but every distribution carrying non-consecutive OpenStack
packages.

Re: Debian's branches and release model

[Gunnar Wolf]

Thomas Goirand dijo [Wed, Oct 20, 2021 at 09:11:13AM +0200]:
> > You can upload it to experimental
> 
> That's obviously what I'm doing. But when there's 2 releases during the
> freeze, it means one of them will never reach Unstable.

Right, which makes perfect sense.

The group of people interested in having always the latest OpenStack
will be able to install from your packages in experimental. I guess
very few will, but if it's needed, it's available -- and the work for
you when the freeze is done is much smaller (just re-target changelog,
re-build, re-upload).

What do you lose by those uploads not reaching unstable?

Re: Finding rough consensus on level of vendoring for large upstreams

[Gunnar Wolf]

Phil Morrell dijo [Fri, Sep 03, 2021 at 02:04:44AM +0100]:
> On Fri, Sep 03, 2021 at 01:03:35AM +0200, Jérémy Lal wrote:
> > - should a package debian/control list bundled dependencies to make
> > sure to avoid duplications ?
> 
> Maybe? I noted in my final paragraph that Fedora has a mechanism for
> this that we don't, but perhaps Provides is sufficient.

Although it very seldom the case IMO.

Even if we don't take into account the horrible practice of vendoring
*and then patching* libraries done by some upstreams, we do ship (and
our shipped packages depend on) specific versions of libraries. One of
the ugly things about vendoring is that they bundle _other_ specific
versions of libraries -- and dependencies are often quite hard to
update without wrecking havoc in its whole ecosystem :-(

> I omitted this from the policy side, because it seems like this is
> already answered in ftp-master practice. Provided the vendored copy is
> not used during the build and unless there is a *different* reason for
> repacking with Files-Excluded, then I see no reason to remove it.

Completely agree. Many packages vendor i.e. rendering libraries to
produce their documentation at build time, and such libraries are not
needed for the package once built.

My example might not be great, because we still like building the
documentation (and thus they would not qualify for Files-Excluded,
only for omitting them from the binary package), but you get the idea
:)


signature.asc
Description: PGP signature

Re: Shall we serve scripts as application or as text?

[Gunnar Wolf]

Simon McVittie dijo [Sun, Aug 29, 2021 at 03:13:02PM +0100]:
> Using types outside text/ is definitely appropriate for very verbose text
> languages like SVG and "flat" OpenDocument, where it's *technically*
> text, and *technically* you could edit it with a text editor, but in
> practice that's rarely what anyone wants.
> 
> For scripting languages like sh and Python, I'm not sure: either way
> could be appropriate. Which is more common: sharing scripts as source
> code to read and edit, or sharing scripts as executables to download
> and run as-is? If the former, text/ makes sense, if the latter,
> application/.

I side with Paul Wise -- If a script is served by a Web server to a
browser, I don't think the desired result will be to download and
execute right away. text/* seems much better suited for me. Users
willing to execute said scripts should download and execute locally --
and nobody should be bitten by the surprise of automatic (even after
a UI acknowledgement) code execution of random Internet content.

Re: Future of /usr/bin/which in Debian?

[Gunnar Wolf]

Clint Adams dijo [Wed, Aug 18, 2021 at 04:20:02AM +]:
> > Besides, will the new "which" tool be installed in Debian by default? Since
> > debianutils is Essential:yes, not providing "which" tool by default could
> > probably break some existing packages.
> 
> My personal opinion is that no one should be using `which` in maintainer
> scripts and that no one should be using `which` in an interactive shell
> unless it is a builtin of that shell.
> 
> There are a ton of postinst scripts relying on `which` right
> now, which makes sense because `type` and `command -v` used to be
> optional extensions to POSIX and not guaranteed to be provided
> by /bin/sh.

I agree with you, maintainer scripts should not rely on 'which'
anymore. However, what about users? 'which' is a standard Unix tool
since forever, and I expect many users to experience head scratching
when told it's not cool to use it anymore.

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Gunnar Wolf]

As I said, on a separate mail...

Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]:
> In an ideal world, would the package manager not be a service utility
> to SUPPORT policy and adapt to changing environment contitions instead
> being a showstopper for innovation?
> 
> Who is the dpkg maintainer to challenge the decisions of the entire
> project? I fully understand that there is only ONE dpkg maintainer,
> but a utility THIS central to the entire ecosystem not being team
> maintained is a HUGE part of the problem.
> 
> And no, I cannot help and no, you wouldn't want me to write a single
> line of code in a package THIS central.
> (...)
> Would it not be dpkg's job to work around these flaws? It's not that
> every other component of a Debian system are perfect.

FWIW, I mostly agree with what you say here -- If the project decides
to a new standard (and, in this case, it has via the TC's decision --
which can of course be repealed by GR, if things come to that),
packages that behave differently... are buggy and should be fixed.

Of course, dpkg is a very special case for obvious reasons; I did try
to reach out to Guillem when we started discussing the bug at the TC,
and was disheartened by his harsh reply basically negating all
possibility of discussion because his non-belief in the TC itself.

There are technical issues that this migration will bring, and yes,
there is a nonzero chance some users will be bitten by the dissonance
between dpkg and reality. But after two TC bug resolutions (#914897
and #978636), and after lots of bytes have been spilled by various
people, I can only see work has to be put into making possibly
problematic cases less likely -- rebuilding and checking packages
don't ship files in the root directories will cover a great deal of
the distance. If aliasing the directories via symlinks is so messy,
well... we should focus on the root cause, and fix the rasons for it
to be broken as much as we can. The symlinks could probably be an
unconsequential footnote if this is done right.


signature.asc
Description: PGP signature

Re: merged /usr considered harmful (was Re: Bits from the Technical Committee)

[Gunnar Wolf]

Sorry to single you out here, Marc -- This goes to many people. This
goes, in fact, to the discussion itself.

Marc Haber dijo [Mon, Jul 19, 2021 at 07:12:24AM +0200]:
> In an ideal world, would the package manager not be a service utility
> to SUPPORT policy and adapt to changing environment contitions instead
> being a showstopper for innovation?
> 
> Who is the dpkg maintainer to challenge the decisions of the entire
> project? I fully understand that there is only ONE dpkg maintainer,
> but a utility THIS central to the entire ecosystem not being team
> maintained is a HUGE part of the problem.
> 
> And no, I cannot help and no, you wouldn't want me to write a single
> line of code in a package THIS central.
> (...)

While I agree with what you write here (will answer on a separate
mail), I'll ask you -and everybody- to please moderate the tone. It is
frustrating to speak in different wavelengths and not be able to hear
one another, but we are not going to get anywhere if we just SHOUT
LOUDER using our same wavelength. We must find some alternate
frequencies to get to a constructive situation.

Bug#990010: ITP: mymake -- A tool for compiling C/C++ programs

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
X-Debbugs-Cc: debian-devel@lists.debian.org, Filip Strömbäck 

* Package name: mymake
  Version : 2.2.0
  Upstream Author : Filip Strömbäck 
* URL : https://github.com/fstromback/mymake/
* License : MIT
  Programming Lang: C++
  Description : A tool for compiling C/C++ programs with minimal 
configuration

I am proposing this package as it is a build dependency for Storm /
Progvis.

Bug#990009: ITP: progvis -- Program visualization tool for C/C++ (and others)

[Gunnar Wolf]

Package: wnpp
Severity: wishlist
Owner: Gunnar Wolf 
X-Debbugs-Cc: debian-devel@lists.debian.org, Filip Strömbäck 

* Package name: progvis
  Version : 0.5.7
  Upstream Author :  Filip Strömbäck 
* URL : 
https://storm-lang.org/index.php?q=06-Programs%2F01-Progvis.md
* License : LGPL-2.1
  Programming Lang: C++
  Description : Program visualization tool for C/C++ (and others)

 A program visualization tool (written in Storm). Supports a subset of
 C/C++, and other languages supported by Storm. Aimed at showing how
 concurrent programs interact with pointers/references and other
 fundamental programming concepts.

<>

Progvis is an educational tool based on the Storm multi-language
toolbox that helps students visualize memory allocation, thread
interaction, synchronization, and several other things.

Progvis is built from the same sources as Storm (so, of course, this
packaging will include several bits of the Storm ecosystem). I will
also upload Filip's build system, called "mymake".

Re: Reconsider sending ITP bugs to debian-devel: a new list?

[Gunnar Wolf]

Steve McIntyre dijo [Fri, Jun 11, 2021 at 01:45:20PM +]:
> >I think the ITP mails can make reading the rest of the list difficult
> >without extra local filtering or steps.  Some times they are the
> >majority of the list traffic. I think it would be better if
> >ITP mail went to a separate, dedicated list, e.g. "debian-itp" to which
> >contributors are encouraged to subscribe and participate.
> 
> To be honest, I think if we did that we'd lose just about all the
> reviews that currently happen. The whole point of sending ITPs to
> d-devel is that they will be seen by a wider audience, but I can't see
> many signing up for YA mailing list for them.

I concur with Steve. Often, I decide to ignore ITPs, or get annoyed or
overwhelmed when very prolific teams (hi nodejs!) announce and set to
package hundreds of packages I won't have any interest on.

But WNPP is problematic on its own: Right now, we have 1586 normal
priority open bugs, 4613 wishlist open bugs (what would the difference
be? It seems *most* normal are O and RFA, while ITPs, RFPs and such
are mostly wishlist... but it's not entirely consistent) between ITA,
ITP, O, RFA, RFH. Quite probably, many of them have just slipped of
anybody's sight and will never be acted upon. Yes, they document work
needed, but are barely visible for us if we don't explicitly go out
searching for them.

We have 20 year old RFPs (#119911, even with nice bug numbers!), 17
year old ITPs (#237925). And this is news to nobody.

I do, however, find value in getting notices when people file new
ITPs. It helps me know what people are up to, and makes me notice some
interesting new things to be on the outlook for. Of course, an ITP
makes no promises... and my RSS reader is subscribed to the list of
packages approved for NEW¹.

¹ https://packages.debian.org/sid/newpkg?format=rss

So... All in all, I prefer to keep getting ITPs as part of this
mailing list, with all and the occasional thread that develops from
some of them. If we move them somewhere else, they will become
effectively irrelevant.

Re: Request for Pricing

[Gunnar Wolf]

Hello Tony,

I don't know where you got this mail address as a source for providing
the goods you need, but it's not correct -- Debian is a volunteer
organization that produces a distribution of the free "Linux"
operating system. We cannot provide what you require.

Andrej Shadura dijo [Fri, May 07, 2021 at 03:59:56PM +0200]:
> > I would like to get pricing on the following:
> > 
> > 525 meters x 2.0m High 
> > 
> > Qty : 350 pieces
> 
> I can sell you 350 pieces of 525 metres of Debian each for €1234567,- total.
> 
> Plz send moneys.

Hi Andrej,

Please don't answer like this to messages that arribe wrongly to
Debian mailing lists. It makes a bad, childish image to the project.

... And also, we don't want to create the reinforcement that, once
upon a time, led Debian to become wrongly associated with sheet music
for the "Dueling Banjos":

http://pigeonsnest.co.uk/stuff/debian-dueling-banjos.html

Re: Thanks and Decision making working group (was Re: General Resolution: Statement regarding Richard Stallman's readmission to the FSF board result)

[Gunnar Wolf]

Steve Langasek dijo [Tue, Apr 20, 2021 at 01:53:02PM -0700]:
> On Mon, Apr 19, 2021 at 11:25:50PM +0300, Adrian Bunk wrote:
> > On Mon, Apr 19, 2021 at 12:31:51PM -0700, Steve Langasek wrote:
> 
> > > IMHO, it's better to have a vote quickly on a limited set of GR options,
> > > with the possibility of a second GR if there is sufficient dissatisfaction
> > > with the first GR outcome, than to have community energy spent endlessly 
> > > on
> > > crafting a perfect set of options before we take a vote.
> 
> > You are saying that whenever there are 6 DDs who don't like the outcome 
> > of the first GR, they should start a second GR that repeals the first GR
> > and replaces it with something better as soon as the results of the 
> > first GR are posted.
> 
> Not exactly.  I'm saying that whenever there are 6 DDs who don't like the
> outcome of the first GR, *and believe it could be overturned with a better
> worded option*, they should start a second GR.

Cfr. the three votes on declassifying debian-private:

https://www.debian.org/vote/2005/vote_002
https://www.debian.org/vote/2016/vote_002
https://www.debian.org/vote/2016/vote_004

The first vote mandated the declassification of debian-private after a
three year period for "historical or ongoing significance". Eleven
years later, it became clear this mandate was untenable, and a second
GR was proposed to repeal it and set up a clearer set of rules
allowing for selective declassification under a given procedure. This
second GR did not succeed. A couple of months later, I proposed a
third GR, with the original text identical to the second one's. The
third GR had two amendments; the three options were ranked above FD,
and one of the amendments was chosen.

So, yes, a similar procedure could be done WRT any other GR decision
we have so far taken.

Well, except for de-electing a previous DPL whose term has already
finished, I guess ;-)


signature.asc
Description: PGP signature

Re: a proper-unix meta package (Re: Proposal: plocate as standard for bookworm)

[Gunnar Wolf]

Jonathan Carter dijo [Wed, Feb 10, 2021 at 07:29:14PM +0200]:
> >> Define "proper Unix"...
> > 
> > The definition depends on whether you are a longhair or shorthair.
> 
> If you're a proper blue-haired person, then the only proper Unix is Debian.

Please do note that your definition might be of sufficiency, but is
–to use our common parlance– a Suggests: or, at most, a
Recommends:. It has been observed there are many example cases where
hair style is orthogonal to Unix preferences.

Re: DAM Key and identity requirements

[Gunnar Wolf]

Mattia Rizzolo dijo [Thu, Sep 24, 2020 at 11:45:48AM +0200]:
> > >  * Minimum key size and acceptable algorithms are actually the domain of
> > >keyring-maint, and we just check those for them.
> > >At the time of writing this, a new key must be larger than 1024bits,
> > >ideally at least 4096bits, and capable of hashes stronger than SHA1.
> > >Please check [KDO] for more recent information.
> >
> > Hmm, this page do not really read like some sort of policy.
> >
> > It talks about key size in bits, which only applies to RSA.  What about
> > X25519?
> 
> You should bring that to the keyring-maints.  However I can tell you that
> EC keys are pretty much always considered good.

FWIW my key is EC25519. We doubted at first due to support for it not
being present in gnupgv1.x, but that's no longer an issue (no part of
Debian infrastructure runs below oldoldstable, which has 2.0.26).

> >  * A signature subkey must be there, since various parts of our
> > >infrastructure require it. Also, it is needed to build up trust (see
> > >below).
> >
> > Signing subkeys are pretty rare.  What is their use-case?
> 
> I believe the *sub*key bit was wrong, it most likely was talking about
> signing capabilities (like above for encryption, it's all about
> capabilities, not subkeys)

Right.

Re: RFC: Final update of DEP-14 on naming of git packaging branches

[Gunnar Wolf]

Seconded. Thanks!

Raphael Hertzog dijo [Sat, Aug 29, 2020 at 01:01:09AM +0200]:
> Hello,
> 
> following the recent discussions of June and of the last days, I'm
> proposing the changes below to DEP-14. Basically it replaces debian/master
> with debian/latest for all the reasons already discussed earlier. And
> it says that debian/unstable is preferred over debian/sid.
> 
> And it also marks the proposal as ACCEPTED given that it has gained
> traction over the years and that we didn't feel the need to make
> significant change to it.
> 
> I'm proposing debian/latest now because DEP-14 is already recommending
> upstream/latest and that makes the result a bit more consistent. But if
> enough person disagree with this choice, we can look into setting a poll
> to choose among all the names proposed so far.
> 
> Let me know your thoughts:
> 
> diff --git a/web/deps/dep14.mdwn b/web/deps/dep14.mdwn
> index 0316fe1..beb96ea 100644
> --- a/web/deps/dep14.mdwn
> +++ b/web/deps/dep14.mdwn
> @@ -2,11 +2,11 @@
>  
>  Title: Recommended layout for Git packaging repositories
>  DEP: 14
> -State: DRAFT
> -Date: 2016-11-09
> -Drivers: Raphael Hertzog 
> -URL: http://dep.debian.net/deps/dep14
> -Source: http://anonscm.debian.org/viewvc/dep/web/deps/dep14.mdwn
> +State: ACCEPTED
> +Date: 2020-08-29
> +Drivers: Raphaël Hertzog 
> +URL: https://dep-team.pages.debian.net/deps/dep14/
> +Source: 
> https://salsa.debian.org/dep-team/deps/-/blob/master/web/deps/dep14.mdwn
>  Abstract:
>   Recommended naming conventions in Git repositories used
>   to maintain Debian packages
> @@ -92,24 +92,28 @@ For development releases
>  
>  
>  Packages uploaded to the current development release should be prepared
> -in a `/master` branch.
> +in a `/latest` branch.
>  
>  However, when multiple development releases are regularly used (for
>  example `unstable` and `experimental` in Debian), it is also accepted to
> -name the branches according to the codename or the suite name of the
> -target distribution (aka `debian/sid` or `debian/unstable`, and
> -`debian/experimental`). Those branches can be short-lived (i.e. they exist
> -only until they are merged into `/master` or until the version in
> -the associated repository is replaced by the version in `/master`)
> -or they can be permanent (in which case `/master` should not
> -exist).
> +name the branches according to the suite name of the
> +target distribution (aka `debian/unstable`, and `debian/experimental`).
> +Those branches can be short-lived (i.e. they exist only until they are
> +merged into `/latest` or until the version in the associated
> +repository is replaced by the version in `/latest`) or they can be
> +permanent (in which case `/latest` should not exist).
> +
> +In the interest of homogeneity and of clarity, we recommend the use of
> +`debian/unstable` over `debian/sid` as it better conveys its special nature
> +as opposed to other branches named after codenames which are used for
> +stable releases.
>  
>  NOTE: If the Git repository listed in debian/control's `Vcs-Git` field does
>  not indicate an explicit branch (with the `-b ` suffix) then it 
> should
>  have its HEAD point to the branch where new upstream versions are being
>  packaged (that is one of the branches associated to a development release).
>  The helper tools that do create those repositories should use a command
> -like `git symbolic-ref HEAD refs/heads/debian/master` to update HEAD
> +like `git symbolic-ref HEAD refs/heads/debian/latest` to update HEAD
>  to point to the desired branch.
>  
>  For stable releases
> @@ -200,7 +204,7 @@ developers and the package maintainers are not the same 
> set of persons.
>  
>  When upstream is Debian (or one of its derivative), the upstream vendor
>  should not use the usual `/` prefix (but all others vendors should
> -do so). The main development branch can be named `master` instead of
> +do so). The main development branch does not have to be named after
>  the codename of the target distribution (although you are free to still
>  use the codename if you wish so).
>  
> @@ -293,3 +297,6 @@ Changes
>  
>  * 2014-11-05: Initial draft by Raphaël Hertzog.
>  * 2016-11-09: Extended version mangling to troublesome dots -- Ian Jackson.
> +* 2020-08-29:
> +  * Replace debian/master with debian/latest
> +  * Recommend debian/unstable over debian/sid



-- 



signature.asc
Description: PGP signature

¡El horario del MiniDebConf en español está en línea!

[Gunnar Wolf]

Hola,

¡Lo hemos logrado!

Sí, una vez más los hispanoparlantes logramos terminar con nuestra
tarea un par de días tarde, así que... Bueno, hace un par de días
deben haberse enterado que ya estaba publicado el horario del
DebConf20 - y había una serie de bloques "reservados para el
MiniDebConf en español".

¡Pues ya no más!

Los horarios para nuestro MiniDebConf quedan como sigue - horarios
UTC, hagan sus conversiones:

Domingo 23-ago

18:00-19:45 Octavio Álvarez:
Empaquetamiento de Debian: de novato a novato
20:00-20:45 anamhoo & zelfos:
apt install feminismos

Lunes 24-ago

18:00-18:20 Edwin Caldon:
Shell ZSH en Debian
    19:00-19:45 Gunnar Wolf:
¿Puedo usar limpiamente Debian en las Raspberry Pi?
20:00-20:45 Jonathan Bustillos:
Construcciones reproducibles en Debian (Debian
Reproducible Builds): Un camino verificable desde el
origen hasta el binario

Martes 25-ago

22:00-22:45 Lisandro Damián Nicanor Pérez Meyer:
Software libre en dispositivos médicos. El caso del
proyecto "Monitoreo simplificado de pacientes en
situación de internación masiva (MoSimPa)"
23:00-23:20 Emmanuel Arias:
Mi experiencia creando una comunidad local en una
ciudad pequeña
23:30-23:50 master:
Presentacion del mastermovil master1 una lucha contra
la obsolescencia programada

¡A difundirlo! ¡Ahí nos vemos, no falten!


signature.asc
Description: PGP signature

Re: DEP-14: renaming master to main?

[Gunnar Wolf]

Colin Watson dijo [Mon, Jun 22, 2020 at 10:13:31PM +0100]:
> I think my ranked preferences are:
> 
>  1. devel (for the sorts of reasons smcv@ gave; also, debian/devel is a
> nice allusion to this list)
>  2. trunk (historical familiarity from other VCSes)
>  3. main or maybe mainline (some tab-completion similarity to master,
> though the confusion with components in a Debian context is
> unfortunate)

I never really understood the word "trunk" when I used older
VCSes... Because, as a non-native English speaker, I always understood
"trunk" as the part of the car you store stuff in.

The "right" meaning is quite obvious, and it makes much more sense
when expressed together with "branches": What in Spanish we call
"tronco" (should be a giveaway! How come I never understood it
before?), the core part of a tree. Thing is, in English I always used
the word "stem" for it.

I'm only sending this message to help explain the term to other people
who might find it odd. So, a DVCS is a tree, and you can follow the
_trunk_ to find its "core" or "main" development direction.

There are many _branches_ splitting, first from the trunk itself, then
from other branches.

So, trunk makes quite a bit of sense for me in that light.

Re: Pimp your shell - Debian developer tips?

[Gunnar Wolf]

Hello world,

Like Paul said in his reply, I also have a "bash monstrosity" as a
Bash prompt. I last spent time tweaking it many years ago, so... This
migh reflect what my head was like in the past, not today :-]

I am attaching here the relevant portion of my .bashrc

> Basically the only improvements over lesser distributions we have are:
> * color: it's not for mere looks, but it visually separates output of
>   commands between themselves
> * full path from ~ (Fedora has only the last component which sucks)

I do consider this to be very important for me. I'm not inlining it
here, as mine is quite verbose, but the colors are defined in
promptFunc(). I don't really follow what you mean by "full path from
~" — Isn't it what \w produces?

> I would like to add at minimum:
> * current git branch (but not -dirty as that can take ages on large repos
>   on slow media -- you want changing directory to be instant)

Yes, I have all this set. I remember it being somewhat slow on large
repos, but I seldom notice it anymore (and on an SSD, it's seldom more
than a couple of seconds on a large Git tree that's not cached). Today
I see this as a heavy number of calls to git, and it always calls git
even if not in a git tree, but... Whatever ☺ This is defined in
parse_git_branch()

> * result of the last command

Yes, I find this to be tremendously useful. I don't absolutely like
the way I handle this (see LAST_RET at the beginning of prompt_func)

> Also, for people who use _many_ terminal tabs while logged on to _many_
> machines like me, I'd also suggest window title.  To simplify the code I've
> personally added parsing this sequence to Linux kernel (as of 3.16).
> I also put the title in ALL UPPERCASE if it's a root session, this helps
> while doing admin tasks.  There's no space for username so I give only
> machine name.

Makes sense. My window title was meant to reflect the previous command
run. But it reflects the last command that _finished_, amd that's not
always immediate.

I also print my regular username in green, but a root login is
presented in red (not only due to the '$' vs. '#' component).

> > I've read a bit on zsh and powerline and the like, but I am annoyed that
> > all those blog posts are quite superficial and do not mention security,
> > interoperability or performance aspects. Frankly any blog post that
> > recommends cloning random repos or even worse, running wget | sh something
> > gives me chills.
> 
> Aye.  Just bash in bashrc should be enough, without iffy Python daemons or
> similar stuff.

I agree. The code I'm sharing here is far from optimal, but it's easy
to follow (after... 5-10 years from its last modification.

> As for powerline: it's not in Unicode, and even worse, illegally uses code
> points that have since been assigned for something else.  Another version of
> powerline uses PUA characters, but also with ill-chosen codepoints that
> clash with popular assignments (CSUR, MUFI).

I'm not aware of Powerline, so I won't comment on it.

> Another thing I've tried but rejected is writing some stuff on the right
> edge of the screen.  This is easy to code and looks good, but causes nasty
> unaligned leftovers if you paste pieces of your console that include the
> prompt, with you not noticing until after the paste is done.

Agree completely.

So, without further ado, my prompt follows:

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

# Useful to know where we stand while using different version control systems
parse_git_branch() {
# Yes, temporary, dirty, yada yada yada. Works for me™.
# --exclude-standard does not exist on git <= 1.5
git_opts='--exclude-standard'
branch=`git branch 2> /dev/null | sed -e '/^[^*]/d' -e 's/* \(.*\)/\1/'`
if [ ! -z "$branch" ]
then
clean=`git status --porcelain`
if [ ! -z "$clean" ]
then
branch="${branch}*"
new=`git ls-files -o $git_opts|wc -l`
del=`git ls-files -d $git_opts|wc -l`
mod=$(( `git ls-files -m $git_opts|wc -l` - $del ))
if [ $mod != 0 ]; then branch="${branch}${mod}M"; fi
if [ $new != 0 ]; then branch="${branch}${new}N"; fi
if [ $del != 0 ]; then branch="${branch}${del}D"; fi

fi
fi
echo $branch
}

# set a fancy prompt (non-color, unless we know we "want" color)
promptFunc()
{
LAST_RESULT="$?:$_"
LAST_RET=${LAST_RESULT/:*/}
LAST_CMD=${LAST_RESULT/*:/}
VC_STATUS=`parse_git_branch`
case "$TERM" in
screen*|xterm*|rxvt*)
COLOR_RED="\[\e[31;40m\]"
COLOR_GREEN="\[\e[32;40m\]"
COLOR_YELLOW="\[\e[33;40m\]"
COLOR_BLUE="\[\e[34;40m\]"
COLOR_MAGENTA="\[\e[35;40m\]"
COLOR_CYAN="\[\e[36;40m\]"

COLOR_RED_BOLD="\[\e[31;1m\]"
COLOR_GREEN_BOLD="\[\e[32;1m\]"
COLOR_YELLOW_BOLD="\[\e[33;1m\]"
COLOR_BLUE_BOLD="\[\e[34;1m\]"

Re: [Summary]: RFC: Standardizing source package artifacts build paths

[Gunnar Wolf]

Michael Biebl dijo [Mon, May 04, 2020 at 11:51:05AM +0200]:
> >> Personally, I don't see any real benefit of standardizing on (making up an 
> >> example here) debian/.build over debian/build.
> > 
> > Same here. The arguments against debian/build are very weak. If we care
> > about a source package building a binary package named "build" or
> > whatever, it's really a unique case and surely it can be built with
> > some overrides and passing a different path where needed.
> 
> If you want to avoid name collisions, you could also use
> debian/_build
> 
> I kinda like the idea of prefixing *all* temporary directory with a '_'

Completely reasonable and almost auto-explaining, I'd say. +1 for
Michael's suggestion.


signature.asc
Description: PGP signature

Re: RFC: Replacing vim-tiny with nano in essential packages

[Gunnar Wolf]

John Paul Adrian Glaubitz dijo [Tue, Mar 17, 2020 at 08:40:43PM +0100]:
> >> The only problem you mentioned was vim-tiny (arch: any) depending on
> >> vim-common (arch: all) and these sometimes getting out of sync on Debian
> >> Ports.  I don't think that is a good reason to switch editors and there
> >> are other ways to work around that problem.
> > 
> > Agree.
> 
> The vim maintainer himself would like to get rid of the vim-tiny package
> and I'm not sure there is a compelling argument that you have to use a
> particular vi implementation in a minimal environment.
> 
> I wouldn't have a problem with vim if the package didn't fail its
> testsuite that often. While the last upload has helped a little, it's
> still FTBFS on five architectures [1], three of them in Debian Ports
> meaning I won't be able to build usable d-i images and several users
> have asked me for updated images already.

What about nvi? Yes, I just checked, it lists the QA group as the
maintainer... but if it is not RC, giving it more visibility can
attract somebody to maintain it (I won't volunteer, I know a bit
what's good for the project )

> >> But if we really wanted a minimal editor: `ed` is still there with an
> >> Installed-Size: 116 kB and no external dependencies besides libc6. It
> >> also works without fancy terminal features.
> > 
> > Well, yes. But while mostly everybody who reads this will be
> > moderately proficient with the basic subset of vi, I don't know
> > anybody who'd know how to drive ed (I have done it, but I surely don't
> > remember how to).
> 
> It's not about the size of the editor package but more about using an
> editor which causes less build issues.

...and which still works for the users. Yes, ed _can_ be used. But I
really do not think including ed would satisfy a regular user in need
to unbreak a minimal system...

Re: RFC: Replacing vim-tiny with nano in essential packages

[Gunnar Wolf]

Ansgar dijo [Tue, Mar 17, 2020 at 09:49:49AM +0100]:
> And Debian ships vim-tiny, not vim, as part of the minimal
> installation. That the same source package also builds other versions
> doesn't really matter for vim-tiny.
> 
> The only problem you mentioned was vim-tiny (arch: any) depending on
> vim-common (arch: all) and these sometimes getting out of sync on Debian
> Ports.  I don't think that is a good reason to switch editors and there
> are other ways to work around that problem.

Agree.

> But if we really wanted a minimal editor: `ed` is still there with an
> Installed-Size: 116 kB and no external dependencies besides libc6. It
> also works without fancy terminal features.

Well, yes. But while mostly everybody who reads this will be
moderately proficient with the basic subset of vi, I don't know
anybody who'd know how to drive ed (I have done it, but I surely don't
remember how to).

> Or have debootstrap not install any editor. But if I remember correctly
> that idea wasn't popular.

I agree with those that would oppose. Having an editor handy is core
to be able to get a Unix system out of many unexpected
situations. Having an Unix system without an editor is IMO having a
broken system. Could make sense for embedded targets... but nothing else.

Accepted raspi-firmware 1.20200114-1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 28 Jan 2020 12:49:12 -0600
Source: raspi-firmware
Architecture: source
Version: 1.20200114-1
Distribution: unstable
Urgency: medium
Maintainer: pkg-raspi 
Changed-By: Gunnar Wolf 
Changes:
 raspi-firmware (1.20200114-1) unstable; urgency=medium
 .
   * New upstream version 1.20200114
   * Updated standards-version 4.3.0 → 4.5.0 (no changes needed)
   * Replaced tabs with spacs throughout debian/copyright to comply with
 DEP-5 and keep lintian happy ☺
Checksums-Sha1:
 93f93702cef8b03316d01a7b1ca4e27a43c87155 1616 raspi-firmware_1.20200114-1.dsc
 4cad1adc1a4d295c8e04cb357b05331d45edfeb2 5568240 
raspi-firmware_1.20200114.orig.tar.xz
 e12269877ec4075e635a84d67254526f1f36b59f 24620 
raspi-firmware_1.20200114-1.debian.tar.xz
 406ecb4700d14edd108fbcb5c44e9f87780707f1 6261 
raspi-firmware_1.20200114-1_source.buildinfo
Checksums-Sha256:
 4a8dcb05ee5c3ba59a08616c0e0ca3340d42d84bcd86153dcd9ea733994c8d4e 1616 
raspi-firmware_1.20200114-1.dsc
 ec0767ab5960071f81d4181e8f3794df52eb9629e24d1c0a43e9ba34ced8c7e3 5568240 
raspi-firmware_1.20200114.orig.tar.xz
 c21b3831993a4b79b7c4f1c351af3b18e8baa84f26ce3e0f91c6ec52e5350baf 24620 
raspi-firmware_1.20200114-1.debian.tar.xz
 8d738a6a8742f1557b75b59d7daa6e3ce56884b3a2c26cced4e31a61d554704d 6261 
raspi-firmware_1.20200114-1_source.buildinfo
Files:
 adad9ee43c272f60f3c2b68dbe9fc537 1616 non-free/misc optional 
raspi-firmware_1.20200114-1.dsc
 96b8e31cdc0dc039b8d165e9142392ea 5568240 non-free/misc optional 
raspi-firmware_1.20200114.orig.tar.xz
 71458239d23bb657264d2db6d08ce94a 24620 non-free/misc optional 
raspi-firmware_1.20200114-1.debian.tar.xz
 5ac104b105ec8cea3529bcf8026cc8de 6261 non-free/misc optional 
raspi-firmware_1.20200114-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRgswk9lhCOXLlxQu/i9jtDU/RZiQUCXjCCsAAKCRDi9jtDU/RZ
iQo0AQCIXkNKjwn4LytyMAMMI6at+IodjyWXQCeWHrEPF5apsQEA+2Z1lFA817g8
JiDy+9syWGTz79HZXeHQaynVD2frMAg=
=/oNf
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2+git20191220-1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 20 Dec 2019 10:56:15 -0600
Source: vmdb2
Architecture: source
Version: 0.13.2+git20191220-1
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf 
Changed-By: Gunnar Wolf 
Closes: 922713 928485
Changes:
 vmdb2 (0.13.2+git20191220-1) unstable; urgency=medium
 .
   * Incorporate newest upstream changes
   * Added step to create /etc/fstab (Closes: #922713)
   * Always send the errors to stderr (Closes: #928485)
Checksums-Sha1:
 c0b25f4cbb67faf8190533469b84cb733d73c547 2097 vmdb2_0.13.2+git20191220-1.dsc
 5d46b84eb9c9ca16d99d4ea076c29c27af29f7c6 35093 
vmdb2_0.13.2+git20191220.orig.tar.gz
 3eb24d270452e6f8f1d69c01b9a8b7b3f4a96dd3 2976 
vmdb2_0.13.2+git20191220-1.debian.tar.xz
 5c47108b6d8558dc5ebedd20cf9f13aba3f36eee 10886 
vmdb2_0.13.2+git20191220-1_source.buildinfo
Checksums-Sha256:
 6bcd1f4b0609c41c539f7cf19147de82a954057389ef59d18b43bdff095eaa38 2097 
vmdb2_0.13.2+git20191220-1.dsc
 a36561ccf98240a2c33445027ce2f2eb57d6208f544d8425500e388d13f7dec0 35093 
vmdb2_0.13.2+git20191220.orig.tar.gz
 44d35b365243fa8d811a582a2147734bb5027ec76e073e34af651f6b9f4a91b9 2976 
vmdb2_0.13.2+git20191220-1.debian.tar.xz
 5e517e8003da46bba75afd42cd0f083ccc6a4c5d316b5e226be241d55b7bfd4e 10886 
vmdb2_0.13.2+git20191220-1_source.buildinfo
Files:
 d7e52d94209e6e444cf115fe4f54576b 2097 admin optional 
vmdb2_0.13.2+git20191220-1.dsc
 de46869142c62d4c66f9a376e3cc1045 35093 admin optional 
vmdb2_0.13.2+git20191220.orig.tar.gz
 6738a9f2dcbd16f76c9786f9f722cb30 2976 admin optional 
vmdb2_0.13.2+git20191220-1.debian.tar.xz
 89f38d93fcc76e53fcc688ee3a948dbb 10886 admin optional 
vmdb2_0.13.2+git20191220-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAl39AuAACgkQSd0qTkl5
YZyYPxAAscv+i8Ya64xS7jqVJtRazKkP98IxhSuJ/b1oStLaVb+YFbyf/X1/6Jcj
o+g6CsCjBmO8zlHnmxDaUXU5y8PyJvGIB4tFMkhFJNHz+9njpNx4vAHOsfHdSyHF
q8oN1UOefv29yCdqijgow5aOzG7hg2uIZ6d9HHZBYq4k9yWZPoKUf1wuA0fToism
j6Mb+alSAKJ5wdklcHo0f6BpSUgZAg23Jti6dI7BkehSkEUjYQnjJHLpZmm1WLd0
5URZAIKyfpwCoKkqI6IuMg0TzLSPWa3xXJZ6zb6jvsteeOUSBTH1TFX0dMQQC8eR
BHKwrl1wCuy/77DKnlowmjJuMnhPvs/4Td91NGwG5O7NaXGOf+FIS9olFSmaWzzx
UqBG55cZF4hmy9hTgHfDXWEfeNhlXH71/C2H2XcCuwo6p4fs7KiZcYsZSPNnDdef
tm5hwvOX1Cb47r1ZYovOoVcr8OzPMnfetTJTfHNAcn2stulGmjlzDPzrWIFdewzZ
A9tAgGlLA9KgoQI23tt3B8R4i2oIxuAfOJwxgco9d8JEYva9fPz7qzjCtduFShBU
z8npOl4DLy7KThnHmyxNc2fREL+DHj/LxXMe+4KtX2LLMP41RZ+q4DdTD1qzT7xi
NSmrHHVxy+zj86XxoFPu9dOuHpS6jQR1/SA1Ydzt3cbI0wm6iWo=
=u2t/
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2+git20191206-2 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 10 Dec 2019 17:39:34 -0600
Source: vmdb2
Binary: vmdb2
Architecture: source all
Version: 0.13.2+git20191206-2
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf 
Changed-By: Gunnar Wolf 
Description:
 vmdb2  - creator of disk images with Debian installed
Changes:
 vmdb2 (0.13.2+git20191206-2) unstable; urgency=medium
 .
   * Updated Vcs-Git and Vcs-Browser to the repositories used for Debian
 development (not upstream)
   * standards-version 4.3.0→4.4.1 (no changes needed)
Checksums-Sha1:
 9e73fb69ca09d357c53f2f47d615b66ad25363f2 2097 vmdb2_0.13.2+git20191206-2.dsc
 e9416dc8618d2cc3f1688b901914e209755bd61b 2908 
vmdb2_0.13.2+git20191206-2.debian.tar.xz
 2d1641dd799d82348f21af65d240246fe2579e87 11155 
vmdb2_0.13.2+git20191206-2_all.buildinfo
 d89cd69be0e5e06d1752e10a977c2405ebd57070 19248 
vmdb2_0.13.2+git20191206-2_all.deb
Checksums-Sha256:
 3ee39770cf16eb679ab0ad5e24e54e09ef195f1512dee0475229f30bbcf12a8b 2097 
vmdb2_0.13.2+git20191206-2.dsc
 ac377e0fd29977324c843f8fdeda0715eaee7fd28537101be4a43a984a4b03d6 2908 
vmdb2_0.13.2+git20191206-2.debian.tar.xz
 1ab09f00cbbd6726bd26f6e2e23f69c686d6197bf349c87e37478030215cf94a 11155 
vmdb2_0.13.2+git20191206-2_all.buildinfo
 c42046aa4f5cebfd740fafa7f26b9bc7f436a415cc64c0b2f37598c4f95c 19248 
vmdb2_0.13.2+git20191206-2_all.deb
Files:
 1077b7bd286f06bd61cf5108f0684e7f 2097 admin optional 
vmdb2_0.13.2+git20191206-2.dsc
 1977e396eeea607835695b6fff6b82c1 2908 admin optional 
vmdb2_0.13.2+git20191206-2.debian.tar.xz
 46b16cb4c4571fb1986c799b5df0 11155 admin optional 
vmdb2_0.13.2+git20191206-2_all.buildinfo
 3e7499209ba205458e9f7843a737ea0f 19248 admin optional 
vmdb2_0.13.2+git20191206-2_all.deb

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAl3wL7AACgkQSd0qTkl5
YZx6ww//ZBOGq8db+9MJTpRKZJVnh3cpx/DsmPpc3y47Uf5CLzklkQds+XIqU4fK
CRKnaw4WF+LJUdXLdo6CGUqaUj2oKcuDA5BbB6aheyUHfgYFv/OW2OXpZPLR4Oxz
nEqhF++Opczrjx3O3iS6xRrq7fv7tOHXK46TcgGWFeN4xH5WsGidF2WSx7IRDar2
25u+8NxRjhApkWwWH68XnaouRCnjB0Tks/0IW9xm6IaoRXgYyUX6IWX1kIDx1eTz
eagqnekteVTdCcWBW/13gy4U2dCxyrd3BUCkfHiL1phAN3pYs5uKvzQHl0ilKiD9
pMS44Vo5Zy82BWeCDe2NJju0Q11mh5XXe+Mrtdrm+fx+Iycjw5zAlTZlKnInBE5C
jHyCQSJRRQHYQ3KUIEGX5fle1b5YoJTAGwYsckCTXwtLuwjDQF/62LgkPyWwtx0W
gASIFxYw8HMfcK3mAN4rNE0TG/FfVTF5WQNeSm9Q+FmusWBhyT46HGBBit7lJN6T
9elMc239Dzc0YCRqMfISXNyKi9JnhM8YnxPsy9kQz/XWgRncA9E9y0flYHSkIbIx
qIV9nFUwcDkkUOKbiqtJmUn+VYOotOtMkAmkvqQUxp3urGELaxyX16TeTqODQIwv
AwjxDTVVTRaXV2+YxrEFIcxv4bWhPksIz2Krjr/H/PB5U7yyud4=
=8Nll
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2+git20191206-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 06 Dec 2019 10:47:42 -0600
Source: vmdb2
Binary: vmdb2
Architecture: source all
Version: 0.13.2+git20191206-1
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf 
Changed-By: Gunnar Wolf 
Description:
 vmdb2  - creator of disk images with Debian installed
Closes: 922660 922709
Changes:
 vmdb2 (0.13.2+git20191206-1) unstable; urgency=medium
 .
   * Adding Vcs-Git and Vcs-Browser fields to debian/control
   * Fix rootfs-unpacked to be rootfs_unpacked in vmdb2.mdwn.
 (Closes:#922709)
   * Drop build-dependency on pylint (its use has already been removed
 upstream) (Closs: #945480)
   * Patch for #922660 was incorporated upstream (Closes: #922660)
Checksums-Sha1:
 1536835c8a625328f3a0941a4dc46bc8ef4fb826 2098 vmdb2_0.13.2+git20191206-1.dsc
 0cbcff918ec544a40ca49875efb8848268d82a95 32715 
vmdb2_0.13.2+git20191206.orig.tar.gz
 a94f573587d1c977f5000e58075fe1ebf8eede39 2848 
vmdb2_0.13.2+git20191206-1.debian.tar.xz
 eecfd244171f6b6f48ae863610a3649bb2473399 19164 
vmdb2_0.13.2+git20191206-1_all.deb
 67df44cabf05902196b7667080d14762de6d133a 11155 
vmdb2_0.13.2+git20191206-1_amd64.buildinfo
Checksums-Sha256:
 8ac05a377e0c6b703185abba2578516788e4256d93e58deb0cdb82e2b353d91d 2098 
vmdb2_0.13.2+git20191206-1.dsc
 177490aedb8f9982a6869be9592469c8c2f376b0879cc4979907f387b4226793 32715 
vmdb2_0.13.2+git20191206.orig.tar.gz
 81543ab896a54fbd6e11b9d18c8ac4225428cc4bd1584aecfa6f8c44ae4f95a6 2848 
vmdb2_0.13.2+git20191206-1.debian.tar.xz
 43a7fb75ac6779cbe575a107ceeddb96f58fcda7d24888e39a03bc5b7413c463 19164 
vmdb2_0.13.2+git20191206-1_all.deb
 0d042f9ff9cda3fffbfe7e13f9389f6723426a981ea39513da10e8ec9448cdfc 11155 
vmdb2_0.13.2+git20191206-1_amd64.buildinfo
Files:
 dfda0347643cd75fbab1cef220d90b77 2098 admin optional 
vmdb2_0.13.2+git20191206-1.dsc
 a6008ecc4223898b87b02336f0f5ddde 32715 admin optional 
vmdb2_0.13.2+git20191206.orig.tar.gz
 409d679cf3f89a37ff6ee40eefd1ff44 2848 admin optional 
vmdb2_0.13.2+git20191206-1.debian.tar.xz
 bc9a4bc21d93105c46b0027da6d7d1ca 19164 admin optional 
vmdb2_0.13.2+git20191206-1_all.deb
 2eae3176f1d82ab037cabd8ab01b008f 11155 admin optional 
vmdb2_0.13.2+git20191206-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAl3rRH0ACgkQSd0qTkl5
YZzLXg//eq05JKzklzbFXp03HiolbvOYfqDyEkElt3FanaRoYlfLPkqmoAqLdjAS
V4fIxxPxpN6WLbuaafXS0NnJIMGPjSZBCtTxOX9qWxXEU0DqzncTTmj7GH+X9Qf5
/jAH/RNfb3QgR4ddGeYIP+QwvrxLixWCAd1tP7N/2cRhLCDtqf43LWC5wcLLNiwH
PD5ES30RVjekHWfoWw7kIa8SMUdR8fFVQQ4kUydSrBHifKKSUe0sOiy8J6a8KrmU
c7orHb6uDB875lG3MnTZNsUjS9TNstK1VYDLTKMXIZFnW1dDj27vwIKPD6q7WPbk
RY7CKjH0J6OfmEJMwExl1caDbBNmIMhQMlucCsqrI9dhpQTLlmI18rwTaZjvEpll
5KmLSBGXHC+AN5TywvyMV7VBknsNfvSjs8fxmbGwXu7QxJhXdlNeL4s8I8h9e/bT
of5vJRXa9Q+S5FFZkk9yzNn9R05d23StN2RUNzkxt6IS1YMpUDieUC5kwejqBX8A
/OT8keoLtYiibV5VXV07RfPlut/zJebY3qh0yiNgUlPatl/9jnlFNZ0q3dI5DcNd
lPq1IlZ4yLiTBsgnGoAg1j7ndE0Y6vsfI2zSIsI5PltkxBnbkjT8ksTP1Z92NNV5
/bnHJAcusReRYU0kRRJNmaXODkk9LP1MmTnXhFpUARRa5UC4zs4=
=Rm2r
-END PGP SIGNATURE-

Re: BITS from the DPL For September/October 2019

[Gunnar Wolf]

Simon Richter dijo [Wed, Oct 30, 2019 at 12:46:21PM +0100]:
> Hi,
> 
> On Tue, Oct 29, 2019 at 10:38:32PM +0100, Thomas Goirand wrote:
> 
> > If we have such vote again, I'll continue on this direction: I'd prefer
> > if we didn't have to vote.
> 
> >From a Policy perspective, packages are supposed to integrate into the
> system by providing init scripts, and Policy has a lengthy definition of
> how init scripts need to behave.
> 
> We need to at least mention systemd unit files at some point, so action is
> needed, and that action needs to be backed up by a vote to avoid being
> more divisive than necessary.

I completely agree with this -- It is time for Policy to specify at
least the equivalence of init scripts to systemd units.

Policy has always documented standard practice, so it was right for it
to lag before doing this. It is, I guess, time to revisit...

> So far, systemd adoption has been mostly smooth sailing because the
> ecosystem effectively consists of two blocks: the systemd core, which is
> centrally coordinated, and some traditional Unix daemons hanging off it,
> but essentially not integrating. This is about to change as projects
> actually start using systemd.

Yes. And that will be a thorn for people investing time in maintaining
Debian as an init-system-agnostic distribution. Or worse, following
the examples you provide :-\

> (...)
> All that requires way more complex unit files than anything we normally
> deal with in Debian, and we need to decide how much control we want to keep
> over package integration here, because that is what Debian does: take
> upstream software and provide a coherent integrated whole.
> 
> By leaving it unspecified in Policy what systemd features are expected in a
> particular Debian release, we essentially take a back seat in what should
> be our core competence.

Although by taking advantage of them, we will not be able to support
on an equal tier other init systems.

> If the project feels that these use cases are not worth supporting, then
> that is a policy decision that needs to be voted on, not just silently
> implemented, last but not least so we can update our marketing materials
> with footnotes on the "universal operating system" tagline, and users (who,
> after all, are one of our priorities) can adjust their expectations.
> 
> So yes, having a vote is necessary at this point. We've neglected setting
> policy way too long, the scope of the project is unclear at this point, and
> people are pulling in all kinds of directions.

Very much agree with this. It is time to revisit and think clearly
about what we win/lose, and where are we heading as a
project. Probably the only way forward is via the full GR process.


signature.asc
Description: PGP signature

Re: quedada debianita en Madrid jueves 3 de octubre

[Gunnar Wolf]

Holger Levsen dijo [Tue, Oct 01, 2019 at 03:36:44PM +]:
> On Tue, Oct 01, 2019 at 01:28:59PM +0200, Laura Arjona Reina wrote:
> > El próximo jueves 3 de octubre vamos a quedar alguna gente Debian (y quien
> > quiera sumarse) para tomar algo, a las 21:00 en Mercado San Anton -  Calle 
> > de
> > Augusto Figueroa, 24B, 28004 Madrid - Metro Chueca L5.
>  
> Anto Recio (some might remember him from DebConf9) and myself will be
> there.
> 
> Looking forward to meet some of you there!

Please hug him for me!


signature.asc
Description: PGP signature

Re: Survey: git packaging practices / repository format

[Gunnar Wolf]

Ian Jackson dijo [Tue, May 28, 2019 at 04:51:10PM +0100]:
> While trying to write the dgit FAQ, and some of the relevant docs, it
> has become even more painfully obvious that we lack a good handle on
> what all the different ways are that people use git to do their Debian
> packaging, and what people call these formats/workflows, and what
> tools they use.
> 
> Can you please look through the table below and see if I have covered
> everything you do ?

I don't know whether this is relevant to what you are asking, but:

>  Main packaging Delta from upstream Tools for manipulating
>   git branch represented as  delta from upstream,
>   contains   building .dsc, etc.
> 
>  Unmodified debian/patches gbp, gbp pq
>   upstream files,(only)quilt / dquilt
>  plus debian/* Manual patch editing
>  incl. d/patches

This could cover two very IMO different cases -- The git repository
is a clone of the upstream development repository, incorporating its
full development history (and perhaps sharing "existence" with the
upstream development), or the git repository incorporates only the
content of upstream released tarballs (i.e. via gbp / pristine-tar).
The packaging workflow is quite different between those cases.

Greetings,

Accepted raspi3-firmware 1.20190215-1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Sun, 17 Feb 2019 21:59:36 -0600
Source: raspi3-firmware
Architecture: source
Version: 1.20190215-1
Distribution: unstable
Urgency: medium
Maintainer: pkg-raspi 
Changed-By: Gunnar Wolf 
Changes:
 raspi3-firmware (1.20190215-1) unstable; urgency=medium
 .
   [ Gunnar Wolf ]
   * New upstream version 1.20190215
   * Added armel as a build architecture
   * Added Romain Perier as an uploader
   * Updated standards-version 3.9.8 → 4.3.0 (no changes needed)
 .
   [ Romain Perier ]
   * d/kernel/postinst.d/z50-raspi3-firmware: Allow the kernel image and the
 initramfs usage to be configurable from /etc/default/raspi3-firmware
   * z50-raspi3-firmware: Add RPI 1 RPI Zero W DTBs when booting linux directly
   * Add support for the armel architecture
Checksums-Sha1:
 3cec15faa99d2f0f82e987b2725253cd5f5792c7 2148 raspi3-firmware_1.20190215-1.dsc
 db757de23b5444e2df508b302fecd5b92ec23c43 13117124 
raspi3-firmware_1.20190215.orig.tar.xz
 cc8667872b3a159408aebd7ba8b713668e15bc9e 23088 
raspi3-firmware_1.20190215-1.debian.tar.xz
 b0954798cf8fcf0a712e95602d2306e7d1af986c 6898 
raspi3-firmware_1.20190215-1_source.buildinfo
Checksums-Sha256:
 8654185f2342d7ab379b1301c8c19dfe17cfe553609590d15ae4bab5e22de7cb 2148 
raspi3-firmware_1.20190215-1.dsc
 8b3e51e61b15b2a94f907d95d6a024a495767156d43ef178d66d7303b10b60fa 13117124 
raspi3-firmware_1.20190215.orig.tar.xz
 d79b8000e4bf68991caaabb4a0a8aa0f10051c810d738803735420247efc8338 23088 
raspi3-firmware_1.20190215-1.debian.tar.xz
 4a4fa8826dbe35041a0512d53599b3f10e5e426197a6b2613044078d27717f22 6898 
raspi3-firmware_1.20190215-1_source.buildinfo
Files:
 4db62d1f15dcce6fb1d8e3ab268c40dc 2148 non-free/misc optional 
raspi3-firmware_1.20190215-1.dsc
 ff5c383ea42cff1ea76bc60a21d523bb 13117124 non-free/misc optional 
raspi3-firmware_1.20190215.orig.tar.xz
 7192cb3b29d3a00bfe6fa5fc39b366ff 23088 non-free/misc optional 
raspi3-firmware_1.20190215-1.debian.tar.xz
 70d11883158c0fc42fd9a7ca032ca1df 6898 non-free/misc optional 
raspi3-firmware_1.20190215-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIyBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAlx1c3YACgkQSd0qTkl5
YZzYdw/3SwT4BpEUqtDxovqRmWPlked/jLQjxnoRvXo5Ee1CVT95wucHSQkeSvYB
xdfSL8YXOINw0tBnuRlIc3HV8SUvTQ4UFUCPJsj9ec4+cAecUSGCflJ0n5j85XDO
Suqz+xR7/QczTpA3fQj6jgg3Y1IR5mO/IIMXmNeYrowNse7azDqjx2mj/WpUmTYv
+n2+DM/Nh49qk21TAKqBzC7bXagb/3i068zdiGj+iED7tXxT3JvMg9ZV3QyaPuZf
w4eRWzssoU6vjb59gmc1BV/ZRFY2dE1rpBUr6wK9KF9SQjo4OACeWTMYv8O59IB/
kbWFqFD7wS5sAQ3ZAcymXf6L20QjgKn/TIKzAqemug9lpABmzDnSg4KFpMFqHvf4
Gb8gse81ic4mtpir3NGmZGrobw+z4Vbp3OMz1JreYd2rRM1nC65teaouapwYVfQ+
eUbbTM2LoCX+FxMDINokZwtjzJdbeN50Xq3Mq8cRrdQIQ60gvTHDfZZwgMu4KPMj
UVk7wI5bZF8jYTY83mRjMF2N5WmE6LRRk/jBP/9z5jFDxCBYbO8e8BzPfMFJNQyV
pMwVRfoDN5dusK+1EtsKOirWRBfzDED4pRbtoorf3MvVsp2x1Xx6tRSQ953tgMxX
xiCWDTUWoTJXflIiNblRI7LspXvN2xc7k7P5CsV38W9Cx7HHcg==
=IcQ0
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2+git20190215-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 15 Feb 2019 11:47:15 -0600
Source: vmdb2
Binary: vmdb2
Architecture: source all
Version: 0.13.2+git20190215-1
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf 
Changed-By: Gunnar Wolf 
Description:
 vmdb2  - creator of disk images with Debian installed
Closes: 922355
Changes:
 vmdb2 (0.13.2+git20190215-1) unstable; urgency=medium
 .
   * Stop specifying xelatex as the PDF engine for building documentation,
 and add both texlive-fonts-recommended and lmodern as
 build-dependencies, as both issues caused the package to FTBFS under
 pbuilder (Closes: #922355)
   * Add build-dependency on dh-python, lintian is happier now
Checksums-Sha1:
 8353ae131c92e970fcbe2eb23be8792dec5deb13 2003 vmdb2_0.13.2+git20190215-1.dsc
 f9b2ed035230d617e441d0156f026812ec7fe328 31797 
vmdb2_0.13.2+git20190215.orig.tar.gz
 9c683ae5f4014f77ef7a72d82d212934de14213e 2720 
vmdb2_0.13.2+git20190215-1.debian.tar.xz
 7da3678f44ffb0687105dd2bc2433d05940ebe9c 182316 
vmdb2_0.13.2+git20190215-1_all.deb
 215e44be3014e95580e496c48731b9ed5fc6125d 10093 
vmdb2_0.13.2+git20190215-1_amd64.buildinfo
Checksums-Sha256:
 ab01b28b88858edf48083049638c33492e9e175c844dfd33f718b46c6eaf8e68 2003 
vmdb2_0.13.2+git20190215-1.dsc
 e24a374a3fb4a7125ea1c90a4562d753b3c5d9d10a63544bb0f04008dced3d8a 31797 
vmdb2_0.13.2+git20190215.orig.tar.gz
 3cfb30b8ac544966f20012e89e1eaabe8f83e8c86aeb872ea809faa1e3d8a1f2 2720 
vmdb2_0.13.2+git20190215-1.debian.tar.xz
 900dfd83beb57d95a116281e7427b60944d55a33fa610a11347eec4cd0c76243 182316 
vmdb2_0.13.2+git20190215-1_all.deb
 be52b5d6f02bf1fdd409a4f89854d081652b05d4eabeb338fad7b57562ec 10093 
vmdb2_0.13.2+git20190215-1_amd64.buildinfo
Files:
 829a6cdb7a25eee9e4591d23c41b9abb 2003 admin optional 
vmdb2_0.13.2+git20190215-1.dsc
 392284ab708ade9f34c4282706bba289 31797 admin optional 
vmdb2_0.13.2+git20190215.orig.tar.gz
 1f33237364b3f1f41fb1a1e578849281 2720 admin optional 
vmdb2_0.13.2+git20190215-1.debian.tar.xz
 530fc3208d1baae72aa8ceceb54e4480 182316 admin optional 
vmdb2_0.13.2+git20190215-1_all.deb
 b1acf0b236c7d1b0425f762d12d58139 10093 admin optional 
vmdb2_0.13.2+git20190215-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAlxm/rIACgkQSd0qTkl5
YZy7fA//XY472qa9bNr3LlgqwmAxKhWifi5J1bREV41fgwuUG49aXxJhuARUws09
vfSTnayQQ16u6MKNl6H5IYsPy9VWhG3jbT4shDHoTXzI/yTN2QX/6ifgOgFOgjrO
KbDfqijzeP/I5nfRWErPt3o8WygFdfMsJiyFK+6nbUwEHS91YjMt72yEbesVJ99R
vXeHg/O4en2CPXA/nmi7BA10C8If2sAoiBAKTqJXkiuYdSqcLb/RO4kzSkzDfYkz
AEI5m8EgCkBUojXtE6GkEdCIPegimdzv3GhEgxMwEEMlg6RrVyE8KOrM67Ejc5tj
YBZdNd21kZpoXyME9BOvS0f4R1H9IVCEEsCDcxTn0HC+m0VPFWWSj/Qhp7S02A2S
Q3xjl4/1xISrsES0A5Oght83BB6puxuFIGLudYLWBHPDZ9etMPetTN44YC/SFlUW
7+7jcuwfqF6NKMZjcFaRQeavKC4LLiUhtpfFPbIKmyOBXPd3MEWK1GhNRX6ejAga
4VcY3aX9rzqDrU8PNSG8JSLcGBWW0ob/j4gvXUIXxmldEQrkrEOjocZ6gdx9UNcY
lwurMaypd1LXnj06soyXBIGNlqEGMiJLwsekiAjdYmDJ3H6HKwf6ORsIvF5Ul/QC
ibJh96Y99ffcW3gQE6J3hKUkmKa9tlTJYAyse0oh9/OS37/SRK4=
=U+v+
-END PGP SIGNATURE-

Accepted vmdb2 0.13.2+git20190214-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 12 Feb 2019 09:17:52 -0600
Source: vmdb2
Binary: vmdb2
Architecture: source all
Version: 0.13.2+git20190214-1
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf 
Changed-By: Gunnar Wolf 
Description:
 vmdb2  - creator of disk images with Debian installed
Closes: 907614 914027
Changes:
 vmdb2 (0.13.2+git20190214-1) unstable; urgency=medium
 .
   * New upstream version.
   * Add dependency and build-dependency on qemu-utils, for qemu-img.
   * Updated Homepage.
   * Build the manual and include it in the Debian package.
 (Closes: #907614)
   * Add build-dependcies for building docs.
   * Taking over maintainership, as upstream author retired from Debian,
 orphaning vmdb2 (Closes: #914027)
   * Bumping up standards-version 3.9.8 → 4.3.0, dh compat level 9 → 12
   * Get the version information from debian/changelog instead of git,
 fixing potential (not reported) FTBFS
Checksums-Sha1:
 4474bfd5d90af77ad0b4c0fea23882f0bd3ceb2f 1956 vmdb2_0.13.2+git20190214-1.dsc
 3dcad379d970d209f8d2e1973366e8771da8d74d 31911 
vmdb2_0.13.2+git20190214.orig.tar.gz
 d3760b43414e4433fb257103f96754a8bb9a7b38 2568 
vmdb2_0.13.2+git20190214-1.debian.tar.xz
 5bc1e986ef71105475fd7f1f52102137ef2e17d3 69632 
vmdb2_0.13.2+git20190214-1_all.deb
 df73b782c647131b7f713d1d6849abf6c84b2abe 11756 
vmdb2_0.13.2+git20190214-1_amd64.buildinfo
Checksums-Sha256:
 ec11a6f15eac577e5df20fd99d00c86e93c737677fd79d2f105a398eaf705a97 1956 
vmdb2_0.13.2+git20190214-1.dsc
 87eda3ab6a4137a57d4ce737d88bacc2a67303d96033f1535bdcba4210830ab9 31911 
vmdb2_0.13.2+git20190214.orig.tar.gz
 34581dc9ed8bdf4667e1b9e041fffdec7a13e163ae1f3eb8b6c2020d9e5c5c61 2568 
vmdb2_0.13.2+git20190214-1.debian.tar.xz
 ef95d392827eace0b107845e79a4e8697294f0368946b801d6635946cf661297 69632 
vmdb2_0.13.2+git20190214-1_all.deb
 e5f330c144d7c89bac54a982c727e786d807fa42af50f58e17d5152e1118012f 11756 
vmdb2_0.13.2+git20190214-1_amd64.buildinfo
Files:
 292b54e5f09f96f6abb448464b39b952 1956 admin optional 
vmdb2_0.13.2+git20190214-1.dsc
 e84283c277c14b149562c2e703aa2d0f 31911 admin optional 
vmdb2_0.13.2+git20190214.orig.tar.gz
 ab36f2aafcc7d1d19747df98512ed4ab 2568 admin optional 
vmdb2_0.13.2+git20190214-1.debian.tar.xz
 d4885da916390c7935e26341838f5460 69632 admin optional 
vmdb2_0.13.2+git20190214-1_all.deb
 c4d4afa930d9637ec13744ef746e 11756 admin optional 
vmdb2_0.13.2+git20190214-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAlxlnQ0ACgkQSd0qTkl5
YZz4bg//c8ty+6QoQw6GZr486/6WgMY/cDk63F+3sds2mHUF7BURXXeHeEeSahNo
GWxbq76XMtp+Hyd0UOg0vZbWQKHCSR5ex4w8peEQLodRJJ7iXRUewNW/RrGTpiaJ
GAikgYf+FFakMCtGbxGT7ZzO6hUik++R/6Yd8AyqTRX8elmN8O8RPvJo5igwgFeY
mmcbPqUBEQi54/iJptokyIofFF20Hlk4QD4kAhI8rVxyj0FgE2DziqfJBtZV2yhr
+j4aU9KH8QtgzJwl4MvcAX5d1qOfEkYpXzHVqGOKYG6wkMMt9Vy6q78rHvgZl/Qk
w5tTSdDMQrLsmN1EVMAjILK6MG9afqlQi6OiLPgofKiQh8z6X1YDZS7uUTMe0/J1
y4ET9qk8AnVE588j+qykq2bM6gbz4JEmJ5oQHKz1qCgHOj3upDMQMuCsohqjYkKj
9z02IZNyWUn4G7zLcEPgN1WlbMUm8TCFcZq7ZSega1oegX7zITZeKamV4bAtRA2Q
VIZmrasMPca5/rAKs3b85virL0Mj0Eeo41lOUgax+RVEkIQeYrRiWCQt8z/m8btt
FMFDp9x/DAlMvbiZwEEMavzYmYTpDuWz9QkjEyluV4tJfSx79iENFHTLSt0SPmmP
p5Xy9panFmvw2QdFWi64ZxyNqU8Vo7WZgEviUj/fXyxQp1co9Q8=
=NIU8
-END PGP SIGNATURE-

Accepted raspi3-firmware 1.20181112-1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 27 Aug 2018 19:00:06 -0500
Source: raspi3-firmware
Binary: raspi3-firmware
Architecture: source
Version: 1.20181112-1
Distribution: unstable
Urgency: medium
Maintainer: pkg-raspi 
Changed-By: Gunnar Wolf 
Description:
 raspi3-firmware - Raspberry Pi 2 and 3 GPU firmware and bootloaders
Closes: 897234 903543 910790
Changes:
 raspi3-firmware (1.20181112-1) unstable; urgency=medium
 .
   [ Gunnar Wolf ]
   * Added support for installing the 3B+ firmware
   * Add configurable options for cmdline.txt (Closes: #903543)
   * Add brcm80211/brcmfmac43430-sdio.txt,
 brcm80211/brcmfmac43455-sdio.txt  and brcm80211/brcmfmac43455.clm_blob
 via a quilt patch, to solve the issue of uscan not providing a full
 tarball to work from. Thanks to Romain Perier for his help! (Closes: 
#897234)
   * Make sure that firmware hooks get triggered after initrd hooks
 (Closes: #910790). Thanks to Matthias Lüscher!
 .
   [ Ondřej Nový ]
   * d/copyright: Use https protocol in Format field
   * d/rules: Remove trailing whitespaces
 .
   [ Romain Perier ]
   * Encode the files to be excluded from the orig.tar.gz in d/copyright so
 that uscan produces a suitable tarball
Checksums-Sha1:
 7eb377d9336d5126859334656191cd7a6ea41eae 2095 raspi3-firmware_1.20181112-1.dsc
 0a36e65bdd9575ea9cb3b869c9daf8d9fa5adbd6 16578608 
raspi3-firmware_1.20181112.orig.tar.gz
 653249a3049420097c6a2ccfd9f3c375e3256bcf 22492 
raspi3-firmware_1.20181112-1.debian.tar.xz
 7d319607c3e0ab9c73d4c38ae3f6a6ece99e7b7d 6922 
raspi3-firmware_1.20181112-1_source.buildinfo
Checksums-Sha256:
 099b4edf44e1c48ee706463f01e552257bd566461b56b78e5d6c42977184e0ad 2095 
raspi3-firmware_1.20181112-1.dsc
 08511cf9117858e47a5ef8c6b9601a4edcb95541082fc525a6cb436da6167032 16578608 
raspi3-firmware_1.20181112.orig.tar.gz
 9d91e1f4ba39f0439274f61c9a3a76036390cf9e2096a09f61f60b35c61dfa2c 22492 
raspi3-firmware_1.20181112-1.debian.tar.xz
 a853ae87a689c1e74447b2183dadca4482bfa170f0776b24952c35e1bcccb6ba 6922 
raspi3-firmware_1.20181112-1_source.buildinfo
Files:
 9e414d3e4505c77d7b6c4f79032aa10a 2095 non-free/misc optional 
raspi3-firmware_1.20181112-1.dsc
 8c9ec39a1f38bbb1f6d057b3ac41541a 16578608 non-free/misc optional 
raspi3-firmware_1.20181112.orig.tar.gz
 418b0a6cf219518a79ef5318ab1d7cf4 22492 non-free/misc optional 
raspi3-firmware_1.20181112-1.debian.tar.xz
 b457643ba81b0c373f9a427f8c8399bd 6922 non-free/misc optional 
raspi3-firmware_1.20181112-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAlv/NeYACgkQSd0qTkl5
YZzEaA//WqpzCqlAf8fdFQuzJDRKv7a2zoFoMl5tv/4VSfemanccG4MnHA7mhcGZ
no23yMx1D+dW+483r53NkP6/FEhiaDJ6yoZ5LbWuWds6jTmFghR/PK6rZwM6Q7RN
BOCtfnV+D5b15eqrKyAvfMnn/6fTYxtGvwgBkOAOX0Q/V9tzB4fWwYRVbS5to6l+
1NTUVoECSPRAghen5YreVBa4ouqGt708kNdttCZX4o7jm/zHBpHUqaCEgOukyxbW
RWdJW4DUTN3Oq0Js0ifnEoF5/MvRSZsr48UK3lOYQ04x/Z6xEtW2jsNNQbx4Iib1
te8qRuWRrFK5IsjbaXsvaUydzLwiwglrAayyY/l3UU4x+EPu0xCIt4hqfqd6QOMV
whYtUXtPLwASPE3rcT/G/clIJBXiL/PaSsX9MfZuYiAN/4dRJ8Rk96Aq/UJAJIQQ
iJQkcRyEpX8JwPlJb8M84G/oPQ2KnRFJ3cBRvbE5YsT9b4KwOCUt0PrcQ7ktKcw0
eO9BzHQxmr2mffCxpygqPMQeGy5ekfNf5kXP32pquZOryOPOu26NhaCe+TOMaeu4
IV4rVu2yWxea7FJ7Od4GgVOg7aGphF8tGQ9DRha6ajri5e2lsjDKpy6caeXivU9o
pVEMp1K3AFj6BgiPHZJQQUyZ+r4kSVhlNhHshIzNKSYlqiOHrJQ=
=9Ky3
-END PGP SIGNATURE-

Accepted listadmin 2.42-1.3 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 20 Sep 2018 12:26:39 -0500
Source: listadmin
Binary: listadmin
Architecture: source
Version: 2.42-1.3
Distribution: unstable
Urgency: medium
Maintainer: Noël Köthe 
Changed-By: Gunnar Wolf 
Description:
 listadmin  - command line mailman moderator queue manipulation
Changes:
 listadmin (2.42-1.3) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * The "trigger-happy NMU" release ☹
   * 2.42-1.2 included a fatal (syntax) error. Fixed it. Shame on me for
 not correctly checking the patch!
Checksums-Sha1:
 2b279af554673641fa9c33f343b0a699adc9d50b 1722 listadmin_2.42-1.3.dsc
 25bb6eee4d1cd987f8031e8f80b1281ac86bf5e1 4980 listadmin_2.42-1.3.debian.tar.xz
 4a4e033e4ec9953aef565e67f11f018fa4898ff1 6885 
listadmin_2.42-1.3_source.buildinfo
Checksums-Sha256:
 bed3fc08ed2c07530535e88b92eebe55c7e205e5c3d9d04cc49837f1d9fd35cd 1722 
listadmin_2.42-1.3.dsc
 d766fd7145c23192946a11b0b815f24012a8404d68d03962470cd55113773cc4 4980 
listadmin_2.42-1.3.debian.tar.xz
 a189930bc2b2da2f58887ecc66879e02d7efddcf55a043f51ada75ee09777061 6885 
listadmin_2.42-1.3_source.buildinfo
Files:
 8733322b0401210f81aaabb74e56c45e 1722 net optional listadmin_2.42-1.3.dsc
 83a8e8b1c1c6d1c7756b8df86a0032b9 4980 net optional 
listadmin_2.42-1.3.debian.tar.xz
 77a6e7cefeb4bc6e51e9a80fc3bacd19 6885 net optional 
listadmin_2.42-1.3_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAluj2JgACgkQSd0qTkl5
YZwF/BAAmKTvGlQTOrZhleSmnI/waEKj/2+6MybinRt5ZOwRPUDOWWxBBT7jZ9y0
slTDnU8uXvwXGQtmRiCbjPtQheW22suoM5AWNhiq/JzXT2EOa6y+0JYZq53Sz6nU
48GdxkTVAYJxVgoczAPzXvc11f8Vj/aRhQnzzkKbxfZyi+84r9XWLcSmyOX/HDeq
fS7mDCgkemSNHTdzqEkl3ZWYAruwQNM5hh2wc4BXlyaMDzUCguC29UtEIcqfcy4M
hcBBwIGkREU4sRL84VKapom8Obpjm5mR0RYMUdVeQfthrsdJ2XP/WASmSrkWrlu7
cb69jPRCf9ycE8Ik5CCylekv7s+gQ448RVkM2XEZ/MAw4X384dXiat2JSRSIZxXD
7q4DSP1qYPec0CWwbR+BaC+rFoxkGy7s5ECLKUMFCvbpLid4eiMMRw1001UTf4af
y6VtEeZBXQKfHaW5LCMbwAMTC8+0A2fzg66jjl8o6coerBT2qCuMd7xQ0pkR603y
T2r8TdEmh1NFk48OkwQSGo/MlilP7Jh4nGhdi6a3Ue0FvLVq/zZOhsPD9siA9bFo
V6L/by4KS2o9KS0nDM9ErTpq3P2Prke/w4bGQscr/FhgFvVXxbJVjTmLkuH6ZHdM
cVEQkbrAN73sLZLcS09Ub3/SDJC76Z3oz8THYk3nizO7LXjIOvs=
=weDS
-END PGP SIGNATURE-

Accepted listadmin 2.42-1.2 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 20 Sep 2018 11:40:56 -0500
Source: listadmin
Binary: listadmin
Architecture: source
Version: 2.42-1.2
Distribution: unstable
Urgency: medium
Maintainer: Noël Köthe 
Changed-By: Gunnar Wolf 
Description:
 listadmin  - command line mailman moderator queue manipulation
Closes: 909236
Changes:
 listadmin (2.42-1.2) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * My patch for #873287 caused logging to stop working. Fixed
 it. (Closes: #909236)
Checksums-Sha1:
 627a13d898ac66c9278660183c1b87b27fd4332d 1722 listadmin_2.42-1.2.dsc
 62d382d7fc1922eeb1617c260c494bc2aba8a7c2 4896 listadmin_2.42-1.2.debian.tar.xz
 d2d94527836bea12c90e95e7d9b24d9ff0fcd27d 6885 
listadmin_2.42-1.2_source.buildinfo
Checksums-Sha256:
 2329d1d6fd99b3df168cff926d9774dd17ed71bd4aac8c58db5f5bd813690465 1722 
listadmin_2.42-1.2.dsc
 4f64024e1befd5851335335557242fb6176761ed89a1d8a71d88624089a4ebea 4896 
listadmin_2.42-1.2.debian.tar.xz
 642429b9aea3556819ccd9c1c16f09f48b34e36a67cea36b0c4d323168775316 6885 
listadmin_2.42-1.2_source.buildinfo
Files:
 7094342682932331190f2fc3b2333bde 1722 net optional listadmin_2.42-1.2.dsc
 8a1b772cd1ad97a305e88cad313ab890 4896 net optional 
listadmin_2.42-1.2.debian.tar.xz
 dcec0f929f17a57157f6fc2bcb967b98 6885 net optional 
listadmin_2.42-1.2_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAlujzu4ACgkQSd0qTkl5
YZyYlA//esGNN9HP8/XY/xZBG6c1LqhLhNixCHzLzyTLK2CkYiEY0Blmy+PCwUGa
mG86+14gUvjnM4c6z6HJC1yA7NbRTtBPUY7E9PNVvcz/u9WnMbI6NJ4FqD9li7VQ
umYpiKQ1pz9QSO/rV2VTRCJsoz+zpAGryzYqt1BwJIxvUOvSj86j1grAVVdSXOlo
8uuKSdISkzdQ9BEeKfj798X9GgsHRkefrlinYB7TWutBM0CiO0GCGwuYFz5E450f
s/YbTVikUmRvlM/5J9hj1hDwj/909VKbtCW13Eff2NRa3bE664m9QSUgwWjttgHu
LkTmKrx1ysV9N2dtXi7Py+YmGhvpisPyzJplM8/CKCdxcwQ3DKTpoRJLP9KYMUES
e1cv1Z2jx1bkJxn8lPRjL6X0Hg1Gm08XqW51SJ+X7RckTNFs429BFlds6jRgiY/k
tFIJWFenN5Njlj3qQSamD2T8JOJxJmiMGBI5phrtSx0hFIh3jVd/q1lgla9Gw9sX
3ysEpoDV1WkBINmCwC6qKYdDjxl0GpGLJ5lWVc0Ao2gDZ29gS1G9Dub20F9jCSwA
EL4YdAt6ykjk98V42eAla0Lf3it9XfjgJPBJVKkkOIdTASeqq7HHJ0GTM/tRVzoT
XfWgPImYYzxbx52BD9STAkBxq1Tl5xMJaoEsoJWVocAHV618Mac=
=RRDc
-END PGP SIGNATURE-

Accepted listadmin 2.42-1.1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 05 Sep 2018 10:41:39 -0500
Source: listadmin
Binary: listadmin
Architecture: source
Version: 2.42-1.1
Distribution: unstable
Urgency: medium
Maintainer: Noël Köthe 
Changed-By: Gunnar Wolf 
Description:
 listadmin  - command line mailman moderator queue manipulation
Closes: 740891 873287
Changes:
 listadmin (2.42-1.1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Allow listadmin to follow HTTPS redirects for Mailman (Closes: #873287)
   * Fix insecure use of /tmp (Closes: #740891)
Checksums-Sha1:
 1724fe9be312fefac55a14d7027e97389f8397b7 1722 listadmin_2.42-1.1.dsc
 ebb46908cbb925826aa3840e6b764e45b8b1eaa0 4680 listadmin_2.42-1.1.debian.tar.xz
 e631e546eb1edc026bd395c72f983c9f58457b91 6886 
listadmin_2.42-1.1_source.buildinfo
Checksums-Sha256:
 6dbd77100779112ecfbf3c254624c6f1273eea1bc16cf1d0ab2bd379c80a9e34 1722 
listadmin_2.42-1.1.dsc
 96a6dfe45775e829be3e6c4991298cb8c0ba0ca873f5aafd46fd14cef83efba9 4680 
listadmin_2.42-1.1.debian.tar.xz
 6253d12079d7759bf8b25a0da2e4c8063bb01efd1fa5a1ba6d46b318286ecef6 6886 
listadmin_2.42-1.1_source.buildinfo
Files:
 48900798146df7e6792a3f0b1fa7229f 1722 net optional listadmin_2.42-1.1.dsc
 6f9ccaaf1f866499887675a4a7b4aba7 4680 net optional 
listadmin_2.42-1.1.debian.tar.xz
 383d903dee1a6d3fe422dea2b6c1cc62 6886 net optional 
listadmin_2.42-1.1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAluQDCwACgkQSd0qTkl5
YZymjRAAnq3CcxWOBpN9HStHa2wiPQd4JWG3stuQ28MMHDkO91EiqJov4gOiWPrg
L15tLf06GtCzhR/x+/BvFA/ylzzkSsEfcmWwfX4wdfD3BrCi7CUw1tt8NxWGte+P
1tnC5AbH4/DRLde46vd2PHdVnykolS+ovejtlwZL7hVXgO5PQ7zu3NaHHL/HzIlv
LqexfOAA7DKDacBRfhmKrM5c5/eG4UXvr3iMKg2h549rSKaWAm5+laJ5VJLFq9Oc
BXDADj90VXPLKbbkyVZaL/V0DbwTZpHRWvXhAMRAO/AxI2bHO0/cGyVlSpewru/R
4GKgiR2XTK7gZky2WsYCTAtN79r2COJZCt6qOV2mayY6uuxE3qqHvIs2RPeq0WzS
jYLbntM62e9Dj28RWrQkOJQjeRywt7vNHp+kH0vyDa6JE/i/1wNAZSACwsUhc9Ep
y+zMu225yYMJnzGEen0DwHRm3n4NGfk9E+RhwaHZ3BpSjtoyzCZvNzD8r85Ny9tR
8vpMGrIO+pho+KtsnVMk9mkWA3GJGJL7iKQdTelRh96wXrIaj9WZm3sZr7lfNtGo
bgGQlz2afQXKPINpkBBSfTJj9UTxGtL0Q/OyrnxzxBczZwINDxft5tW2rRvalPjr
XNGvsxdXTqemWiIRCeiD8I0peM+BJ4DegbqG8o5Q09advsDUy6g=
=Mant
-END PGP SIGNATURE-

Accepted raspi3-firmware 1.20180619-1 (source) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Wed, 18 Jul 2018 14:05:26 -0500
Source: raspi3-firmware
Binary: raspi3-firmware
Architecture: source
Version: 1.20180619-1
Distribution: unstable
Urgency: medium
Maintainer: pkg-raspi 
Changed-By: Gunnar Wolf 
Description:
 raspi3-firmware - Raspberry Pi 2 and 3 GPU firmware and bootloaders
Changes:
 raspi3-firmware (1.20180619-1) unstable; urgency=medium
 .
   * New upstream version 1.20180619-1
   * Added myself as an uploader
   * Updated the VCS URLs to salsa.debian.org
   * Differentiated the two proprietary licenses in debian/copyright to
 please Lintian
Checksums-Sha1:
 bafdf444e84e2ded3512a781fb810d9d779294ca 2092 raspi3-firmware_1.20180619-1.dsc
 698c2e44235961fa4b24e37c6eb4dcf7911fc886 6899344 
raspi3-firmware_1.20180619.orig.tar.gz
 5c1474cae720ca0f806a7a66a9d51b4b9d67d15f 11496 
raspi3-firmware_1.20180619-1.debian.tar.xz
 0b3d426e2d15adb62875fe3548d9e45b3c54d69a 6541 
raspi3-firmware_1.20180619-1_source.buildinfo
Checksums-Sha256:
 b708b2ea3ab0205cef9f967a73c9da60c151152811f04532bf9cc7786c7c0677 2092 
raspi3-firmware_1.20180619-1.dsc
 c006f12cc095ded09e4bc899daaefef40e861dc598ab05b67cbfddbf3a0c4dfe 6899344 
raspi3-firmware_1.20180619.orig.tar.gz
 34385ea0cd21114ce158865ca961792225cbf4fd78b23031a4c9587dc48f 11496 
raspi3-firmware_1.20180619-1.debian.tar.xz
 5a4b31cc5ffef3f337e5324070292baea83098eccf75c839f3048ec5a9a19ab3 6541 
raspi3-firmware_1.20180619-1_source.buildinfo
Files:
 7551e6c97779a0163aeab2e35008b08d 2092 non-free/misc optional 
raspi3-firmware_1.20180619-1.dsc
 c1168e0a9b16421263a511207d3195b8 6899344 non-free/misc optional 
raspi3-firmware_1.20180619.orig.tar.gz
 02647a9bae7355793c20f00acb9d19a0 11496 non-free/misc optional 
raspi3-firmware_1.20180619-1.debian.tar.xz
 a63c30e2f5db553c9141e43b235f6e12 6541 non-free/misc optional 
raspi3-firmware_1.20180619-1_source.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEfHleU5lojd9m99YgSd0qTkl5YZwFAluEiiwACgkQSd0qTkl5
YZx6khAArmQ0FhwYC4VF+Cs46WDLcym46RRp+4pzTPJSHydn7Cs5vXhlD8PdMTCK
BbVGmVl6kbwKYEGD7UKuago2RM1jLvR+R7ibexNTaSQ3LkMTD2Jr86rrCNHdt7Ez
DB9KN1mOGGR35CRfVxthI/xdpmtdcWdWjUUwL3cAvRiQsU+HJLUS1qT0CY/opj9o
ej0mO5Sndqbl5AH0M/dQ2sG5PIeZNQPNn2F5XZwZS7u+uASlb79UhzCHj/45Z1Ql
k1zuCG3KzYifxYjyjaivTHQXl1mQQFx6Rz4vXxz373SUFKMg5rhmjGRGsFkumLkX
hUKmiPq+ExitfZ+AEQ0N82Fci5LZ0cxpzdhPzzL41pba9x5DU+O0kNeAAqo/5mOP
eKa4OJl/kIcCO1lHCbfxMDkpbxaIJJcJk+Z/ZxeI+m5r4PwUUqAfUgZRqpZ+yrmZ
iq9S2XIfqfMk4RpOmlILlAvah0Mdx0gPzDRm8fJtLWkxp2Aa+rP3uwXHb7N3IbqQ
7AiSynMpDzyYedF9uovY1w9pWr3YMmKQrC0Zw94ghTgBoq2lpIqhmB23Ia+OXAwZ
Q0vgt/8KSD+oFaVcWW0PsWuPbvneAYmkJEJFv5jugy+/ZXfCtLb0KVJRucYO+p+U
vGJbm/LRuCiar1n7p2IJM58ElK1Ibcf2LdqkroEtd49vIfNTZpg=
=0X41
-END PGP SIGNATURE-

Re: Leftover in ftp-master.debian.org/dm.txt after DM -> DD transition

[Gunnar Wolf]

Boyuan Yang dijo [Sun, Aug 26, 2018 at 12:17:17PM -0400]:
> Hello all,
> 
> My role in Debian recently changed from Debian Maintainer to Debian 
> Developer. 
> However, my DM permission record [1] in
> https://ftp-master.debian.org/dm.txt are still left untouched. When I try to 
> remove them, I would receive errors:
> (...)
> Is there any way to get rid of those records?

Hello Bouyan,

I think we (keyring-maint) skipped a step in our keyring push last
Friday. I believe this should be fixed now - Please tell me if it's
not.

(And congratulations for becoming a full-DD ;-) )


signature.asc
Description: PGP signature

Re: Research survey: Impact of Microsoft Acquisition of GitHub

[Gunnar Wolf]

Ian Jackson dijo [Tue, Aug 14, 2018 at 04:33:46PM +0100]:
> Asavaseri Natnaree writes ("Re: Research survey: Impact of Microsoft
> Acquisition of GitHub"): > I am happy to announce that we are ready
> to release preliminary results of the "Developer Perception to
> Microsoft's acquisition of GitHub" survey. These results can be
> accessed at "
> https://naist-se.github.io/study-of-microsofts-github-acquisition/;. Again
> thank you for your participation and please feel free to share or
> discuss these results.
> 
> I'm sorry to say that I think this is a poor piece of work.
> (...)

Hello Ian,

I understand your frustration with the work shared with the author and
other linked people. However, this is not the way to answer to
somebody who is attempting to do a contribution to understand the
social weather after an important change.

The first part of your mail is... Maybe somewhat harsh (I would invite
you to review the "ignoring negativity" panels at this last DebConf;
that's not the communication pattern our project needs!), but this
last paragraph is frankly... Frightening.

> To debian-devel: Does someone here speak enough Japanese to find the
> contact email address for someone at NAIST who will take reports of
> potential problems with research ethics ?

So, maybe Asavaseri is a student struggling with methodology? Maybe a
researcher from a different field, who can use some correction in his
ways for this subject? For that, we would all thank you for most of
your mail.

But with this paragraph, your mail turned into a _threat_. That is not
something that should go down easily. I ask you not to pursue this
path.


signature.asc
Description: PGP signature

Accepted swaks 20170101.0-4 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 18 Jun 2018 13:00:08 -0500
Source: swaks
Binary: swaks
Architecture: source all
Version: 20170101.0-4
Distribution: unstable
Urgency: medium
Maintainer: Andreas Metzler 
Changed-By: Gunnar Wolf 
Description:
 swaks  - SMTP command-line test tool
Changes:
 swaks (20170101.0-4) unstable; urgency=medium
 .
   * Complementing the just-uploaded version, added the optional
 dependencies as either Suggests: or Recommends:
Checksums-Sha1:
 321a55973a22ed47b5cfa5f2ff42f8d5a7423298 1877 swaks_20170101.0-4.dsc
 d3bf5581ff41dba1e2db277dd520cd383af2cf52 6784 swaks_20170101.0-4.debian.tar.xz
 ce04d0e5813307605482b966441ecea1fbee3b74 86504 swaks_20170101.0-4_all.deb
 0e45e2f1dd0855e844cb1a96cba293078c469430 4577 
swaks_20170101.0-4_amd64.buildinfo
Checksums-Sha256:
 6c1f77fb46c2b6e121017b3dae3909d25ee9f449cfe2dd8570fb028bd627c433 1877 
swaks_20170101.0-4.dsc
 b251326d4dd80103aa47c1beba316706799e970d6f3df9c1c3c33dc01224ccf9 6784 
swaks_20170101.0-4.debian.tar.xz
 81a90b5b50a05d7bc4f124b5e5356c69a8bdb1a6841b4c1eb61c6c3df7ee1342 86504 
swaks_20170101.0-4_all.deb
 b82fa7063af26fe69f734682ef38ba1eef882f0c347b357a4f65a0432a27767b 4577 
swaks_20170101.0-4_amd64.buildinfo
Files:
 3385755a6e5877ce5f4ffb9d720e3a93 1877 mail optional swaks_20170101.0-4.dsc
 825eac7a2ec79977bd8f9d3463520389 6784 mail optional 
swaks_20170101.0-4.debian.tar.xz
 9fa3b65ff65c277f4282a2949f8da04d 86504 mail optional swaks_20170101.0-4_all.deb
 a667ba1482f6695f10b4365cd1787ffa 4577 mail optional 
swaks_20170101.0-4_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlsn89gACgkQZzoD5MHb
kh+wRg//RiSFB5ulOH9L80v0e1Yad5qSOMsF9u2FybMv//UmXMgplCPl+T9VCfBj
S7p9mO4UESYIvOM6ck8TIQM3KA2mq9+9q28Ad8FYJZ/cMhLz+2FyQn1va4xJwuHh
4l7qdyI3BToiowfb1zEfsuCeM5bq4qKNq4NDHeqTqcL3YtZg2NR9V7gVtZZEIvab
UE6rMEcNobYLbjyN9zqHuW62sqhJoF1Tz5ZMLyJJTg7zx6QkXpSE692eZ6zammck
uiRbfzhTloH96G9oyDm9A/0P8WK6OkiNikH/Ean1AAKzJXK7kIw/G4fKnecSGM5Y
75Qe/+noyct6ouKbQMjWZDPPWvdicUlprLF9+CKSqGGVJU0QRLhlOg4ETkUhswLq
QnL6wIKGPu4lXK9W0ux9t9k8foqKbve3lqCchR5jYqgqNxlV6QezplHO/0+Nv0BV
j2Dvnpd0xnAi+3iJnVKWGh1FZc6+3TKEjS58SY1/Fm10ebpW7LiIlvcigFhLjpfJ
UMjFO3qPrDe+GO39Zsuk/vSKP4gQ1vGmBJm+Xk7GjpFV7e3yUQifqhE6Atnt41a9
34UGXkGkNcC7cWn42swKmo/vRyfxONrxEE3hp8UWGelwqSHi+bfCCnPZHdLrrnD6
38QXqfQrRoecdY80E8DiXliwZRLK5nIju7b4K43zemBoFgCDqt0=
=EWai
-END PGP SIGNATURE-

Accepted swaks 20170101.0-3 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 18 Jun 2018 11:04:01 -0500
Source: swaks
Binary: swaks
Architecture: source all
Version: 20170101.0-3
Distribution: unstable
Urgency: medium
Maintainer: Andreas Metzler 
Changed-By: Gunnar Wolf 
Description:
 swaks  - SMTP command-line test tool
Closes: 901747
Changes:
 swaks (20170101.0-3) unstable; urgency=medium
 .
   * Update Vcs-Git, Vcs-Browser to point at salsa instead of alioth
   * Added Recommends: on libio-socket-inet6-perl (Closes: #901747)
Checksums-Sha1:
 99d5562ceac5ada5736e76ec9ab058ad35dce81c 1877 swaks_20170101.0-3.dsc
 314965323ba342879a5d39d5e225b3abf7da7438 6712 swaks_20170101.0-3.debian.tar.xz
 f36024d4e11cd3ae258a75c3e409df752136f7ea 86492 swaks_20170101.0-3_all.deb
 bee2f736e98c4f4504f1b7a22262d684c11ef140 4577 
swaks_20170101.0-3_amd64.buildinfo
Checksums-Sha256:
 82d23d7ad27dfbc4c8489a5dfde5717d0ce23a893e06bb0047e93e53c00edf60 1877 
swaks_20170101.0-3.dsc
 f4ca1fea71e6b18f48e3c88538001aabdeefc3c3167eeeada64aba76a08cbf69 6712 
swaks_20170101.0-3.debian.tar.xz
 82d260d9b9ff8fc2767097ca8d161504504cc1d5289825f7a2e9dec8f1631721 86492 
swaks_20170101.0-3_all.deb
 0b974d3520905a8ab1e0fd447d4a124cc997b39edf35feebf9a89511f2ffa487 4577 
swaks_20170101.0-3_amd64.buildinfo
Files:
 bec3755f4fc16f23f8b3be2daded4141 1877 mail optional swaks_20170101.0-3.dsc
 483e62d84d8070464a9f109c67c0242c 6712 mail optional 
swaks_20170101.0-3.debian.tar.xz
 223c410a2eb0b6d7a2b1c3320c854e25 86492 mail optional swaks_20170101.0-3_all.deb
 2c774b6172c4d13ce5b7e1d30bcbb3e5 4577 mail optional 
swaks_20170101.0-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlsn2jQACgkQZzoD5MHb
kh/BahAApuOwabjD9M1NsrgcKvYkSmsycl6fIcprmEKWZ2iUvxI0RO/9wULibGKN
gSBamInPMaBjucbJxAWojDFeDU0A3WjiclxaAKlJhgJeFg4IQHz+P7BuJVLA0zHh
HCgNc13qA98kJoudlWds70b1dew3976gQPxDEhUrTd3FjbrpWfcWYdCOKKppioR8
nCmnn0jlzZjcbTKSaKXQZ7k7hwBgl7b1jCuPXUuZ7MgqJMW4ZlSECXs2F/Y0A/iK
gou7+IUzjwfFiarufehDGN00y8cKnUmlIJRN+rPxrJZduqpmYUkziftGHlcqmeno
hr6s2odyrCG4obeZzy+6HxejzfJRY7rOKUV0VmQf5Ia0N3FQgypWKYlgyfAOQJc5
q3w49dAQXRWGE/FCEkqUyEfuvKLKm/tjumu2r8+fNb/epOBANz8EplLtmMl9zqJ8
qkYOHhGmhXx1YGsJAkWMMNKaQjusnO6cwACub57MBgueIuW5kdQ2YCKbVmjjnmlh
A1l569K+IsCwg1KkKgAEhF/BylZxaPQurJcXbtiu8awkLTyGn+QuqLUWKBr1cSLx
gyJLUxsVqdhfmp6RAomLqZBuFIJ6dqKs9OGc4qSNRKy0DRoenoHGmmijWdt11Mt3
YJ8XNpAvaa3nliiUYtUHrgx8Uke+JC2w3Weakc5v4XbFJtjmRHk=
=vQf3
-END PGP SIGNATURE-

Re: Bits from the release team: full steam ahead towards buster

[Gunnar Wolf]

Matthew Crews dijo [Wed, Apr 18, 2018 at 01:10:06PM -0400]:
> On April 18, 2018 9:19 AM, Gunnar Wolf <gw...@debian.org> wrote:
> > But why would ü not be part of the sorting? Yes, that was my example
> > before you censored my thought process - In Spanish, [áéíóú] and
> > [aeiou] share the same spot while ordering, as do ñ and n, as do u and
> > ü (and we have no further diacriticals). I understand that German
> > sorts äöü at the end.
> > 
> > But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
> > school, "ch" and "ll" were treated as single letters (sorted
> > respectively between "c" and "d", and between "l" and "m". So,
> > thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
> > and lobster < llama < manatee.
> 
> Not speaking as a programmer, but as a native American English
> speaker...
> 
> Your example is incorrect sorting behavior in English. Although
> Spanish might sort their words that way, English does not have
> double-character letters; ch and ll are treated as c then h, and l
> then l, for purposes of sorting. Therefore in English, it is correct
> that we sort cheetah < cow < dinosaur, and llama < lobster <
> manatee.
> (...)

Right - I was giving an example where a Latin-alphabet-using language
might sort differently than the C locale.

FWIW I *believe* we don't do that anymore in Spanish. But old
dictionaries did have this behavior. So, point in case – If you want
to sort, use numbers.

Re: Lucas Kanashiro and Athos Ribeiro hijack my package

[Gunnar Wolf]

Athos Ribeiro dijo [Tue, Apr 17, 2018 at 06:31:31PM -0300]:
> (...)
> I can not change what had happened here but I hope we can put this
> behind us and move forward.
> 
> @debian-devel:
> 
> I am sorry my past actions have been taking so much time of everyone
> else, which could be put into something more productive for the
> community.

Athos, I'm writing this mail as a reaction to what Lucas wrote about
your engagement, and knowing the energy it takes to run a real-life
technical meeting of people.

Erroneous process handling and failure in communication are something
that happens to us all, something that you will stumble upon sooner or
later. I hope this episode does not "scare" you away from Debian.

I processed a person through his New Maintainer process, and as a part
of our interview, I asked him for points he would change in our
foundation documents (in this case, the Social Contract). And, yes, as
he detected an incongruence, I prompted him to push the project to fix
it.

My fault.

But he did propose a General Resolution (GR) to modify the social
contract. And there was quite a bit of backlash from the project,
mainly from old-timers who... knew how a similar GR went, many years
ago.

I feared this would push this new DD away from contributing to the
project. Happily, not only he became a very active DD, but works very
closely with some of the people that made the criticism of his
proposed GR. He put life back in the policy editor's role,
and... Well, no point in anonymizing details anymore, as only one
person fits the description I gave so far :-]

I hope, in due time, your story in Debian reads as this one.

Re: Bits from the release team: full steam ahead towards buster

[Gunnar Wolf]

Stephan Seitz dijo [Wed, Apr 18, 2018 at 05:11:47PM +0200]:
> On Mi, Apr 18, 2018 at 02:47:11 +, Holger Levsen wrote:
> > On Wed, Apr 18, 2018 at 10:23:29AM -0400, Michael Stone wrote:
> > > really? there's more than one alphabetical order for english words?
> > yes, sorting depends on the locale... :)
> 
> Can you please give an example for the sorting difference in different
> locales if you only have english words (and I would say it means only ASCII
> in this case)?
> 
> I know that there are differences if you have words containing non-ASCII
> characters like ü.

But why would ü not be part of the sorting? Yes, that was my example
before you censored my thought process - In Spanish, [áéíóú] and
[aeiou] share the same spot while ordering, as do ñ and n, as do u and
ü (and we have no further diacriticals). I understand that German
sorts äöü at the end.

But... Ok, lets stick to 7-bit ASCII as defined. When I was in primary
school, "ch" and "ll" were treated as single letters (sorted
respectively between "c" and "d", and between "l" and "m". So,
thinking with an Ubuntu slant, we would have cow < cheetah < dinosaur
and lobster < llama < manatee.

Re: libzstd_1.3.3+dfsg-2_multi.changes REJECTED

[Gunnar Wolf]

Chris Lamb dijo [Wed, Apr 18, 2018 at 12:52:18PM +0100]:
> (...)
> Whilst this is not the most egregious example, I am not enjoying
> this recent trend of almost-immediately escalating issues to our
> mailing lists.
> 
> As has been pointed out elsewhere, people make mistakes in
> technical matters and in judgement. Jumping to publically naming
> and shaming folks is rarely the best solution to these mistakes,
> irrespective of what one thinks of the importance of an outside
> image.
> 
> If one feels hurt or aggrievied by an interaction that might be
> completely fair and legitimate (!) but the "junk" energy you feel
> in the moment of dashing out a publical riposte has long-reaching
> negative effects both on yourself and others that I am certain you
> do not intend.

Thanks for this reply, Chris!


signature.asc
Description: PGP signature

Re: Invitación Lección Magistral de Jesús M. González Barahona - Fuenlabrada, 6.4 a las 19:00

[Gunnar Wolf]

Gregorio Robles dijo [Mon, Apr 02, 2018 at 10:55:33AM +0200]:
>   Estimados desarrolladores de Debian,
> 
>   os envío noticias de este evento, de especial interés si sois de Madrid y
> si conocéis a Jesús, antiguo desarrollador Debian. Aceptad mis disculpas el
> resto.
> 
>   A mitad de camino entre lo que hacen en Alemania los 'Professoren' al
> cumplir los 50 años y lo que organizan en Francia p.ej. a los nuevos
> catedráticos de la Académie Française, sus antiguos estudiantes de
> doctorado tenemos el gusto de invitarte a asistir a una lección magistral
> impartida por del Prof. Dr. Jesús M. González Barahona.

Me encantaría estar por allá y tener oportunidad de saludar a Jesús,
con quien he coincidido físicamente en muy breves y pocas ocasiones,
pero a quien tengo en muy alta estima.

Gregorio, por favor envíale un fuerte abrazo de mi parte.

(y va uno más para ti, aprovechando la oportunidad ;-) )


signature.asc
Description: PGP signature

Accepted drupal7 7.58-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Mon, 12 Mar 2018 12:04:53 -0600
Source: drupal7
Binary: drupal7
Architecture: source all
Version: 7.58-1
Distribution: unstable
Urgency: high
Maintainer: Gunnar Wolf <gw...@debian.org>
Changed-By: Gunnar Wolf <gw...@debian.org>
Description:
 drupal7- fully-featured content management framework
Closes: 894259
Changes:
 drupal7 (7.58-1) unstable; urgency=high
 .
   * New upstream release
   * Fixes critical security vulnerability SA-CORE-2018-002, CVE-2018-7600.
 (Closes: #894259)
   * Move repository from Alioth to Salsa; update Vcs-Git and Vcs-Browser
 accordingly
Checksums-Sha1:
 1261c61d5ed59396a106b6bda86827c8f6e0a8f1 1854 drupal7_7.58-1.dsc
 b5bebe67682c24792316c4bb591c968f146e4799 3281269 drupal7_7.58.orig.tar.gz
 3373ddcc54a40f97f679c16f66f917ec2cf9441d 187700 drupal7_7.58-1.debian.tar.xz
 9ce17cc187df6cf6f24d22b3a7643daec25dbbc9 2525936 drupal7_7.58-1_all.deb
 7e9dbdfcdbf132965178580518bf1f64d4a79a14 8694 drupal7_7.58-1_amd64.buildinfo
Checksums-Sha256:
 1c76c0f5ef7bc601e26b8eb84f019c887ce75cf4cf360051703cbe70cb1f25e6 1854 
drupal7_7.58-1.dsc
 33d29980593477ab1504d21e4bf10455f6a386935a88b34ac6d14aaf94c42272 3281269 
drupal7_7.58.orig.tar.gz
 77478d6afc7c0f852c984a3ce27f0acdddca8030fadfc15985cb77c954170544 187700 
drupal7_7.58-1.debian.tar.xz
 97ebacd461081635432c9da555b1e29f78773da3d39c600249617ac1acc59535 2525936 
drupal7_7.58-1_all.deb
 c5b5bd426cc25fdc4e74515c1baf978d0ffcd7b4797fccaf95369f1dfac6a1b3 8694 
drupal7_7.58-1_amd64.buildinfo
Files:
 61bda42ca213d26f0ceb2f8074deaca5 1854 web optional drupal7_7.58-1.dsc
 c59949bcfd0d68b4f272bc05a91d4dc6 3281269 web optional drupal7_7.58.orig.tar.gz
 0a4d96a4ad6333fa0077fdf0899e871c 187700 web optional 
drupal7_7.58-1.debian.tar.xz
 e083fb3b5f961801af6ea09e3c952aa7 2525936 web optional drupal7_7.58-1_all.deb
 7bbf466196e14c256a50a96cfa6db0b5 8694 web optional 
drupal7_7.58-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlq8KckACgkQZzoD5MHb
kh9wCw/9FF4wtGNRzkSoxwquElhED9OgSbBWNn9qjnHGeUTEu1j4xAuBDZmBJtJu
COsvXNjl5GVZNy/tMtp0kzcbDYYI05WwzYtnLuAhWRMuT/Am0+dsEQFXsnPkFhri
lAC0Xmb5fJg8bs38EvOP/zE5lOhKCpPMjUjf+NKXNsc/ngtCj5Y8dwoGnvmVQ7fq
VJxzgOeTIT0q24DZs1n5W60/GsPV6fjczK9c8OfWWfql49OkncUU+nCXkCiJE+Bq
Kinb7tctETGuidCwpTVHOaQZfPJYoa3QLfS4+L/X/dlGELVoI2EaWOa38bvbxgBy
wABwIz4w/PdRuIkSpbeq1eNO8PmCoFOYta/GF6bRixu4d4iYxExG/EEHzElBSO3F
mCXJiVUYlu8W1Hlx+RmgERNHk51TVxa5NlUUCGeAo6uY4uwHWb73YyI+u1AKDv9+
1zrWc0xBqTuvMobzies//NgtBst8d6vrM+OYadx4kUuSg5ZaBdC7T4w1XXIsRXL+
jNhlXCX9sdu+/nibft/jib2zdj4T4I1wecqgDEZWxeGoxFyzMf+eKnebX9PRa/ND
nNXbmxaLnnCuPwmii1tIGOpwdnaJcDqQ8o+EVabQn/Ftm3hfUYzkXhMXLDb/M3to
cI0s3rMWCeB0xHKhwIRhcfg3mhK9+AJGzWEMyLq8y8ftjGDe3f8=
=jRBh
-END PGP SIGNATURE-

Re: Bug#880014: Technical committee appointment

[Gunnar Wolf]

Thomas Goirand dijo [Mon, Mar 26, 2018 at 10:18:18PM +0200]:
> On 03/16/2018 07:51 PM, Gunnar Wolf wrote:
> > I have to pick a nit here - I know this mail probably comes from a template
> > and you are repeating what used to be true here. But, according to GR
> > 003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
> > the "Chairman".
> > 
> > ¹ https://www.debian.org/vote/2016/vote_003
> 
> Does this mean tech committee members can sit on Didier? :)

I have been part of different conference organizations, including of
course DebConf. In more formal ones, they have the figure of the
Conference Chair (the person in charge of logistics) and of the
Standing Committee (year-to-year group of experts that oversee
conference organization and provides it with "prestige").

Of course... It is striking that the Standing Committee does not make
better use of the Chairs!

Re: Bug#880014: Technical committee appointment

[Gunnar Wolf]

Chris Lamb dijo [Fri, Mar 16, 2018 at 06:14:37PM +]:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> Dear fellow developers,
> 
> As defined by our constitution (§6.2.2), the Debian Technical Committee
> has recommended the appointment of Simon McVittie (smcv).

Yay! Welcome on board!

> I am extremely happy to follow their recommendation and hereby appoint
> Simon as a member of the Technical Committee, effective immediately.>
 
> For reference, the nomination of Simon may be followed at
>  and the Committee now consists of:
> 
>   * Didier Raboud (chairman)
> (...)

I have to pick a nit here - I know this mail probably comes from a template
and you are repeating what used to be true here. But, according to GR
003 in 2016¹, Didier is the "Chair" of the Technical Committee, not
the "Chairman".

¹ https://www.debian.org/vote/2016/vote_003

Thanks!


signature.asc
Description: PGP signature

Re: FTP Policy Development

[Gunnar Wolf]

Steve Robbins dijo [Sat, Mar 03, 2018 at 01:15:35PM -0600]:
> (...)
> To me, one of the puzzling aspects is why the FTP policy work has been so 
> secretive.  The release team has a mailing list, tech committee has a mailing 
> list.  There is Debian Policy list.  It doesn't seem in congruence that the 
> ftp team is making their policy behind closed doors.  Should it not flow from 
> Debian Policy and be debated on open lists?
> 
> Or maybe it is all open and I simply haven't found it.  If so, I would 
> gratefully accept pointers.  Concretely: where would one find the 
> deliberations behind https://ftp-master.debian.org/REJECT-FAQ.html ?

Ummm...

Not that I know much about how ftp-masters work internally. But I have
been on several other Debian teams. In general, all decisions are
taken in the public - But it is by far not uncommon to resort to
private communication for many of the non-obvious, contentious
cases. There are *always* cases where you want to discuss something
without the affected actors being part of the loop.

Yes, Debian as a whole strives for openness, and you will often see
calls to "get out of private" whenever interesting discussions taking
place. But I would perfectly understand and support a ftp-master
workflow that routinely involves private communication - Their
decisions, although non-personal in nature, can be *felt* as personal
attacks. 


signature.asc
Description: PGP signature

Re: [Pkg-javascript-devel] three.js_80+dfsg2-2_amd64.changes REJECTED

[Gunnar Wolf]

Pirate Praveen dijo [Thu, Mar 01, 2018 at 03:15:42PM +0530]:
> >> 1. If a single ftp master is in disagreement, there should be a team
> >> decision (in previous cases of disagreement also, other team members did
> >> not get involved).
> > 
> > I'm lost already, sorry. As I understand the case of three.js's recent
> > rejection, no other ftp-master said anything and thus there cannot be
> > any dissention.
> 
> I think it would be better if that is made explicit else how many days
> should someone wait to see no response and assume no dissent? or is to
> be always assumed there won't be any dissent?

We should not wait for dissent just forever. The issue you mention was
rejected by ftp-masters, then brought to the TC, then dismissed by the
TC as not-our-role-to-overrule-delegates, and some more days
passed. Do you really think there's a brewing dissent within the
ftp-masters team that has not yet bubbled to become public?




signature.asc
Description: PGP signature

Accepted drupal7 7.57-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 23 Feb 2018 13:37:09 -0600
Source: drupal7
Binary: drupal7
Architecture: source all
Version: 7.57-1
Distribution: unstable
Urgency: high
Maintainer: Gunnar Wolf <gw...@debian.org>
Changed-By: Gunnar Wolf <gw...@debian.org>
Description:
 drupal7- fully-featured content management framework
Closes: 891150 891152 891153 891154
Changes:
 drupal7 (7.57-1) unstable; urgency=high
 .
   * New upstream release
   * Fixes multiple security vulnerabilities, grouped under Drupal's
 SA-CORE-2018-001 (CVEs yet unassigned):
 - External link injection on 404 pages when linking to the current
   page (Closes: #891154)
 - jQuery vulnerability with untrusted domains (Closes: #891153)
 - Private file access bypass (Closes: #891152)
 - JavaScript cross-site scripting prevention is incomplete (Closes:
   #891150)
   * Uncruft: Remove an unused .dpatch file still from the drupal6 era(!)
   * Bump up standards-version to current policy (4.1.3.0)
 - Move from Priority: extra to Priority: optional
Checksums-Sha1:
 0bcd900da299b17059356c94278916987249 1881 drupal7_7.57-1.dsc
 0e11212a07c87f10706b80cbf19db18925791a49 3279405 drupal7_7.57.orig.tar.gz
 da525361ab1e539ae1b0f11d7ed0e8ff278f2005 187672 drupal7_7.57-1.debian.tar.xz
 88353ce704092b8b55a227c5365c387d50420060 2522040 drupal7_7.57-1_all.deb
 17e1e0943c4247ee3fc3f422bb500cff31e990ff 8525 drupal7_7.57-1_amd64.buildinfo
Checksums-Sha256:
 d20e95ef2b4ee9acc371a800c354092f07ea00939316eab5f53efc9166a18a9d 1881 
drupal7_7.57-1.dsc
 c3bc1173d7830941fa9ee6061d555fec334bd6834d2fc5c870f3aef1fbf667e2 3279405 
drupal7_7.57.orig.tar.gz
 165bd1bccc78ce131637338f4581d9c61c0c612a8f72282904d3af3026681f0a 187672 
drupal7_7.57-1.debian.tar.xz
 abcc665c3f312adde572a778ecbabfc3f265673fd9b1c2bd068b7c708a7f74a6 2522040 
drupal7_7.57-1_all.deb
 38b8552844f54d86daec47fa59360b0e25375eaca175cb3060ecf9472537c192 8525 
drupal7_7.57-1_amd64.buildinfo
Files:
 b03b351c50f06d6765b5d54f03dd290c 1881 web optional drupal7_7.57-1.dsc
 44dec95a0ef56c4786785f575ac59a60 3279405 web optional drupal7_7.57.orig.tar.gz
 959a8236637c8a36b1536f1985e45c7d 187672 web optional 
drupal7_7.57-1.debian.tar.xz
 33278b3d6a14a99b4b226d7e48739477 2522040 web optional drupal7_7.57-1_all.deb
 6651b3ca66fc3dff98bd670a0c1ae75e 8525 web optional 
drupal7_7.57-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIyBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlqQcHUACgkQZzoD5MHb
kh/rAw/449Axo2wmdaWZEvZemUcmNRlQSt3pfsTxARHGIio49NmzeidKpbnl9cMu
I2sqNDegKgKL5WF+oL+5hkDqstnT8ko9Pfw+eR/RPU9pqkbamnItToGaQvNvCFth
vHpG4wnYdN/PEa6YoUbqfVlGlXcqRRuO6PE1a86CbK5KBSZEsFVBZwsDhDsI+6hr
V6uWC2FAmKVXxhZuTvCE1s3tHPOhKkFg2VellXnuMg5WGEOy3fh8ACdGZo3l2L7X
NjDBrB3m0cIcmipgRaTMeaP/VEN+FWSW4dMsnNUT04zeh0KKxX/8+CO/Z6PaE6Jw
bmRf6IItL+WPj6wH2KHZ4EMGjYTstPN/guYhRFaKClJYw7uGBc0RCHcjX8Sg/GKu
LDbKroNPxBDbJiH4fuFlRXpJxnaFstBO2oOELYLiDXQaeYuotGUktU4zJFRtOIrp
dbV/PyNL562pKV7KrG0hOipA6hiAUMYggJ4+kA/Y3Nibhv7JeCSA8HjlqOH2MOK+
pINFXN7vGoWGx+39l27a/z7IbIc12jSgZB6vHn6I8l2sU2eXBr1x+me4EuGgijwY
Jj1yLgIdScbq/3o2Zt95FN6LRsp5n1+jT0On0EWLdzZcYzhmxKkr4wfUMQIkh/n7
bL49b70Q2Jy4i0dhcHz/RWAUQWOIVrVaj/6zEgP07cJrxS1sOA==
=p3By
-END PGP SIGNATURE-

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Philipp Kern dijo [Mon, Feb 19, 2018 at 09:18:13AM +0100]:
> Putting security support over all else is surely how some people see it. But
> some upstreams also complain if you are going to ship ancient versions
> because the most recent ones contain all of the fixes. It's certainly more
> work to validate security fixes when backporting them to older versions. So
> it's also the "stable" guarantee (whatever it is seen as) that might need
> some re-adjustment.

Maybe we abuse the "security support" term - It's also "stability
support" or "bugfix commitment". We can commit to fixing the one
version of a library we ship that's producing erroneous results on
given inputs; that's not necessarily security-related (although it
might be). If libpng gets confused¹, it's not a security issue until
its input is treated on a sensitive way.

¹ http://gwolf.org/node/1952 for quite an old report

> One of the values is that you get some set of software that works together
> as a base and doesn't change, but then people install software on top of it
> that provides their service and if it's actually the thing they want to
> provide it's most likely not packaged anymore at this point. Because you'd
> want the latest features of the product you're using. So there's already a
> disconnect of essentially two tracks: the system's base at a solid version
> and whatever it is you want to offer at a fast moving pace.

This is an oft-repeating issue. At some point, Debian was the ugly
duckling because we did two- or three-year release cycles; at some
point, basically all other important distributions switched to a
longer release cycle in some way or another, keeping a "stabilized
snapshot" of sorts (i.e. Fedora for RH, Ubuntu on its non-LTSes). Or,
OTOH, became a fully rolling release. And we have both - only that we
don't recommend testing to users who expect the rock-solid we are
known to produce.

Having large software ready as a Debian package allows me, as a casual
user, to take it for a spin and evaluate it. As a sysadmin, I have the
habit of preferring Debian-packaged software for everything I can,
except when there is a _real_ reason for needing somewhat
newer. Again, I know I'm probably more Debian-centric than most of our
users, but I don't think it is too hard a line to pick: Use Debian for
all of your needs, and if it does not completely fill the bill, you
can locally install what you need. Of course, if it's hard to install
or something like that... maybe you want to learn the technologies you
will be using instead!

> That's also a reality in 2018. And coming up with arbitrary
> deadlines of support are not all that helpful. Users don't care if
> the ancient version of the software they need in stable is security
> supported until mid-2022. If it doesn't satisfy their requirements
> anymore, they move to testing or to another distribution.

My users are most often irked when I do OS upgrades and modify their
stale, beloved webmail installation. Of course, I still do it whenever
it's needed. But I have been repeatedly, even publicly asked as to why
do we push a "consumerist" worldview where old things are not
good. It's sometimes hard to explain why we need updated software...

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Raphael Hertzog dijo [Mon, Feb 19, 2018 at 03:19:59PM +0100]:
> On Fri, 16 Feb 2018, Jonathan Carter (highvoltage) wrote:
> > > - we could relax our requirements and have a way to document the
> > >   limitations of those packages (wrt our usual policies)
> > 
> > Which requirements are you referring to? If it's relaxing the need for
> > source for minified javascript, then no thanks.
> 
> Instead of requiring the source to be provided in the source package as a
> non-minified file, we could require the packager to document in
> debian/README.source where the upstream sources actually are.

Pointing to sources outside our system might go away, and that would
make us instant-buggy. That's why we have introduced the
debian/missing-sources mechanism; your source package bloats, but is
source-complete. Further, you can parse them with the "correct"
minifiers and compare the results are identical (or provide our
minified versions if they are not).

> When I was maintaining wordpress, I introduced the idea of providing
> debian/missing-sources/ to comply with the Debian policy.

Yay, so it's not you who I have to lecture on this ;-)

> I would just dump there the upstream tarball of the bundled
> libraries to be sure that we have the source for the correct
> version. The Debian/ftpmaster rules are respected but it's not
> really better than the above because you still don't have a simple
> way to rebuild a modified version of the javascript library shipped
> in the package.

build-depend on yui-compressor, node-uglifyjs-webpack-plugin,
libjavascript-minifier-perl, or whatever minifier suits you; add them
to the binary package in debian/rules instead of just copying over the
upstream-provided minified versions. That is, think of minification as
you would think of compilation.

> So instead of ugly work-arounds, it might be better to just acknowledge
> that we can't have the same level of support for all applications.
> (...)
> Those applications could rely on the package manager of their ecosystem to
> setup the dependencies as they need them without polluting the host
> system.

...But that pollutes the host system for all of their ecosystem. And
that's what I suggest - Paraphrasing the SC, «We acknowledge that some
of our users require the use of works that do not conform to the
Debian Free Software Guidelines». We might come up with an area
similar to contrib or non-free (or even decide to ship such systems
there, as they kind-of-belong there!)

Maybe Drupal, WordPress, NextCloud or WhatEver are not non-free by
themselves. But they are not allowing for a practical source
distribution; they force our hands into trusting software we cannot
vouch for or give warranties on. So, maybe they belong in non-free.

Re: Bug#890816: ITP: autovpn -- Connect to a VPN in a country of your choice

[Gunnar Wolf]

Michael Meskes dijo [Mon, Feb 19, 2018 at 12:44:40PM +0100]:
> >   I'd strongly urge you to reconsider packaging this project, for
> >  three main reasons:
> > 
> >   * It relies upon the external VPNGate.net site/service.  If this
> > goes away in the lifetime of a stable Debian release users will
> > be screwed.
> 
> That is actually a good point. I wonder if using a local copy might be
> a good alternative.

I suppose the information it downloads is needed to keep the database
up to date. Thinking about a lifetime of ~5 years (stable+oldstable),
I don't think we could work around that

> >   * It allows security attacks on against the local system which the
> > remote service could exploit:
> > 
> > 1.  The tool downloads a remote URL to /tmp/openvpnconf
> > 
> > 2.  The file is then given as an argument to the command:
> > sudo openvpn /tmp/openvpnconf
> > 
> > 3.  That generated/downloaded openvpn configuration file could
> >be written to do anything, up to and including `rm -rf /`.
> 
> Can you actually get openvpn to do this?

Depends on what information you put in /tmp/openvpn.conf, I guess. The
least likely candidates end up opening holes - i.e. remember the quite
recent KDE notifier bug allowing FAT volume labels containing $() to
be executed :-P

I mean - It might be completely OK. But given this creates
configuration for setting up a high-privileged daemon from a public
place, it'd be on you to carefully comb on the relevant parts of the
source to assert the handling of this information is sensible.

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Michael Meskes dijo [Sat, Feb 17, 2018 at 01:57:53PM +0100]:
> > Minification is quite comparable to compilation. I will give you some
> > examples from my frustration with Drupal8 in this answer. This can no
> > longer be seen as source code:
> > ...
> 
> I disagree, it is not maintainable source code, yes, but source code
> nonetheless. According to wikipedia source code is:
> 
> In computing, source code is any collection of computer instructions,
> possibly with comments, written using[1] a human-readable programming
> language, usually as plain text.
> 
> I guess minified source code does qualify. However, this discussion is
> mood since the bigger lies in the modules that get included without any
> real documentation.

Some others have answered to this claim. As I understand it, source
code should ideally be the author's preferred form of
modification. That is clearly different from what a minified
representation is.

Even adjusting this a bit... Maybe not a preferred form of
modification, but a plausible form for performing support? Well, even
leaving the obvious change from a readable, indented set of
instructions to a single line with no comments nor anything to aid
humans to understand it, it also does not cut the bill. Minification
preserves function (and thus, calls to the stdlib and such are
discernible), but function and variable names are mangled. That is a
_huge_ obstacle for being able to fix anything but the most trivial
details. Of course, we cannot push our patches upstream.

> > But packaging the precise version that is required in each little
> > bump
> > is just impossible.
> 
> I get your point, I just don't accept the consequence that we should
> not package these applications.

Well, try to find somebody with time and motivation to _properly_ do
the packaging, and to keep it up for several years...


signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Michael Meskes dijo [Fri, Feb 16, 2018 at 10:07:06PM +0100]:
> > Is was a relevant part of the problem mentioned in Raphaels bug
> > report: Minified JS libraries without source code. this was one
> > of the starting points of this discussion. (#890598)
> 
> Right, although merely technical since there is source code, albeit not
> very legible or maintainable.

Minification is quite comparable to compilation. I will give you some
examples from my frustration with Drupal8 in this answer. This can no
longer be seen as source code:


https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/core/assets/vendor/classList/classList.min.js

And it's far from the ugliest example I can quote. Of course, I needed
to ship sources for all of them - Take a look at:


https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/debian/missing-sources/README

And, of course, think about the huge diff that is to be created for
all of the files in debian/missing-sources.

> > The bug report mentions two orthogonal problems:
> >  - libraries without source code or no license information
> 
> I might have missed the missing license problem, but I'm pretty noone
> wants to see unlicensed software in Debian, which also would be
> illegal.

Take this as an example of what is needed for a moderately complex PHP
webapp with lots of JS in it:


https://anonscm.debian.org/cgit/collab-maint/drupal8.git/tree/debian/copyright

Of course, it was all hand-generated and validated.

> >  - libraries which are needed in specific versions
> 
> This one really worries me. I wonder how many similar cases we already
> have, where somebody took some code and changed it slightly before
> including it.

And that's where I dropped the ball. Upstream says they will keep
dependencies refreshed - that means that every project version bump,
they will pull in the newest stable versions for all of the projects I
covered in the above links. Of course, I had come up with a clunky bit
in my debian/rules to track any changes:

override_dh_install:
# Ensure the list of third-party included libraries remains
# consistent with what we already checked
SHATMP=`mktemp --tmpdir SHA_CK.X` && \
sha256sum core/core.libraries.yml > $$SHATMP && \
diff -q debian/missing-sources/tracking.sha256 $$SHATMP && \
rm $$SHATMP

But... That would inescapably be run at every minor bump. And it's
just too much of a PITA to build.

> > I add a third one:
> >  - libraries that are not packaged, because there are too many
> 
> The problem is probably less the amount but more the manual work to
> find the canonical sources. Packing a go "library" for instance does
> not take a lot of time, because it can be done mostly automated.

But packaging the precise version that is required in each little bump
is just impossible.


signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Michael Meskes dijo [Fri, Feb 16, 2018 at 06:12:04PM +0100]:
> > No, I think it's better if people know they're on their own for maintaining
> > something. What's surely worse is when we ship stuff that we know we can't
> > properly maintain in the long term. Better to be out of the archive than in
> > without the expected level of quality.
> 
> Who said we cannot properly maintain this stuff? And where do you
> think our expected level of quality (whatever that is) will not be
> reached?

In this thread, at least Raphaël and myself.

And, I guess, many others (say, OwnCloud was already brought up to
this thread).

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Michael Meskes dijo [Fri, Feb 16, 2018 at 04:58:04PM +0100]:
> Can't we treat a .deb file like a container in the sense that it may
> include additional source if needed? I'd very much like this.
> 
> I know that this does create some problems for us, e.g. on the security
> side, but the alternative is, as you mentioned, manually installed
> software and that surely is worse.

Dunno.

As a sysadmin, I know I can trust that most of my system is OK if I
just apt update / apt upgrade every so often. And I know the maybe
five to ten software packages I have hand-installed. I know I must be
aware of their alerts and whatnot.

I know that being a 15-year DD does not make me the average
sysadmin. But that's one of Debian core values to sysadmins. I guess
I'm not the only one appreciating that.

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

W. Martin Borgert dijo [Fri, Feb 16, 2018 at 06:59:21PM +0100]:
> If I understand Samuels idea correctly, he likes to have multiple
> versions of the same (JavaScript) library installed on Debian.
> Not "stuff", but proper Debian packages, with all bells and whistles.
> Only that you don't remove necessarily the old version, when the new
> one comes in. Similar to C libraries, kernel, etc. but with a different
> way to actually use the files, of course.
> (...)
> This is very much a web application problem. Other software is
> less affected in my experience.
> 
> Maybe we just have to package JS libraries with their version
> number in the package name in the first place?

While I agree with you, just the number of node-.* (1249) or libjs-.*
(398) packages (which tend to fall within this fast-paced development
culture) makes me shiver... Who will maintain them at different
compatibility levels? Even more so if their upstreams have effectively
abandoned them?



signature.asc
Description: PGP signature

Re: What can Debian do to provide complex applications to its users?

[Gunnar Wolf]

Raphael Hertzog dijo [Fri, Feb 16, 2018 at 04:11:29PM +0100]:
> Hello everybody,
> 
> the fact that I had to request the removal of dolibarr from Debian makes
> me sad (see below for the reasons) and I believe that we should be able
> to do better to provide complex applications to our end users.
> (...)
> I'm sure we are missing lots of good applications due to our requirements.
> What can we do to avoid this?
> 
> I don't have any definite answers although there are ideas to explore:
> (...)
> What do you think? Do you have other ideas? Are there other persons
> who are annoyed by the current situation?

I was bitten by a similar issue; I maintained Drupal 7 for several
years (was included in 3 stable releases). But I gave up when
packaging Drupal 8, much for the same reasons:

   http://gwolf.org/node/4087

However it saddens me, that's... Well, the right thing to do, IMO.

> - we could relax our requirements and have a way to document the
>   limitations of those packages (wrt our usual policies)
> 
> - we could ship those applications not as .deb but as container
>   and let them have their own lifecycle

I would not like us relaxing our requirements. If there is a need to
distribute webapps as container images, that can be done, and much
probably it can be done by ourselves - But that's not Debian. That
means, distributing a container with dolibarr or with drupal8 will not
allow us to build packages that depend on them (such as
drupal7-mod-civicrm), or packaging helpers (such as
dh-make-drupal). Maybe few webapps introduce full ecosystems as Drupal
does; we had a similar issue a couple of years ago with OwnCloud, and
it would fall in the same case. And I think examples will be too many
to list.

Re: ISO download difficult (was: Debian Stretch new user report (vs Linux Mint))

[Gunnar Wolf]

W. Martin Borgert dijo [Fri, Dec 01, 2017 at 02:39:12PM +0100]:
> Every time I need a Debian ISO, it takes me minutes to find it.
> I didn't even know, that there were an ISO with non-free firmware.
> 
> There should be a beautiful ISO download page, e.g.
> https://www.debian.org/download[s]/
> with all architectures and supported releases, similar to
> https://www.ubuntu.com/download
> or
> https://linuxmint.com/download.php
> 
> Who likes to the hero of the day? :~)

http://get.debian.org

Might not be beautiful, but it has the needed information, clearly
spelt out.

Re: Debian Stretch new user report (vs Linux Mint)

[Gunnar Wolf]

Arturo Borrero Gonzalez dijo [Fri, Dec 01, 2017 at 01:15:04PM +0100]:
> >> It would have been best for him to download the ISO with non-free
> >> firmware embedded, do you know how he made the decision to download
> >> the ISO without non-free firmware?
> 
> What others say is true. It's not easy to find the download link, even
> for me as DD.
> 
> But this is something that we have already detected: our main website
> needs work.
> We just need someone doing the work.

Yes, but... this is an issue often brought up and discussed since I am
aware of, that is, for over 15 years. It's _hard_ work to properly
structure a web site as information-rich as ours, with as many
different user types as its targets. Even more, with moving targets,
as Web design styles rise and fade continuously.

And I am _not_ implying that not enough work has been done; the Debian
website has vastly improved since I know it. But properly organizing
it is something... VERY hard to get right.

> > udisks2 already recommends ntfs-3g. Most major desktops should use and
> > install udisks2. Which desktop environment did your user install and did
> > he maybe choose to not install recommends?
> 
> I don't really know, I would say gnome.
> We would have to check every desktop stack and review how things are
> for both NTFS and HFS+.

I think GNOME is a safe bet, as it is the "most defaultest" of all
desktops (even given "there is no default" ☺)

> Other thing is the branding topic. I would like to promote usage of
> Debian testing for standard desktop/laptop users in personal
> environments (not for business machines)
> but the 'testing' word scares people. I don't have a valid candidate :-(
> 
> But we should really point to stable to specific users rather than all
> by default.

This is something that does not seem to draw consensus. I am of the
opposite camp. Regular users should have stable, as they don't want
huge updates or regularly broken systems, missing pieces and so on. A
regular user should be fine with upgrading their desktop every two
years, if anything! I mean... Look over the fence. How long did it
take for Windows XP to disappear? Before that, how long was Windows 98
king? How many users still cling to Windows 7? They don't need the
newest, shiniest software. They want something stable that works, and
that _they know_ how to make work. The same should be valid for most
users over here.

Re: Bug#882445: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Sean Whitton dijo [Thu, Nov 23, 2017 at 02:40:54PM -0700]:
> Hello David,
> > On Wed, Nov 22, 2017 at 05:18:37PM -0700, Sean Whitton wrote:
> >> >   "cowsay-offensive".  In this situation the "-offensive" package can
> >> >   be Suggested by the core package(s), but should not be Recommended
> >> >   or Depended on, so that it is not installed by default.
> >   ^^
> > While it seems to be a reasonable explanation for why it should be at most
> > a suggests, this half-sentence is hardcoding behaviour of a specific
> > package manager in its current default configuration into policy.
> >(...)
> 
> Thank you for your feedback.  I see what you mean.
> 
> I second the patch revised to exclude this half-sentence.

Makes sense. Sean, please note that, having seconded Ian's original
wording, I also second this modification.


signature.asc
Description: PGP signature

Re: Proposed change of offensive packages to -offensive

[Gunnar Wolf]

Ian Jackson dijo [Wed, Nov 22, 2017 at 12:32:40PM +]:
> So to be concrete, how about this:
> 
>   N. Packages with potentially offensive content
> 
>   As a maintainer you should make a judgement about whether the
>   contents of a package is appropriate to include, whether it needs
>   any kind of content warning, and whether some parts should be split
>   out into a separate package (so that users who want to avoid certain
>   parts can do so).  In making these decisions you should take into
>   account the project's views as expressed in our Diversity Statement.
> 
>   If you split out (potentially) offensive or disturbing material into
>   a separate package, you should usually mark this in the package name
>   by adding "-offensive".  For example, "cowsay" vs
>   "cowsay-offensive".  In this situation the "-offensive" package can
>   be Suggested by the core package(s), but should not be Recommended
>   or Depended on, so that it is not installed by default.
> 
> This is hopefully vague enough that everyone can agree it ?

I agree to this wording.

Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Ian Jackson dijo [Thu, Oct 05, 2017 at 01:29:16PM +0100]:
> I have also heard of packages which do "apt-get source" in their rules
> files.
> 
> I think that both of these activities are reasonable things to do.
> They don't violate the self-containedness of Debian.  If they are
> technically forbidden by policy then policy should be changed.  There
> should be an exception saying that a package build may access the
> Debian archive (and ideally it should specify how this should be
> done.)  If someone cares enough to document this situation then they
> can file the bug against policy.
> 
> Of course it would be better if we had a more declarative way of
> saying "this package needs foo.deb to build - and we mean the .deb,
> not for foo to be installed", and the corresponding "this package
> needs the source code for bar".  But this is rather a niche, and it
> doesn't seem to cause trouble in practice.  So AFAICT it's no-one
> priority.

UGH.

I am not convinced this use case should be supported - Even if the
software providers are ourselves, which we trust not to trojan our own
goodies, this still allows for a great deal of nondeterminism. If the
"apt-get source"d package is updated, the build might not work anymore
or might yield different results. 

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Pirate Praveen dijo [Wed, Oct 04, 2017 at 04:52:37PM +0530]:
> > However, that verification isn't really sufficient if a rebuild
> > on the buildds could download an entirely different version of the
> > out-of-archive tools: a sufficiently inventive attacker who had gained
> > control over upstream's distribution channel could even arrange to serve
> > a non-malicious toolchain to your IP address, but then serve a malicious
> > version to Debian buildds' IP addresses.
> 
> But debian buildds already prohibit network access during build and
> these packages has to be binary included always. So the theoretical
> security issue never manifests in practice.

So, what happens currently? Do the affected packages FTBFS? (that,
IMHO, would be a *good* thing, as we would only need to patch Policy
to reflect reality)

> > At least that way, you have the opportunity to inspect the pre-built
> > binary (I hope "binary" here means a bundled/minified version that is
> > not the preferred form for modification but is somewhat human-readable,
> > rather than something as opaque as a compiled C binary) and have some
> > level of confidence that it corresponds to the source.
> 
> That is how it is happening even now as it will always be built on a
> maintainers machine. Having pre-built binaries instead will only change
> the perception. It makes build process non standard and manual making it
> harder for others to build (will need to learn about nodejs specifics
> unlike the regular dpkg-buildpackage) or introduce possibilities of
> making mistakes (any manual steps can introduce mistakes).

No. It does not only change the perception. You ship a pre-built
binary as part of your sources, then the build process (with, yes, a
piece of untrusted blob... But still, that's as far as we can get)
will happen across our buildds, or by whoever wants to NMU, or even by
yourself days or weeks later, with a piece of software known to yield
the package as it got built. We will not be bitten by a random site
being unexpectedly offline, or by a transpiler changing some
command-line options without notifying us (to mention only two
possible issues)

> But as I already mentioned in my last mail, I will accept this advice,
> even though I'm not convinced.

Yes. Reading through the thread, I see several people are still
directing their criticisms of this situation to your person. Lets try
to keep this separate from Praveen, and focus on the general
reasoning!




signature.asc
Description: PGP signature

Re: Bug#877212: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Jérémy Lal dijo [Tue, Oct 03, 2017 at 07:46:43PM +0200]:
> It might be a good idea to make policy more explicit about downloads during
> build.

I completely agree. This led me to look at #813471 ("network access to
the loopback device should be allowed"), and... Well, it seems to set
the stage to the issue we are tackling now: #813471 is opened as a
reaction against #770016 ("Clarify network access for building
packages in main").

I fully agree with Guillem's suggestions, although Pabs has a point in
cuffing the build process more strongly.

But anyway, #770016 worries me as it seems to deal with main only;
however, the precise issue we are discussing was mentioned then as
well by Henrique:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#48
  And it is is not just for main, I don't think contrib is supposed to
  hit the network during *build*, either.

Bill explicitly mentioned he was not targeting contrib on this bug's
proposed (and accepted) changes:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=770016#58
  I have no idea abut contrib.



signature.asc
Description: PGP signature

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Pirate Praveen dijo [Tue, Oct 03, 2017 at 12:12:54PM +0530]:
> > I am completely with Sean here; I read the following messages, and am
> > happy a better resolution was found. But, FWIW, I'll support Sean's
> > interpretation - Contrib and non-free are *not* places where we can
> > happily breach any bits of policy; they are exclusively for things
> > that cannot be shipped in Debian Main due to their DFSG status.
> 
> I cannot accept arbitrary interpretations of policy. When build tools
> are not available in main, they cannot go to main, and if the software
> itself is Free Software, it can go to contrib. If you disagree, please
> get the policy clarified. As per the current policy, these packages
> clearly qualified for contrib and these were already accepted by ftp
> masters into the archive. You could go to CTTE and challenge the
> decision of ftp masters.

Let me quote the Debian Social Contract:

Works that do not meet our free software standards

We acknowledge that some of our users require the use of works that do
not conform to the Debian Free Software Guidelines. We have created
"contrib" and "non-free" areas in our archive for these
works. (...)

So, contrib is _explicitly_ meant for software that does not meet the
DFSG, not for random stuff that cannot be packaged for convenience or
different issues.

According to Policy, section 2:

Packages in the other archive areas (contrib, non-free) are not
considered to be part of the Debian distribution, although we
support their use and provide infrastructure for them (such as our
bug-tracking system and mailing lists). This Debian Policy Manual
applies to these packages as well.

Policy says that all packages in contrib and non-free should be policy
compliant. Further, in 2.2.2:

The contrib archive area contains supplemental packages intended
to work with the Debian distribution, but which require software
outside of the distribution to either build or function.

Every package in contrib must comply with the DFSG.

In addition, the packages in contrib

  • must not be so buggy that we refuse to support them, and
  • must meet all policy requirements presented in this manual.

For this section, yes, I will be making interpretation - But I hold
that we would be hard-pressed to provide support for something built
with a compiler downloaded at build time. Maybe, as Simon suggests, if
your debian/ includes hashes for the compiler version being
used (and everything it pulls in via npm)... But in that case, it's
probably better to include the tar.gz as part of your debian/

I *do* take note, however, of:

Examples of packages which would be included in contrib are:

• free packages which require contrib, non-free packages or packages
  which are not in our archive at all for compilation or execution,
  and
• wrapper packages or other sorts of free accessories for
  non-free programs.

The first point would seem to cover your use case. However, it's not
necessarily covering (...) compilation or execution via code just
downloaded. It does not cover the equivalent of
"curl http://exploit.me/stuff | bash"

> Alternatively, those who care enough about the issue can help get these
> tools into main. I have been doing just that over the last years (grunt,
> gulp, babel, jison, webpack to name a few, each with 100s of
> dependencies) so many of the packages currently in main could go there.
> Since the tools are just so many and the people packaging them are
> handful, it will take quite a while for all these tools to be in main
> and I'm going to continue using contrib for these packages until that time.
> 
> You can also check the record of people who are most vocal over the
> issue (not just in this thread, but in earlier discussions about
> handlebars/dfsg/browserify) and compare who is helping fix the issue and
> who is just talking.

In this case, I'm clearly in the group of those who are somewhat
vocal, and are not helping your efforts. Well, I did quite a bit of
effort in a related matter with the work I put into packaging Drupal8,
which I dropped in the end¹ precisely due to it not being cleanly
packagable for Debian.

¹ http://gwolf.org/node/4087

> > And, yes, network access during a build... Is a clear no-go. Specially
> > if as a project we are committed to this so neat Reproducible Builds
> > thingy that has made so many among us proud to be part a project where
> > an ages-long problem is finally being tackled - And quite
> > successfully, even!
> 
> I thought building these things (making sure the source corresponds to
> the distributed binaries), though using tools outside archive, was
> preferred over shipping pre-built binaries. But it seems shipping
> pre-built binaries are preferred. It looks to me like a misplaced
> compromise, but I will follow this advice and ship pre-built binaries
> next time without building them using npm.

I would strongly 

Re: [Pkg-javascript-devel] Bug#877212: node-d3-color: B-D npm not available in testing

[Gunnar Wolf]

Sean Whitton dijo [Sat, Sep 30, 2017 at 12:10:54PM -0700]:
> > The whole purpose of having contrib and non-free is to host packages
> > that can't be in main, either permanently or temporarily. I fail to
> > see how it is against the spirit.
> 
> To my mind, at least, the purpose of contrib and non-free is for
> packages that can't be in main for DFSG reasons /alone/.  Social
> Contract item 5:
> 
> We acknowledge that some of our users require the use of works that
> do not conform to the Debian Free Software Guidelines.  We have
> created "contrib" and "non-free" areas in our archive for these
> works.
> (...)
> I am still very uneasy about serving our users -- even our users of
> Debian unstable -- with packages that are built using material pulled
> from the net.  I think that people who add 'contrib' to their
> sources.list do not expect this kind of thing.

I am completely with Sean here; I read the following messages, and am
happy a better resolution was found. But, FWIW, I'll support Sean's
interpretation - Contrib and non-free are *not* places where we can
happily breach any bits of policy; they are exclusively for things
that cannot be shipped in Debian Main due to their DFSG status.

And, yes, network access during a build... Is a clear no-go. Specially
if as a project we are committed to this so neat Reproducible Builds
thingy that has made so many among us proud to be part a project where
an ages-long problem is finally being tackled - And quite
successfully, even!

Re: popularity-contest reachs 200000 submitters!

[Gunnar Wolf]

Zlatan Todoric dijo [Sat, Jun 24, 2017 at 01:05:10AM +0200]:
> > Reports by versions of popcon:
> >
> > 1.46 (lenny)   : 2925  
> > 1.49 (squeeze) : 9600
> > 1.56 (wheezy)  : 33450
> > 1.61 (jessie)  : 114427
> > 1.64 (stretch/stable/testing/unstable) : 36640
> > 1.65 (unstable): 785
> > others: 3131
> >
> > (Yes there still more submitters running wheezy or squeeze than stretch).
> 
> Actually if I read it correctly - stretch already surpassed wheezy and
> take into account it is just released so give it a time.

Yes, but do consider that 1.64 is run also by all machines that track
Unstable (and have not updated popcon during the past week) or
Testing. The number of machines tracking Stable / Stretch are just a
fraction of it.

Accepted drupal7 7.56-1 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Thu, 22 Jun 2017 11:59:07 -0500
Source: drupal7
Binary: drupal7
Architecture: source all
Version: 7.56-1
Distribution: unstable
Urgency: high
Maintainer: Gunnar Wolf <gw...@debian.org>
Changed-By: Gunnar Wolf <gw...@debian.org>
Description:
 drupal7- fully-featured content management framework
Closes: 865498
Changes:
 drupal7 (7.56-1) unstable; urgency=high
 .
   * New upstream release
   * Fixes security vulnerability: SA-CORE-2017-003: Files uploaded by
 anonymous users into a private file system can be accessed by other
 anonymous users. (CVE-2017-6922) (Closes: #865498)
Checksums-Sha1:
 6b7fcff6623fb0d4919aebf3c31aadd928ba454e 1876 drupal7_7.56-1.dsc
 4647ccc356a8557659a3a3891dbae1dce8467396 3277833 drupal7_7.56.orig.tar.gz
 0a8ae16a98035fcd0a26e71f5efe8fb3dba5a642 188452 drupal7_7.56-1.debian.tar.xz
 66429200b06589f01bd8843bf54285931855a42f 2525036 drupal7_7.56-1_all.deb
 ae5e09783fff5ee8e0da54f01ccdc6635f13a8c9 8388 drupal7_7.56-1_amd64.buildinfo
Checksums-Sha256:
 a6b6c99c8dbfdd5cede73a0dc4a5091baff5dd08acd958ca90e508b6a249d464 1876 
drupal7_7.56-1.dsc
 02fb4b46060d53c2f876d2381a8741249819e3a02ea1d7291036f6ea280d7b69 3277833 
drupal7_7.56.orig.tar.gz
 3a5b50bfb5b2db506e69b75a49d94a1c29b7ad982e9dbbda1025bb7cd6e1dc69 188452 
drupal7_7.56-1.debian.tar.xz
 19b69047ade1a158e98e4402869f2491dcca072f3d6caa5019602dc0581d9754 2525036 
drupal7_7.56-1_all.deb
 57ebf339fabb81c474072e95ae9e02122952aaf5810ecdbe2c665593d4e5c708 8388 
drupal7_7.56-1_amd64.buildinfo
Files:
 9c3d02493e698446b832181936834efe 1876 web extra drupal7_7.56-1.dsc
 5d198f40f0f1cbf9cdf1bf3de842e534 3277833 web extra drupal7_7.56.orig.tar.gz
 f849f3f68821196b632639422ef68683 188452 web extra drupal7_7.56-1.debian.tar.xz
 6db03e633fcdd6cf0e894bf57a2bffe3 2525036 web extra drupal7_7.56-1_all.deb
 ad552036806e395a43fa82b4a7327adf 8388 web extra drupal7_7.56-1_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIyBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAllL/8AACgkQZzoD5MHb
kh/31w/2OH8qkPx1mqPwHsE7Stn2/dFuUDB0st/J1QY9nxpGGg2McWpWW64LxlzN
U9MAHbpC2qA/nzyCgXTE6BzowJHe0f6OS5BRSze2AsKDP5p4EUC08XjTiXarXAvf
RmSUZecNH2ggutsvYVKnxDLXB/C76oUg2a0QA7UYNij5AgKv6nf+1JGRMoZPKYjD
CXoz/HxElTs+2O73lCqB/PpP69xyz+MbYmmd54GFUMshDQRQXX7eXkM7NIsyoKv6
pP4MVEDo5SGBOysX7IaZxHELm2H+KFR3CGDIA7zvgT0BcsnnGXMt0QwjRS1iKFuo
SJgwt5T/pvPtQiFzMGRDJ7I3Ufevwf68oQINX5mUXYpVpp9OBw3iI7Glfmh/LmI9
AFUp+FdP4wGOZllxuR0vy5kgZBbxl4uZGUAt91/Q71w16U1bIdAlZbazEUH0SAp1
jgZ6LhzfFePIKT1GNjKWrn6+JjBtDxnh2nfGpxKJkwursgj+U4g9nqrS5QDB/WNA
SYsjTghDCU++EMeCNmOfW858atPmeZBAVLkW3w6Qz1W2muq9PHItziOBIr0ac7cb
VzS5k/bLQP7Binw23Fr+OgvpqMxtdwhKQ+TSg1Er8zXiF90rq+Ib1KWP1Cg/qdCy
z+/YNoXO3Rvl4sU6qMEfJEE/81OnukJdHrdvLCq2ThJNa6Db3Q==
=1xtp
-END PGP SIGNATURE-

Re: Switch default installation image link?

[Gunnar Wolf]

> [ Note Reply-To: set to d-devel ]

(answering only to said list)

> Hey,

Hiya,

> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page. I think it's time to just switch
> that to just an amd64 image for stretch now. The vast majority of the
> machines out there are now amd64, and we're asking people to download
> useless stuff in such cases. i386 users can still find an image for
> download.

Sounds quite sensible. You magically win quite a bit of capacity as
you don't have to include packages for two architectures.

> I'm *also* tempted to switch from the netinst to the first DVD image
> instead - network connections have improved a lot.

I'll chime in to what others have said. I think DVD images should not
be the default/main download venue. Even though the careful package
ordering by (alleged?) popularity, I am sure a great deal of Debian
installs use under half of the packages provided by the first DVD (and
many that are not there, of course). A completely offline user will
have to juggle no matter if they got the DVD, and a connected user (no
matter their available bandwidth) will spend more time waiting for the
network if they choose to install from DVD.

Greetings,



signature.asc
Description: Digital signature

Re: When do we update the homepage to a modern design? (was Re: Moving away from (unsupportable) FusionForge on Alioth)

[Gunnar Wolf]

Arturo Borrero Gonzalez dijo [Mon, May 15, 2017 at 01:42:09PM +0200]:
> Hi Paul,
> 
> I believe that what we are actually looking for is a bit of
> improvement in the marketing side.
> Modern and fancy things.
> 
> The LXDE example is good on that.

Is a good example on how to craft content-void websites that look well
on mobile devices but are useless for finding information.

I guess that if you click around enough, you will get to a decent web
site in it that actually contains information.

Re: Moving away from (unsupportable) FusionForge on Alioth?

[Gunnar Wolf]

Jonathan Dowland dijo [Mon, May 15, 2017 at 09:27:27AM +0100]:
> On Mon, May 15, 2017 at 09:13:11AM +0200, Alexander Wirt wrote:
> > Nice to have:
> (snip)
> > - Mailinglists
> 
> I've always thought it a bit weird, unfortunate (and possibly a historical 
> accident)
> that we have lists.debian.org and lists.alioth.debian.org. Could this be an 
> opportunity
> to move to one Debian mailing list service?

Oh, but we also have them at lists.debconf.org! And they even use
different software. And there have been attempts at joining, but don't
succeed...

Accepted gnuhtml2latex 0.4-3 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Fri, 12 May 2017 12:17:53 -0500
Source: gnuhtml2latex
Binary: gnuhtml2latex
Architecture: source all
Version: 0.4-3
Distribution: unstable
Urgency: low
Maintainer: Gunnar Wolf <gw...@debian.org>
Changed-By: Gunnar Wolf <gw...@debian.org>
Description:
 gnuhtml2latex - Convert HTML files to LaTeX
Changes:
 gnuhtml2latex (0.4-3) unstable; urgency=low
 .
   * Keep Lintian happy
 + Bump up standards-version 3.9.3→3.9.8
 + Bump up dh compat version 7→10
Checksums-Sha1:
 12153d281cfc4139332757716f244dbd589c53c8 1819 gnuhtml2latex_0.4-3.dsc
 d01e71c2b4a06de68fb878f7757b9d69a3498a79 2864 gnuhtml2latex_0.4-3.debian.tar.xz
 6ee6daf5c6d22a498fa4c9bc751c780ee2d7fab4 9862 gnuhtml2latex_0.4-3_all.deb
 0e80457e6604dc34c223429fed71e51cede0c29e 6289 
gnuhtml2latex_0.4-3_amd64.buildinfo
Checksums-Sha256:
 758d66df1d6dfb23eb220f11bef9c2cef312b4fe38302e759fb516edbe74534a 1819 
gnuhtml2latex_0.4-3.dsc
 26c75f92cf8c7c018036db636096b2421f6ba2a337274a49c05282704041778b 2864 
gnuhtml2latex_0.4-3.debian.tar.xz
 83cc7c5f7d2ca2592b2d496e269cca4a73a7165b1391c51fd816672511b5045a 9862 
gnuhtml2latex_0.4-3_all.deb
 53f6af3698bf95eb5f434a858b64be3fc7cff39e4643fb2763931f136b8ceb8f 6289 
gnuhtml2latex_0.4-3_amd64.buildinfo
Files:
 941acd1a32b40ab4ed3ac66c4089b1da 1819 text optional gnuhtml2latex_0.4-3.dsc
 ae26c4d1b48c4d4555295d8daae00d17 2864 text optional 
gnuhtml2latex_0.4-3.debian.tar.xz
 94664a278dfd2b094b385f1dadda9a63 9862 text optional gnuhtml2latex_0.4-3_all.deb
 532d58765a3519e16871453bed5dcc26 6289 text optional 
gnuhtml2latex_0.4-3_amd64.buildinfo

-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEq0HBxor9ZoygRev4ZzoD5MHbkh8FAlkV8pkACgkQZzoD5MHb
kh/iuhAAhAnpUz1eFQjWPl66CG9TdVUDEdXQkgoG/6C+n505rx1gMmCxqPW8OKYR
LOKlc6TcBUFIh7RzMYLQ1PDM7ZsrZHT/SnJvGLLi7X8WTg9Rqp9P+mGBIKFqLdDD
VjM6DOxYPIsu+4u6jisolwY/zfqASRbgG75OHN62e8122a0DxJbBqhkQ4XaGItNr
VZ5cFmBGZ6WVHK/O69E+DsM4AJubsMqIoY1XakkNFn18GDaZJWWJEr4hUn97duep
NCBQU1uHbvZmJr5ll61ln6sRlcRaOm2+HLMRK/1c1PmkFM8ap2BbpJQkqTTXCcZW
uHO/pi5hq1CsaBF11Sd6oG4NWNiJ/vwoKyylc65PoyXYL5XdTdNfwVZMIM2P3ukk
Zu/Kn9iwKD7SrWoqOTASOLXcmZPgBXUxkAJdnRTxyPVj+K9GLeoJzhSmalSv5oTL
G34oS/g8esUvnJ4McIYkf5UmpJtnC/NPcXqcowma0aj+PDQFG85BEUGxiFgty+Rw
xD3/LhXEZXJsBAhi0xIaB9Q3e2VkcVTHYZ73fc1lgfpUsywYzvTeNSSYHB3imCCx
fQkt42UONxmClYF5G0QjjXvAbxOWdfeHnczpgtsdaNp4s35aa0e7087SuZGx4Fp1
Nb5hRWxmtxS3in+7MFtlauCizhOqgNRI1wAC6PW7NENS4kO7yIA=
=kxVY
-END PGP SIGNATURE-

Bug#860714: general: disk became full after running a perl program

[Gunnar Wolf]

The bug submitter followed up by private mail to me only; I'm cc:ing
the bug report before closing it to provide a reasoned follow-up.

- Forwarded message from Luis Duarte <turcova...@sapo.pt> -

Date: Sat, 22 Apr 2017 16:36:29 +0100
From: Luis Duarte <turcova...@sapo.pt>
To: Gunnar Wolf <gw...@debian.org>
Subject: Re: Bug#860714: general: disk became full after running a perl program
Message-ID: <9115278b-70fc-03fd-f7ff-0b56012c2...@sapo.pt>
References: <20170419084010.1659.21073.reportbug@batelatas> 
<20170419235152.ga1...@gwolf.org>
X-Spam-Level: 
X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_00,FREEMAIL_FROM, 
SPF_NEUTRAL autolearn=no autolearn_force=no version=3.4.0

Hi Wolf
Thank you for replying and for being helpful.
I wrote a batch of perl programs to deal with the emails returned to me.
Everyday I send emails marketing a book I had written. The perl program I sent
to you in attachment do the parsing of the files related to the emails
returned to me. The emails are previously saved  in a directory. The perl
program analyses the return codes of emails, and accordingly, the email
addresses are written in different files (a file with the email addresses
considered spam; a file with email addresses considered unknown; a file with
new email addresses, etc). The program also analyses the returning emails like
"out of office". After that, another perl program includes the treated email
addresses in a small (kind of) data base.

Let's go to the reported bug. As I told you, I use the last release of debian
Jessie, with Xfce. Previously, the perl programs were executable ones.
Sometimes, in the file manager Thunar 1.6.3 I click two times in a perl
program (executable) in order to open it with the gedit text editor, but
instead to open it, I mistakenly  execute it. It happens that the
xfce4-terminal (0.6.3) don't open to show the output. Due to these actions, I
think the disk became full several times, creating a lot of trouble.

Since I marked the perl files as not executable, when I click two times on a
perl file, it opens automatically gedit text editor, presenting the respective
perl file. This way, the double click do not start the execution of the
program. When I intend to run the perl program (file), I open a
xfce4-terminal, and write: perl name_of_perl_program. Since then I had any
problem.

In Wheezy I got disk full a lot of times. In Jessie, it happen to me one time.
I managed to free some disk, I restarted the computer, and I got 30% of disk
usage instead of 100%. I think Jessie managed to recover nicely from this kind
of error. On the contrary, Wheezy was a mess.

Soon I will do some experimentation about this bug in a separate disk. I am
not sure that the problem resides in the operating system, or in Xfce, or in
my programs. I am not a perfect programmer.

My best wishes
Luis Duarte


- End forwarded message -

Bug#860714: general: disk became full after running a perl program

[Gunnar Wolf]

Luis Duarte dijo [Wed, Apr 19, 2017 at 09:40:10AM +0100]:
> Package: general
> Severity: normal
> 
> My windows manager is Xfce. Using Thunar - when I opened a directory 
> containing
> perl programs, somethimes I click two times on a perl program to start it. No
> Xterm appears - what I think that happen is that my disk become full. I happen
> a lot of times in Wheezy, but in Jessie it happened one times. I don't know if
> this happens (the disk became full) as I described, if it is a bug of Xfce, or
> if it is a bug of Jessie. In Jessie I freed some space on disk, and I restat 
> my
> computer, and everything runs as normal (with space freed). I Wheezy I had a
> lot of problems.

Hi,

What kind of Perl programs are they? Are they made by yourself, or
shipped by Debian?

Please give us some more insight on what is causing this bug. Only
this way we can be sure what component of Debian is at hand - Or if
it's something we can help you with in your programming.

Re: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Gunnar Wolf]

Nikolaus Rath dijo [Wed, Apr 05, 2017 at 03:18:57PM -0700]:
> >> I have a very different perception
> >
> > Me too.  I guess it depends very much on whether one can afford to buy
> > a good laptop which works well with Linux.
> 
> I think there's a pre-requisite that's much harder for a lot of people:
> finding out what laptop works well with Linux. This is the stage where I
> have repeatedly failed - the differences in model numbers are just too
> tiny and subtle, and typically things that work well are no longer sold
> commercially.

FWIW it's been a long time since I had any problems in this regard,
and I'm surprised it's still an issue among knowledgeable people by
2017!

My last two laptops (bought in 2009 and 2013, IIRC) have been of the
Acer Aspire One range. Both, bought at a supermarket, for around
US$300. Both worked completely flawlessly since day one; I admit to
having b0rked several things (power management included) due to my
configurations, but I'm now used to it "just working" - I last
clean-reinstalled this computer maybe two years ago, and I just push
the lid down, it always suspends properly.

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[Gunnar Wolf]

Sean Whitton dijo [Mon, Feb 13, 2017 at 04:33:15PM -0700]:
> > So, my idea was, in short: Thinking in a post-Buster world, do we even
> > need the finalized line? I mean, take a look at debian/changes. The
> > archive handling tools do get both «Date» and «Changed-By» fields,
> > which reflect when the package was last *built* (which has a much
> > clearer meaning than a nondescript finalization line). Debian tools
> > can act from there. We could then just remove this dissonant bit :-)
> 
> The final line of a finalised changelog indicates who signed off on the
> package: the person who said "it's time to upload this".

At least according to some readings. Up to now, I never gave any
thought to this line; usually dch updates the date for me, but I often
upload packages "signed by" others, or the opposite.

> I think that we should continue to record the person who made that
> judgement.  Someone who made a small change and whose name appears [in
> square brackets ] shouldn't automatically have responsibility for the
> whole upload -- but *someone* should have that overarching
> responsibility.

I see, and it is a valuable reading. I wonder if I'm alone in not
considering it important so far (after all, I've only been a DD for 14
years...)


signature.asc
Description: Digital signature

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[Gunnar Wolf]

Sean Whitton dijo [Mon, Feb 13, 2017 at 04:35:19PM -0700]:
> > (Of course, the signoff line in the changelog is redundant with
> > the GPG signature, which is what actually matters but isn't at all
> > user-visible...)
> 
> It's not redundant for sponsored uploads where the sponsor is not a
> member of the relevant team (which are quite common on
> d-mentors@lists.d.o).  The sponsee needs to sign off on the whole
> upload, in addition to the sponsor.

Right, I didn't think about that. Maybe it's time I go back to
sponsoring uploads to understanda gain that side of Debian ;-)


signature.asc
Description: Digital signature

Re: changelog practice, unfinalised vs UNRELEASED vs ~version

[Gunnar Wolf]

Simon McVittie dijo [Sun, Feb 12, 2017 at 02:11:12PM +]:
> On Sun, 12 Feb 2017 at 12:48:35 +, Ian Jackson wrote:
> > What do people think ?
> 
> I think you're the only person I've ever seen using unfinalized
> changelog entries for Debian packages.
> 
> If I'm understanding correctly, your motivation to do so is that you
> have a strong belief that building a Debian source package with `debuild`
> or similar, directly from a VCS checkout, should always work and should
> always produce results that could be considered correct (in terms of not
> having the version number of a prior version, not having the version
> number of a future version either, not claiming to have been released
> by a person who did not in fact release it, and so on).
> 
> These might be valid axioms for your particular workflow, but they do
> not fit all workflows, and I don't think they are necessarily the
> axioms that lead to the best practical results.

Interesting discussion. This (and not particularly your message, but
this whole thread even leads me to questioning: Does our "finalized"
changelog lines make *any* sense nowadays?

Let me explain. I think this line has clear signs of days long past:

 -- Gunnar Wolf <gw...@debian.org>  Mon, 13 Feb 2017 10:37:57 +0600

Yes, in some way it summarizes who did the last (or first? or n-th?)
modification to the changelog entry in case. But, given we see
team-maintained workflows as preferable, it is very common to also see
the following in the lines behind it:

  [ Gunnar Wolf ]
  * Frobbed the foobarnicators
  * Oiled up the grease

  [ Other Maintainer ]
  * Replaced quux with blah (Closes: #876543)

A text line documenting who (something)ed (first|last) with the
changelog is not really relevant. The date is even treacherous; it
could have been introduced by me when frobbing up the
foorbarnicators. There is no indication as to whether Other did his
work before I oiled up the grease — at least in debian-keyring we have
the habit of grouping maintainer messages (by using dch
--multimaint-merge) instead of keeping time-order. Maybe this would be
the real sequence of events in my example changelog:

  [ Gunnar Wolf ]
  * Frobbed the foobarnicators

  [ Other Maintainer ]
  * Replaced quux with blah (Closes: #876543)

  [ Gunnar Wolf ]
  * Oiled up the grease

But it creates too much unnecessary and (at least in some aspects)
redundant noise.

But... Yes, even though in our case (debian-keyring) the changelog
closely follows the Git commit messages (the first line matches for
all "routine" changelog entries), debian/changelog and git log have
somewhat different and general meanings.

> * Write the changelog later: each commit just has a commit message
>   in a normal git way, and its debian/changelog is out of date.
>   At release time, write a cumulative debian/changelog entry for
>   everything that happened since the last release, finalize it and
>   commit it. The `gbp dch` command assumes this model (and is very
>   useful when following it).

In the specific case of this team, we could most probably compose
debian/changelog by reading git log since the last tag. But... I am
not convinced I want to be constrained by this!

Anyway, I'm steering quite a bit off the track

> > Q2. Should the changelog entry be finalised ?  That is, should it
> > have an uploader name and date ?
> 
> While as an abstract model I agree that the uploader name and date
> are not meaningful in an unreleased version, I can't help thinking
> that this is a "boil the ocean" sort of change - a lot of tools follow
> and require Policy syntax, in which the uploader name and date are
> non-optional. Obviously, Policy only really applies to finished packages,
> and unfinished packages often violate the semantics of Policy (for
> instance by using UNRELEASED as a suite name); but it seems reasonable
> for a tool author to oppose changes that, as well as violating Policy
> semantics, also violate Poliy syntax.

So, my idea was, in short: Thinking in a post-Buster world, do we even
need the finalized line? I mean, take a look at debian/changes. The
archive handling tools do get both «Date» and «Changed-By» fields,
which reflect when the package was last *built* (which has a much
clearer meaning than a nondescript finalization line). Debian tools
can act from there. We could then just remove this dissonant bit :-)



signature.asc
Description: Digital signature

Re: Team analysis graphs

[Gunnar Wolf]

Andreas Tille dijo [Wed, Feb 08, 2017 at 10:03:30AM +0100]:
> Hi,
> 
> this is my yearly hint to the teammetrics graphs you can find for your
> team at
> 
>  http://blends.debian.net/liststats/

Very interesting! I will share this link with a student who is working
with me and doing time-related analysis of Debian; he started by
working with the keyring data, but this will surely be interesting to
him.

The sheer number of files you are presenting is overwhelming as it is,
but, if this person is interested in this data, could you share your
dataset at a finer resolution? (say, monthly instead of yearly) Or, if
you don't keep the source data with you, the scripts that produce
them?

Thanks a lot!


signature.asc
Description: Digital signature

Re: If you can't describe what the package is, you probably should not Intend To Package it.

[Gunnar Wolf]

Hi Jordi,

Jordi Mallach dijo [Tue, Jan 31, 2017 at 12:38:18PM +0100]:
> I know dh-make-golang creates an "ITP template" that you edit to
> correct/improve the autogenerated stuff, and the description comes
> directly from the README.md in the github repo. I wonder if the nodejs
> stuff does something similar and that's where the not so great
> descriptions come from.

Maybe adding a note stating 'this content is autogenerated and should
be hand-reviewed', in all of the dh-make-*-enerated packages, would
help?

Re: Bug#851306: ITP: freebayes -- Bayesian haplotype-based polymorphism discovery and genotyping

[Gunnar Wolf]

Scott Kitterman dijo [Sun, Jan 15, 2017 at 04:34:40PM +]:
> >> "freebayes" seems like a very generic name for something specific to
> >such a 
> >> narrow field.  Maybe freebayes-genetic-variance or some such instead.
> >
> >I fully agree with your generic name consideration.  The software is
> >well known in this work field anyway so I'm hesitating a bit to rename
> >it.  Would you consider this a strong issue that needs to be discussed
> >with upstream or is it in a "not nice but acceptable" status?
> 
> I think it should be discussed with upstream, but we have broader
> namespace considerations that they may not understand or care about.
> 
> As long as a package search for freebayes returns this in the result
> set, I don't think it's critical to have the package name match
> exactly the upstream name.
> 
> Not wearing my FTP team hat for this, consider it as a comment from
> another DD.

As Scott is not "officially" speaking from the FTP team but just as a
DD, I'll chime in here.

I think the package name should indicate the field for which it is
meant (freebayes-genetic-variance), but I don't think the program name
should deviate from upstream; we have had issues such as when node.js
was introduced (that 'node' was a name already taken by another
program), but I don't think 'freebayes' will be such a contentious
program name.

Accepted drupal7 7.52-2 (source all) into unstable

[Gunnar Wolf]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Format: 1.8
Date: Tue, 13 Dec 2016 11:09:27 -0600
Source: drupal7
Binary: drupal7
Architecture: source all
Version: 7.52-2
Distribution: unstable
Urgency: medium
Maintainer: Gunnar Wolf <gw...@debian.org>
Changed-By: Gunnar Wolf <gw...@debian.org>
Description:
 drupal7- fully-featured content management framework
Changes:
 drupal7 (7.52-2) unstable; urgency=medium
 .
   * Added the Druplicon in vector format, providing the preferred form
 of modification for an icon used in several places throughout the
 package. Thanks to Sean Whitton for the pointer!
Checksums-Sha1:
 603418891fd9647cc4c5641d84c11d99cf2747bd 1844 drupal7_7.52-2.dsc
 d74fc05711c3224881591598598532345fbd26ff 188360 drupal7_7.52-2.debian.tar.xz
 025ca93ba7df74ec147f4d72554b0395b7769666 2519602 drupal7_7.52-2_all.deb
Checksums-Sha256:
 f9d424fbd98cc12ab53e01c92d3138b8c6f156f9e27e4064b6c007c7c94d8b30 1844 
drupal7_7.52-2.dsc
 66925940f8c556596c9ca7207195d0d18b175a5d0577319fc8025dd030e45e9f 188360 
drupal7_7.52-2.debian.tar.xz
 6b210897580cbd4c0688c5b0ba8c5d661afb88efaa21fc2fb5d8bee3bb4c 2519602 
drupal7_7.52-2_all.deb
Files:
 f8bd7c30dfc6dd863fd4c2249c1c38a9 1844 web extra drupal7_7.52-2.dsc
 c083b1797d42687dc96971cd007c0925 188360 web extra drupal7_7.52-2.debian.tar.xz
 5f722b06ef6a914b8aa95844925c2969 2519602 web extra drupal7_7.52-2_all.deb

-BEGIN PGP SIGNATURE-

iQIcBAEBCAAGBQJYUCvJAAoJEGc6A+TB25IfIikP+wbZAxzgI23J3vtLWW6jz+Wm
SQHpJ/1ZvinkpV7YtOdFw5+5pisVK78P0jVgyxH6nevkjGZVcyn3WpbJaUMqCFen
1XHYQzNve2SyQHsU/ahIB5g6iG7/k4jNTpCwR1RODtg05EIH7gBww9NzPKhOcNWr
BLTJXQw0Naf8ef/CeyXhYfOrNZReuSMWWdPMsMumkgiEqc89coFBpdEmxjvo9GsO
69PMYQDuJbtlJRDOEw6obSZJuzh+SqZnl2h/pnB5nZ0RnAjH1aQP+uwqfKZBkKOx
7ZqeeQlee6e8NgVonRW/XnsCC+MAbI2y5kjzjnmbAlNsCiLJG141+OwrFV1EPA4+
rJAYr9jCNWZ6L6alIipIyu2CsOyKY+eXDrbkunH/Iad6h9YdSJMFqpWt2h4m53JX
VlPEu4mlrfSwfSdaWEn2HjBegbbl5dHLfCBmUQqxKKYo7sBXtyXhNLwi7sIpQcXa
C3KNxf5MTiDD0B2PZa4UscRDPDfD9KJYGYQAMFWru1lVNpYZVqJ371/Wyds3RwR2
QNVONKkVq9WBuJPObVLpeaquxIWgWGQXCgs3T5sIW5b1cj/DHWXwTo5ecRTfqvb7
GNnvY8Wj25zktroLGdy+SE5g2ApvNRjV9iQONqQKs/qqS3HYPX0LXfD1YzKmmD5z
tXvfeYxkxqR0Qg+sBG2+
=Ls+T
-END PGP SIGNATURE-