Hi!
On Fri, 2014-08-15 at 16:05:57 +0200, Johannes Schauer wrote:
> I have not managed to solve this issue in a satisfactory manner and am too
> embarrassed to show what I came up with to people who actually know how to
> write perl :D
>
> Thus I created bug#758191 to keep track of this issue.
T
Hi,
Quoting Johannes Schauer (2014-04-21 16:31:13)
> Quoting Guillem Jover (2014-04-21 16:04:17)
> > Sorry for not mentioning before, I had already locally a very similar patch,
> > which will be included in 1.17.7 to be uploaded in few minutes, but using a
> > key=value1,value2 format instead, so
Hi Guillem,
Quoting Guillem Jover (2014-04-21 16:04:17)
> Sorry for not mentioning before, I had already locally a very similar patch,
> which will be included in 1.17.7 to be uploaded in few minutes, but using a
> key=value1,value2 format instead, so that the new stuff can appear in any
> order a
Hi!
On Mon, 2014-04-21 at 14:26:25 +0200, Johannes Schauer wrote:
> I now believe the former option to be the superior one. As Raphaël Hertzog
> pointed out initially, which binary packages builds with what arch or profile
> is a property of the source package. Thus, the information should become
Hi everybody,
Quoting Johannes Schauer (2014-03-20 08:40:05)
> So maybe this brings us back to encoding the Architecture as well as the
> Build-Profiles field information in the Package-List field of the source
> package as suggested by Raphaël Hertzog?
>
> Or maybe two new fields would solve the
Hi Guillem,
Quoting Guillem Jover (2014-03-20 07:00:10)
> Sorry, what I meant is that the information of which architecture each binary
> package is built on is only propagated to the Packages files if those
> binaries have been built before, which is usually not the case when
> bootstrapping a ne
On Tue, 2014-03-18 at 00:40:45 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-03-14 20:46:23)
> > > Right now the information which binary packages do or do not build for
> > > which build profile is restricted to debian/control. Coming back to my
> > > original mail: what do you see
Hi,
Quoting Guillem Jover (2014-03-14 20:46:23)
> > Right now the information which binary packages do or do not build for
> > which build profile is restricted to debian/control. Coming back to my
> > original mail: what do you see as the best way to propagate this
> > information into the Packag
Hi!
[ Sorry, have been traveling. ]
On Sat, 2014-03-08 at 01:13:06 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-03-07 22:34:15)
> > Ok, two scenarios. First one, you have a source producing multiple
> > binary packages, one of which contains only an ldap plugin. If the
> > package
Hi :)
Quoting Guillem Jover (2014-03-07 22:34:15)
> On Fri, 2014-03-07 at 15:57:53 +0100, Johannes Schauer wrote:
> > The problem might lie in the fact that I do not understand how "profiles
> > the binary package gets produced for" is different from "profiles the
> > binary package supports or ca
Hey!
On Fri, 2014-03-07 at 15:57:53 +0100, Johannes Schauer wrote:
> Quoting Guillem Jover (2014-03-07 03:18:54)
> > Ok, just to clarify what we are talking about, and which recently realized
> > (after having seen the debhelper implementation) I might have misunderstood
> > the proposed purpose o
Hi Guillem,
Quoting Guillem Jover (2014-03-07 03:18:54)
> Ok, just to clarify what we are talking about, and which recently realized
> (after having seen the debhelper implementation) I might have misunderstood
> the proposed purpose of the field in the past, and think I might have already
> said
Hi!
On Fri, 2014-02-21 at 12:30:13 +0100, Johannes Schauer wrote:
> The problem is, that tools which analyze dependency relationships between
> binary and source packages (like dose3), currently use only Packages and
> Sources files as input. While the bits of the Build-Depends
> field is properl
Hi dpkg people, :)
since build profiles have successfully been introduced in dpkg 1.17.2, it was
very easy to also convince others like apt and debhelper to support them. In
this email I want to discuss an addendum to what is implemented in dpkg right
now.
The problem is, that tools which analyze
14 matches
Mail list logo
