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

[Ansgar Burchardt]

Sean Whitton writes:
> 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
> .

What about contributions to non-packaged parts of Debian?

I also don't like having more systems only a subset of contributors can
use.  Having a place where every contributor can publish merge requests
is nicer (one can still have a tool to make it easier to check commit
signatures using the Debian keyrings if one so desires).

Ansgar

Bug#864408: ITP: dehydrated-dnspython-hook -- dehydrated dns-01 challenge response support

[Debian/GNU]

Package: wnpp
Severity: wishlist
Owner: =?utf-8?q?IOhannes_m_zm=C3=B6lnig_=28Debian/GNU=29?= 


* Package name: dehydrated-dnspython-hook
  Version : 0.1
  Upstream Author : Elizabeth Ferdman 
* URL : https://github.com/eferdman/dnspython-hook
* License : GPL-3
  Programming Lang: Python
  Description : dehydrated dns-01 challenge response support

 This package provides a hook script to serve dns-01 challenge responses for
 dehydated.
 .
 It uses the dnspython API to perform dynamic DNS updates, creating a temporary
 TXT record for the given domain, thereby proving ownership of the domain.
 It requires a DNS-server capable of performing dynamic DNS updates, like bind9.
 There is no need for the DNS-server to run on the local machine.
 .
 This is especially useful if you want to create ACME certificates for servers
 that do not serve HTTP and/or are not exposed to the public internet.

Most ACME-related packages in Debian only deal with http-01 challenges.
This one deals with dns-01.
I intend to maintain this package under the "Debian Let's Encrypt" umbrella
(provided that the team accepts this :-))

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

[Christian Seiler]

Hi Sean,

Am 2017-06-07 22:56, schrieb Sean Whitton:

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
.


I really hate to be negative here, but I just don't see the
point of it.

If I look at how I maintain packages, if someone sends me a
patch (or later once implemented a pull request), I will
always carefully look at that patch - regardless of who it
is from. Not because I necessarily mistrust people, but just
so I also am up to speed about the current state of the
package. I really don't see how having an area to pull from
where only DDs and selected DMs can push to would help here.
(And if contributions from a specific person come often
enough, I'd suggest co-maintainership anyway.)

To me this looks like a very complicated technical solution
to something that I've never encountered as a problem myself.

Again, sorry that I'm so negative here, and of course I have
my own biases, but maybe you could provide an example work-
flow where your proposal actually helps the maintainer and/
or the contributor?

Regards,
Christian

Bug#864428: RFS: bitfield/0.6.3-1 [ITP #864358]

[Vitalie Ciubotaru]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package "bitfield"

* Package name : bitfield
  Version : 0.6.3-1
  Upstream Author : Vitalie Ciubotaru  (me)
* URL : https://github.com/ciubotaru/bitfield
* License : GPLv3+
  Section : libs

It builds those binary packages:

  bitfield - bit array manipulation library in C
  bitfield-dev - bit array manipulation library in C -- development package

To access further information about this package, please visit the following 
URL:

  https://mentors.debian.net/package/bitfield

Alternatively, one can download the package with dget using this command:

  dget -x
https://mentors.debian.net/debian/pool/main/b/bitfield/bitfield_0.6.3-1.dsc

Best regards,

Vitalie Ciubotaru

Re: Switch default installation image link?

[Steve McIntyre]

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

Happy to see that people agree here.

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

And also happy to go with the flow here and leave things with default
netinst.

I'll make the changes.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"The problem with defending the purity of the English language is that
 English is about as pure as a cribhouse whore. We don't just borrow words; on
 occasion, English has pursued other languages down alleyways to beat them
 unconscious and rifle their pockets for new vocabulary."  -- James D. Nicoll

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

[Johannes Schauer]

Quoting Christian Seiler (2017-06-07 15:26:35)
>   - 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.

You may want to have a look at the following apt configuration setting:

APT::AutoRemove::RecommendsImportant "false";

It controls whether "autoremove" also considers autoremoving packages that are
only pulled in because of a Recommends relationship.

Thanks!

cheers, josch


signature.asc
Description: signature

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

[Christian Seiler]

Am 2017-06-08 16:07, schrieb Johannes Schauer:

Quoting Christian Seiler (2017-06-07 15:26:35)

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


You may want to have a look at the following apt configuration setting:

APT::AutoRemove::RecommendsImportant "false";

It controls whether "autoremove" also considers autoremoving packages 
that are

only pulled in because of a Recommends relationship.


Well, that doesn't really help in this case.

In my scenario, I do have Recommends installed by default, I just
may decide to not install some Recommends in some cases. In that
case, apt-get autoremove with the setting you suggested would
remove a _ton_ of packages I actually want to keep. Your setting
is only useful if you also disable installing Recommends by default.
In that case, yes, it would help.

Regards,
Christian

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

[Adrian Bunk]

On Wed, Jun 07, 2017 at 03:26:35PM +0200, Christian Seiler wrote:
>...
>  - 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.
>...

apt-get blacklist-from-recommends-install B
(or a similar entry in a configuration file)

This would help people who have a strong need/desire to opt out of some 
specific package (e.g. pulseaudio) when it would otherwise be pulled in 
through recommends.

> Regards,
> Christian

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)

[Nikolaus Rath]

On Jun 08 2017, Adrian Bunk  wrote:
> On Wed, Jun 07, 2017 at 03:26:35PM +0200, Christian Seiler wrote:
>>...
>>  - 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.
>>...
>
> apt-get blacklist-from-recommends-install B
> (or a similar entry in a configuration file)

I might be able to get this today when using debfoster ("negative
keepers").

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: "Ask HN: What do you want to see in Ubuntu 17.10?"

[Steven Chamberlain]

I would certainly reiterate this:
https://news.ycombinator.com/item?id=14003253

Some versions of Ubuntu (at least trusty, xenial) have the added
"feature" to keep older kernel versions when installing new ones.  It
kind of makes sense to keep at least the previous one (in case of a
regression), but keeping every new patch-version is too much.

Debian doesn't do this (except when the ABI version or upstream version
is new, I think).

apt-get autoremove is supposed to remove the unneeded ones, but
apparently does not.  (And users can't be expected to remember this
either).

On Ubuntu this can fill /boot every few weeks.  In a user group today
I've helped two Ubuntu users who'd run into this problem and been unable
to install new packages/updates as a result.  In the past months I've
seen this about 10 times on all manner of *buntu systems.  (It's a very
popular OS around here, apart from this problem!).

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org


signature.asc
Description: Digital signature

Bug#864454: ITP: ghub-el -- Minuscule client for the Github API

[Matteo F. Vescovi]

Package: wnpp
Owner: Matteo F. Vescovi 
Severity: wishlist

* Package name: ghub-el
  Version : 1.2.0
  Upstream Author : Jonas Bernoulli
* URL or Web page : https://github.com/tarsius/ghub
* License : GPL-3+
  Description : Minuscule client for the Github API

I intend to work on this package under the pkg-emacsen team.

-- 
Matteo F. Vescovi


signature.asc
Description: PGP signature

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

[Ben Hutchings]

On Thu, 2017-06-08 at 19:52 +0100, Steven Chamberlain wrote:
> I would certainly reiterate this:
> https://news.ycombinator.com/item?id=14003253
> 
> Some versions of Ubuntu (at least trusty, xenial) have the added
> "feature" to keep older kernel versions when installing new ones.  It
> kind of makes sense to keep at least the previous one (in case of a
> regression), but keeping every new patch-version is too much.
>
> Debian doesn't do this (except when the ABI version or upstream version
> is new, I think).

I believe Debian has the same APT hook as Ubuntu now, but different
results due to not bumping ABI so often.

> apt-get autoremove is supposed to remove the unneeded ones, but
> apparently does not.  (And users can't be expected to remember this
> either).
[...]

Why doesn't it?  We used to have the problem that many things
recommended linux-image which was provided by all linux-image-*
packages; so all of them would be considered non-removable.  But that
hasn't been the case since jessie.  Does Ubuntu still have this
problem?

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program than to understand a correct
one.



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

Work-needing packages report for Jun 9, 2017

[wnpp]

The following is a listing of packages for which help has been requested
through the WNPP (Work-Needing and Prospective Packages) system in the
last week.

Total number of orphaned packages: 1071 (new: 1)
Total number of packages offered up for adoption: 171 (new: 1)
Total number of packages requested help for: 45 (new: 0)

Please refer to http://www.debian.org/devel/wnpp/ for more information.



The following packages have been orphaned:

   snappy (#863946), orphaned 6 days ago
 Description: fast compression/decompression library
 Reverse Depends: androguard apitrace apitrace-gui boomaga ceph-mon
   ceph-osd ceph-test chromium chromium-shell crash (25 more omitted)
 Installations reported by Popcon: 24793
 Bug Report URL: http://bugs.debian.org/863946

1070 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/orphaned for a complete list.



The following packages have been given up for adoption:

   numba (#864367), offered yesterday
 Description: on-the-fly native machine code compiler for Python
 Installations reported by Popcon: 7
 Bug Report URL: http://bugs.debian.org/864367

170 older packages have been omitted from this listing, see
http://www.debian.org/devel/wnpp/rfa_bypackage for a complete list.



For the following packages help is requested:

   autopkgtest (#846328), requested 190 days ago
 Description: automatic as-installed testing for Debian packages
 Reverse Depends: debci-worker openstack-pkg-tools
 Installations reported by Popcon: 808
 Bug Report URL: http://bugs.debian.org/846328

   balsa (#642906), requested 2083 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 683
 Bug Report URL: http://bugs.debian.org/642906

   busybox (#854181), requested 124 days ago
 Description: Tiny utilities for small and embedded systems
 Reverse Depends: bootcd busybox-syslogd dropbear-initramfs
   live-boot-initramfs-tools open-infrastructure-system-boot udhcpc
   udhcpd wicd-daemon zfs-initramfs
 Installations reported by Popcon: 193587
 Bug Report URL: http://bugs.debian.org/854181

   cargo (#860116), requested 58 days ago
 Description: Rust package manager
 Installations reported by Popcon: 467
 Bug Report URL: http://bugs.debian.org/860116

   cups (#532097), requested 2924 days ago
 Description: Common UNIX Printing System
 Reverse Depends: bluez-cups boomaga chromium
   cinnamon-settings-daemon cloudprint cups cups-backend-bjnp
   cups-browsed cups-bsd cups-client (66 more omitted)
 Installations reported by Popcon: 177328
 Bug Report URL: http://bugs.debian.org/532097

   cyrus-sasl2 (#799864), requested 624 days ago
 Description: authentication abstraction library
 Reverse Depends: 389-ds-base 389-ds-base-libs 389-dsgw adcli
   autofs-ldap cairo-dock-mail-plug-in claws-mail
   claws-mail-acpi-notifier claws-mail-address-keeper
   claws-mail-archiver-plugin (127 more omitted)
 Installations reported by Popcon: 194936
 Bug Report URL: http://bugs.debian.org/799864

   dee (#831388), requested 328 days ago
 Description: model to synchronize mutiple instances over DBus
 Reverse Depends: dee-tools gir1.2-dee-1.0 libdee-1.0-4-dbg
   libdee-dev zeitgeist-core
 Installations reported by Popcon: 63524
 Bug Report URL: http://bugs.debian.org/831388

   developers-reference (#759995), requested 1013 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 18975
 Bug Report URL: http://bugs.debian.org/759995

   devscripts (#800413), requested 618 days ago
 Description: scripts to make the life of a Debian Package maintainer
   easier
 Reverse Depends: apt-build apt-listdifferences aptfs arriero
   bzr-builddeb customdeb debci debian-builder debmake debpear (24 more
   omitted)
 Installations reported by Popcon: 13161
 Bug Report URL: http://bugs.debian.org/800413

   ejabberd (#767874), requested 948 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib ejabberd-mod-cron
   ejabberd-mod-log-chat ejabberd-mod-logsession ejabberd-mod-logxml
   ejabberd-mod-message-log ejabberd-mod-muc-log-http
   ejabberd-mod-post-log ejabberd-mod-pottymouth ejabberd-mod-rest (4
   more omitted)
 Installations reported by Popcon: 647
 Bug Report URL: http://bugs.debian.org/767874

   fbcat (#565156), requested 2703 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 202
 Bug Report URL: http://bugs.debian.org/

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

[Tollef Fog Heen]

]] Sean Whitton 

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

I'm not sure why this is very useful.  It can, in some cases, be a
useful data point, but in general, as the maintainer, I'll want to
review the patch in the same way no matter whether it came from somebody
with a key in the keyring or not.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are