pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)

[Andreas Henriksson]

Hello all.

On Wed, Sep 16, 2015 at 09:10:15PM +0200, Sven Hartge wrote:
[...]
> Why? The vlan package is not needed since at least Wheezy to configure
> VLANs on devices since the program "ip" can do everything the same or
> even better. 
> 
> Also ifupdown was changed to be able to configure VLANs using "ip"
> directly without the need for the "vconfig" from the vlan package.

I think this example is a good one to describe why we should be more
pro-active with removals from the archive.

I filed http://bugs.debian.org/501402 in 2008 when the vlan package had
already been deprecated. This was to allow the package maintainer (or
anyone else!) to implement a smooth transition to the new tools for
anyone still using the vlan package This has obviously not happened
(and I don't blame people for loosing interest in something that becomes
deprecated but it'd ofcourse be nice if we could provide smooth upgrades
for our users). As the years pass by it seems less likely that anyone
will step up and do the work to implement a smooth migration. Given
this, I think it would be a *service* to our users if we removed this
(and many other packages in similar situation) from the archive so that
we don't fool users into using (or wasting time even looking at)
long-deprecated software. If the package is no longer available that means
they'll find out the reason and discover the newer replacement that anyone
should really be looking at for new deployments today.

Unfortunately getting things removed from the archive is alot harder
than adding to the archive. This is something that I think we should
fix.

Regards,
Andreas Henriksson

Re: pro-active removals (was: Re: suggestion to add package vlan to default instalation DVD)

[Stephan Seitz]

On Thu, Sep 17, 2015 at 10:55:58AM +0200, Andreas Henriksson wrote:

this, I think it would be a *service* to our users if we removed this
(and many other packages in similar situation) from the archive so that
we don't fool users into using (or wasting time even looking at)
long-deprecated software. If the package is no longer available that means


It is not a service if you remove packages without replacement strategy.
I don’t care if I use the package iproute2 or vlan/ifenslave to configure 
VLAN interfaces and/or bonds as long as I have documentation how to do 
this in /etc/network/interfaces in an easy way.


The packages vlan and ifenslave are working very well.

That said I think it would be very cool if I could configure VLANs and 
bonds with the Debian installer.


Shade and sweet water!

Stephan

--
| Stephan Seitz  E-Mail: s...@fsing.rootsland.net |
| Public Keys: http://fsing.rootsland.net/~stse/keys.html |


smime.p7s
Description: S/MIME cryptographic signature

Re: pro-active removals

[Vincent Bernat]

 ❦ 17 septembre 2015 10:55 +0200, Andreas Henriksson  :

>> Why? The vlan package is not needed since at least Wheezy to configure
>> VLANs on devices since the program "ip" can do everything the same or
>> even better. 
>> 
>> Also ifupdown was changed to be able to configure VLANs using "ip"
>> directly without the need for the "vconfig" from the vlan package.
>
> I think this example is a good one to describe why we should be more
> pro-active with removals from the archive.
>
> I filed http://bugs.debian.org/501402 in 2008 when the vlan package had
> already been deprecated. This was to allow the package maintainer (or
> anyone else!) to implement a smooth transition to the new tools for
> anyone still using the vlan package

As for ifconfig, people rely on the vconfig command. If I type
"configure vlan linux", on the 10 first results, I have 5 of them
(including the first one) that explain how to use vconfig. One of them
is for "Google Fiber". Another one is from the Ubuntu Wiki. Another one
From Oracle. In fact, only two of them explain that it can be done with
"ip link".
-- 
Don't patch bad code - rewrite it.
- The Elements of Programming Style (Kernighan & Plauger)


signature.asc
Description: PGP signature

DAK Commands for Bikesheds

[Joerg Jaspert]

Hi,

first off I haven't found a "Standard" document documenting the command
feature of dak as currently used for DMs, so if there is one, that
should be merged with what I wrote up now.

Second, the reason why I started writing: I defined the possible
commands for the upcoming bikeshed feature, which use the same command
interface as the DM commands do.

The whole document will end up our git repository[1], though currently
you need my bikeshed branch from [2] to see it (together wit a bit of
basic code for the commands). Without using git you can look at the
document at [3] - i try to keep that copy updated with changes.

Please check if I forgot something obvious or if there is some big error
in it. Patches/git trees to merge from/... are welcome.

Please reply to debian-...@lists.debian.org so we keep a possible
discussion at one place, easier to find again later. Thanks.

[1] git clone https://ftp-master.debian.org/git/dak.git
[2] git clone https://ftp-master.debian.org/users/joerg/dak.git/
[3] https://ftp-master.debian.org/users/joerg/README.commands

-- 
bye, Joerg


signature.asc
Description: PGP signature

Re: Bug#501402: pro-active removals

[ard]

Hi,

On Thu, Sep 17, 2015 at 12:23:02PM +0200, Andrew Shadura wrote:
> Two years ago I wrote a replacement for vconfig [1], which I thought
> would replace it in Debian, but that still hasn't happened.
> 
> [1] https://bitbucket.org/andrew_shadura/fake-vconfig/src

Can I include that as is? Ah, yes, copyright is in the script.
To be clear: I am little bit fed up at network handling in
debian, so I mostly do this:

auto eth0
iface eth0 inet manual
pre-up ip link set up dev eth0

# Use only link-local
iface vlan1 inet manual
pre-up ip link add link eth0 name vlan1 type vlan id 1
pre-up sysctl -w net.ipv6.conf.vlan1.accept_ra=0
pre-up ip link set up dev vlan1
down ip link del vlan1

# To prepare for macvlan usage in lxc:
iface vlan51 inet manual
pre-up ip link add link eth0 name ${IFACE} type vlan id 51
pre-up sysctl -w net.ipv6.conf.${IFACE}.disable_ipv6=1
pre-up ip link set arp off dev ${IFACE}
up ip link set up dev ${IFACE}


I probably should turn of arp and ipv6 too on eth0 before upping
it.

Anyway: it might be best if I scrap the old vlan package and
install some replacement scripts, making it a debian native
package.
And then find a debian maintainer who is willing to upload.

Regards,
Ard van Breemen
-- 
.signature not found

Re: DAK Commands for Bikesheds

[Raphael Hertzog]

Hi,

On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> Please check if I forgot something obvious or if there is some big error
> in it. Patches/git trees to merge from/... are welcome.

Please don't call this feature "Bikesheds" and don't hardcode this naming
in the suggested API. It was funny during one Debconf talk... but it won't
be funny in the long term.

I don't want to suggest bikeshedding on the name but stick to something
simple like "XXX Package (Repository|Archive)" with a XXX that makes sense
to you (Special, Developer, Custom, ...).

Thank you!
-- 
Raphaël Hertzog ◈ Debian Developer

Support Debian LTS: http://www.freexian.com/services/debian-lts.html
Learn to master Debian: http://debian-handbook.info/get/

Status of the src:lsb package (was: Debian LSB compliance)

[Didier 'OdyX' Raboud]

Hi all,

It is time for an update about the lsb source package status, especially 
as a quite important change landed in testing.

After the discussion [0] about these changes back in July (on both 
debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to 
unstable, building no LSB compatibility packages anymore (besides lsb-
release and lsb-base). As far as I could see, this didn't affect 
anything in unstable at the time (and that's how things should be).

This change landed in stretch on September 14. and is de facto the 
"outright giving up" of LSB support for Debian, from stretch onwards. As 
mentionned in the NEWS.Debian entry, the lsb-base (init-functions) and 
lsb-release packages are still available, and are here to stay: lsb-
release has 102 reverse-depends, and lsb-base has 800+ reverse-depends.

But Debian's not throwing all of the LSB overboard: we're still firmly 
standing behind the FHS (version 2.3 through Debian Policy; although 3.0 
was released in August this year) and our SysV init scripts mostly 
conform to LSB VIII.22.{2-8}. But don't get me wrong, this src:lsb 
upload is an explicit move away from the LSB.

I will keep an eye on src:lsb, but really, I don't intend to invest much 
more time; so I'll happily hand over maintainership to anyone wanting to 
invest time in LSB 5.0 Debian support.

Cheers,
OdyX

[0] https://lists.debian.org/4682310.7LIWdV4Lar@gyllingar

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

Re: DAK Commands for Bikesheds

[Geert Stappers]

On Thu, Sep 17, 2015 at 02:41:11PM +0200, Raphael Hertzog wrote:
> Hi,
> 
> On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > Please check if I forgot something obvious or if there is some big error
> > in it. Patches/git trees to merge from/... are welcome.
> 
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

+1



signature.asc
Description: Digital signature

Bug#799281: ITP: mailman3-core -- Mailing list management system

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3-core
  Version : 3.0.0
  Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, 
Terri Oda, Stephen J. Turnbull, Abhilash Raj
* URL : http://list.org/
* License : GPLv3
  Programming Lang: Python3
  Description : Mailing list management system

GNU Mailman3 is a package providing mailing list management system.
This would be the bare core of Mailman3, without client package,
HyperKitty or Postorius, that would be packaged in different sources
packages.

There is currenctly mailman2 in Debian archive, and I was considering
involve myself in packaging mailman3, Mailman developers seems to think
that it is a pretty good idea, but they suggested me to wait 'till 3.1.0
is out.

I'm currently looking for a sponsor as I'm not a Debian Developer, nor
used to build brand new packages. Since 3.1 is not released yet, I've
some time to learn but I'll be happy to work with people already used to
packaging.

This bug report is CC-ed to Debian mailman team, as I do intend to
collaborate with them, I hope I'll be helpful.

This bug report will come with the others for the others components of
Mailman3 suite. I hope this is the good way of doing ITP

Bug#799283: ITP: mailman3-core -- Mailing list management system

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3-core
  Version : 1.0.0
  Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, 
Terri Oda, Stephen J. Turnbull, Abhilash Raj
* URL : http://list.org/
* License : LGPLv3
  Programming Lang: Python2
  Description : Official python bindings for mailman3-core REST API

This package would provide the client for REST API of mailman3-core. It
would depend on mailman3-core, and provide the other minimal part in
order to have mailman3 working correctly.

--

There is currenctly mailman2 in Debian archive, and I was considering
involve myself in packaging mailman3 suite, Mailman developers seems to
think that it is a pretty good idea, but they suggested me to wait 'till
mailman3-core version 3.1.0 is out.

I'm currently looking for some sponsorship as I'm not a Debian
Developer, nor used to build brand new packages. Since version 3.1 is
not released yet, I've some time to learn but I'll be happy to work with
people already used to packaging.

This bug report is CC-ed to Mailman for Debian team, as I do intend to
collaborate with them, I hope I'll make myself helpful.

This bug report will come with the others for the others components of
Mailman3 suite. I hope this is the good way of doing ITP

Re: Status of the src:lsb package (was: Debian LSB compliance)

[Marco d'Itri]

On Sep 17, Didier 'OdyX' Raboud  wrote:

> This change landed in stretch on September 14. and is de facto the 
> "outright giving up" of LSB support for Debian, from stretch onwards. As 
Is there any point in (formally?) maintaining LSB compatibility?
Is there any proprietary application that does actually benefit from it 
in the real world?

-- 
ciao,
Marco


pgpNYlEV5_i0Z.pgp
Description: PGP signature

Bug#799285: ITP: mailman3-core -- Mailing list management system

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3-postorius
  Version : 1.0.1
  Upstream Author : Anna Senarclens de Grancy, Benedict Stein, Barry Warsaw, 
Mark Sapiro, Aurélien Bompard, Florian Fuchs, Terri Oda, Stephen J. Turnbull, 
Abhilash Raj
* URL : http://list.org/
* License : GPLv3
  Programming Lang: Python2
  Description : Django web user interface for accessing GNU Mailman3

Mailman3 comes as a suite of many components. This one provides a django
interface to access GNU Mailman3. It would be an administration
interface, excluding archive access to mailing lists, which is a
specific component.

--

The first version of this django site has been developped during GSoC
2010 and 2011 by Benedict Stein and Anna Senarclens de Grancy.

There is currenctly mailman2 in Debian archive, and I was considering
involve myself in packaging mailman3, Mailman developers seems to think
that it is a pretty good idea, but they suggested me to wait 'till core
version 3.1.0 is out.

I'm currently looking for some sponsorship as I'm not a Debian
Developer, nor used to build brand new packages. Since 3.1 is not
released yet, I've some time to learn but I'll be happy to work with
people already used to packaging.

This bug report is CC-ed to Debian mailman team, as I do intend to
collaborate with them, I hope I'll be helpful.

This bug report will come with the others for the others components of
Mailman3 suite. I hope this is the good way of doing ITP

Bug#799287: ITP: mailman3-hyperkitty -- Mailing list management system

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3-hyperkitty
  Version : 1.0.0
  Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, 
Terri Oda, Stephen J. Turnbull, Abhilash Raj
* URL : http://list.org/
* License : GPLv3
  Programming Lang: Python2
  Description : Django app to access Mailman3 archives

Mailman3 comes as a suite of different components to provide modularity.
Hyperkitty is the web app to access archives.

--

It requires a specific mailman3 plugin to send the mails to HK in order
to have them archived.  This one will be packaged independently.

There is currenctly mailman2 in Debian archive, and I was considering
involve myself in packaging mailman3, Mailman developers seems to think
that it is a pretty good idea, but they suggested me to wait 'till 3.1.0
is out.

I'm currently looking for some sponsorship as I'm not a Debian Developer, nor
used to build brand new packages. Since 3.1 is not released yet, I've
some time to learn but I'll be happy to work with people already used to
packaging.

This bug report is CC-ed to Debian mailman team, as I do intend to
collaborate with them, I hope I'll be helpful.

This bug report will come with the others for the others components of
Mailman3 suite. I hope this is the good way of doing ITP

As it is a django using package, I don't know if there is specific
things to take care about. Please help me know.

Bug#799288: ITP: mailman3-hyperkitty-plugin -- Mailing list management system

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3-hyperkitty-plugin
  Version : 1.0.0
  Upstream Author : Barry Warsaw, Mark Sapiro, Aurélien Bompard, Florian Fuchs, 
Terri Oda, Stephen J. Turnbull, Abhilash Raj
* URL : http://list.org/
* License : GPLv3
  Programming Lang: Python2
  Description : Mailman archiver plugin for HyperKitty

Mailman3 comes as a suite of components. Hyperkitty is the web app
designed to show archives. This plugin comes over mailman3-core and
makes it send emails to hyperkitty in order to have it archive them.

--

There is currenctly mailman2 in Debian archive, and I was considering
involve myself in packaging mailman3, Mailman developers seems to think
that it is a pretty good idea, but they suggested me to wait 'till 3.1.0
is out.

I'm currently looking for some sponsorship as I'm not a Debian Developer, nor
used to build brand new packages. Since 3.1 is not released yet, I've
some time to learn but I'll be happy to work with people already used to
packaging.

This bug report is CC-ed to Debian mailman team, as I do intend to
collaborate with them, I hope I'll be helpful.

This bug report will come with the others for the others components of
Mailman3 suite. I hope this is the good way of doing ITP

Re: DAK Commands for Bikesheds

[Joerg Jaspert]

On 14067 March 1977, Raphael Hertzog wrote:
>> Please check if I forgot something obvious or if there is some big error
>> in it. Patches/git trees to merge from/... are welcome.
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

I disagree.

-- 
bye, Joerg

Bug#799292: ITP: mailman3 -- Mailman3 mailing list manager suite

[Pierre-Elliott Bécue]

Package: wnpp
Severity: wishlist
Owner: "Pierre-Elliott Bécue" 

* Package name: mailman3
  Version : 1.0.0
  Upstream Author : Pierre-Elliott Bécue 
* URL : none
* License : GPLv3
  Programming Lang: ?
  Description : Mailman3 mailing list manager suite

This package would depend on mailman3-core, mailman3-client,
mailman3-postorius, mailman3-hyperkitty and mailman3-hyperkitty-plugin
to provide the full suite of Mailman3 components.

Re: DAK Commands for Bikesheds

[Wookey]

+++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> Hi,
> 
> On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > Please check if I forgot something obvious or if there is some big error
> > in it. Patches/git trees to merge from/... are welcome.
> 
> Please don't call this feature "Bikesheds" and don't hardcode this naming
> in the suggested API. It was funny during one Debconf talk... but it won't
> be funny in the long term.

It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
the unix tradition of mildly amusing/punny names.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Re: Status of the src:lsb package

[Nikolaus Rath]

On Sep 17 2015, m...@linux.it (Marco d'Itri) wrote:
> On Sep 17, Didier 'OdyX' Raboud  wrote:
>
>> This change landed in stretch on September 14. and is de facto the 
>> "outright giving up" of LSB support for Debian, from stretch onwards. As 
>
> Is there any point in (formally?) maintaining LSB compatibility?
> Is there any proprietary application that does actually benefit from it 
> in the real world?

I don't know about formal LSB compatibility, but there are several
proprietary applications that require nothing but the
/{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
would be great if they could be preserved.


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

Re: Status of the src:lsb package

[Didier 'OdyX' Raboud]

Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
> I don't know about formal LSB compatibility, but there are several
> proprietary applications that require nothing but the
> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
> would be great if they could be preserved.

FYI, this used to be in lsb-core, and is to be found in the package VCS 
history.

I will not work towards this, but feel free to adopt the package and 
upload an updated version.

Cheers,
OdyX

P.S. Please keep debian-lsb@ in the loop.

Re: DAK Commands for Bikesheds

[Steve McIntyre]

Joerg Jaspert wrote:
>On 14067 March 1977, Raphael Hertzog wrote:
>>> Please check if I forgot something obvious or if there is some big error
>>> in it. Patches/git trees to merge from/... are welcome.
>> Please don't call this feature "Bikesheds" and don't hardcode this naming
>> in the suggested API. It was funny during one Debconf talk... but it won't
>> be funny in the long term.
>
>I disagree.

Ditto. It's a memorable name that quite well describes some of the
usage it's likely to see. It may be funny *too*, and I don't see a
downside to that.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Further comment on how I feel about IBM will appear once I've worked out
 whether they're being malicious or incompetent. Capital letters are forecast."
 Matthew Garrett, http://www.livejournal.com/users/mjg59/30675.html

Re: DAK Commands for Bikesheds

[Dominic Hargreaves]

On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote:
> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > Hi,
> > 
> > On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > > Please check if I forgot something obvious or if there is some big error
> > > in it. Patches/git trees to merge from/... are welcome.
> > 
> > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > in the suggested API. It was funny during one Debconf talk... but it won't
> > be funny in the long term.
> 
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

On the other hand, neither this thread nor any other d-d thread
that I can find explains what the feature is... so to those who weren't
aware of the name already, it doesn't mean anything :)

>From the context I take it to be a new name for "PPA"s - in which case
thank you for working on this feature!

Cheers,
Dominic.

Re: Status of the src:lsb package

[Nikolaus Rath]

Hi Didier,

(Please honor the Mail-Followup-To or Mail-Copies-To header, thanks!)

On Sep 17 2015, Didier 'OdyX' Raboud  wrote:
> Le jeudi, 17 septembre 2015, 08.46:24 Nikolaus Rath a écrit :
>> I don't know about formal LSB compatibility, but there are several
>> proprietary applications that require nothing but the
>> /{lib,lib64}/ld-lsb.so* symlinks to work properly under Debian. So it
>> would be great if they could be preserved.
>
> FYI, this used to be in lsb-core, and is to be found in the package VCS 
> history.
>
> I will not work towards this, but feel free to adopt the package and 
> upload an updated version.

I'm only a DM and having to search for a fresh sponsor for every upload
is very frustrating. Would you be generally available to sponsor my
uploads (ideallyl until you feel comfortable to give me upload
privileges)?

Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

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

Re: DAK Commands for Bikesheds

[Neil Williams]

On Thu, 17 Sep 2015 17:20:21 +0100
Dominic Hargreaves  wrote:

> On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote:
> > +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > > Hi,
> > > 
> > > On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > > > Please check if I forgot something obvious or if there is some
> > > > big error in it. Patches/git trees to merge from/... are
> > > > welcome.
> > > 
> > > Please don't call this feature "Bikesheds" and don't hardcode
> > > this naming in the suggested API. It was funny during one Debconf
> > > talk... but it won't be funny in the long term.
> > 
> > It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> > the unix tradition of mildly amusing/punny names.
> 
> On the other hand, neither this thread nor any other d-d thread
> that I can find explains what the feature is... so to those who
> weren't aware of the name already, it doesn't mean anything :)

There is a strong British tradition, exported to a range of other
countries, of engineers toiling away in garden sheds, inventing stuff -
be it cars, engines, radios, metalwork, carpentry ... anything someone
can produce which requires only heating, lighting, power and time. It's
quite natural that toiling away in your own little packaging world for
Debian would happen in a software shed - and in software, there's only
really one kind of shed, the bikeshed. 

> >From the context I take it to be a new name for "PPA"s - in which
> >case
> thank you for working on this feature!

... and that's part of the reason to call them bikesheds - these aren't
a new name for PPAs or a version of PPAs for Debian. These are official
hacking space within the Debian project for packages which - for any
number of reasons - just aren't ready to leave the shed yet (or should
be put back into the shed to get out of the hair of those trying to
*actually do a release*).

It looks like a shed, it sounds like a shed, it's a shed.

There is no time or appetite for another round of bikeshedding and we
don't need more TLAs, please allow dak to get me a bikeshed soon!
please!

-- 


Neil Williams
=
http://www.linux.codehelp.co.uk/



pgpsevALwj1Dv.pgp
Description: OpenPGP digital signature

Re: DAK Commands for Bikesheds

[Stefano Zacchiroli]

On Thu, Sep 17, 2015 at 04:39:43PM +0100, Wookey wrote:
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

Not to mention that this bikeshed thread about the Bikeshed name is
going to be both epic and very meta.

-- 
Stefano Zacchiroli  . . . . . . .  z...@upsilon.cc . . . . o . . . o . o
Maître de conférences . . . . . http://upsilon.cc/zack . . . o . . . o o
Former Debian Project Leader . . . . . @zacchiro . . . . o o o . . . o .
« the first rule of tautology club is the first rule of tautology club »


signature.asc
Description: Digital signature

Re: DAK Commands for Bikesheds

[Philip Hands]

Steve McIntyre  writes:

> Joerg Jaspert wrote:
>>On 14067 March 1977, Raphael Hertzog wrote:
 Please check if I forgot something obvious or if there is some big error
 in it. Patches/git trees to merge from/... are welcome.
>>> Please don't call this feature "Bikesheds" and don't hardcode this naming
>>> in the suggested API. It was funny during one Debconf talk... but it won't
>>> be funny in the long term.
>>
>>I disagree.
>
> Ditto. It's a memorable name that quite well describes some of the
> usage it's likely to see. It may be funny *too*, and I don't see a
> downside to that.

Quite right.

The name also emphasises that they're not just the same as PPAs,
which they are not,
which is another good thing about them.

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: Bug#799222: ITP: hitch -- scalable TLS proxy

[Clint Byrum]

Excerpts from Stig Sandbeck Mathisen's message of 2015-09-16 15:57:15 -0700:
> Package: wnpp
> Severity: wishlist
> Owner: Stig Sandbeck Mathisen 
> 
> * Package name: hitch
>   Version : 1.0.0~beta5
>   Upstream Author : Varnish Software AB (and others)
> * URL : https://hitch-tls.org/
> * License : BSD
>   Programming Lang: C
>   Description : scalable TLS proxy
> 
>  hitch is a network proxy that terminates TLS/SSL connections and
>  forwards the unencrypted traffic to some backend. It's designed to
>  handle 10s of thousands of connections efficiently on multicore
>  machines.
>  .
>  Features
>   * TLS1.0, TLS1.1 and TLS1.2 support
>   * SNI, with and without wildcard certificates.
>   * Support for HAproxy's PROXY protocol.
> 
> hitch is a fork of stud (https://github.com/bumptech/stud) which has not
> been packaged in Debian.
> 
> hitch is used at my workplace for TLS termination of online newspapers,
> using Varnish as a backend.
> 
> Hitch will be maintained in the collab-maint group, or in the
> pkg-varnish group. Extra hands for maintenance would be welcome.


Given the reasons for hitch's existence here:

http://ingvar.blog.redpill-linpro.com/tag/hitch/

"hitch is a fork of stud. The fork is maintained by the Varnish
development team, as stud seems abandoned by its creators, after the
project was taken over by Google, with no new commits after 2012."

Perhaps hitch should replace stud?

Re: DAK Commands for Bikesheds

[Robert Edmonds]

Wookey wrote:
> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:
> > Hi,
> > 
> > On Thu, 17 Sep 2015, Joerg Jaspert wrote:
> > > Please check if I forgot something obvious or if there is some big error
> > > in it. Patches/git trees to merge from/... are welcome.
> > 
> > Please don't call this feature "Bikesheds" and don't hardcode this naming
> > in the suggested API. It was funny during one Debconf talk... but it won't
> > be funny in the long term.
> 
> It wasn't supposed to be a joke. Bikeshed is an appropriate name, in
> the unix tradition of mildly amusing/punny names.

Which tradition would that be?

Out of the few hundred or so Unix [0] and GNU [1] commands listed on
Wikipedia, the only vaguely amusing/punning names I can find are tac
("cat" backwards) and pinky (a lightweight "finger").

[0] https://en.wikipedia.org/wiki/List_of_Unix_commands

[1] https://en.wikipedia.org/wiki/GNU_Core_Utilities

RFC 1178 ("Choosing a Name for Your Computer", a reprint from a CACM
article) has some good advice about picking hostnames.  Some of it is
applicable to picking names for software, too, including:

  [...]

  Don't overload other terms already in common use.

 Using a word that has strong semantic implications in the
 current context will cause confusion.  This is especially true
 in conversation where punctuation is not obvious and grammar is
 often incorrect.

 For example, a distributed database had been built on top of
 several computers.  Each one had a different name.  One machine
 was named "up", as it was the only one that accepted updates.
 Conversations would sound like this: "Is up down?"  and "Boot
 the machine up." followed by "Which machine?"

 While it didn't take long to catch on and get used to this
 zaniness, it was annoying when occasionally your mind would
 stumble, and you would have to stop and think about each word
 in a sentence.  It is as if, all of a sudden, English has
 become a foreign language.

  [...]

  Don't use antagonistic or otherwise embarrassing names.

 Words like "moron" or "twit" are good names if no one else is
 going to see them.  But if you ever give someone a demo on your
 machine, you may find that they are distracted by seeing a
 nasty word on your screen.  (Maybe their spouse called them
 that this morning.)  Why bother taking the chance that they
 will be turned off by something completely irrelevant to your
 demo.

  [...]

  Use words/names that are rarely used.

 While a word like "typical" or "up" (see above) isn't computer
 jargon, it is just too likely to arise in discussion and throw
 off one's concentration while determining the correct referent.
 Instead, use words like "lurch" or "squire" which are unlikely
 to cause any confusion.

 You might feel it is safe to use the name "jose" just because
 no one is named that in your group, but you will have a problem
 if you should happen to hire Jose.  A name like "sphinx" will
 be less likely to conflict with new hires.

  [...]

-- 
Robert Edmonds
edmo...@debian.org

Re: DAK Commands for Bikesheds

[Josselin Mouette]

Le jeudi 17 septembre 2015 à 18:52 +0200, Stefano Zacchiroli a écrit :
> Not to mention that this bikeshed thread about the Bikeshed name is
> going to be both epic and very meta.

I herd you like bikesheds…

-- 
 .''`.  Josselin Mouette
: :' :
`. `'
  `-

binNMU or reproducible builds (choose only one)

[Santiago Vila]

Hello.

I see "serious" bug reports asking for packages to drop
"dh_installdocs --link-doc" (see Bug #799316 for an example).

However, binNMUs break the reproducibility of the packages being
NMUed, since apparently the requirement of providing the *exact*
source code that was used for the *.deb is "relaxed" for the packages
being NMUed.

I wonder: Instead of forbidding "dh_installdocs --link-doc", which I
consider a useful feature that should not be dropped lightly, why
don't we just do source-full NMUs that do not change anything?

We could just append a .0 to the Debian version, so that foo 1.0-1
becomes 1.0-1.0 and allow the maintainer to skip this release from the
changelog for 1.0-2 (as we already do for the current binNMU suffixes).

Maybe I'm missing anything, but why do we *need* to break existing
dh_installdocs practice?

Thanks.

Re: binNMU or reproducible builds (choose only one)

[Niels Thykier]

On 2015-09-17 22:02, Santiago Vila wrote:
> Hello.
> 

Hi,

> I see "serious" bug reports asking for packages to drop
> "dh_installdocs --link-doc" (see Bug #799316 for an example).
> 

To clarify (for those who haven't read the bug): I requested that
--link-doc between arch:any AND arch:all packages was removed.  I made
no requests to drop --link-doc between the two arch:any packages.

> However, binNMUs break the reproducibility of the packages being
> NMUed, since apparently the requirement of providing the *exact*
> source code that was used for the *.deb is "relaxed" for the packages
> being NMUed.
> 

The current implementation might not be reproducible-safe, and we should
probably patch.  However, I do not see why binNMUs contradicts
reproducible builds in general.

> I wonder: Instead of forbidding "dh_installdocs --link-doc", which I
> consider a useful feature that should not be dropped lightly, why
> don't we just do source-full NMUs that do not change anything?
> 

binNMUs are much more lightweight than source-full NMUs.  Notably:

 * They are not subject to the NMU policy which involves delays
   - These are certainly politics that could be changed, but ...

 * Scheduling a binNMU is a simple command that involves nothing from
   the person scheduling beyond running it.
   - Certainly the tool could be patched/replaced, but notably, you
 do not have to sign/upload things for this to work.

Again, not saying it could not be changed, but binNMUs are used fairly
often.  Having to download the source code, add a changelog entry and
sign the result would make any non-trivial transition a living hell.

To put this into perspective, the perl 5.22 transition involves ~570
packages.  We expect to be able to binNMU the vast majority of those -
that is a lot of time saved by binNMUing rather than having to download,
unpack, dch -r "", pack, sign and dput.

> [...]
> 
> Maybe I'm missing anything, but why do we *need* to break existing
> dh_installdocs practice?
> 
> Thanks.
> 

The use of dh_installdocs --link-doc between arch:any and arch:all has
up to now always been "broken" (read: binNMU unsafe).  If we were to
replace the binNMU implementation with something that ensured lock-step
versions between arch:all and arch:any packages, it could start work.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: binNMU or reproducible builds (choose only one)

[Santiago Vila]

BTW: We *do* have an "Architecture: all" autobuilder.

(Just in case lack of it was an argument in favour of current
practice).

Re: Status of the src:lsb package

[Michael Biebl]

Am 17.09.2015 um 14:56 schrieb Didier 'OdyX' Raboud:
> After the discussion [0] about these changes back in July (on both 
> debian-lsb@ and debian-devel@), I have uploaded src:lsb 9.20150826 to 
> unstable, building no LSB compatibility packages anymore (besides lsb-
> release and lsb-base). As far as I could see, this didn't affect 
> anything in unstable at the time (and that's how things should be).

So far I only stumbled upon one proprietary deb which has a Depends:
lsb, which will be broken by dropping the lsb compat packages.
It's the closed-source Epson printer driver [1]. It's a rather badly
maintained package (using alien), still wanted to mention it as a data
point.

Michael



[1]
http://download.ebz.epson.net/dsc/du/02/DriverDownloadInfo.do?LG2=DE&CN2=&DSCMI=41168&DSCCHK=0e9768085d5eb29e4f7ff342373d89a6397237ce
-- 
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: binNMU or reproducible builds (choose only one)

[Santiago Vila]

[ Dropping cc and moving to devel only ].

On Thu, Sep 17, 2015 at 10:26:11PM +0200, Niels Thykier wrote:
> binNMUs are much more lightweight than source-full NMUs.  Notably:
> 
>  * They are not subject to the NMU policy which involves delays
>- These are certainly politics that could be changed, but ...

The source-full NMUs I propose for cases like this would be equivalent
for all purposes to the old binNMUs, so it would be reasonable to
treat them as such regarding delays, warnings and such.

(i.e. no delays, no warnings, they are done every time they are needed,
and the maintainer does not need to acknowledge them in the changelog
at all).

>  * Scheduling a binNMU is a simple command that involves nothing from
>the person scheduling beyond running it.
>- Certainly the tool could be patched/replaced, but notably, you
>  do not have to sign/upload things for this to work.

Ok. It may be worth to change the tool to do source-only uploads instead
(which, combined with the Arch: all autobuilder, should yield the
same result).

I will not claim that the change is trivial, but on the other side, if
autobuilders have special code to handle binNMUs, once that the new
tools is in place, the old code could be dropped, which would simplify
things a little bit, I guess.

> [...]
> The use of dh_installdocs --link-doc between arch:any and arch:all has
> up to now always been "broken" (read: binNMU unsafe).  If we were to
> replace the binNMU implementation with something that ensured lock-step
> versions between arch:all and arch:any packages, it could start work.

Well, from the point of view of build-reproducibility, what is broken is the
whole binNMU idea.

Re: binNMU or reproducible builds (choose only one)

[Julien Cristau]

On Thu, Sep 17, 2015 at 22:53:15 +0200, Santiago Vila wrote:

> Well, from the point of view of build-reproducibility, what is broken is the
> whole binNMU idea.
> 
Well, not at all...

Cheers,
Julien


signature.asc
Description: Digital signature

Re: Status of the src:lsb package

[Russ Allbery]

m...@linux.it (Marco d'Itri) writes:

> Is there any point in (formally?) maintaining LSB compatibility?  Is
> there any proprietary application that does actually benefit from it in
> the real world?

LSB seems pretty dead.  I'm dubious there's much point in investing effort
in this.

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

Re: binNMU or reproducible builds (choose only one)

[Wookey]

+++ Santiago Vila [2015-09-17 22:53 +0200]:
> [ Dropping cc and moving to devel only ].
> 
> 
> Well, from the point of view of build-reproducibility, what is broken is the
> whole binNMU idea.

It also causes a lot of trouble for multiarch. To be co-installable
libraries need to have exactly the same version. As soon as you binNMU
one its version doesn't match so it becomes uninstallable alongside
another arch.

This is tracked here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758616

It would become moot if we always had sourceful uploads.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

Re: binNMU or reproducible builds (choose only one)

[Dimitri John Ledkov]

On 17 September 2015 at 22:29, Wookey  wrote:
> +++ Santiago Vila [2015-09-17 22:53 +0200]:
>> [ Dropping cc and moving to devel only ].
>>
>>
>> Well, from the point of view of build-reproducibility, what is broken is the
>> whole binNMU idea.
>
> It also causes a lot of trouble for multiarch. To be co-installable
> libraries need to have exactly the same version. As soon as you binNMU
> one its version doesn't match so it becomes uninstallable alongside
> another arch.
>
> This is tracked here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=758616
>
> It would become moot if we always had sourceful uploads.

In Ubuntu, there is no binNMU implementation server side, and we do
source uploads only, and it's actually not that huge of a pain.
As a side effect, multiarch libraries are more co-installable in Ubuntu.

-- 
Regards,

Dimitri.

Re: binNMU or reproducible builds (choose only one)

[Wouter Verhelst]

On Thu, Sep 17, 2015 at 10:26:11PM +0200, Niels Thykier wrote:
> Again, not saying it could not be changed, but binNMUs are used fairly
> often.  Having to download the source code, add a changelog entry and
> sign the result would make any non-trivial transition a living hell.

There's no reason why you would need to do that manually. Indeed, the
tool that actually does the binNMU (sbuild) will do all that behind the
scenes, but then *throws away* that modified source[1].

Everything needed to remedy that would be to not do so, and include the
source to a binNMU with its upload instead.

(Whether that is a desirable thing to do isn't something I have an
opinion on)

[1] At least it did when I last looked at its code in detail, which
admittedly is over half a decade ago.

-- 
It is easy to love a country that is famous for chocolate and beer

  -- Barack Obama, speaking in Brussels, Belgium, 2014-03-26

Re: binNMU or reproducible builds (choose only one)

[Simon McVittie]

On 17/09/15 21:53, Santiago Vila wrote:
> Ok. It may be worth to change the tool to do source-only uploads instead
> (which, combined with the Arch: all autobuilder, should yield the
> same result).

BinNMUs don't upload any source at all. They instruct the autobuilders
to run sbuild with some non-default options ("sbuild --binNMU=2
--make-binNMU "Rebuild with foo 3" foo_1.2-3" will result in
foo_1.2-3+b2_i386.changes, I think), and sbuild on each autobuilder
downloads the foo_1.2-3.dsc that already exists in the archive.

The only inherent conflict that I can see between binNMUs and
reproducible builds is that all attempts to reproduce the original build
need to prepend the same changelog entry as the original build, for
example by copying them from the build info that will already be
necessary to be able to use the same build-dependency versions.

BinNMUs that happen for all architectures + source simultaneously might
be good to have eventually, to remove some of the weird special cases
from packaging; but if the packages where I've tried it recently are a
reasonably representative sample, I'd estimate that about half the
packages that have both arch:any and arch:all are initially going to
FTBFS on the "all" autobuilder, so we shouldn't rush into that.

Historically, maintainers have normally built source, "all" and one
architecture (dpkg-buildpackage without special options; sbuild -As).
That's well-tested and will usually work, and if it doesn't, it quickly
attracts severity:serious bugs. One of Ubuntu's autobuilder
architectures (I think it's amd64?) is also responsible for their
arch:all packages; it builds with dpkg-buildpackage -b (sbuild -A).
That's very similar to a sourceful upload, so in practice it'll also work.

Debian autobuilders, and Ubuntu's other autobuilders, build  with
dpkg-buildpackage -B (sbuild without special options). Again, that's
well-tested and will usually work, and where it doesn't, it's normally
severity:serious.

Unlike the approach taken in Ubuntu, the new arch:all autobuilder
specifically only builds "all" even if the source produces arch:any
binaries (dpkg-buildpackage -A, sbuild --arch-all-only[1]), which has
not been frequently tested up until now. In my experience, things that
haven't been tested usually don't work.

S

[1] no released version of sbuild has this option; it's new in git

Work-needing packages report for Sep 18, 2015

[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: 668 (new: 3)
Total number of packages offered up for adoption: 178 (new: 2)
Total number of packages requested help for: 49 (new: 0)

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



The following packages have been orphaned:

   apvlv (#798945), orphaned 3 days ago
 Installations reported by Popcon: 271

   fet (#798954), orphaned 3 days ago
 Description: timetable generator
 Reverse Depends: fet
 Installations reported by Popcon: 57

   tintin++ (#799220), orphaned yesterday
 Description: classic text-based MUD client
 Installations reported by Popcon: 162

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

   haxe (#799151), offered yesterday
 Description: Web-oriented universal programming language
 Installations reported by Popcon: 71

   realtimebattle (#798812), offered 4 days ago
 Description: Programming game
 Reverse Depends: realtimebattle
 Installations reported by Popcon: 140

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

   apt-xapian-index (#567955), requested 2054 days ago
 Description: maintenance tools for a Xapian index of Debian packages
 Reverse Depends: goplay muon muon-discover packagesearch
 Installations reported by Popcon: 52018

   athcool (#278442), requested 3978 days ago
 Description: Enable powersaving mode for Athlon/Duron processors
 Installations reported by Popcon: 33

   awstats (#755797), requested 421 days ago
 Description: powerful and featureful web server log analyzer
 Installations reported by Popcon: 4172

   balsa (#642906), requested 1453 days ago
 Description: An e-mail client for GNOME
 Reverse Depends: balsa-dbg
 Installations reported by Popcon: 760

   cardstories (#624100), requested 1606 days ago
 Description: Find out a card using a sentence made up by another
   player
 Installations reported by Popcon: 6

   cups (#532097), requested 2294 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 (65 more omitted)
 Installations reported by Popcon: 157358

   debtags (#567954), requested 2054 days ago
 Description: Enables support for package tags
 Reverse Depends: goplay packagesearch
 Installations reported by Popcon: 2075

   developers-reference (#759995), requested 383 days ago
 Description: guidelines and information for Debian developers
 Installations reported by Popcon: 17053

   ejabberd (#767874), requested 318 days ago
 Description: distributed, fault-tolerant Jabber/XMPP server written
   in Erlang
 Reverse Depends: ejabberd-contrib
 Installations reported by Popcon: 796

   fbcat (#565156), requested 2073 days ago
 Description: framebuffer grabber
 Installations reported by Popcon: 176

   freeipmi (#628062), requested 1575 days ago
 Description: GNU implementation of the IPMI protocol
 Reverse Depends: freeipmi freeipmi-bmc-watchdog freeipmi-ipmidetect
   freeipmi-ipmiseld freeipmi-tools ipmitool libfreeipmi-dev
   libfreeipmi16 libipmiconsole-dev libipmiconsole2 (6 more omitted)
 Installations reported by Popcon: 6465

   gnat-gps (#496905), requested 2576 days ago
 Description: co-maintainer needed
 Reverse Depends: gnat-gps gnat-gps-dbg
 Installations reported by Popcon: 541

   gnokii (#677750), requested 1188 days ago
 Description: Datasuite for mobile phone management
 Reverse Depends: gnokii gnokii-cli gnokii-smsd gnokii-smsd-mysql
   gnokii-smsd-pgsql gnome-phone-manager libgnokii-dev libgnokii6
   xgnokii
 Installations reported by Popcon: 1339

   gridengine (#703256), requested 914 days ago
 Description: Distributed resource management
 Reverse Depends: gridengine-client gridengine-drmaa-dev
   gridengine-exec gridengine-master gridengine-qmon
 Installations reported by Popcon: 1100

   grub2 (#248397), requested 4147 days ago
 Description: GRand Unified Bootloader
 Reverse Depends: debootstick grml-rescueboot grml2usb grub-coreboot
   grub-coreboot-bin grub-coreboot-dbg grub-disk grub-efi
   grub-efi-amd64 grub-efi-amd64-bin (38 more omitted)
 Installations reporte

Bug#799336: general: Prepare for quantum computers breaking encryptions

[Victor Porton]

Package: general
Severity: normal

Dear Maintainer,

We should prepare that invention of quantum computers may break
SSH, HTTPS, PGP, and other encryptions we use in practice.

Packages like these providing SSH should be developed around this problem.

Also there should be written a user manual about new security threats
posed by quantum computers, and how to configure software to get around
these problems.

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (990, 'testing'), (500, 'unstable'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 4.1.0-2-686-pae (SMP w/8 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)

Re: DAK Commands for Bikesheds

[The Wanderer]

On 2015-09-17 at 15:04, Robert Edmonds wrote:

> Wookey wrote:
> 
>> +++ Raphael Hertzog [2015-09-17 14:41 +0200]:

>>> Please don't call this feature "Bikesheds" and don't hardcode
>>> this naming in the suggested API. It was funny during one Debconf
>>> talk... but it won't be funny in the long term.
>> 
>> It wasn't supposed to be a joke. Bikeshed is an appropriate name,
>> in the unix tradition of mildly amusing/punny names.
> 
> Which tradition would that be?
> 
> Out of the few hundred or so Unix [0] and GNU [1] commands listed on
> Wikipedia, the only vaguely amusing/punning names I can find are tac
> ("cat" backwards) and pinky (a lightweight "finger").

There's also nano; it's named for similarity to pico, which I believe
was named as a shortening of "pine composer". pine in its turn was (I
believe) named for similarity to elm, which was an abbreviation for
something I forget. Both the names pine and nano are "amusing/punny" in
that sense.

Also, the GIMP is a play on words of its own - and for that matter, the
recursive acronym "GNU" is a similar piece of wordplay.

I concur that this sort of wordplay in naming is a *nix tradition;
however, I withhold comment as to whether the name "bikeshed" is
appropriate in this case, as the first I remember hearing about them is
this thread and I don't know enough about the context to form a
defensible opinion.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Processed: closing 799336

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> close 799336
Bug #799336 [general] general: Prepare for quantum computers breaking 
encryptions
Marked Bug as done
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
799336: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=799336
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: DAK Commands for Bikesheds

[Craig Small]

On Thu, Sep 17, 2015 at 11:19:57PM -0400, The Wanderer wrote:
> I concur that this sort of wordplay in naming is a *nix tradition;
> however, I withhold comment as to whether the name "bikeshed" is
> appropriate in this case, as the first I remember hearing about them is
> this thread and I don't know enough about the context to form a
> defensible opinion.
The irony is arguing about the name could be considered bikeshedding
to some.

At least, *I* found it amusing.

 - Craig
-- 
Craig Small (@smallsees)   http://enc.com.au/   csmall at : enc.com.au
Debian GNU/Linux   http://www.debian.org/   csmall at : debian.org
GPG fingerprint:5D2F B320 B825 D939 04D2  0519 3938 F96B DF50 FEA5

Re: Bug#799222: ITP: hitch -- scalable TLS proxy

[Stig Sandbeck Mathisen]

Clint Byrum  writes:

> "hitch is a fork of stud. The fork is maintained by the Varnish
> development team, as stud seems abandoned by its creators, after the
> project was taken over by Google, with no new commits after 2012."
>
> Perhaps hitch should replace stud?

"stud" only exists in oldstable, it was removed some time ago, see
https://bugs.debian.org/765404 and
https://tracker.debian.org/news/578119

So in a sense, "hitch" will replace "stud".

-- 
Stig Sandbeck Mathisen