Re: Q: Ubuntu PPA induced version ordering mess.

[Gunnar Wolf]

Alec Leamas dijo [Tue, Jul 02, 2024 at 01:59:26AM +0200]:
> So, at least three possible paths:
> 
> 1. Persuade users to uninstall PPA packages before installing official
> packages and also generation 2 PPA packages with sane versions like 5.10.x
> 
> 2. Use versions like 9000.5.10, 9000.5.12. etc.
> 
> 3. Use an epoch.

You can also consider a third possible path: Pick a different package
name.

I am unfamiliar with opencpn to be able to suggest an alternative. But
given opencpn has never been part of Debian, you could just name your
package "opencpn-deb". Just to be sure users don't get surprised by
having two different versions of the same package, it can "Conflict:
opencpn". Then, you get a blank slate from which you can work your
versioning as you deem adequate.

It does, yes, introduce some confusion, but I think is the least evil
option. 

Re: Mini-DebConf in Cambridge, UK - October 10-13 2024

[Gunnar Wolf]

Roberto C. Sánchez dijo [Tue, Jun 25, 2024 at 06:14:54AM -0400]:
> On Tue, Jun 25, 2024 at 08:39:51AM +0530, Nilesh Patra wrote:
> > On Mon, Jun 24, 2024 at 12:32:59PM +0100, Steve McIntyre wrote:
> > > On Mon, Jun 24, 2024 at 12:18:56PM +0200, somebody *claiming* to be Luna 
> > > Jernberg wrote:
> > > 
> > > 
> > > 
> > > Just to be 100% clear, that mail didn't come from Luna's normal gmail
> > > account but was instead spoofed and sent via emkei.cz, a "free online
> > > fake mailer". It's now blocked from Debian lists.
> > 
> > If what you're saying is correct (based on headers that make sense), it's a 
> > bit
> > concerning since someone is launching targeted spoofing attacks with the 
> > name
> > of actual Debian contributors.
> > 
> > The style of writing mail - everything in one line, CCing several lists is
> > similar to how Luna writes it too. Freaky.

Sadly, we do have our resident, established, well-known favorite
troll. And the project has quite recently made an announcement
involving him:

https://lists.debian.org/debian-news/2024/msg0.html

So, given no evidence otherwise, I point my finger to said troll's
general direction.

> AI can already generate audio and video that convincingly imitate real
> people. Why not the same with email? Though, the implications are rather
> serious.
> 
> Perhaps our policies need to evolve to expect (or require?)
> cryptographic signatures from DDs in mailing list discussion. We may
> eventually reach a point where AI can fabricate those as well, but that
> seems to not be possible yet.

This time around we don't need to overcomplicate things given we know
it is his establihed pattern to come up with false identities trying
to smear sh*t on DD's noses.

Re: About i386 support

[Gunnar Wolf]

rhys dijo [Fri, Jun 14, 2024 at 01:09:18PM -0500]:
> My response remains the same.  If it only affects a small slice of
> systems that already represent a small slice of systems, it becomes
> untenably difficult to chase that one bug that affects that one
> case.
> 
> But that does not translate into an excuse to drop all of the many
> working legacy systems.
> 
> This argument gets used both ways by people who just want to abandon
> "old stuff," regardless of the circumstances.
> 
> As someone who uses things until they fail, I find myself unmoved by
> these excuses.
> 
> There is always a corner case that doesn't work.  But my 32-bit
> machines have been able to run Linux for as long as Linux has
> existed.  Even under the bookworm "Intel 686-only" rules, it still
> works, so I still use it.  It's built, it runs, it serves a purpose,
> and it costs very little.
> 
> Dropping support for something that works based on some other much
> less common thing that doesn't work sounds to me like an excuse, not
> a logically valid reason.

I'm very happy that Debian has provided you with a tool for your aging
hardware for 30 years already. However, the Debian project (a group of
around a thousand individuals, each of them working independently in
their own time, and according to their own motivations) has decided to
drop support for that architecture.

I am sorry this becomes a pain point for you. As a project, we try to
always put our users first. But there is a tension --- the amount of
energy (person-hours) needed to keep i386 alive is higher than what we
are willing to put up with (and there are many documented documents
leading to that, mostly the most prominent of which is the
architecture qualification rules).

Maybe you didn't read Russ' excellent explanation as an answer to your
previous message. Supporting an architecture (that, yes, still has
many millions of computers that can use it, and that was the original
development target both of Linux and of Debian) is not as easy as
setting up some computers to compile and accept some bugs as corner
cases. There are, and there will be, each time more technically-hard
bugs to overcome.

And there's just not the needed interest to keep it alive.

In case you, and a group of devoted people, are willing to put up with
the effort to keep i386 a viable architecture, please step up and do
it (either as a port or as an official architecture). It is too late
for you to become a DD and join the developer for architecture
qualification for the Trixie cycle (but having a full-hosted i386
install as a port would not be impossible!), but you might still
achieve it for our next release.

In the meantime, please don't abuse volunteer time. Every minute
somebody spends time answering to rants blindly saying that "this old
stuff is not so broken" is a minute we don't spend making Debian
better for more use cases.

- Gunnar.


signature.asc
Description: PGP signature

Re: DEP17 /usr-move: debootstrap set uploaded

[Gunnar Wolf]

Helmut Grohne dijo [Thu, Jun 06, 2024 at 09:28:52AM +0200]:
> Hello,
> 
> I have just uploaded
>  * base-files
>  * bash
>  * dash
>  * glibc
>  * util-linux
> to unstable. These were the last remaining packages shipping aliased
> files inside the package set relevant to debootstrap.
> (...)
> Thanks for bearing with me and also thanks to all the people (release
> team and affected package maintainers in particular) who support this
> work.
> 
> Helmut

Let me chime in with all of the people that have been amazed at your
depth of analysis and your commitment to implementing the *properly
right* situation. It cannot be overstressed that, for this release
cycle, one of the main reasons Debian will probably keep its honor
badge of being easy and reliable to upgrade without breakage is the
work you have taken as yours.


signature.asc
Description: PGP signature

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

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\]"
CO

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.

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: 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,

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

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  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: 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

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 pref

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.

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...

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  -

Date: Sat, 22 Apr 2017 16:36:29 +0100
From: Luis Duarte 
To: Gunnar Wolf 
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   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.

Re: spammers closing bugs in BTS

[Gunnar Wolf]

Daniel Pocock dijo [Wed, Aug 17, 2016 at 06:38:35PM +0200]:
> I was only talking about control emails (e.g. the -done address and
> control@).  The requirements for opening bugs or submitting comments
> (without pseudo-headers) could remain as they are.
> 
> Maybe it could insist that emails from addresses known to be DDs have
> to be signed.  This would prevent people impersonating DDs.

Ummm... I'd set the bar a bit lower - If mails closing a bug were
required to be from an identity that had already corresponded to such
bug report. Of course, we would probably be tying the verification to
the sender mail address, and that can be problematic if I tend to mail
from different addresses, but it'd be a point to later work on
(i.e. maybe also match on sender name, or such).

So, if I were to close a bug I had not previously interacted with,
maybe it would be required for me to send a mail stating "I will soon
close this bug" five minutes before actually closing it. Or maybe
adding a 'X-not-a-robot' pseudoheader.

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Gunnar Wolf dijo [Wed, Aug 10, 2016 at 02:08:12PM -0500]:
> That's the reason why a key by itself means little, but we do place
> value on the web of trust around it.
> (...blah...)

Anyway, I managed to twist my mail with many facts and make it into a
long mess :) That was my main point. Nobody should trust my key to be
"just" even AB41C1C68AFD668CA045EBF8673A03E4C1DB921F — It's not yet
feasible to willingly create a collision, but by mere chance, somebody
might just find it on their next key generation. My identity should be
trusted based on this long number plus the web of trust around
it.

It is highly unlikely somebody will find a collision with my
fingerprint by itself, but it's mindboggingly stupidly utterly
bloody unlikely some will find two, three other (even 64-bit)
collisions to sign my fake with. And I have over a hundred ;-)


signature.asc
Description: Digital signature

Re: use long keyid-format in gpg.conf (Re: Key collisions in the wild

[Gunnar Wolf]

Samuel Thibault dijo [Wed, Aug 10, 2016 at 02:03:33PM +0200]:
> And actually, moving to 64bit fingerprints by default is possibly not a
> good idea: who knows when 64bit will not be secure any more? Estimating
> very roughly, if a 32bit collision can be found within a few seconds
> with one GPU now as evil32 seems to show, a supercomputer with 1
> GPUs can find a 64bit collision within a month...
> 
> Really, only signature paths should be looked at by people, and it seems
> like we are tending to let people think 64bit fingerprints are "secure".

That's the reason why a key by itself means little, but we do place
value on the web of trust around it. If a given 64-bit keyid takes a
month to generate¹, and the uploading developers keyring is somewhere
around the 820 keys (from which around 700 make up the strong set), it
would still take ~60 years to generate our full strong set of evil
twins. This is not trivial time.

Of course, Evil32 started aided with the power of numbers — It's not
that they search to make a evil-twin of every 32-bit keyid, but that
they generate keys as fast as they can, and just discard any key not
matching an existing keyid. The keyserver network currently carries
over 4.3 million keys, so roughly one every thousand generated keys
will match *something*¹. Of course, Evil32 is interested in the
keyservers' strong set, which I guess will be way smaller (but have no
numbers to back my hopes).

I believe we are safe to use 64-bit keys *for the time being*. Of
course, nobody will imply that it's as safe to use 64-bit as
160-bit. We should end accepting that human-usable keyids are not
worth their salt and move to full-fingerprint. But there are many
things to fix before that... Among them (and I might be mistaken here)
the PGP key format itself, as AFAICT signatures are stored based on
their long keyid (and not on full hashes)!

--

¹ Yes, the keyserver network carries several already collided keys —
  Such as the ones that prompted this thread!

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Jonas Smedegaard dijo [Thu, Jun 23, 2016 at 10:30:21PM +0200]:
> I sign keys by a similar policy as Gunnar, it seems.  But I do sign also 
> people I have not met before...
> 
> The logic I use is that I should be able to re-identify later.  If I 
> meet the person later I might have forgotten their name (I easily do) 
> but if they remind me and tie it to something we talked about or did 
> together, I should go "Ahhh!" rather than "hmmm".
> 
> It is a balancing act.  Easiest is to only trust your mother and very 
> close friends through many years, but you also want to expand the web of 
> trust (and maybe also social circles, but that is a _different_ matter).

Excelent! I knew you were a good friend to keep around ;-)

> I think what can help here is expiry time on signatures: If my gut 
> feeling says that the person I've discussed perl with for an hour does 
> not really etch into my brain that efficiently, and I worry if we bump 
> into each other, say 3 years from now, then I would've forgotten who it 
> is.  What I then do is sign but with an expiry of the key of 1-2 years.
> 
> Expiry on signatures is relatively new to me, however, so I welcome 
> input on how that is sensible or not.  And also on how to eventually 
> extend the lifespan.

OK, so the people that agree with Jonas are exempt from attending my
session in DebConf, Monday 2016.07.04, 4PM. I expect to show some
pretty graphs and talk about how I have been having fun with the
keyring lately :-) So welcome to join, or to stream. Or to see later,
of course!


signature.asc
Description: Digital signature

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Jakub Wilk dijo [Thu, Jun 23, 2016 at 07:30:42PM +0200]:
> * Nikolaus Rath , 2016-06-23, 09:23:
> >I am wondering if the extra burden is worth the gain in security. If
> >everyone were to follow this procedure then the bar to becoming a Debian
> >developer would be raised significantly.
> 
> As as data point, if everybody[0]'s key signing policy had been that
> establishing "social bonds" was a prerequisite, I would have almost
> certainly never become a DD.
> 
> [0] And by "everybody" I mean that one developer that happened to live in
> the same big city as me.

Of course, the same can be said for me. My first signature was by
Bdale, when he was invited to give a talk in Mexico (and I jumped to
find him), and my next three were by three DDs living at the time in
Munich, where I went to for a conference. We had no previous knowledge
of each other.

I have at times advocated to DAM for accepting a DD with no signatures
on his key when it was clear they were unable to get any; I have (and
will) sign many keys without clearly meeting the criteria I
delineated, but always on a one-on-one basis (and never again on a
mass KSP).

I will not formally specify my signing policy as some do¹, asI use
this criteria just as a *criteria*, not as a hard guideline. And I
don't expect you or any of the participants on this thread to apply
the exact same criteria I do, much less with the same exceptions I
make. I just insist on showing my stand on this... And *try* to be
coherent with what I believe to be a right usage, without being at the
same time a PITA.

--
¹ From the people that have signed my key:

  
http://martin-krafft.net/gpg/cert-policy/55c9882d999bbcc4/200907121833?sha512sum=f33b17c9af515bd98b2927cb453a992d3d7500e9f671966616e90510b9940895108d241648d1a0eb46b32bcbf3251a136a6ee1e2275745e11bb328c14e7e7263
  
http://www.golden-gryphon.com/download/policy.20090821.txt?version=1.0&sha256sum=03b987f1eefa098c350929157e9c6ef5d234970c406e748935e65c0efcceaebb
  


signature.asc
Description: Digital signature

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Lars Wirzenius dijo [Wed, Jun 22, 2016 at 07:32:28PM +0300]:
> PS. *Obviously* a policy to only sign keys for people you already know
> is a stratagem to get people to talk to me at parties.

Grah, my evil plan has been foiled. I fear, I will sit lonely with no
friends at DebConf :-(

Please, somebody come talk to me, starting next Tuesday! \o/


signature.asc
Description: Digital signature

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Nikolaus Rath dijo [Wed, Jun 22, 2016 at 07:58:43AM -0700]:
> > Now, I have said this too many times, but once more: As keyring-maint,
> > we are not collecting samples of people showing valid-looking ID
> > documents to others. This is one of the issues why we don't have
> > long-queue key signing parties: Just checking the ID of a complete
> > stranger is not real identity validation.
> >
> > My personal guideline is that I will sign your key if and only if I
> > see your face and can think of your name, and the opposite way
> > around.
> 
> Hmm. Can you explain that in a little more detail?
> 
> As I understand, we'll have to meet a few times for beer until we
> remember each others name, and then we sign keys - without ever having
> verified if we've actually given our legal name.

Yes, I try to keep that as a guideline. Of course, were you to come to
Mexico and meet me, or where I to travel to wherever you live, if we
agree to meet for a beer or so and have a couple of hours chatting
about what we do and want in Debian or in life... I guess I'd have a
much better recollection on your face than if we had met at a massive
key-signing party.

In said case, however, I would resort to verifying your identity on
some official-looking papers. It is not what *I* regard as best, but
it's the closest available. Living over 1000Km from the nearest DD, I
know firsthand that some people can have a hard time getting
signatures, and I will be flexible if needed. But those special cases
will more probably "make it" to my long-term memory.

> I'm a little confused as to what sort of malicious activity this is
> intended to stop/make more difficult...? 

I want to ensure people actually are known by the identity I sign. The
best way to do it is to interact in their social circle and know other
people that trust this person's identity. Of course, that's often
impossible.

A second-best would be to meet you repeatedly throughout some time
period, with you having the same identity. That's what I do most of
the time: I know the names or pseudonyms of people in Debian and in my
local LUGs. I will sign according to those.

Government-issued IDs are, IMO, a distant third.

What can a malicious user do? Say, you detect that Foob Arski is a MIA
Debian Developer and his mail address bounces. I can point you to
several places in my city where you can print genuine-looking fake
IDs. Get a drivers license or so going by Foob's name, come to me,
I'll sign your key. Do the same with one other DD. Then ask DAM to
change your mail in db.debian.org, and ask keyring-maint to change
your GPG key. There, you have successfully impersonated a MIA DD, and
got upload, machine usage and voting rights in Debian.

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Jason Thomas dijo [Wed, Jun 22, 2016 at 02:38:52PM +1000]:
> Hi Gunnar,
> I'm basically in Sydney Australia, however finding time to meet people
> is difficult these days, with work, a wife and two little kids.
> I live in Penrith NSW, and work in Granville NSW. I do travel up and
> down the east coast of Australia and around Sydney for work, buts its
> sporadic.
> If anyone living in the Sydney area wanted to meet up, I'd be all for
> it.
> Thanks.

Answered mostly off-list, as this included some could-be private
information I gathered from many public sources :)

Now, for anybody needing to set up a keysigning, please do remember
checking the relevant web page for your country!

https://wiki.debian.org/Keysigning/Offers#AU


signature.asc
Description: Digital signature

Re: Keysigning via Video Conferencing

[Gunnar Wolf]

Jason Thomas dijo [Mon, Jun 20, 2016 at 12:31:57PM +1000]:
> Hi all,
> 
> I need to get my key signed, is anyone willing to work with me via
> video conferencing.
> 
> I have uploaded my key to keyring.debian.org and I have also signed
> this message.
> 
> I have a scan of my government issued drivers licence available.



The medium you use to verify your counterpart's identity when
performing a signature is completely up to you; I could be perfectly
happy with cross-signing with $person via videoconferencing — But what
we push, what we *really* expect each of us to do, is to actually
*ensure identity*.

For some, ensuring identity is a matter of checking a
government-issued ID. In this case, Jason is providing a scan of such
an ID. Might I add, in case you take on his request: Are you familiar
with his country's drivers licenses? How hard are they to forge? How
hard would they be to digitally manipulate without other parties
noticing? If that satisfies you, please go ahead and sign. Of course,
Jason, same for you — Although it suffices for us to have your key
"reachable" from the strong set, we really prefer your key being part
of the strong set (that is, other keys being reachable from yours). If
somebody signs your key, please try to sign theirs as well (if you are
convinced of their identity).

Now, I have said this too many times, but once more: As keyring-maint,
we are not collecting samples of people showing valid-looking ID
documents to others. This is one of the issues why we don't have
long-queue key signing parties: Just checking the ID of a complete
stranger is not real identity validation.

My personal guideline is that I will sign your key if and only if I
see your face and can think of your name, and the opposite way
around. That is, if I have a decently-lasting memory of you. Being my
brain so deffective in that sense, it is quite a high bar to pass. But
it's also very flexible as well: I can count several dozens of people
in this project who could set up a videoconference with me, read a key
fingerprint with no further requisites, and have a successful
exchange.

Just as an example (as he answered to this mail), were Jonas to ever
require a key signature from me, he is free to video-call me, even if
he decided to burn all of his government-issued papers, as his face is
worth more to me than any document. Of course, that gives me the
flexibility to also decide to sign pseudonymous keys — I have several
friends who are not OK with divulging their official identity. I often
don't know their real names. That won't stop me from signing their
keys, if their pseudonym's usage is long-term and consistent.

I like my personal policy, but cannot enforce it on anybody. I expect
us all DDs to be careful and responsible on what we sign. Define
responsible as you prefer.

Jason, as Jonas said: Where do you live? We are most interested in you
getting your key back online. If you want, contact us directly to
keyring-ma...@debian.org (or publicly here, if you are OK with it) and
we can try to arrange for an in-person meeting between you and
somebody else!




signature.asc
Description: Digital signature

Re: Next steps for gitlab.debian (Re: GitLab B.V. to host free-software GitLab for Debian project)

[Gunnar Wolf]

Pirate Praveen dijo [Tue, Jun 07, 2016 at 11:22:11PM +0530]:
> Does gitolite allow merge requests? How easy it is for a new contributor
> to use gitolite? I think the merge request workflow is really the key.

Gitolite is a very lightweight way to manage access to a set of Git
repositories to several users, identified by their public SSH key. It
is a decently elegant solution to host Git repositories where you
don't want to set up system accounts; easy to set up by non-root users
even on shared server settings. But it's quite far from what Gitlab or
Alioth offer — It is not a full project tracking/management system.

Bug#819663: O: collabtive

[Gunnar Wolf]

Package: wnpp
Severity: normal

Collabtive is a very nice and simple, calendar- and project-based
group collaboration tool. The package description reads:

Description: Web-based project management software
 This package is intended for small to medium-sized businesses and
 freelancers.
 .
 All major browsers like Internet Explorer (7/8), Firefox, Opera,
 Safari, and Chrome are supported.

(ouch, didn't see how outdated the description is! ;-) )

I have maintained it since June 2010, and has mostly been an easy
task; upstreams are friendly, although some views on the world diverge
to what we have in Debian.

I have left pending the work for the new upstream release for too
long, and I'm leaving my work-in-progress as it is in the Git
repository. IIRC, the main issue delaying the upload was that I wanted
to provide sources for the Javascript libraries that are embedded in
minified-only version.

Re: dbconfig-common: near future change in dependency stack

[Gunnar Wolf]

Mathias Behrle dijo [Tue, Dec 08, 2015 at 10:16:38AM +0100]:
> Some questions for Tryton server:
> 
> The situation is
> 
> - Tryton server runs out of the box without configuration with a SQLite
>   database
> - The (strongly) recommended database is PostgreSQL, but there is also support
>   for MySQL (and beta for Oracle)
> - There is a standalone package called Neso (Tryton Neso), that provides a
>   simple combined setup of Tryton client and server (using SQLite), depending
>   on those two.
> 
> Would it be possible for the last point to skip completely the database
> configuration (e.g. dbconfig* not jumping in at all, when tryton-neso pulls in
> tryton-server)?
> 
> What would be the best way to handle the strong preference for PostgreSQL?
> MySQL is supported for Tryton, but fails to complete some tests due to missing
> Standard SQL compliance. So I dislike generally the idea to install a
> client package for MySQL on a default system. The solution would probably be 
> to
> not implement at all the option for MySQL, right?

Ummm, I think this level of detail is where you should not leave it up
to the package manager only, but explain the situation to the user, be
it (very succintly) as part of your debconf prompts, or (better?) via
a README.Debian

Re: Buen dia

[Gunnar Wolf]

[ Sending instructions on how to subscribe to our lists ]

Marcos Jimenez dijo [Sun, Sep 06, 2015 at 04:05:23AM +]:
> Buen dia me gustaria suscribirme
> 
> Marcos Jimenez

Hola Marcos,

Para subscribirse a las listas de Debian, puedes hacerlo desde nuestra
página Web. Para esta lista en particular, puedes hacerlo desde la
página:

https://lists.debian.org/debian-devel/

Toma en cuenta que esta es una lista enfocada al desarrollo de la
distribución. Si te interesan listas para aprender o preguntar acerca
del uso, te sugiero esta:

https://lists.debian.org/debian-user/

Y si prefieres una en español:

https://lists.debian.org/debian-user-spanish/

En general, si no se indica explícitamente, las listas de Debian son
en idioma inglés.

Saludos,

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Wed, Sep 02, 2015 at 09:47:23AM +0200]:
> If you talk about uglifyjs or the like, it is already packaged and
> doesn't solve all the problems we have (see my message to Odyx,
> ).
> 
> If you talk about Grunt, Grunt comes with a lot of plugins (and does
> almost nothing without those) and each upstream will require different
> plugins with different versions (Grunt plugin versions are evolving
> fast). See the tree I posted for jQuery 3.x in
> . All this dependency chain is maintained
> by a variety of upstreams with different release schedules and goals.

This sounds quite similar to the situation we had with Rails (might
still have it, but I cannot say for sure, as I'm not much involved
with it anymore). Rails packages a set of Ruby libraries, each of
which has its schedule and versions.

Rails' developers "curate" such libraries, write some glue between
them (sometimes even take over their whole development), and come up
with "versions". Those versions have a stable set of libraries
presented together.

Of course, that does not (completely) solve the mess we have to deal
with when packaging Ruby, as each developer wants her code to work
with wildly differing versions of the involved "gems", and... and...

Sigh :-) You know what I mean.

But anyway — Grunt can be seen as a whole. If you just see it as a
collection of plugins, packaging them becomes just a pointless
PITA. We just cannot have different versions of hundreds of projects
in Debian and expect to maintain a decent code quality. Bad Things
(i.e. software vulnerabilities) can and will happen, and as Neil
Williams mentioned earlier on this thread, keeping track of all those
embedded code copies becomes an exponentially hard task.

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Lars Wirzenius dijo [Wed, Sep 02, 2015 at 09:32:12AM +0300]:
> However, I want to raise the point that upstreams do not always make
> sensible decisions, and if they don't, it's good to raise that with
> them. For example, there was recently an ITP bug for
> node-number-is-nan. Upstream source code is at
> https://github.com/sindresorhus/number-is-nan, and the whole package
> boils down to these four lines of code:
> 
> 'use strict';
> module.exports = Number.isNaN || function (x) {
> return x !== x;
> };
> 
> (https://github.com/sindresorhus/number-is-nan/blob/master/index.js)
> 
> If something or someone needs this, we should package it, and it seems
> Grunt needs it. However, it doesn't seem sensible to have a package
> for every one-liner Javascript function, either in Debian or upstream.
> (...)

I agree, having all the boilerplate and infrastructure that make up a
package makes very little sense in this case. We have several packages
that are made up of bits from different origin, but linked with a
common target. The first example that comes to my mind is devscripts
(which, yes, has important peculiarities, such as being mostly written
by Debian-people as upstreams), but others can be mentioned
(i.e. emacs-goodies, texlive-generic-extra, etc.)

Such a package could be created for all such Javascript snippets which
present a ES6→ES5 "transpiler" (I still don't believe in such a term),
i.e. things such as what's mentioned at:

   https://github.com/addyosmani/es6-equivalents-in-es5

   
http://www.agile-environment.com/blog/fox-on-software/2015-04-06-es6-coffeescript-part-1

That is, one package that would allow using tricks such as Perl
(>=5.10)'s "use feature" and "no feture" tricks that allow for Perl6
idioms.

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Fri, Aug 28, 2015 at 10:48:28AM +0200]:
> >> What will happen is that maintainers will fallback to the second less
> >> horrible solution and cripple the package (by using an older version of
> >> the JS lib for example) to allow it to stay in main.
> >
> > Why would they want to stay in main?
> 
> [...]
> 
> > I had the same issue with loadlin: it could only be built on MS-DOS with
> > the proprietary tasm, and thus got #356055. I thus extended the free
> > yasm to recognized the tasm syntax, and patched loadlin a bit to remove
> > some extensions which were hard to implement in yasm but easy to replace
> > in loadlin.
> >
> > Then it could stay in main.
> 
> Here is why.

So, in short, this could be read as "it implies extra work".

But what makes Debian famous for is that we as developers *do* make
that extra work.

It is a great benefit to our users, and it's a core value of the
project. So core, that it is encoded in our foundational documents. 

Re: Security concerns with minified javascript code

[Gunnar Wolf]

Vincent Bernat dijo [Fri, Aug 28, 2015 at 11:54:43AM +0200]:
> > I still find it hard to believe that *so* much code is required to
> > minify JS. The excuse that JS is "moving fast" is nonsense. The reality
> > would appear to be that nobody actually *cares* about the mess, they
> > just use it.
> 
> It's a feature. The JS community is quite proud to have so many packages
> for so little tiny tasks. Their packaging system enables to do this
> "easily".

Sounds much like the canonical description of Unix, only throwing
aside tens of years of engineering best practices.

> > Why isn't there a KISS tool to do this? Is it all just special
> > snowflake optimisations for what has to be / should be a simple process
> > of removing whitespace and collapsing the formatting?
> 
> uglifyjs is a KISS tool to minify. Unfortunately, many projects do not
> require only minification. They require transpiling (convert from ES6 to
> ES5 or from CoffeeScript/Typescript/... to vanilla JS) and dependency
> handling (through loaders). And this is becoming more and more common
> because people want to use ES6 or some more modern JS.

...If so, they should be properly labeled and treated as something
different. "Transpiling" effectively means "compiling", and we know
what requirements we have with code in order to accept it compiled: We
need to have the sources as well. Nobody will argue that we don't have
to ship sources for binaries on ARM platforms because ARM has enough
registers so that compiled objects are as good as source.

And, of course, having a tool behave as a compiler when it does not
really understand the mess it is creating... Well, leads to gaping
holes such as what Yan describes here:

https://zyan.scripts.mit.edu/blog/backdooring-js/

A beautiful way of showing how minification hurts.

Re: system upgrade by systemd

[Gunnar Wolf]

Raphael Hertzog dijo [Wed, Aug 26, 2015 at 02:41:59PM +0200]:
> > Please tell me which package is the one misbehaving and I gladly report it.
> > But so far I have yet to figure that our.
> 
> Are you sure that you did not shutdown your computer from GNOME and did
> not pay attention to the new checkbox allowing it to install upgrades
> during shutdown/boot?
> 
> I have seen it once already and I have always unchecked it.

Ough.

I thought that checkbox was part of the Windows 7 shutdown logic, not
of GNOME :-/