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:
>
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
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
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
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:
> >>
>
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
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
>>>
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
* 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
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
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
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
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.
> >
> >
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
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
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
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
* 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
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.
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
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
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 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
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
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
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
* 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
28 matches
Mail list logo