ITP: golang-github-mitchellh-go-homedir -- detect the user's home directory without cgo

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-mitchellh-go-homedir
  Version : 0.0~git20161203.0.b8bc1bf-1
  Upstream Author : 2013 Mitchell Hashimoto
* URL : https://github.com/mitchellh/go-homedir
* License : Expat
  Programming Lang: Go
  Description : detect the user's home directory without cgo

 This golang library implements methods for detecting the user's home directory
 without the use of cgo, so the library can be used in cross-compilation
 environments.
 .
 Usage:
 - homedir.Dir()
   + get the home directory for a user
 - homedir.Expand()
   + expand the ~ in a path to the home directory

This is being packaged as a new dependency of golang-github-spf13-cobra,
which is being packaged as a dependency of gitea.

Re: Debian built from non-Debian sources

[Paul Wise]

On Tue, Jul 18, 2017 at 9:09 AM, Steve McIntyre wrote:

> Making images often requires tweaks to the build script at/near
> release time. The archive continues to be a moving target until very
> close to that time. More than once we've fixed things or added
> workarounds in the image generation scripts *on release day*.

Does the freeze have an affect on this situation?

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Debian built from non-Debian sources

[Jonas Smedegaard]

Quoting Steve McIntyre (2017-07-18 02:32:11)
> On Tue, Jul 18, 2017 at 02:04:04AM +0200, Jonas Smedegaard wrote:
> >Quoting Steve McIntyre (2017-07-18 01:09:43)
> >> I've corrected several of your incorrect assertions already. I'm bored 
> >> of this.
> >
> >Your arrogant attitude hurts!
> 
> I'm *sorry* if you're hurt. Look at it from my point of view. You've
> come in with complaints about stuff I've spent a very long time
> working on. You've made several factual mistakes amongst those
> complaints, and you've continued to imply that I'm doing it wrong,
> showing little apparent understanding or experience of the problem
> space.

I do not say you are doing it wrong.

I say we(!) can do better.  I can do better if I can repreat your work 
using Debian components.  I can more confidently verify that I did not 
mess things up if I can mimic with a higher degree your work.  When I am 
more confident in testing that my setup fails not because I am stupid 
but there is some likelihood that it is a more general problem, I am 
more likely to dare raise it as a bugreport.  Yes, I know that you 
welcome my asking on the mailinglist - but I know that I can have 
trouble explaining myself, so I can be shy.  I don't think I am alone.

I try argue that treating build tools used for producing Debian make 
sense to get packaged for Debian.  Could be after the fact.

I say your looking at services and build tools together and concluding 
the task is too big might change by looking at a smaller task.

This is not an attack on your work.


 - 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: Debian built from non-Debian sources

[Steve McIntyre]

On Tue, Jul 18, 2017 at 02:04:04AM +0200, Jonas Smedegaard wrote:
>Quoting Steve McIntyre (2017-07-18 01:09:43)
>> I've corrected several of your incorrect assertions already. I'm bored 
>> of this.
>
>Your arrogant attitude hurts!

I'm *sorry* if you're hurt. Look at it from my point of view. You've
come in with complaints about stuff I've spent a very long time
working on. You've made several factual mistakes amongst those
complaints, and you've continued to imply that I'm doing it wrong,
showing little apparent understanding or experience of the problem
space.

This does not make for a productive conversation.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"When C++ is your hammer, everything looks like a thumb." -- Steven M. Haflich

Re: Debian built from non-Debian sources

[Jonas Smedegaard]

Quoting Steve McIntyre (2017-07-18 01:09:43)
> I've corrected several of your incorrect assertions already. I'm bored 
> of this.

Your arrogant attitude hurts!


 - 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: Debian built from non-Debian sources

[Steve McIntyre]

Jonas wrote:
>Quoting Steve McIntyre (2017-07-17 02:00:25)
>
>> But a *lot* of the infrastructure we use to run Debian is not exactly 
>> what's been packaged, as already mentioned. Look at dak. debian-cd, 
>> live-wrapper et al *are* packaged, but we're not *necessarily* using 
>> the exact code that's in the stable archive at any point. We're 
>> typically using code from git on the build machines, to allow for more 
>> flexibility in terms of changes to build scripts as problems arise. We 
>> release things to the archive periodically as a convenience to users, 
>> but serious use often necessitates using git too. This isn't going to 
>> change any time soon.
>
>Sure it would be ideal to keep track of *everything* we do, including 
>how we run services.  But as mentioned above I distinguish between 
>services and things directly affecting our product.  Would you agree 
>that at first limiting the task to covering only the tools directly 
>affecting our product (e.g. debian-cd, liver-wrapper, libisofs) is more 
>realistic than tracking also e.g. dak and Alioth?
>
>For starters, I believe they all exist as packages in Debian, it is 
>"only" a matter of releasing into Debian the specific version used in 
>production.
>
>...but since they seemingly are excempt from Debian Policy exactly 
>because the code used is not packaged code, we cannot track this issue 
>in the same way we track issues with packages.  We can "ask on the 
>list"...

I've corrected several of your incorrect assertions already. I'm bored
of this.

Making images often requires tweaks to the build script at/near
release time. The archive continues to be a moving target until very
close to that time. More than once we've fixed things or added
workarounds in the image generation scripts *on release day*. I'm not
going to remove the ability to do that and make working images to
pander to your ideals here.

-- 
Steve McIntyre, Cambridge, UK.st...@einval.com
"Because heaters aren't purple!" -- Catherine Pitt

Re: Bug#868640: hdb_generate_key_set_password broke ABI

[Brian May]

Hello Debian-Devel!

I have this tricky situation. It appears in 2011, upstream made a change
to Heimdal that broken the shared library ABI, and didn't change the
SONAME.

=== cut ===
commit af011f57fc4ae6e865bab471c20aa9047e4e19d4
Author: Roland C. Dowdeswell 
Date:   Mon Nov 28 15:18:52 2011 +

Provide server side kadm5_chpass_principal_3() with ks_tuple implementation.

We enable kadm5_chpass_principal_3() in the server side of the
library.  The client kadm5 library calls will still return the
error KAMD5_KS_TUPLE_NO_SUPP.

Signed-off-by: Nicolas Williams 
=== cut ===

This change was undetected, and included in Debian in Wheezy, Jessie,
Stretch.

Now Upstream has realized their
error. https://github.com/heimdal/heimdal/issues/246

There response was to restore the ABI to the previous state. This change
is now in testing and unstable.

What should I do? It appears patch the ABI back to the previous state,
and break compatability with other distributions. Or I can keep it as it
and break upgrades.

Please read the bull details of 868640 for more information, and for
details of similar situation that occured before the Stretch
release. #848694
-- 
Brian May 

ITP: golang-github-bsm-pool -- simple connection pool in Go

[Michael Lustfield]

Package: wnpp
Severity: wishlist
Owner: Michael Lustfield 

* Package name: golang-github-bsm-pool
  Version : 0.0~git20161215.0.502d32d-1
  Upstream Author : Black Square Media Ltd
* URL : https://github.com/bsm/pool
* License : Expat
  Programming Lang: Go
  Description : simple connection pool in Go

 BSM Pool implements a simple connection pool for Go.
 .
 Features:
 - thread-safe
 - lock-free
 - stack-based rather than queue-based
   + connections that have been used recently are more likely to be re-used
 - supports pool shrinking (reap idle connections)

This is being packaged as a new dependency to golang-github-bsm-redeo.


pgpOF1Qlhw0JT.pgp
Description: OpenPGP digital signature

Re: Debian built from non-Debian sources

[Tollef Fog Heen]

]] Ian Jackson 

> Russ Allbery writes ("Re: Debian built from non-Debian sources"):
> > I think it would be interesting to strive for making available all Debian
> > infrastructure in our archives (although I think you may find that you'll
> > need a separate archive that doesn't correspond to stable or unstable,
> > based on having done similar things in the past), but it would be
> > premature to put a requirement into Policy until we actually *did* decide
> > to do that.  Which would affect a ton of different teams, and would be
> > quite a bit of work.
> 
> As a practical matter, complex bespoke services are much easier to run
> directly out of their vcs trees.

I've been toying with the idea of running those services from
containers.  That would at least get us a runnable artifact, even if it
wasn't purely generated from the archive.  (Yes, we'd need to publish
them somewhere and record where they came from and there's a lot of
practical questions.)

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

Re: Future cme dpkg changes about versioned dependencies

[gregor herrmann]

On Mon, 17 Jul 2017 20:05:12 +0200, Dominique Dumont wrote:

> Some parameters exists that let user decide whether the "cut-off" should be 
> done for stable or old-stable.

I vaguely remember setting this somewhere long ago ...

*after quite some time*

% cat ~/.dpkg-meta.yml 
---
dependency-filter: lenny
group-dependency-filter:
  'Debian Perl Group ': lenny

Haha.

(Interesting detail: last modified 2017-07-02 ?!)
 
> The possibility to choose between old-stable and stable has been broken for 
> quite a while and nobody complained. 


Because of

  'dependency-filter',
  {
'choice' => [
  'etch',
  'lenny',
  'squeeze',
  'wheezy'
],

in lib/Config/Model/models/Dpkg/Meta.pl?

> I guess that nobody uses this feature, so 
> I'm going to remove it. (it's one of those "cool" feature that nobody 
> actually 
> cares about, oh well... )

It seems at least you and me cared about it years ago :)
But I agree that it didn't turn out to be so helpful as apparently I
completly forget about the file.
 
> Unless someone has a better idea, I plan to implement a simpler ruler: a 
> warning will be issued only for dependencies requiring a version older than 
> the oldest one known by madison.

Excellent, that would have been exactly my suggestion.


Cheers,
gregor

-- 
 .''`.  https://info.comodo.priv.at/ - Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member of VIBE!AT & SPI, fellow of the Free Software Foundation Europe
   `-   NP: Sinéad O'Connor: The Healing Room


signature.asc
Description: Digital Signature

Re: Debian built from non-Debian sources

[Russ Allbery]

Jonas Smedegaard  writes:

> I still believe that libisofs are closer tied to our product than to our
> surrounding services: We (or derivatives) may upgrade/replace/skip
> Apache or dak or Alioth and still deliver an identical product, but
> upgrading libisofs may directly cause an image to fail or succeed.
> Isn't that exactly the reason you have chosen to not rely on Debian
> packages but stayed in close contact with upstream and custom compiled
> versions for use in the release process?

Maybe it just depends on one's perspective, but with my Debian user hat
on, I interact with the output of dak and its integrations with apt and
debootstrap and the like *way* more often than I interact with the
installer.  The output of libisofs is something I use every year or two;
the output of dak is something I consume multiple times per day.

Not arguing that you're wrong about the close link between libisofs and
our product, but I do think that any argument you can make about it
applies about equally well to dak.  They're both "just" ways of shipping a
set of Debian packages in a particular consumable configuration used by
key components of our distribution.

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

Future cme dpkg changes about versioned dependencies

[Dominique Dumont]

Hi

Currently, cme dpkg issues warning when a package has a dependency with a 
version requirement (e.g. "foo (>=1.2)") which can be satisfied by stable or 
old-stable.

Some parameters exists that let user decide whether the "cut-off" should be 
done for stable or old-stable.

The possibility to choose between old-stable and stable has been broken for 
quite a while and nobody complained. I guess that nobody uses this feature, so 
I'm going to remove it. (it's one of those "cool" feature that nobody actually 
cares about, oh well... )

Unless someone has a better idea, I plan to implement a simpler ruler: a 
warning will be issued only for dependencies requiring a version older than 
the oldest one known by madison.

All the best

-- 
 https://github.com/dod38fr/   -o- http://search.cpan.org/~ddumont/
http://ddumont.wordpress.com/  -o-   irc: dod at irc.debian.org

Re: Debian built from non-Debian sources

[Jonas Smedegaard]

Quoting Steve McIntyre (2017-07-17 02:00:25)
> Jonas wrote:
> >Quoting Steve McIntyre (2017-07-16 22:14:29)
> >> Jonas wrote:
> >> >Quoting Andrey Rahmatullin (2017-07-16 19:28:06)
> >> >> On Sun, Jul 16, 2017 at 07:05:10PM +0200, Jonas Smedegaard 
> >> >> wrote:
> >> >> > Is our install images excepmt from our Policy that all 
> >> >> > dependencies must be in Debian, or am I mistaken that we have 
> >> >> > such Policy?
> >> >> Do we?  The Debian Policy covers only debs.
> >> >> Also, dak isn't in the archive either.
> >> >
> >> >I thought Policy covered what we distribute - which excludes dak 
> >> >but includes libisofs code embedded in installer images.
> >> 
> >> Can you identify any code at all from libisofs which is embedded in 
> >> the images? I'm honestly not aware of any.
> >
> >I believe the embedded MBR is part of the libisofs project.
> 
> No, the MBR is generated from the isolinux/syslinux packages. xorriso 
> (libisofs) just updates some pointers in there to point at the El 
> Torito bootable images, to add a fake partition table, etc.

Ok, so I stand corrected in that libisofs do not provide code (like e.g. 
a library).  Thanks for clarifying.

I still believe that libisofs are closer tied to our product than to our 
surrounding services: We (or derivatives) may upgrade/replace/skip 
Apache or dak or Alioth and still deliver an identical product, but 
upgrading libisofs may directly cause an image to fail or succeed.  
Isn't that exactly the reason you have chosen to not rely on Debian 
packages but stayed in close contact with upstream and custom compiled 
versions for use in the release process?

I mean, if it were packages, then a new version of the libisofs package 
would likely result in a binNMU of the image packages.  An updated 
version of Debian _services_ like apache or Alioth or dak would unlikely 
lead to binNMUs of any packages.


> >My concern is the ability to replicate and derive the least possible 
> >from Debian resources like the install images.
> 
> ACK, understood.
> 
> >Concretely The Debian derivative PureOS is having trouble booting their 
> >homemade live image on some hardware, but boots fine on both Debian 
> >netinst image and Debian live image.  Looking at the properly working 
> >images I noticed that the live image for stable was produced using 
> >newer-than-stable libisofs,
> 
> Sorry, wrong. It was built using the standard xorriso and libisofs
> versions in stretch. From the stretch-based VM used to build it:

Whoops - you are right.  My eyes are apparently too used to see equal 
versions in tracker.d.o as meaning unstable+testing, not the rare 
unstable+testing+stable that we have now.  Sorry!


> If the PureOS folks are having problems, they could ask on the 
> debian-cd list?

Sure there is always the option to simply ask.

I mentioned the concrete problem as an *example* of a more general 
concern: Whether or not it is even *possible* for anyone outside Debian 
to replicate the Debian product.  We have Debian Policy governing (i.e. 
_documenting_ for outsiders) how we create packages, but apparently we 
have nothing governing the final procedures of how we create our images.


> >and that the stable netinst image was produced using a
> >never-in-Debian release of libisofs.
> 
> Right, I'll give you that one. But there's *seriously* nothing special 
> there any more than what you'd find in any backport to jessie.

I am talking about _avoiding_ uncertainty: Irrelevant to compare with 
other ways of introducing variability to a Debian system!


> But a *lot* of the infrastructure we use to run Debian is not exactly 
> what's been packaged, as already mentioned. Look at dak. debian-cd, 
> live-wrapper et al *are* packaged, but we're not *necessarily* using 
> the exact code that's in the stable archive at any point. We're 
> typically using code from git on the build machines, to allow for more 
> flexibility in terms of changes to build scripts as problems arise. We 
> release things to the archive periodically as a convenience to users, 
> but serious use often necessitates using git too. This isn't going to 
> change any time soon.

Sure it would be ideal to keep track of *everything* we do, including 
how we run services.  But as mentioned above I distinguish between 
services and things directly affecting our product.  Would you agree 
that at first limiting the task to covering only the tools directly 
affecting our product (e.g. debian-cd, liver-wrapper, libisofs) is more 
realistic than tracking also e.g. dak and Alioth?

For starters, I believe they all exist as packages in Debian, it is 
"only" a matter of releasing into Debian the specific version used in 
production.

...but since they seemingly are excempt from Debian Policy exactly 
because the code used is not packaged code, we cannot track this issue 
in the same way we track issues with packages.  We can "ask on the 
list"...


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkit

Re: Naming of network devices - how to improve it in buster

[Guus Sliepen]

On Mon, Jul 17, 2017 at 05:12:07AM +0200, Adam Borowski wrote:

> > That's indeed an interesting issue. Currently, ifupdown doesn't rename
> > interfaces. You could add a line like:
> > 
> > post-up ip link set $IFACE name $LOGICAL
> > 
> > Which will do what you want, except ifupdown doesn't track interface
> > renames this way and will get very confused. In particular, ifdown will
> > not work anymore. So some code should be added to ifupdown to support
> > interface renaming.
> 
> This is what I assumed your new code does -- it seemed an obvious and
> natural thing to do.

Well, it just matched an existing interface to a logical iface stanza,
it didn't need to rename anything. The use case is anything outside of
ifupdown and its plugins that might use interface names, such as for
example netfilter-persistent.

> As Ben noticed, the post-up stanza above can't work as Linux doesn't allow
> renaming interfaces at that point. It can't work in pre-up either as
> ifupdown wouldn't know about the rename.

Ah, indeed.

> Thus, what about this:
> auto mac/00:16:0a:26:99:c6/=en0
> iface en0 inet6 static
>   address 3:1415:9265:3589:7932:3846:2643:3832/64
>   gateway 3:1415:9265:3589::1
>   rename
> 
> With the rename command taking an optional argument (the new name) that
> defaults to the logical name (ie, after =).

Yes, that should be implementable.

-- 
Met vriendelijke groet / with kind regards,
  Guus Sliepen 


signature.asc
Description: PGP signature

Re: Debian built from non-Debian sources

[Holger Levsen]

On Mon, Jul 17, 2017 at 12:09:30AM +0200, Christian Seiler wrote:
> [...] downstreams should be able to reproduce Debian images.
> In the short term only in functionality and not bit-by-bit, but I
> would consider reproducible image builds a worthwhile long-term goal
> after fully reproducible package builds throughout the archive have
> been achieved.
 
fully reproducible images are possible with unreproducible packages,
those two are related+similar but don't depend on each other.

(of course with unreproducible packages in reproducible images you
still need to believe the providers of those unreproducible packages
that they contain what they should contain, but at least the image
can be reproducible…)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Debian built from non-Debian sources

[Ian Jackson]

Russ Allbery writes ("Re: Debian built from non-Debian sources"):
> I think it would be interesting to strive for making available all Debian
> infrastructure in our archives (although I think you may find that you'll
> need a separate archive that doesn't correspond to stable or unstable,
> based on having done similar things in the past), but it would be
> premature to put a requirement into Policy until we actually *did* decide
> to do that.  Which would affect a ton of different teams, and would be
> quite a bit of work.

As a practical matter, complex bespoke services are much easier to run
directly out of their vcs trees.

I think a better engineering approach to allowing others to share our
infrastructure code is to ensure that every service we run can
provide, automatically and at runtime, its own source code.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#868665: ITP: python-asgiref -- ASGI in-memory channel layer

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: python-asgiref
  Version : 1.1.2
  Upstream Author : Django Software Foundation 
* URL : https://github.com/django/asgiref/
* License : BSD-3-clause
  Programming Lang: Python
  Description : ASGI in-memory channel layer

 Contains various reference ASGI implementations, including:
 .
  * A base channel layer, asgiref.base_layer
  * An in-memory channel layer, asgiref.inmemory
  * WSGI-to-ASGI and ASGI-to-WSGI adapters, in asgiref.wsgi

-BEGIN PGP SIGNATURE-

iQFFBAEBCgAvFiEEqVSlRXW87UkkCnJc/9PIi5l90WoFAllsovARHGZsYWRpQGRl
Ymlhbi5vcmcACgkQ/9PIi5l90WpNHQf7Bizo8KnRdfSO9CId2q6kDi/tGTdwlvDG
9XBPwGh5nhKKT/vjXA6gQOgpzPLXr3nke/ZmDSd1x3PiAchiO30dq9Vl/Ipolyjg
xy3uBR53DNX2Uxuw43TqA0AAUWoSsOxbDHpcnIyBFzs49kBj+oQR3XClhKgr7fch
aKu/BNhC1DpAp5TtKurMPn+4tDlLgIs9TTGEOKAG7iT1tWf0NyTCnRLEgv212L4p
dJ1SQYMJlbDE8jhZk0TwKTE02mIS/DaBf6DArl0B5AtFTmdFHFLrLIETtTdqC8+D
bfsR94UT1LzHlvPaHmVyp8YTi6yymh15Pg90PNu65R7wMlBHw6kX8A==
=rV+h
-END PGP SIGNATURE-

Bug#868660: ITP: maven-mapping -- Apache Maven Mapping

[Emmanuel Bourg]

Package: wnpp
Severity: wishlist
Owner: Emmanuel Bourg 

* Package name: maven-mapping
  Version : 3.0.0
  Upstream Author : The Apache Software Foundation
* URL : https://maven.apache.org/shared/maven-mapping/
* License : Apache-2.0
  Programming Lang: Java
  Description : Apache Maven Mapping

Maven Mapping is a shared component to assist in interpolating file names
using properties from a Maven project.

This library is a new dependency of maven-war-plugin.
It'll be maintained by the Java Team.