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

[Philipp Kern]

On 06/06/2017 11:52 PM, Adam Borowski wrote:
>> 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.

On the other hand gvfs is not a kernel driver but a userspace filesystem
and hence has a different threat surface. (Sure, there's still the
possibility of arbitrary code execution from content on a network file
system, but that's then shared with other GNOME applications using it.)

Kind regards
Philipp Kern

Re: Switch default installation image link?

[Adrian Bunk]

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.
> 
> So, no earlier than 2008.

The last Atom-based netbooks with a BIOS supporting only 32-bit were 
actually sold ~ 2012/2013.

And with a peak of 12 million units sold in a quarter Atom netbooks
were at some point mainstream.

No disagreement from me that anything other than amd64 in unusual and 
should be non-default, just pointing out that new i386-only hardware was 
still being sold and popular nearly a decade after 2004.

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

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

[Jonas Smedegaard]

Quoting Afif Elghraoui (2017-06-07 01:44:45)
> 
> على الثلاثاء  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.

Upstreams of Python projects are "in the best position to decide" about 
_PyPI_ hinting.

What we discuss here is _Debian_ hinting, which is not necessarily the 
same, even if labels are identically/equivalently named.

Debian maintainers are in the best position to decide about Debian 
hinting.  Taking upstream hinting into consideration is quite sensible, 
but *not* authoritative not "best" for _Debian_ hinting.


 - 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: Too many Recommends (in particular on mail-transport-agent)

[Wouter Verhelst]

On Tue, Jun 06, 2017 at 03:55:48PM +0200, Adam Borowski wrote:
> 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
> 
> : libreoffice-base
> * BLOAT: they're no longer owned by Sun, what's the reason to keep Java
>   scripting?

Actually, there's significant functionality for some part of
libreoffice-base (this is not the "core" of libreoffice, but the
database component) that's implemented in Java. You can still use
libreoffice-base without java, but that functionality won't be available
then.

I think that's a perfect match for "all but unusual" here.

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

This is about lxc being able to resolve the other containers and the
host system, not about other machines on the network.

You may not be interested in that, but it seems as a perfectly
reasonable thing for a recommends to me.

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

Yes, but isn't there missing functionality then? If so, that makes
perfect sense.

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

I think this is something that can only reasonably be decided by someone
who actually speaks the languages in question.

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

freedoom is quite fun, actually, IMHO. I think this should be a Depends
rather than a Recommends, but perhaps there's a way to use a doom engine
without wads? Dunno.

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

PostScript is often used to store images, too. All these tools use
ghostscript as an import filter for opening those files.

It makes perfect sense to me?

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

No. Just, no. i18n is not a "feature" that we should disable by default.
It should be on by default. Users should not have to check every time
they use a program whether there's i18n files.

There is no stronger example than this to show the "all but unusual"
argument, IMO.

[...]
> libaacs0: libbluray1
> * BLOAT: useful only if you rip optical media

Yes, but essential if you do.

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

They make things go much faster ("The XS accessor methods were between
1.6 and 2.5 times faster than typical pure-perl accessors in some simple
benchmarking.", the description says). However, since it's written in C,
it's not guaranteed to work everywhere. If they're not available or
buggy on your architecture, you might still want to be able to say "use
Moo;" without running into issues, but the normal way of using
libmoo-perl is to have libclass-xsaccessor-perl installed, too.

How is that in any way "bloat"?

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

devscripts has an "interesting" way to categorize recommends and
depends. Some of them are debateable, but they are internally
consistent.

> libgnomeui-0: xscreensaver
>

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

[Wouter Verhelst]

On Wed, Jun 07, 2017 at 12:29:05PM +0800, Paul Wise wrote:
> 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.

Yeah, but I agree with the general feeling that it's extremely annoying
when bash-completion *removes* file names as completion options.
Sometimes the completion has a whitelist of possible filenames; when
that whitelist is incomplete or does not match my system, bash
completion does not help (on the contrary). Yes, it's possible to force
filename completion with alt-shift-/ (at least on my BE AZERTY
keyboard), but that requires a different keystroke than just "tab".

I think if bash had an option to allow programmable completion to add
additional completion options but not remove others, that would be much
much much more interesting.

[...]
-- 
Help me, off-by-one kenobi. You're my only nought.

Re: game engines, game data, dependencies

[Simon McVittie]

On Wed, 07 Jun 2017 at 10:36:17 +0200, Wouter Verhelst wrote:
> On Tue, Jun 06, 2017 at 03:55:48PM +0200, Adam Borowski wrote:
> > 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).
> 
> freedoom is quite fun, actually, IMHO. I think this should be a Depends
> rather than a Recommends, but perhaps there's a way to use a doom engine
> without wads? Dunno.

prboom-plus is not useful without Doom-compatible wad files, but
maybe you are going to use it to play Doom (shareware or commercial),
Freedoom (Free) or Chex Quest (gratis) wad files obtained other than
via Debian, so a Depends would be too strong IMO.

This is analogous to how we don't give ScummVM a Depends on any particular
SCUMM game, and we don't give the darkplaces Quake engine a Depends on
either Quake data, OpenQuartz, Nexuiz, Xonotic or any of the various other
games it can play (many of them not in Debian).

I'm a big fan of distinguishing between the engine and the user-facing
"game" when packaging game engines that can potentially play more than
one game (as in set of game content with its own gameplay/level design -
for instance Quake III Arena, OpenArena and World of Padman are distinct
games that that happen to share an engine and the vast majority of their
game mechanics). The quake series in contrib exemplify this; there's a
mini-policy at
.

The Debian Doom mini-policy takes a different approach, and considers
the engine, not the game content, to be the important user-facing thing.
Wolfenstein 3D in Debian contrib is packaged the same way. I personally
think that this is misguided, and the user-facing things should be
Doom, Doom II, Freedoom etc. Otherwise we have the ridiculous situation
that the Doom game content, Freedoom and Chex Quest are treated as
essentially equivalent (data to be consumed by a Doom engine), which they
are clearly not; and similarly Wolfenstein 3D game content is clearly
not equivalent to its sequel Spear of Destiny, or to Super 3D Noah's Ark.
In each case a player halfway through completing one of those would be
confused and disappointed to get the other after a reinstall :-)

> >   On the other hand, this is an excuse for Doom engines
> >   in main.

The consensus reached between the ftp team and game packagers seems to
be that a game engine packaged like a content-free engine (quakespasm,
ioquake3) can go in main if Free data *exists*, even if that Free data
is not itself present in Debian. yquake2 is still contrib, because we do
not know of any Free data compatible with Quake II engines.

However, a game engine packaged *like a game* (e.g. menu entries
labelled with the name of the game) clearly needs to depend
on appropriate data. For games that are non-distributable (paid-for) like
Return to Castle Wolfenstein and Jedi Academy, I discussed it with the
ftp team and we agreed that "Depends: rtcw-data | game-data-packager" is
appropriate for contrib - conceptually, the game depends on either the
proprietary data (unsatisfiable within Debian+contrib+non-free), or a
way to get it installed to the right place (satisfiable within contrib).

S

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

[Ian Jackson]

Paul Wise writes ("Re: Too many Recommends (in particular on 
mail-transport-agent)"):
> 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.

I recognise that many feel that way; personally I hate bash-completion
and turn it off.  But that's beside the point.

Whether installing bash-completion is a good idea on a particular
system depends on the opinions and tastes (and finger macros) of its
administrators and users.  It does not depend on whether dput-ng or
licensecheck are installed.  So there the dput-ng and licensecheck
Recommends are silly.

And they cause actual lossage: bash-completion is installed by
default, so if it is not installed that's because the administrator
wanted it that way.  Trying to install dput-ng or licensecheck should
not pull in bash-completion as a side-effect.

The Recommends from bash is just the way that it gets installed by
default.  I think it would be better for it to be in tasksel.  A very
minimal machine (with no tasks, or some very minimal task) will work
fine with bash but without bash-completion.

AFAICT none of these three have been filed as a bug yet so I will do
that right away for dput-ng and licensecheck.

I guess for bash, the right answer would be to file bugs against
tasksel and bash, and block the bash bug with the tasksel bug ?

FAOD I am not trying to change the usual default from `with
bash-completion' to `without bash-completion'.  I'm just trying to
arrange that it's slightly easier not to have bash-completion if you
want to, and that it doesn't come back unexpectedly if you deinstall
it.

Ian.

Re: Switch default installation image link?

[Marc Haber]

On Tue, 6 Jun 2017 13:41:31 +, Holger Levsen
 wrote:
>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…

Thinking this further, we should probaby have an
Install-Debian-on-multiple-machines virtual appliance / live USB image
with a DHCP/tftp/http server and a proxy to install more than one
Debian system with network boot on a site with bad connectivity. That
way, one would only transfer the barely necessary amount of software,
and only once.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

Re: Switch default installation image link?

[Marc Haber]

On Tue, 6 Jun 2017 17:39:42 -0500, Gunnar Wolf 
wrote:
>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.

And many people will end up downloading the full DVD set anyway
because they didn't know any better and they didn't read the docs.

Greetings
Marc
-- 
-- !! No courtesy copies, please !! -
Marc Haber |   " Questions are the | Mailadresse im Header
Mannheim, Germany  | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

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

[Christian Seiler]

Hi there,

Am 2017-06-06 15:55, schrieb Adam Borowski:

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


I know there's a faction of people out there who absolutely despise
PulseAudio, and that they constantly have problems with it. But,
as a request collective to all of you that fall into this category:
could you please stop with these snide remarks?

There are other people out here, such as myself, who are really
glad for PulseAudio, and that have never experienced their sound
not to work at all with PA. (Before Jessie I did run into some
issues on some combinations of hardware and software, but all were
solvable, and in the end I was always able to run the configuration
I wanted.)

Now I'm not writing that to try to convince you about PA, and I
don't doubt that you've apparently had trouble with it. And I don't
have a dog in this fight really because I'm not really attached to
PA: if something better comes along in the future, I'd be very
happy to switch. However, what these kind of snide remarks do is
to poison the discussion atmosphere.

To give you an example where I don't like a bit of software: I
really don't like GNOME. But I don't make a habit of going around
and dropping snide remarks such as "I want a usable desktop" [*],
especially in generic discussions. I think this is very counter-
productive.

Or to look at it from this perspective: what I find troubling
here is the apparent lack of recognition that people other than
you might see actual advantages in PA. These kind of remarks come
across as quite condescending to all the people who've looked at
the same software and come to a different conclusion.

Regards,
Christian

PS: Btw. you're objecting to a package with 'pulseaudio' in its
name to recommend the pulseaudio package itself? I think
that this Recommends is a prime example for something that
really makes sense here. In this case the recommends is
fully justified anyway, because the XFCE4 maintainers have
apparently decided that PA should be used by default on
XFCE4 desktops, which is why xfce4 (meta package) Depends:
on xfce4-pulseaudio-plugin.

So in the end, if you don't like PA, then you have two
options here:

  a. Accept the fact that PA is installed by default on
 XFCE4 desktops, be glad that the dependency from the
 XFCE4 plugin to PA itself is only a Recommends: and
 not a Depends:, and remove the package manually. This
 is what Recommends: is for, after all.

   - or -

  b. Convince the XFCE4 people to not make use of PA in the
 default install.

But the Recommends: relationship between the plugin and PA
itself makes perfect sense here.

[*] Which, btw. I would never say about GNOME regardless,
because while I don't like a lot of things they've done, I
wouldn't call it "unusable".

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

[Christian Seiler]

Hi there,

I think one of the main problems with Recommends: is not
actually the dependencies of packages themselves (I think
that most things in your list I disagree with, those
Recommends: are fine in my eyes), but rather in the way
they are handled in APT.

Let me make a couple of points (some are problems, some are
suggestions):

 - You install package A, which Recommends: B, but you don't
   want B, notice that at the time, and either remove B
   afterwards, or install A with --no-install-recommends. But
   then you install package C at a later point in time, which
   actually depends on B. You notice that C is not what you
   wanted, purge it again, but apt-get autoremove will _not_
   remove B, even though it's automatically installed, because
   A recommends it.

   So basically, the following command sequence may or may not
   leave your system in an identical state, depending on the
   packages that previously have been installed on your system:

  apt-get install A
  apt-get purge A
  apt-get autoremove --purge

   Unfortunately, I don't see a good solution to this problem,
   and I've thought about this a lot in the past.

 - When installing APT's text UI doesn't differentiate between
   extra packages that were full dependencies, and those that
   were just recommends. What would be great if APT could
   somehow show this information.

 - My guess is that most power users don't use any GUI, but
   the command line client, for installing packages. (Like I
   do.) However, it would be great if there could be some
   possibility of dropping individual Recommends even with
   the minimalistic text UI of APT.

   Example:

 # apt-get install $pkg
 Reading package lists... Done
 Building dependency tree
 Reading state information... Done
 The following additional packages will be installed:
   $pkg2 $pkg3 $pkg4
 Of these, the following only due to a recommendation:
   $pkg3 $pkg4
 Suggested packages:
   $pkg5 $pkg6
 The following NEW packages will be installed:
   $pkg $pkg2 $pkg3 $pkg4
 0 upgraded, 4 newly installed, 0 to remove and 0 not
 upgraded.
 Need to get 42 MB of archives.
 After this operation, 108 MB of additional disk space will
 be used.
 Do you want to continue? [Y/c/n]

   Where the 'c' button will first show a help (in case a more
   inexperienced user presses it accidentally) and then allow
   the user to remove packages from the list if they are pulled
   in via Recommends: - transitively or intransitively.

 - Instead of globally selecting "no recommends", it would be
   great if one could use something like apt-preferences to
   indicate that certain packages should not be installed
   unless they are manually selected _or_ they are actual hard
   Depends:-dependencies of other packages that do not fall
   in this category. Then one could for example make sure that
   -doc packages aren't installed unless they are hard
   Depends:.

 - What could also be nice would be a new dependency type that
   works like this: if the package that declares this
   dependency has been pulled in via Depends: or manually by
   the user, it should act like Recommends:, otherwise like
   Suggests:.

   For example:

  A
Depends: B
Recommends: C
  B:
Depends: D
Recommends: E
Intransitive-Recommends: F
  C:
Depends: G
Recommends: H
Intransitive-Recommends: I
  G:
Intransitive-Recommends: J

   Then "apt-get install A" would yield the following package
   list:

  A (duh)
  B (Depends)
  C (Recommends)
  D (Depends -> Depends)
  E (Depends -> Recommends)
  F (Depends -> Intransitive-Recommends)
  G (Recommends -> Depends)
  H (Recommends -> Recommends)

   Not pulled in:

  I (Recommends -> Intransitive-Recommends)
  J (Recommends -> Depends -> Intransitive-Recommends)

   (Feel free to bikeshed over the name.)

   This could make the transitivity issue of Recommends:
   easier to deal with. Unfortunately this has some weird
   side-effects: if you mark a specific package as manually
   installed later, their Intransitive-Recommends: would need
   to change from effective Suggests: to effective Recommends:,
   which means APT somehow needs to figure out that it should
   install them. Disadvantage: APT would need to add support
   for this at the beginning of the Buster cycle, but it
   could only be used in the archive starting with Buster+1,
   otherwise upgrades from Stretch wouldn't work.

I'm not sure how good of an idea each of these is, but maybe
they could provide some inspiration for this topic.

Regards,
Christian

Bug#864355: ITP: cod-tools -- tools for manipulation of Crystallographic Information Format v1.1 and v2.0 files

[Andrius Merkys]

Package: wnpp
Severity: wishlist
Owner: Andrius Merkys 

* Package name: cod-tools
  Version : 2.0
  Upstream Author : Saulius Gražulis , Andrius Merkys 
, Antanas Vaitkus 
* URL : http://wiki.crystallography.net/cod-tools
* License : GPL 2.0
  Programming Lang: C, Perl, Python, Shell
  Description : tools for manipulation of Crystallographic Information 
Format v1.1 and v2.0 files

The package contains Crystallographic Information Format (CIF) v1.1 and
v2.0 parser (parser of CIF v1.1 is compared to other parsers in Merkys et
al. 2016, doi:10.1107/S1600576715022396) and scripts for manipulating CIF
files. Package includes CIF parser bindings for C, Perl and Python. Tools
from the package are used in the development and maintenance of the
Crystallography Open Database (http://www.crystallography.net/cod/, usage
described in Gražulis et al. 2009, doi:10.1107/S0021889809016690 and
Gražulis et al. 2015, doi:10.1107/S1600576714025904). The tools follow
the same filter-like usage pattern as Netpbm.

As I am an upstream author, I plan to maintain the package myself. As
this is my first submission, I will need a sponsor.

Re: Switch default installation image link?

[Adam Borowski]

On Wed, Jun 07, 2017 at 03:12:54PM +0200, Marc Haber wrote:
> On Tue, 6 Jun 2017 13:41:31 +, Holger Levsen
>  wrote:
> >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…
> 
> Thinking this further, we should probaby have an
> Install-Debian-on-multiple-machines virtual appliance / live USB image
> with a DHCP/tftp/http server and a proxy to install more than one
> Debian system with network boot on a site with bad connectivity. That
> way, one would only transfer the barely necessary amount of software,
> and only once.

Sounds good!  CDs/DVDs have gone the way of the dodo, and while writing an
iso image to an USB stick works, there's fully writeable medium underneath.
Thus, using a rw file system and apt-cacher-ng (or even bind-mounted
/var/cache/apt/archives) would do the trick.


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#864358: ITP: bitfield -- bit array manipulation library

[Vitalie Ciubotaru]

Package: wnpp
Severity: wishlist
Owner: Vitalie Ciubotaru 

* Package name: bitfield
  Version : 0.6.3
  Upstream Author : Vitalie Ciubotaru 
* URL : https://github.com/ciubotaru/bitfield
* License : GPL
  Programming Lang: C
  Description : bit array manipulation library

bitfield is a library of functions for creating, modifying and destroying bit
fields (or bit arrays), i.e. series of zeroes and ones spread across an array of
storage units (unsigned long integers).

Bit array is a simple data structure used in a wide range of software (starting
from Linux kernel), yet there is no library that would provide this
functionality, so every package has to reinvent the wheel.

As the author, I would be willing to maintain the Debian package. This is my
first submission, so I would need a sponsor.

Bug#864374: ITP: nheko -- desktop IM client for the Matrix protocol

[Hubert Chathi]

Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: nheko
  Version : git snapshot
  Upstream Author : Konstantinos Sideris and others
* URL or Web page : https://github.com/mujx/nheko
* License : GPL-3+
  Description : desktop IM client for the Matrix protocol

Nheko is a Qt-based chat client for the Matrix protocol, an open,
federated communications protocol.  The motivation behind the project is
to provide a native desktop app for Matrix that feels more like a
mainstream chat app and less like an IRC client.

Bug#864375: ITP: quaternion -- desktop IM client for the Matrix protocol

[Hubert Chathi]

Package: wnpp
Owner: Hubert Chathi 
Severity: wishlist

* Package name: quaternion
  Version : git snapshot
  Upstream Author : QMatrixClient team 
* URL or Web page : https://github.com/QMatrixClient/Quaternion
* License : GPL-3+
  Description : desktop IM client for the Matrix protocol

Quaternion is a Qt-based chat client for the Matrix protocol, an open,
federated communications protocol.

DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Dear all,

I am hereby reserving DEP number 15 for my draft DEP, "Reserved
namespaces for DD-approved non-maintainer changes".

I'd like to suggest discussing this DEP on d-devel (which is the
Reply-to for this e-mail).  The canonical DEP text is at
.

The drivers are myself and Ian Jackson, who came up with the idea, but I
said I'd write up the formal proposal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Jeremy Bicha]

On Wed, Jun 7, 2017 at 4:56 PM, Sean Whitton  wrote:
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".

I think this proposal somewhat contradicts DEP-14.

It also feels to me like this proposal is another way of pushing dgit?

Thanks,
Jeremy Bicha

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Boyuan Yang]

在 2017年6月7日星期三 +08 下午9:56:39，Sean Whitton 写道：
> Dear all,
> 
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
> 
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> .
> 
> The drivers are myself and Ian Jackson, who came up with the idea, but I
> said I'd write up the formal proposal.

Just wondering why we need to control the branch name of proposed topic 
branch, or even use a single repo to receive contributions.

My thought is that all we need is the "Pull Request / Merge Request" feature 
on Alioth, where random contributors (who might have absolutely no permission 
anywhere) can create forks (forked repositories) freely and request for review 
and eventual merge from the forked repo into main repo if necessary. People 
are much familiar with such workflow similar to GitHub / GitLab's fork-and-
merge behaviour.

That would also be much easier than setting up custom access control rules 
based on permission inside a single repository.

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

Bug#864393: ITP: elpa-rich-minority -- Clean-up and beautify the list of minor-modes in Emacs' mode-line

[Nicholas D Steeves]

Package: wnpp
Severity: wishlist
Owner: Nicholas D Steeves 

Package name: elpa-rich-minority
Version : 1.0.1
Upstream Author : Artur Malabarba 
URL : https://github.com/Malabarba/rich-minority
License : GPL2+
Programming Lang: Lisp
Description : Clean-up and beautify the list of minor-modes in Emacs' 
mode-line
 Rich-minority-mode is used for hiding and/or highlighting the list of
 minor-modes in the mode-line.
 .
 By default, it has a couple of small effects (provided as examples).
 These can be customised by modifying the following three variables:
 .
 rm-blacklist: List of minor mode names that will be hidden from the
 minor-modes list. Use this to hide only a few modes that are always
 active and don’t really contribute information.
 .
 rm-whitelist: List of minor mode names that are allowed on the
 minor-modes list. Use this to hide all but a few modes.
 .
 rm-text-properties: List text properties to apply to each minor-mode
 lighter. For instance, by default Ovwrt is highlighted with a red
 face, so you always know if you’re in overwrite-mode.

I'm not a fan of the upstream name "rich-minority", but this package
is a dependency for elpa-smart-mode-line.  The name seems to be a pun
on rich text (eg: coloured) support for the mode line.  I would
maintain it as part of the pkg-emacsen team and will require a sponsor.

Sincerely,
Nicholas

Bug#864394: ITP: ayatana-indicator-power -- Ayatana Indicator showing power state

[Mike Gabriel]

Package: wnpp
Severity: wishlist
Owner: Mike Gabriel 

* Package name: ayatana-indicator-power
  Version : 2.0.91
  Upstream Author : Mike Gabriel 
Charles Kerr 
Ted Gould 
* URL : https://github.com/ArcticaProject/ayatana-indicator-power
* License : GPL-3
  Programming Lang: C
  Description : Ayatana Indicator showing power state

 This Ayatana Indicator displays current power management information and
 gives the user a way to access power management preferences.
 .
 The Ayatana Indicator provides a generic, multi-desktop-env aware
 approach of accessing power information and management features.

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Ian Jackson]

Sean Whitton writes ("DEP 15: Reserved namespace for DD-approved non-maintainer 
changes"):
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
> 
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> .
> 
> The drivers are myself and Ian Jackson, who came up with the idea, but I
> said I'd write up the formal proposal.

Thanks, Sean.

For others: this was prompted by a conversation Sean and I had in a
pub on Monday.

Before we get into a detailed discussion here on -devel I think it
would be worth Sean and me getting the DEP draft into some kind of
reasonable shape that we both agree on.

So I won't reply in detail to the comments.

Ian.

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

On Thu, Jun 08, 2017 at 05:41:22AM +0800, Boyuan Yang wrote:
> Just wondering why we need to control the branch name of proposed topic
> branch, or even use a single repo to receive contributions.
> 
> My thought is that all we need is the "Pull Request / Merge Request" feature 
> on Alioth, where random contributors (who might have absolutely no permission 
> anywhere) can create forks (forked repositories) freely and request for 
> review 
> and eventual merge from the forked repo into main repo if necessary. People 
> are much familiar with such workflow similar to GitHub / GitLab's fork-and-
> merge behaviour.

We also want merge requests!  This DEP's implementation should live
alongside those.

Per the DEP:

> it is very useful for a maintainer to know that a change has been
> approved by someone who has been trusted by the project with the
> technical ability to NMU the package

This would be much more cumbersome to achieve with PRs.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

[Sean Whitton]

Hello Jeremy,

On Wed, Jun 07, 2017 at 05:06:10PM -0400, Jeremy Bicha wrote:
> On Wed, Jun 7, 2017 at 4:56 PM, Sean Whitton  wrote:
> > I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> > namespaces for DD-approved non-maintainer changes".
> 
> I think this proposal somewhat contradicts DEP-14.

I forgot to include in the draft an explanation for why this is separate
to DEP-14.  DEP-14's reserved namespaces are meant to be present in
every clone of the repository.  By contrast, DEP-15 reserves a namespace
that should not be present in every clone.

That being said, I don't see why it /contradicts/ DEP-14.  Perhaps you
could explain.

> It also feels to me like this proposal is another way of pushing dgit?

It doesn't require dgit.  I tried to state this as clearly as I could in
the text of the DEP.  dgit-repos is the suggested implementation, but
from the point of view of a DD/DM, it's just a git remote that requires
PGP-signed pushes, which is part of upstream git.

-- 
Sean Whitton


signature.asc
Description: PGP signature