Re: Too many Recommends (in particular on mail-transport-agent)

[Ghislain Vaillant]

On Tue, 2017-06-06 at 00:14 -0400, Afif Elghraoui wrote:
> I see now that python-networkx has some integration with those
> visualization libraries [1], which is not what I expected to be the
> case, though the page also says:
> 
> ~~~
> NetworkX provides basic functionality for visualizing graphs, but its
> main goal is to enable graph analysis rather than perform graph
> visualization. In the future, graph visualization functionality may be
> removed from NetworkX or only available as an add-on package.
> ~~~
> 
> so I guess until that integration is removed, it makes sense to keep it
> as Recommends. My main problem remains, however, and it is that networkx
> brings in a graphics stack when you try to install pbhoney on a headless
> machine, like cluster compute nodes.

Given this is a Python package, we should not even have to argue about
package relationships. Setuptools metadata provides install_requires
and extras_require, the former mapping to Depends, the latter to
Suggests. Period.

Your typical Python project README would instruct users to install the
Python package via `pip install`. If one runs `pip install networkx`,
the graphics dependencies do not get pulled. That alone is enough to
justify that these dependencies should not go to Recommends.

FYI, I have a similar problem with sympy (#861741), which pulls an
insane amount of packages via chained Recommends.

Ghis

Re: Too many Recommends (in particular on mail-transport-agent)

[Jonas Smedegaard]

Quoting Ghislain Vaillant (2017-06-06 10:13:55)
> On Tue, 2017-06-06 at 00:14 -0400, Afif Elghraoui wrote:
>> I see now that python-networkx has some integration with those 
>> visualization libraries [1], which is not what I expected to be the 
>> case, though the page also says:
>>
>> ~~~
>> NetworkX provides basic functionality for visualizing graphs, but its 
>> main goal is to enable graph analysis rather than perform graph 
>> visualization. In the future, graph visualization functionality may 
>> be removed from NetworkX or only available as an add-on package.
>> ~~~
>>
>> so I guess until that integration is removed, it makes sense to keep 
>> it as Recommends. My main problem remains, however, and it is that 
>> networkx brings in a graphics stack when you try to install pbhoney 
>> on a headless machine, like cluster compute nodes.
>
> Given this is a Python package, we should not even have to argue about 
> package relationships. Setuptools metadata provides install_requires 
> and extras_require, the former mapping to Depends, the latter to 
> Suggests. Period.
>
> Your typical Python project README would instruct users to install the 
> Python package via `pip install`. If one runs `pip install networkx`, 
> the graphics dependencies do not get pulled. That alone is enough to 
> justify that these dependencies should not go to Recommends.
>
> FYI, I have a similar problem with sympy (#861741), which pulls an 
> insane amount of packages via chained Recommends.

We should certainly continue to align package relations with Debian 
Policy - and therefore by extension continue to argue about that as 
necessary to evolve Debian Policy:

Upstream (or other) package relation hints can be a valuable _aid_ in 
resolving Debian package relations, but only that: An aid!

Debian packaging follows Debian Policy - other hints do not.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: /root directory

[Steve McIntyre]

jvieir...@sapo.pt wrote:
>
>In the Debian tutorials, somewhere in the Debian file system[1] page  
>it states: “When you refer to root directory it means you talk about  
>the root of the file system: ‘/’. This is different from the home  
>directory for the root user: ‘/root’.”
>
>The use of the same term with different meanings (“root”, in the case)  
>in general makes things getting confused for those non familiar with  
>the matter.
>
>Would it be feasible to change the name of the /root directory to sort  
>out the confusion? It could be renamed as /adm, for instance.

Feel free to do that on your systems - just change the location of the
home directory for root in /etc/passwd. The default on GNU/Linux
systems has been /root for many years, and I don't see it
changing. This is already different from some older Unix tradition -
some systems simply used / for the root user home directory too, but
thankfully that died a long time ago.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
  Armed with "Valor": "Centurion" represents quality of Discipline,
  Honor, Integrity and Loyalty. Now you don't have to be a Caesar to
  concord the digital world while feeling safe and proud.

Switch default installation image link?

[Steve McIntyre]

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

Hey,

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.

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

Thoughts?

[ Yes, I know that #819664 should fix this but I've not finished
  working there yet, and at this point it's not going to be ready and
  translated in 10 days... ]

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"I used to be the first kid on the block wanting a cranial implant,
 now I want to be the first with a cranial firewall. " -- Charlie Stross

Re: Switch default installation image link?

[Paul Wise]

On Tue, Jun 6, 2017 at 8:01 PM, Steve McIntyre wrote:

> For a number of years, we've been linking to the amd64/i386 netinst
> installer image from the front page.

Seems reasonable, perhaps with a small link for other options.

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

I think that improvement has been mostly specific to Europe and maybe
also parts of Asia & North America. Most of Australia is going to be
stuck on ADSL for a long time to come and remembering back to Sicelo's
DebConf16 talk, Africa might too.

https://debconf16.debconf.org/talks/121/
https://en.wikipedia.org/wiki/List_of_countries_by_Internet_connection_speeds

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Switch default installation image link?

[Colin Tuckley]

On 06/06/17 13:01, Steve McIntyre wrote:

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

Seems sensible.

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

I'd be inclined to say no to that. There are places (even in the UK)
where network access is still quite slow. People with fast networks can
use the netinst image and let *that* take advantage of the speed, and,
also, the netinst image fits on small, cheaper, media.

Colin

-- 
Colin Tuckley| +44(0)1223 830814 |  PGP/GnuPG Key Id
Debian Developer | +44(0)7799 143369 | 0xFA0C410738C9D903

Time was invented by an Irish guy named O'Clock.

Re: Switch default installation image link?

[Nikolaus Rath]

On Jun 06 2017, Steve McIntyre  wrote:
> I'm *also* tempted to switch from the netinst to the first DVD image
> instead - network connections have improved a lot.

Why is that relevant? Is installing+downloading the DVD image faster
than downloading netint + installing from network?

Personally, I would only ever download a DVD image if I was on a *slow*
connection and knew that I had to install to multiple machines.


Best,
-Nikolaus

-- 
GPG Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«

Re: Switch default installation image link?

[Holger Levsen]

On Tue, Jun 06, 2017 at 09:38:29AM -0400, Nikolaus Rath wrote:
> Personally, I would only ever download a DVD image if I was on a *slow*
> connection and knew that I had to install to multiple machines.
 
still then, I would rather use netinst plus a proxy…


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Mon, Jun 05, 2017 at 05:39:41PM -0700, Russ Allbery wrote:
> Maybe someone has a list of things they view as Recommends inflation that
> have (a) been reported as bugs to the appropriate package maintainers, and
> (b) have been rejected by those package maintainers?  Those are the
> controversial ones that we'd need to talk about.

Here's something even better: an automated way to list bad Recommends that
personally affect you -- ones that made you take steps to ignore them when
installing a package you actually use:

.--==[ list-unsatisfied-recommends ]
#!/usr/bin/python
import apt
c = apt.Cache()
for pkg in c:
if pkg.installed is not None:
for rd in pkg.candidate.get_dependencies("Recommends"):
if not rd.installed_target_versions:
print pkg, rd
`

Forgot whom to credit for this tool; alas, it's written in a language that
itself is bloat[1].

More seriously, though, let's go through the list of 94 unsatisfied ones on
my desktop; the list below is transposed to collate recommendees.


Categories:
OK: "Recommends:" looks warranted
DEBATABLE: duh.
BLOAT: potentially useful but I wouldn't make it a Recommends
BAD: downgrade please
TRANSITIVELY BAD: useful for a direct user but not when pulled via a
dependency -or- causes this lower in the chain



alpine-doc: alpine
* OK: this one looks reasonable

at: devscripts
* BAD: only use: pts-{,un}subscribe.  Why would I ever be interested in a
  package for only a limited time?  The listed use case is bad: NMUs are
  done on unmaintained packages, thus they won't magically fix themselves in
  30 days.

bash-completion: bash dput-ng licensecheck
* DEBATABLE: I like the Tab key to do something reasonable,
  "bash-completion" means you never know what you'll get.

: libreoffice-base
* BLOAT: they're no longer owned by Sun, what's the reason to keep Java
  scripting?

dnsmasq-base: lxc
* BAD: how often are you on a network without a DNS server?

fonts-cantarell: fontforge-common
* BAD: FontForge works perfectly without it

fonts-noto-cjk: fonts-noto
* BLOAT: unlike greek/runes/etc, you can't learn Chinese hieroglyphs on a
  whim, thus it's useless for most users.  You may want a _single_ CJK font
  so you can tell whether a text is in C, J or K but that's it.

freedoom | game-data-packager: prboom-plus
* DEBATABLE: freedoom is too ugly to live, shareware Doom has assets missing
  for running pretty much anything Doom-related (and AFAIK its license
  forbids add-ons).  On the other hand, this is an excuse for Doom engines
  in main.

freepats: libwildmidi-config timidity
* BAD: freepats is too ugly to live: abysmal quality, lacks instruments for
  pretty much any .mid file in the wild.  We do have a bunch of good
  alternatives.  timgm6mb-soundfont for one is 5.6 times smaller yet is
  complete.

geoclue-2.0: redshift
* TRANSITIVELY BAD: insane dependency chains, otherwise would be useful for
  a mobile device (this desktop is not one)

gfortran-mingw-w64: gcc-mingw-w64
* BAD: seriously, Fortran?

ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm
* BAD: why would editing images care about a grossly obsolete _document_
  format?

gimp-gmic: gimp-plugin-registry
* BLOAT: an obscure plugin, looks useful for only for a small minority of
  users; -plugin-registry is not pulled by default though so it's debatable

gnat-mingw-w64: gcc-mingw-w64
* BAD: see Fortran.

gnupg-l10n: gnupg
* DEBATABLE: I don't think anyone tech skilled enough to use GPG would have
  problems with English, but localization is important.  On the other hand,
  this is 4.5MB in the default install.

gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
* BAD: see ghostscript

gvfs: atril easytag thunar
* BAD: gvfs is a major annoyance and a security hole

libaacs0: libbluray1
* BLOAT: useful only if you rip optical media

libatm1 >= 2.4.1-17~: iproute2
* BLOAT: I'm rather certain my desktop machine has no direct ATM link --
  unfit for the default install

libclass-xsaccessor-perl: libmoo-perl
* BLOAT: wut?

libgit-wrapper-perl: devscripts
* : I've never used git-deborig, is it actually useful?  Tiny package,
  though.

libgnomeui-0: xscreensaver
* BAD: Gnome users won't run xscreensaver

libgpm2: libncurses5:i386
* OK: or rather, not doable with current tools: we do want mouse support
  in curses programs (libgpm2 handles X terminals too, right?) but in this
  case it's a multiarch copy of an otherwise important package

libgpod-common: libgpod4
* BLOAT: nope, I don't use iJunk

libgtk2-perl: tablet-encode
* out of archive

libhtml-format-perl: libhtml-tree-perl libwww-perl
* : wut?

libhttp-daemon-perl: libwww-perl
* TRANSITIVELY BAD: dependency comes from a client package; if I want to run
  a http server I know where to find it

libimage-magick-perl: inkscape
* : wut?

liblist-compare-perl: devscripts
* : again, git-deborig

libmail-sendmail-perl: po-debconf
* BAD: why would po stuff want to send mail?

libpackage-stash-xs-perl: lib

Bug#864294: ITP: pycryptodome -- cryptographic library for Python

[Christopher Hoskin]

Package: wnpp
Severity: wishlist
Owner: Christopher Hoskin 

* Package name: pycryptodome
  Version : 3.4.6
  Upstream Author : Legrandin 
* URL : http://www.pycryptodome.org/
* License : BSD-2-Clause / Unlicense
  Programming Lang: Python / C
  Description : cryptographic library for Python

PyCryptodome is a self-contained Python package of low-level
cryptographic primitives.

PyCryptodome is a fork of PyCrypto. It brings several enhancements
with respect to the last official version of PyCrypto (2.6.1),
for instance:

* Authenticated encryption modes (GCM, CCM, EAX, SIV, OCB)
* Accelerated AES on Intel platforms via AES-NI
* First class support for PyPy
* Elliptic curves cryptography (NIST P-256 curve only)
* Better and more compact API (`nonce` and `iv` attributes for ciphers,
  automatic generation of random nonces and IVs, simplified CTR cipher mode,
  and more)
* SHA-3 (including SHAKE XOFs) and BLAKE2 hash algorithms
* Salsa20 and ChaCha20 stream ciphers
* scrypt and HKDF
* Deterministic (EC)DSA
* Password-protected PKCS#8 key containers
* Shamir's Secret Sharing scheme
* Random numbers get sourced directly from the OS (and not from a CSPRNG in 
userspace)
* Simplified install process, including better support for Windows
* Cleaner RSA and DSA key generation (largely based on FIPS 186-4)
* Major clean ups and simplification of the code base

PyCryptodome is not a wrapper to a separate C library like *OpenSSL*.
To the largest possible extent, algorithms are implemented in pure Python.
Only the pieces that are extremely critical to performance (e.g. block ciphers)
are implemented as C extensions.

I plan to maintain this package within the DPMT. I do not require a sponsor.

Christopher Hoskin

Re: Switch default installation image link?

[Adam Borowski]

On Tue, Jun 06, 2017 at 01:01:29PM +0100, Steve McIntyre wrote:
> 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.

Please do!  At this time, i386 is a trap for newbies who don't know better.
No proper crossgrade tools exist yet, but a good first step is to stop
digging that hole.

No one installs i386 new -- machines that are non-amd64-capable are:
* mainstream machines from 2004 and earlier
* a brief wave of mobile devices, now thankfully gone
* deeply embedded, usually incapable of running d-i

If you're installing on one of them, you're reinstalling a buggered up
system thus know what you're doing.  It's no different from installing on
alpha, mips or powerpc.  Thus, secondary architectures should be kept out
of the view of newbies (with a convenient link for the rest).

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

I'd vote no -- netinst + packages you need is smaller than an entire DVD.
Those who want to install multiple machines from an image tend to know what
to do -- and even them will typically still download the installer more
times during tests than they have machines to install.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Re: Too many Recommends (in particular on mail-transport-agent)

[Jonas Smedegaard]

Quoting Adam Borowski (2017-06-06 15:55:48)
> More seriously, though, let's go through the list of 94 unsatisfied 
> ones on my desktop; the list below is transposed to collate 
> recommendees.
> 
> 
> Categories:
> OK: "Recommends:" looks warranted
> DEBATABLE: duh.
> BLOAT: potentially useful but I wouldn't make it a Recommends
> BAD: downgrade please
> TRANSITIVELY BAD: useful for a direct user but not when pulled via a
> dependency -or- causes this lower in the chain
> 
> 
> 
> bash-completion: bash dput-ng licensecheck
> * DEBATABLE: I like the Tab key to do something reasonable,
>   "bash-completion" means you never know what you'll get.

I don't understand what is debatable here.  Please consider filing a 
bugreport against licensecheck to start that debate (if not here).


> fonts-noto-cjk: fonts-noto
> * BLOAT: unlike greek/runes/etc, you can't learn Chinese hieroglyphs on a
>   whim, thus it's useless for most users.  You may want a _single_ CJK font
>   so you can tell whether a text is in C, J or K but that's it.

The very purpose of Noto fonts is large coverage (no "tofu" chars), and 
the very purpose of "fonts-noto" package specifically is described as 
"Use this package if you want all Noto fonts".  If you disagree with 
that, then avoid fonts-noto altogether, don't try redefine its prupose.


> ghostscript: gimp imagemagick-6.q16 libmagickcore-6.q16-3 netpbm
> * BAD: why would editing images care about a grossly obsolete _document_
>   format?

Because some (most except you, I guess!) don't consider PDF "obsolete".


> gnupg-l10n: gnupg
> * DEBATABLE: I don't think anyone tech skilled enough to use GPG would have
>   problems with English, but localization is important.  On the other hand,
>   this is 4.5MB in the default install.

We should not actively make GnuPG _harder_ for newcomers to use.


> libclass-xsaccessor-perl: libmoo-perl
> * BLOAT: wut?

This and other lib*-xs-perl recommendations are faster implementations 
that you commonly want: An example (exotic!) need for avoiding those is 
when bootstrapping a new architecture.



 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Bug#864300: ITP: fcitx-autoeng-ng -- Fcitx autoeng module for Sogou pinyin

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: fcitx-autoeng-ng
  Version : 0.1.1~git20150311
  Upstream Author : Gao Qunkai 
* URL : https://github.com/sogoupinyin/fcitx-punc-ng/
* License : GPL-2
  Programming Lang: C
  Description : Fcitx autoeng module for Sogou pinyin

fcitx-module-autoeng-ng is a module for Sogou pinyin

This package will be inside pkg-ime team, and Aron Xu agreed to
sponsor.


signature.asc
Description: PGP signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Russ Allbery]

Adam Borowski  writes:

> More seriously, though, let's go through the list of 94 unsatisfied ones
> on my desktop; the list below is transposed to collate recommendees.

And what happens here is, I think, typical: any one person often thinks
choices of recommends make no sense, but a broader perspective provides
quite a bit of justification.  A good example:

> dnsmasq-base: lxc
> * BAD: how often are you on a network without a DNS server?

Your question here indicates to me that you've missed the point of this
dependency entirely.  lxc uses the dnsmasq program (not service, hence
-base) for *DHCP* for containers on the container network.  If you do a
search for lxc dnsmasq, you'll see tons of justification for this
Recommends.  lxc is already pulling in tons of stuff; it would be dumb to
make it harder to use by omitting this small recommends of a few binaries.

> gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
> * BAD: see ghostscript

Your concept of what file formats are obsolete is not even remotely
similar to mine.

> libgnomeui-0: xscreensaver
> * BAD: Gnome users won't run xscreensaver

What?  The hell they won't.

> libmail-sendmail-perl: po-debconf
> * BAD: why would po stuff want to send mail?

This is for podebconf-report-po.  I assume you've not packaged something
with translations?

> libpam-systemd: xfce4-power-manager xfce4-session
> * BAD: Depends:systemd, utterly pointless without it.

This is a whole other discussion, but we had *endless* discussions of
this, and there are very sound technical reasons for structuring the
dependency chain this way.

> libpurple-bin: libpurple0
> * BAD: a library has no reason to install programs

This, like all other lib*-bin packages in Debian, are external helper
utilities *run by the library* under specific situations, which are split
into a separate package to avoid SONAME issues.  This is an entirely
correct packaging strategy for optional library APIs (in this case, things
like opening remote URLs).

I'm going to stop here, since at this point I think this is just going to
turn into a thread educating you about Debian packaging conventions you've
apparently not encountered before, which is really not a good use of
everyone's time.

I am completely unconvinced that there is any real problem here.  There
are doubtless some bugs, most of them minor, in our separation between
Recommends and Suggests, and there's probably some opportunity to craft
better language to guide packagers to do the right thing, but mostly
there's an opportunity for people to file a few bugs after a *thoughtful*
analysis of package Recommends and why they might be there.  There
certainly doesn't seem to be a problem large enough to warrant TC
involvement.

-- 
Russ Allbery (r...@debian.org)   

Re: Switch default installation image link?

[Marco d'Itri]

On Jun 06, Steve McIntyre  wrote:

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

> I'm *also* tempted to switch from the netinst to the first DVD image
> instead - network connections have improved a lot.
Bad idea: non-netinst images should be downloaded only by people who 
need to install offline systems.
Everybody else will use less bandwidth AND will install Debian in 
a shorter time (because if the network is fast then the limiting factor 
will be the disk).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Bug#864303: ITP: fcitx-fullwidthchar-enhance -- Fcitx fullwidthchar enhance module for Sogou pinyin

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: fcitx-fullwidthchar-enhance
  Version : 0.0~git20150311
  Upstream Author : Gao Qunkai 
* URL : https://github.com/sogoupinyin/fcitx-fullwidthchar-enhance
* License : GPL-2
  Programming Lang: C
  Description : Fcitx fullwidthchar enhance module for Sogou pinyin

fcitx-module-fullwidthchar is a module for Sogou pinyin

This package will be inside pkg-ime team, and Aron Xu agreed to
sponsor.


signature.asc
Description: PGP signature

Bug#864304: ITP: fcitx-punc-ng -- Fcitx punc module for Sogou pinyin

[Shengjing Zhu]

Package: wnpp
Severity: wishlist
Owner: Shengjing Zhu 

* Package name: fcitx-punc-ng
  Version : 0.1.1~git20161101
  Upstream Author : Gao Qunkai 
* URL : https://github.com/sogoupinyin/fcitx-punc-ng/
* License : GPL-2
  Programming Lang: C
  Description : Fcitx punc module for Sogou pinyin

fcitx-module-punc-ng is a module for Sogou pinyin

This package will be inside pkg-ime team, and Aron Xu agreed to
sponsor.


signature.asc
Description: PGP signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Simon McVittie]

On Tue, 06 Jun 2017 at 09:06:46 -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
> 
> And what happens here is, I think, typical: any one person often thinks
> choices of recommends make no sense, but a broader perspective provides
> quite a bit of justification.

Adam, if you want the size of a typical system to be reduced, I don't
think the approach you've taken here is going to be the most effective.
Making maintainers angry by dismissing software as obsolete, pointless or
similar - even if it is true! - is not usually going to make them more
likely to do what you say.

I can see that you value minimal systems. That's fine, but bear in mind
that you are experienced enough to make those systems work, and
hopefully also experienced enough to avoid making them insecure while
making them work; and relately, you are experienced enough to use a
package manager to get the system the way you want it. Not everyone is.

If there is a best set of Recommends for inexperienced users, and a
best set of Recommends for experienced users who value minimality, then
we should err in the direction of supporting the inexperienced users,
precisely because those are the people least likely to be able to use
package managers to get a particular feature that they want. If some
"wasted" disk space on typical systems is the price we pay for a feature
working on the first attempt, rather than an inexperienced user giving
up before they can get that feature to work, or simply not knowing that
the feature is even possible, then that seems a worthwhile price to pay.

You are already making a cost/benefit trade-off by using Debian, a
relatively complete binary distribution. You could get a more minimal
system by disabling more things at compile time with something like
Gentoo's USE flags, but presumably you've considered that and decided
that the benefits of using a binary distribution outweigh the costs.

(Insert the usual observation here about how a typical Debian system
has both libapparmor and libselinux, despite it being literally
impossible for both to be useful at the same time...)

> > libgnomeui-0: xscreensaver
> > * BAD: Gnome users won't run xscreensaver
> 
> What?  The hell they won't.

This one *is* obsolete though - not xscreensaver, but libgnomeui-0.
libgnome and libgnomeui were deprecated sometime during the GNOME 2
era, and for stretch the GNOME team has finally managed to exclude them
from a default desktop installation (task-gnome-desktop), but
unfortunately there are still more than 50 packages using them.
The GNOME team would be delighted to see that number go down.
The libgnome* libraries help you to integrate with a desktop from around
10 years ago that we no longer ship, and are not part of modern GNOME;
their high-level functionality has mostly been superseded by code in
GLib and GTK+.

During the time that libgnome was a recommended thing to use,
I think xscreensaver was used by default in a complete GNOME
installation. It was subsequently replaced by gnome-screensaver,
which was in turn replaced by the screen lock included in GNOME Shell
during the transition to GNOME 3. It is certainly possible to construct
your own GNOME-based desktop environment that includes xscreensaver by
fitting together the pieces yourself (similar to how the openbox-*-session
packages provide openbox-based variants of several desktop environments),
but that isn't the complete GNOME environment any more than
openbox-gnome-session is.

S

Re: Too many Recommends (in particular on mail-transport-agent)

[Tom H]

On Tue, Jun 6, 2017 at 9:55 AM, Adam Borowski  wrote:
>
> dnsmasq-base: lxc
> * BAD: how often are you on a network without a DNS server?

The dnsmasq-base "recommends" is about providing a dhcp server for
containers not a dns server.

libvirt-daemon-system has the same "recommends" for its VMs.

Re: Too many Recommends (in particular on mail-transport-agent)

[Russ Allbery]

Simon McVittie  writes:

> If there is a best set of Recommends for inexperienced users, and a
> best set of Recommends for experienced users who value minimality, then
> we should err in the direction of supporting the inexperienced users,
> precisely because those are the people least likely to be able to use
> package managers to get a particular feature that they want.

Yes, this.  Experienced users can also turn off installation of
Recommends, so I think the focus should be on making things work "as
expected" for people who don't want to understand the details.

There's also a huge difference, given this criteria, betweeen wasted disk
space and running daemons.  I think the latter is worth trying to track
down; the former seems largely futile to me.  All of the disk space gains
you might conceivably get from, say, removing the recommeds on
libmail-sendmail-perl from po-debconf will be dwarfed by minor changes to
the documentation of some other package on your system, or some new
feature in some standard library.

> If some "wasted" disk space on typical systems is the price we pay for a
> feature working on the first attempt, rather than an inexperienced user
> giving up before they can get that feature to work, or simply not
> knowing that the feature is even possible, then that seems a worthwhile
> price to pay.

Amen.

>>> libgnomeui-0: xscreensaver
>>> * BAD: Gnome users won't run xscreensaver

>> What?  The hell they won't.

> This one *is* obsolete though - not xscreensaver, but libgnomeui-0.
> libgnome and libgnomeui were deprecated sometime during the GNOME 2 era,
> and for stretch the GNOME team has finally managed to exclude them from
> a default desktop installation (task-gnome-desktop), but unfortunately
> there are still more than 50 packages using them.  The GNOME team would
> be delighted to see that number go down.  The libgnome* libraries help
> you to integrate with a desktop from around 10 years ago that we no
> longer ship, and are not part of modern GNOME; their high-level
> functionality has mostly been superseded by code in GLib and GTK+.

Ah, good call.  So this one really should be a bug report.

https://bugs.debian.org/864310 -- please feel free to weigh in and correct
me if I got any of the details wrong.

-- 
Russ Allbery (r...@debian.org)   

Bug#864313: ITP: ipcalcng -- Tool to assist in network address calculations for IPv4 and IPv6

[Muri Nicanor]

Package: wnpp
Severity: wishlist
Owner: Muri Nicanor 

* Package name : ipcalcng
  Version  : 0.2.0-1
  Upstream Author  : Nikos Mavrogiannopoulos
* Url  : https://github.com/nmav/ipcalc
* Licenses : BSD-3-Clause,GPL-2
  Programming Lang : C
  Section  : net

 This is a modern tool to assist in network address calculations for
 IPv4 and IPv6. It acts both as a tool to output human readable
 information about a network or address, as well as a tool suitable to
 be used by scripts or other programs.
 .
 It supports printing a summary about the provided network address,
 multiple command line options per information to be printed,
 transparent IPv6 support, and in addition it will use libGeoIP if
 available to provide geographic information.

I'm an intense user of ipcalc, which is a really useful tool, but ipcalc
does not do IPv6 addresses. I've stumbled over the ipcalc by Nikos
Mavrogiannopoulos when looking for a version that is IPv6 capable. I'm
aware of the naming collision, thats why i propose to call the package
(and the binary) ipcalng. I'm not sure yet if that name is the right
solution, in particular because in fedora the perl ipcalc version was
renamed to ipcalculator and this one is now called ipcalc [0]. This
could lead to a lot of confusion and i would have to maintain that
change forever. If there are better solutions please let me know.

cheers,
muri

[0] https://fedoraproject.org/wiki/Changes/ipcalculator



signature.asc
Description: OpenPGP digital signature

Bug#864314: ITP: libsml -- C Library for the Smart Messaging Language (SML)

[Andreas Moog]

Package: wnpp
Severity: wishlist
Owner: Andreas Moog 

* Package name: libsml
  Version : 0.1.1
  Upstream Author : Juri Glass,
Mathias Runge,
Nadim El Sayed,
Steffen Vogel
* URL : https://github.com/volkszaehler/libsml
* License : GPL3
  Programming Lang: C
  Description : C Library for the Smart Messaging Language (SML)

 libSML is a library which implements the Smart Messaging Language (SML)
 protocol specified by VDE's Forum Netztechnik/Netzbetrieb (FNN).
 It can be utilized to communicate to FNN specified Smart Meters
 or Smart Meter components (EDL/MUC).

This library is needed for vzlogger, ITP bug #864255.

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> 
> > More seriously, though, let's go through the list of 94 unsatisfied ones
> > on my desktop; the list below is transposed to collate recommendees.
> 
> And what happens here is, I think, typical: any one person often thinks
> choices of recommends make no sense, but a broader perspective provides
> quite a bit of justification.

It is remarkable that out of 94 unsatisfied recommends on my system you
disagreed with just 6, despite them going contrary to the maintainer's
wishes thus being certain to be controversial.

Also, it's quite obvious this list was very hastily done, with often just a
few seconds per entry.  Thus, I admit the list does contain inaccuracies
that fail when confronted with a bit more research.  The intent is just to
have a sample -- not to file actual bugs yet.

> A good example:
> 
> > dnsmasq-base: lxc
> > * BAD: how often are you on a network without a DNS server?
> 
> Your question here indicates to me that you've missed the point of this
> dependency entirely.  lxc uses the dnsmasq program (not service, hence
> -base) for *DHCP* for containers on the container network.

I do use lxc quite heavily, usually choosing IP addresses within config
files but sometimes using DHCP.  And it seems to work just fine without
dnsmasq -- thus, unless I'm missing something, it's not something that
"would be found together [...] in all but unusual installations".

> If you do a search for lxc dnsmasq, you'll see tons of justification for
> this Recommends.  lxc is already pulling in tons of stuff; it would be
> dumb to make it harder to use by omitting this small recommends of a few
> binaries.

906kB is bigger than most of Recommends on this list, but as not a part of
the default install you do have a point that it may make it easier to have
pre-installed: while it's a common setup to store a lxc host on a separate
small filesystem, typical lxc boxes aren't on the small side overall.
I'm not persuaded about the importance of this add-on, but that's exactly
why we're having this debate.

The point of a debate is not to "win" but to find the best solution...

> > gsfonts: libmagickcore-6.q16-3 libwmf0.2-7
> > * BAD: see ghostscript
> 
> Your concept of what file formats are obsolete is not even remotely
> similar to mine.

I did not happen to know ghostscript can also be used not for .ps but also
for some .pdf workflows (I prefer to not use blatantly fake-free software)
but my main point stands: an _image_ manipulation program cannot be said to
import _documents_ in "all but unusual installations".

And "gsfonts" is not even ghostscript itself but merely an add-on for it.

> > libgnomeui-0: xscreensaver
> > * BAD: Gnome users won't run xscreensaver
> 
> What?  The hell they won't.

There's gnome-screensaver, which has better integration with Gnome at the
cost of using a ton of gnome-related bloat (which doesn't hurt a Gnome user
in any way -- they already have that installed).  Thus, a _typical_ Gnome
user won't install xscreensaver, and a typical xscreensaver user won't
install Gnome.  And "Recommends:" is all about typical use.

Plus, as Simon McVittie mentioned, libgnomeui-0 is strongly deprecated even
within Gnome itself.

> > libmail-sendmail-perl: po-debconf
> > * BAD: why would po stuff want to send mail?
> 
> This is for podebconf-report-po.  I assume you've not packaged something
> with translations?

I'm not dealing with any po-heavy packages at the moment, yeah.  It might
indeed be useful for some deep po stuff, but the package I want is
"debhelper".  Technically, I do know how to package without debhelper (see
"goodbye") but I still would prefer to use it.  And as someone involved in
both QA and sponsoring -- thus dealing with hundreds of packages -- I have
yet to use podebconf-report-po once.  Thus, it's quite hard to say that
debhelper and libmail-sendmail-perl "would be found together in all but
unusual installations".

> > libpam-systemd: xfce4-power-manager xfce4-session
> > * BAD: Depends:systemd, utterly pointless without it.
> 
> This is a whole other discussion, but we had *endless* discussions of
> this, and there are very sound technical reasons for structuring the
> dependency chain this way.

Let's not waste too much time right now, but if I recall that discussion
correctly, the sane way would be to have a non-systemd alternative _first_:
on a systemd install, the second alternative would be already present and
thus satisfy the dependency, while the first one would avoid imposing
systemd when not wanted.

> > libpurple-bin: libpurple0
> > * BAD: a library has no reason to install programs
> 
> This, like all other lib*-bin packages in Debian, are external helper
> utilities *run by the library* under specific situations, which are split
> into a separate package to avoid SONAME issues.

Nope, its contents are four misc "extra utilities" that are mean to run _by
the user_ or at most by

Re: Too many Recommends (in particular on mail-transport-agent)

[Russ Allbery]

Adam Borowski  writes:
> On Tue, Jun 06, 2017 at 09:06:46AM -0700, Russ Allbery wrote:

>> And what happens here is, I think, typical: any one person often thinks
>> choices of recommends make no sense, but a broader perspective provides
>> quite a bit of justification.

> It is remarkable that out of 94 unsatisfied recommends on my system you
> disagreed with just 6, despite them going contrary to the maintainer's
> wishes thus being certain to be controversial.

I skipped all of the ones that you didn't mark as BAD, since the other
classifications were beside the point, and commented only on the ones
where your classification leaped out at me as incorrect.  I'm pretty
dubious about the whole list, but as I said at the start of my message, I
was giving some specific examples where I had the information readily to
hand (or thought I did; I was wrong on libpurple).

> Also, it's quite obvious this list was very hastily done, with often
> just a few seconds per entry.

And you did this in response to a message of mine that was asking for
something more thoughtful, which is part of why I reacted the way that I
did.

> I did not happen to know ghostscript can also be used not for .ps but
> also for some .pdf workflows (I prefer to not use blatantly fake-free
> software) but my main point stands: an _image_ manipulation program
> cannot be said to import _documents_ in "all but unusual installations".

> And "gsfonts" is not even ghostscript itself but merely an add-on for it.

PostScript is one of the common image types (in the form of EPS) that
ImageMagick manipulates.  Use of ImageMagick to handle those files is not
as common as JPEG or PNG, but certainly not unusual, particularly if you
have tool chains that like to generate EPS; I used to run into it a lot
when processing TeX documents, for instance.  gsfonts may be a requirement
for correctly converting some of those files to other formats because it
provides the fonts that are "built in to any PostScript printer" and
therefore do not have to be embedded in files (by specification).

This is pretty classic Recommends stuff, just in a field that you're not
personally using ImageMagick for.  One can argue about the merits of
having a Swiss Army knife tool like ImageMagick that is pretty much
guaranteed to only be used for 10% of what it can do by any given user of
it, but in that context, support for PostScript images is well within its
scope and less obscure than many other formats it handles.

>>> libmail-sendmail-perl: po-debconf
>>> * BAD: why would po stuff want to send mail?

>> This is for podebconf-report-po.  I assume you've not packaged something
>> with translations?

> I'm not dealing with any po-heavy packages at the moment, yeah.  It
> might indeed be useful for some deep po stuff, but the package I want is
> "debhelper".

podebconf-report-po is not "deep po stuff."  It should be used by
literally every maintainer who packages something with debconf
translations, whenever the debconf templates are changed.

> Technically, I do know how to package without debhelper (see "goodbye")
> but I still would prefer to use it.

po-debconf includes the tools the package maintainer should be using to
manage debconf translations.  You could conceivably separate the ones
needed during a build from the maintainer tools, but I'm not sure it's
really worth the effort for the tiny amount of disk space this would save.

>> This, like all other lib*-bin packages in Debian, are external helper
>> utilities *run by the library* under specific situations, which are split
>> into a separate package to avoid SONAME issues.

> Nope, its contents are four misc "extra utilities" that are mean to run
> _by the user_ or at most by some scripts.  They look somewhat useful
> (purple-remote allows controlling pidgin from cmdline, etc) but are
> seriously hampered by a lack of documentation.  On the other hand, not a
> single one is ever called by the library:

> strings `dpkg -L libpurple0`|grep purple-remote
> strings `dpkg -L libpurple0`|grep purple-send
> strings `dpkg -L libpurple0`|grep purple-send-async
> strings `dpkg -L libpurple0`|grep purple-url-handler

Ah, indeed, I apologize; you're entirely correct.  I made a bad assumption
about how the URL handling in libpurple worked and should have done a
little bit of research first.

I think (barring other information I'm not aware of) I agree with you
here, and also think that the name of this package is probably wrong and
should be something more like purple-tools or the like.

>> I'm going to stop here, since at this point I think this is just going
>> to turn into a thread educating you about Debian packaging conventions
>> you've apparently not encountered before, which is really not a good
>> use of everyone's time.

> Uhm... could you be please be a bit more civil?

I apologize; you're right.  I should have been more civil.

I do have to also add that I found your message considerably less civil
than how I think you

Re: Too many Recommends (in particular on mail-transport-agent)

[Philip Hands]

Adam Borowski  writes:

>> > dnsmasq-base: lxc
>> > * BAD: how often are you on a network without a DNS server?
>> 
>> Your question here indicates to me that you've missed the point of this
>> dependency entirely.  lxc uses the dnsmasq program (not service, hence
>> -base) for *DHCP* for containers on the container network.
>
> I do use lxc quite heavily, usually choosing IP addresses within config
> files but sometimes using DHCP.  And it seems to work just fine without
> dnsmasq -- thus, unless I'm missing something, it's not something that
> "would be found together [...] in all but unusual installations".

I suspect that you are bridging your containers straight onto a real
network, which is then providing the DHCP, whereas the default
arangement for naive users is to have a layer of NAT or some such (I'm
not 100% sure, because like you I never use that option either, but I'm
aware it exists).

I also suspect that if you have configured lxc as you have, dnsmasq sits
unused on the disk, which is not something to object to if it means that
people using the default setup get something that works -- which they
would not get if you had your way.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


signature.asc
Description: PGP signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Tue, Jun 06, 2017 at 01:06:03PM -0700, Russ Allbery wrote:
> Adam Borowski  writes:
> > Uhm... could you be please be a bit more civil?
> 
> I apologize; you're right.  I should have been more civil.
> 
> I do have to also add that I found your message considerably less civil
> than how I think you actually intended it.  I found your message rather
> condescending and dismissive of the analysis maintainers have put into
> their package metadata, and confrontational about your personal opinions
> about some widely used software, in a way that felt honestly like you were
> intentionally provoking people.

Indeed, I was once again wise-ass where I should be wise[1] -- at least some
of the remarks were condescending when read literally.  My bad.

> > The issue is systematic, and we have far more than "a few" cases.  The
> > very post you're responding to had 94 of them,
> 
> There were absolutely not 94 real problems on that list.  It was a largely
> unfiltered dump of Recommends of packages on your system.  I would be
> surprised if there were more than 10 real problems there, most of which
> are quite minor in terms of user impact and didn't seem to be to be worth
> the amount of energy that you're putting into this.

I do disagree here, but I'll better pause talking in this thread to let the
heat down.  And, bugs filed today would be forgotten -- while it takes
almost no effort to make a single-word change, once you context switch away
it becomes a part of the backlog and ignored.

> That said, I absolutely welcome bug reports against any of my packages for
> too-broad Recommends

I went through your packages (57 sources, 251 binaries), and found no
issues (I only skimmed through nvidia stuff, though).  So if I'm going to
bark at anyone, it's not at you. :)

> And if there's wording we can change on the Policy side to try to make it
> clearer when Recommends should be used and to head off some of these
> issues

Let's see what other folks have to say.



Meow!

[1]. Although pabs is taken.
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Re: Too many Recommends (in particular on mail-transport-agent)

[Michael Biebl]

Am 06.06.2017 um 18:06 schrieb Russ Allbery:
> Adam Borowski  writes:

>> libpam-systemd: xfce4-power-manager xfce4-session
>> * BAD: Depends:systemd, utterly pointless without it.
> 
> This is a whole other discussion, but we had *endless* discussions of
> this, and there are very sound technical reasons for structuring the
> dependency chain this way.

xfce4-power-manager, xfc4-session recommending libpam-systemd (or even
requiring libpam-systemd) seems correct, as those use systemd-logind.

The Recommends systemd-sysv | systemd-shim is superfluous and should be
dropped. It's an implementation detail whether systemd (PID 1) or
systemd-shim provides the functionality needed by
libpam-systemd/systemd-logind.


-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Michael Biebl]

Am 06.06.2017 um 15:55 schrieb Adam Borowski:
> gvfs: atril easytag thunar
> * BAD: gvfs is a major annoyance and a security hole

"Annoys Adam Borowski" is not a very convincing argument.
As for "security hole", I'm not sure what exactly you have in mind
there. I don't see any open CVEs or bugs tagged with security against gvfs.


Michael
-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Re: Switch default installation image link?

[Henrique de Moraes Holschuh]

On Tue, 06 Jun 2017, Adam Borowski wrote:
> No one installs i386 new -- machines that are non-amd64-capable are:
> * mainstream machines from 2004 and earlier

That date is incorrect.  I can't give you a precise date, but the
Thinkpad T43 with a 32-bit Centrino Pentium-M was **launched** in
April/2005.

And I am pretty sure there were several 32-bit only processors after the
Pentium-M, including several Atom-based systems that either didn't
support, or had 64-bit mode disabled in BIOS because it was just too
damn slow.

So, no earlier than 2008.

-- 
  Henrique Holschuh

Re: Too many Recommends (in particular on mail-transport-agent)

[Adam Borowski]

On Tue, Jun 06, 2017 at 11:29:20PM +0200, Michael Biebl wrote:
> Am 06.06.2017 um 15:55 schrieb Adam Borowski:
> > gvfs: atril easytag thunar
> > * BAD: gvfs is a major annoyance and a security hole
> 
> "Annoys Adam Borowski" is not a very convincing argument.

For the first part, it indeed varies by use case.  I don't recall ever using
an USB or SD attached storage for "data" in an Unix machine, yet I have two
SD readers, four cards and one USB stick on my desk right now despite having
cleaned the desk a few days ago.  It's just always a "disk" for some SoC
or bootable media (d-i, etc).

Some people may disagree.

> As for "security hole", I'm not sure what exactly you have in mind there. 
> I don't see any open CVEs or bugs tagged with security against gvfs.

I found a security hole in the vfat driver as an idiot kid ~20 years ago,
before I even started using Linux myself.  That particular filesystem is
simplicistic enough to _possibly_ be exploitable bug free by now, but as a
btrfs@vger regular, I hear about enough unintentional corruption caused
failures that I see no way the filesystem could be secured against a
malicious image without an extreme effort that would also destroy
performance.  And that's a maintained filesystem.  We do, in our default
kernel, ship drivers for so many obscure filesystems no one has used for
years that I'm 100% certain you can find an arbitrary code execution bug
triggerable by just mounting such an untrusted USB stick.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

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: Switch default installation image link?

[Adam Borowski]

On Tue, Jun 06, 2017 at 06:43:46PM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 06 Jun 2017, Adam Borowski wrote:
> > No one installs i386 new -- machines that are non-amd64-capable are:
> > * mainstream machines from 2004 and earlier
> 
> That date is incorrect.  I can't give you a precise date, but the
> Thinkpad T43 with a 32-bit Centrino Pentium-M was **launched** in
> April/2005.
> 
> And I am pretty sure there were several 32-bit only processors after the
> Pentium-M, including several Atom-based systems that either didn't
> support, or had 64-bit mode disabled in BIOS because it was just too
> damn slow.

Those were mobile CPUs, as in the second entry.

> So, no earlier than 2008.

Which is still 9 years ago.

The installed base of 32-bit-only x86 is probably still bigger than all
non-x86 non-ARM together, but I believe a new user trying to install Debian
on such a machine is unlikely enough to warrant hiding this option to help
those who would be better served by amd64.

There's hope that by Buster we'll put arm64 on the front page, but for now I
think Steve McIntyre's idea of making amd64 the only prominently visible
arch is the way to go.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Bug#864322: ITP: node-es6-promise-polyfill -- JavaScript Polyfill for ES6 Promise

[Daniel Ring]

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

* Package name: node-es6-promise-polyfill
  Version : 1.2.0
  Upstream Author : Roman Dvornov 
* URL : https://github.com/lahmatiy/es6-promise-polyfill
* License : Expat
  Programming Lang: JavaScript
  Description : JavaScript Polyfill for ES6 Promise

 Polyfill for the ECMAScript 6 Promise object. Promises allow for ordered
 execution of asynchronous callbacks.

 Node.js is an event-based server-side JavaScript engine.

 This library is a build dependency for webpack. Webpack takes code targeted at
 node.js and adapts it to run in the browser. Node.js comes with an API of
 its own that is not available in browsers. Webpack exposes this code to
 programs that are unaware they are running in a browser.

Re: Too many Recommends (in particular on mail-transport-agent)

[Vincent Bernat]

 ❦  6 juin 2017 15:55 +0200, Adam Borowski  :

> pulseaudio: xfce4-pulseaudio-plugin
> * BAD: I want working sound, duh.

From now on, you may be more likely to get sound with pulseaudio than
without due to upstreams dropping support for Alsa. See for example
Firefox. And the trend will continue since it's easier to write stuff
for PulseAudio than for Alsa. Maybe it would be better to solve the
problem you have with PulseAudio instead of just ranting (the only bug I
have found you reported against pulseaudio [0] was left unanswered on
your side despite very clear instructions on what to provide to help).

[0]: https://bugs.freedesktop.org/show_bug.cgi?id=84667
-- 
Avoid unnecessary branches.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

Re: Too many Recommends (in particular on mail-transport-agent)

[Afif Elghraoui]

على الإثنين  5 حزيران 2017 ‫09:52، كتب Scott Kitterman:
>> The answer to that is not clear from the maintainer's response; nor is
>> it clear from what the submitter has written whether they know the
>> answer.
> Why is that question relevant?  The policy definition of Recommends (versus 
> Suggests) has nothing to with if there will be a failure or not:
> 
>> The Recommends field should list packages that would be found together with
>> this one in all but unusual installations

That's not the complete definition of Recommends. The part you left out
states that there should be a strong, but not absolute dependency.
Presumably their being almost always found together on all but unusual
installations is a consequence of that.

> Personally, I think the maintainer articulated what he views as the usual 
> situation and declines to remove Recommends that are, in the maintainer's 
> view, appropriate.  His rationale makes complete sense to me.
>  I'm not saying 
> there aren't other, reasonable choices that could be made, but it make sense. 
>  
> I don't think this is the kind of thing the TC should even entertain 
> overruling a maintainer on.

It's not about targeting the maintainer. It's about clarifying what
should be done. I'd be happy to know whether I should have turned the
pbhoney Recommends into a Depends to avoid unwarranted fallback behavior
when people disable Recommends to avoid numerous unneeded packages.

regards
Afif

-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Too many Recommends (in particular on mail-transport-agent)

[Afif Elghraoui]

على الثلاثاء  6 حزيران 2017 ‫04:42، كتب Jonas Smedegaard:
> Quoting Ghislain Vaillant (2017-06-06 10:13:55)
>>
>> Given this is a Python package, we should not even have to argue about 
>> package relationships. Setuptools metadata provides install_requires 
>> and extras_require, the former mapping to Depends, the latter to 
>> Suggests. Period.
>>
>> Your typical Python project README would instruct users to install the 
>> Python package via `pip install`. If one runs `pip install networkx`, 
>> the graphics dependencies do not get pulled. That alone is enough to 
>> justify that these dependencies should not go to Recommends.
>>
>> FYI, I have a similar problem with sympy (#861741), which pulls an 
>> insane amount of packages via chained Recommends.
> 
> We should certainly continue to align package relations with Debian 
> Policy - and therefore by extension continue to argue about that as 
> necessary to evolve Debian Policy:
> 
> Upstream (or other) package relation hints can be a valuable _aid_ in 
> resolving Debian package relations, but only that: An aid!
> 
> Debian packaging follows Debian Policy - other hints do not.
> 

Both good points, but upstream is in the best position to decide whether
something is a strong-yet-not-absolute-dependency (Recommends) of their
software. What Ghislain is saying about Python packages here makes a lot
of sense to me.

regards
Afif
-- 
Afif Elghraoui | عفيف الغراوي
http://afif.ghraoui.name

Re: Too many Recommends (in particular on mail-transport-agent)

[Steve Langasek]

On Tue, Jun 06, 2017 at 11:08:30PM +0200, Michael Biebl wrote:
> Am 06.06.2017 um 18:06 schrieb Russ Allbery:
> > Adam Borowski  writes:

> >> libpam-systemd: xfce4-power-manager xfce4-session
> >> * BAD: Depends:systemd, utterly pointless without it.

> > This is a whole other discussion, but we had *endless* discussions of
> > this, and there are very sound technical reasons for structuring the
> > dependency chain this way.

> xfce4-power-manager, xfc4-session recommending libpam-systemd (or even
> requiring libpam-systemd) seems correct, as those use systemd-logind.

> The Recommends systemd-sysv | systemd-shim is superfluous and should be
> dropped. It's an implementation detail whether systemd (PID 1) or
> systemd-shim provides the functionality needed by
> libpam-systemd/systemd-logind.

If they interface with the dbus APIs directly, they ought to express a
relationship on systemd-sysv | systemd-shim since systemd-shim is not
guaranteed to be already installed on a system booted without systemd.

If they don't interface with the apis and only use them via libpam-systemd,
then libpam-systemd already has this dependency and the separate recommends
could be dropped.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: Switch default installation image link?

[Michael Lustfield]

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.


Usually, when I hear about people downloading the DVD over a slow
paid-per-bit connection, they do it so that they can burn multiple copies
and share so that what people have to download is kept to a minimum.


I'm​ sure other reasons exist where the DVD is the sane option, but the
netinst iso is the only thing I ever considered using.

Re: Too many Recommends (in particular on mail-transport-agent)

[Paul Wise]

On Tue, Jun 6, 2017 at 9:55 PM, Adam Borowski wrote:

> bash-completion: bash dput-ng licensecheck
> * DEBATABLE: I like the Tab key to do something reasonable,
>   "bash-completion" means you never know what you'll get.

I definitely would not want to run a Debian system that didn't have
bash-completion installed. Being able to tab complete command-line
arguments and apt package names are two examples of invaluable
features this package provides.

> fonts-cantarell: fontforge-common
> * BAD: FontForge works perfectly without it

Cantarell is the default font in the UI, changing it would mean Debian
FontForge would look very different to FontForge on other distros.

https://codesearch.debian.net/search?q=Cantarell+package%3Afontforge

> freepats: libwildmidi-config timidity
> * BAD: freepats is too ugly to live: abysmal quality, lacks instruments for
>   pretty much any .mid file in the wild.  We do have a bunch of good
>   alternatives.  timgm6mb-soundfont for one is 5.6 times smaller yet is
>   complete.

We probably need a pair of virtual packages for this.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Bug#864335: ITP: ppx-deriving-yojson -- OCaml syntax extension for JSON serialization

[Ralf Treinen]

Package: wnpp
Severity: wishlist
Owner: Ralf Treinen 

* Package name: ppx-deriving-yojson
  Version : 3.0
  Upstream Author : whitequark 
* URL : https://github.com/whitequark/ppx_deriving_yojson
* License : MIT
  Programming Lang: OCaml
  Description : OCaml syntax extension for JSON serialization


ppx-deriving-yojson is a syntax extension for the OCaml programming
language. It allows you to annotate your type definitions, such that
functions for serialization to JSON, and for deserialization from
JSON, are automatically derived.

This package will be maintained by the debian-ocaml-maint team.

-Ralf.