On Wed, Oct 12, 2016 at 11:27:28AM +1300, Michael Hudson-Doyle wrote:
> On 12 October 2016 at 10:44, Moritz Mühlenhoff wrote:
>
> > On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> > > On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> > > > Florian Weimer wrote:
> > > >
On 12 October 2016 at 10:44, Moritz Mühlenhoff wrote:
> On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> > On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> > > Florian Weimer wrote:
> > >> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> > >> >> W
On Mon, Jul 11, 2016 at 10:53:57AM +1200, Michael Hudson-Doyle wrote:
> On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> > Florian Weimer wrote:
> >> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> >> >> What's the current status? Is there technical progress compared to
On 13 July 2016 at 19:20, Moritz Mühlenhoff wrote:
> On Mon, Jul 11, 2016 at 09:12:05AM +1200, Michael Hudson-Doyle wrote:
>> On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
>> wrote:
>> > On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
>> >>
>> >> On 06/07/16 20:59, Moritz Mühlenhoff
On Mon, Jul 11, 2016 at 09:12:05AM +1200, Michael Hudson-Doyle wrote:
> On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
> wrote:
> > On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
> >>
> >> On 06/07/16 20:59, Moritz Mühlenhoff wrote:
> >>
> >>> What's the current status? Is there tech
On 9 July 2016 at 07:21, Moritz Muehlenhoff wrote:
> Florian Weimer wrote:
>> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
>> >> What's the current status? Is there technical progress compared to what
>> >> was
>> >> discussed in April? The freeze is coming really close an
On 8 July 2016 at 20:03, Potter, Tim (HPE Linux Support)
wrote:
> On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
>>
>> On 06/07/16 20:59, Moritz Mühlenhoff wrote:
>>
>>> What's the current status? Is there technical progress compared to what was
>>> discussed in April? The freeze is coming rea
On 09/07/16 20:39, Florian Weimer wrote:
>> We can get list of all source packages to re-build from reverse build
>> dependencies. Then it should be possible to filter arch:any packages to bin-
>> NMU.
>>
>> Alternatively Built-Using field could be of help.
>
> We already discussed why this does
* Dmitry Smirnov:
> On Friday, 8 July 2016 8:53:20 AM AEST Florian Weimer wrote:
>> Part of the problem is that we currently lack a decent way to list all
>> these reverse dependencies.
>
> We can get list of all source packages to re-build from reverse build
> dependencies. Then it should be pos
On 9 Jul 2016, at 3:52 PM, Martín Ferrari wrote:
>
> Moritz,
>
> On 08/07/16 20:21, Moritz Muehlenhoff wrote:
>> And with that setup (and in addition to what Florian mentioned) I see
>> no sane way that we can support Go applications in stretch. It's
>> already difficult enough to support a dis
Moritz,
On 08/07/16 20:21, Moritz Muehlenhoff wrote:
> And there's also the much bigger problem that we can't actually rebuild
> packages on security.debian.org without a lot of manual work!
>
> The dak installation for security-master has a _lot_ of tech debt. One
> that particularly bites us h
On Fri, 2016-07-08 at 21:21 +0200, Moritz Muehlenhoff wrote:
>
> As Haskell was mentioned; sure it has the same problem. But Go is a totally
> different ballpark:
I mentioned Haskell only because AIUI they have a tool for generating
sets of binNMUs from a changed source package, I didn't intend t
On Friday, 8 July 2016 8:53:20 AM AEST Florian Weimer wrote:
> Part of the problem is that we currently lack a decent way to list all
> these reverse dependencies.
We can get list of all source packages to re-build from reverse build
dependencies. Then it should be possible to filter arch:any pac
Florian Weimer wrote:
> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> >> What's the current status? Is there technical progress compared to what was
> >> discussed in April? The freeze is coming really close and we can't support
> >> the status quo for stretch.
> >
> > Perh
* Tim Potter:
> Hi everyone. I've done a small amount of research into the
> buildmode=c-shared and the dynlink option and they look good on
> paper. Has anyone examined these options more seriously?
I think structure sizes and field offsets still leak across shared
object boundaries (probably
On 7 Jul 2016, at 12:40 PM, Martín Ferrari wrote:
>
> On 06/07/16 20:59, Moritz Mühlenhoff wrote:
>
>> What's the current status? Is there technical progress compared to what was
>> discussed in April? The freeze is coming really close and we can't support
>> the status quo for stretch.
>
> The
On Fri, 2016-07-08 at 08:53 +0200, Florian Weimer wrote:
> * Dmitry Smirnov:
>
> > On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> >> What's the current status? Is there technical progress compared to
> what was
> >> discussed in April? The freeze is coming really close and we
* Dmitry Smirnov:
> On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
>> What's the current status? Is there technical progress compared to what was
>> discussed in April? The freeze is coming really close and we can't support
>> the status quo for stretch.
>
> Perhaps I'm not the
On Wednesday, 6 July 2016 9:59:32 PM AEST Moritz Mühlenhoff wrote:
> What's the current status? Is there technical progress compared to what was
> discussed in April? The freeze is coming really close and we can't support
> the status quo for stretch.
Perhaps I'm not the best person to speak on th
On 06/07/16 20:59, Moritz Mühlenhoff wrote:
> What's the current status? Is there technical progress compared to what was
> discussed in April? The freeze is coming really close and we can't support
> the status quo for stretch.
The discussion stalled at that point. AFAIK, there is no technical
s
On Wed, Apr 06, 2016 at 09:24:20AM +1000, Dmitry Smirnov wrote:
> IMHO Golang community abused almost as much as possible with static linking,
> embedding resources to executables, not using versioning and breaking API at
> any time, etc.
>
> Even if we find effective technical solution to detec
On 13 April 2016 at 17:03, Florian Weimer wrote:
> * Michael Hudson-Doyle:
>
>> There is another approach to the static linking issue, which is to
>> start using dynamic linking instead. It's implemented upstream for
>> most architectures now (only mips64 le/be and ppc64 be missing I
>> think). I'
* Michael Hudson-Doyle:
> There is another approach to the static linking issue, which is to
> start using dynamic linking instead. It's implemented upstream for
> most architectures now (only mips64 le/be and ppc64 be missing I
> think). I'm going to be working on starting to use dynamic linking
Bit of a late reply, been busy.
On 5 April 2016 at 19:27, Florian Weimer wrote:
> Hi,
>
> we need to discuss how we can support applications written in Go for
> stretch.
>
> The most radical approach would be not to ship any Go applications in
> stretch, only the basic Go language implementations
On Tue, Apr 05, 2016 at 06:05:21PM -0400, Paul Tagliamonte wrote:
> Love this idea, I wonder if the Import-Path XS header could help resolve
> packages in a proof of concept
If I am not mistaken, the XS-Go-Import-Path cannot be queried with
dpkg-query since it is a field in the source package. Wha
We can change it to XSB-Go-Import-Path, but it only really applies for the
-dev packages; so it might need some fiddling to do right, yeah. I'll think
a bit more about it.
We could also likely build up mappings for Source -> import path, and index
from Binary control Source -> Source -> Import Pat
On Tuesday, 5 April 2016 10:41:04 PM AEST Paul Tagliamonte wrote:
> | Backports are packages taken from the next Debian release (called
> | "testing"), adjusted and recompiled for usage on Debian stable.
>
> So my confusion here is that you don't want to see them in Stable, but
> you do want to se
On Wed, Apr 06, 2016 at 12:37:10PM +1000, Dmitry Smirnov wrote:
> I feel your pain. Over last 9 months I've invested even greater effort to
> packaging of containers related Golang software.
>
> Yet we can provide anything we want to users of stable releases through
> official backports:
>
>
On Tuesday, 5 April 2016 10:08:04 PM AEST Peter Colberg wrote:
> On Wed, Apr 06, 2016 at 09:24:20AM +1000, Dmitry Smirnov wrote:
> > Unless we can exclude Golang from security support I think we should not
> > ship any Golang applications with next stable release.
>
> I really hope not, that would
On Wed, Apr 06, 2016 at 09:24:20AM +1000, Dmitry Smirnov wrote:
> Unless we can exclude Golang from security support I think we should not ship
> any Golang applications with next stable release.
I really hope not, that would be a real shame.
All the work that we did together on acmetool (#81709
On Tuesday, 5 April 2016 9:27:27 AM AEST Florian Weimer wrote:
> we need to discuss how we can support applications written in Go for
> stretch.
>
> The most radical approach would be not to ship any Go applications in
> stretch, only the basic Go language implementations. This is probably
> not
https://sources.debian.net/src/dh-golang/1.12/script/dh_golang/#L121
is where Built-Using is added (generated from the code above that
line)
https://sources.debian.net/src/dh-golang/1.12/lib/Debian/Debhelper/Buildsystem/golang.pm/#L144
is where dh-golang currently invokes "go list" (on "DH_GOPKG/.
Love this idea, I wonder if the Import-Path XS header could help resolve
packages in a proof of concept
On Apr 5, 2016 5:54 PM, "Tianon Gravi" wrote:
> On 5 April 2016 at 14:47, Florian Weimer wrote:
> > We currently need these intermediate dependencies to discover all the
> > affected applicati
On 5 April 2016 at 14:47, Florian Weimer wrote:
> We currently need these intermediate dependencies to discover all the
> affected applications. So perhaps dh_golang needs to construct the
> transitive closure, instead of listing just immediate build
> dependencies. If we don't want to put this
* Martín Ferrari:
>> The alternative is to rebuild reverse dependencies as needed. I can
>> see two challenges with that. Right now, the Built-Using field only
>> records the source versions of the *direct* dependencies (based on the
>> dh_golang manual page and a few examples I looked at). If
Hi Florian,
On 05/04/16 09:27, Florian Weimer wrote:
> we need to discuss how we can support applications written in Go for
> stretch.
Thanks for bringing this up for discussion.
Coincidentally, a few days ago we were discussing the implementation of
autopkgtest to deal with issues that stem fr
Hi,
we need to discuss how we can support applications written in Go for
stretch.
The most radical approach would be not to ship any Go applications in
stretch, only the basic Go language implementations. This is probably
not desirable.
So we need something to deal with the static linking issue
37 matches
Mail list logo