ing similar with CMake.
>
> > I don't want to repeat those flags in debian/rules as this way I will
> > have to change them in two places in case any of them changes.
>
> Ack.
>
> > Is there some simple way to avoid usage of `dpkg-buildflags` during
> > com
ure. I assume you could
do something similar with CMake.
> I don't want to repeat those flags in debian/rules as this way I will
> have to change them in two places in case any of them changes.
Ack.
> Is there some simple way to avoid usage of `dpkg-buildflags` during
>
) and we definitely don't want that. Is there some way to
prevent `dpkg-flags` from changing them?
I don't want to repeat those flags in debian/rules as this way I will
have to change them in two places in case any of them changes.
Is there some simple way to avoid usage of `dpkg-buildfla
On Tue, 19 Jan 2021 at 05:02:29 +0100, Guillem Jover wrote:
> On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> > SOURCE_BASE_DIR has a delightful symmetry to SOURCE_DATE_EPOCH and the
> > algorithm for use is similar: if it is in the environment then use it, if
> > not,
> > fall ba
Hi!
On Mon, 2021-01-11 at 00:48:42 +1100, Stuart Prescott wrote:
> Sune Stolborg Vuorela wrote:
> > Can you provide some kind of hook in the environment so we at least can work
> > around it in the users, so that the internal functions (where the output of
> > __FILE__ is forwarded to) can glue e.
Sune Stolborg Vuorela wrote:
> Can you provide some kind of hook in the environment so we at least can work
> around it in the users, so that the internal functions (where the output of
> __FILE__ is forwarded to) can glue e.g. the content of an environment
> variable in front of the usage of the _
On Saturday, January 9, 2021 12:49:50 AM CET Guillem Jover wrote:
> Disabling this option in these few places gives you room to possibly
> look for a fix, or not, w/o the pressure of the freeze, while not
> affecting the other packages.
Hi Guillem
Can you provide some kind of hook in the environm
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> Note: in case we do not agree on this topic this will be the text I'll
> send to the
> tech-ctte.
Thanks for taking the time to draft some text. If we can come closer to
agreement on the proposed text, that would probably take a bit of th
Hi (again)!
On Sat, 9 Jan 2021 at 17:53, Vagrant Cascadian
wrote:
>
> On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> > Oh, I have sadly forgotten to mention another thing.
> >
> > On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
> >> # __FILE__ is a public
On 2021-01-09, Lisandro Damián Nicanor Pérez Meyer wrote:
> Oh, I have sadly forgotten to mention another thing.
>
> On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
> wrote:
>> # __FILE__ is a public, well defined API
>
> According to:
> Adrian Bunks mentions it in
> https://bugs.
Hi!
On Sat, 9 Jan 2021 at 16:39, Samuel Thibault wrote:
>
> Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
> ecrit:
> > # __FILE__ is a public, well defined API
>
> ? My copy of C11 says
>
> “
> __FILE__ The presumed name of the current source file (a character stri
Hi!
On Sat, 9 Jan 2021 at 16:52, Mattia Rizzolo wrote:
>
> On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote:
> > Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300,
> > a ecrit:
> > > # __FILE__ is a public, well defined API
> >
> > ? My copy of C11 says
> >
On Sat, Jan 09, 2021 at 08:37:48PM +0100, Samuel Thibault wrote:
> Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
> ecrit:
> > # __FILE__ is a public, well defined API
>
> ? My copy of C11 says
>
> “
> __FILE__ The presumed name of the current source file (a charact
Lisandro Damián Nicanor Pérez Meyer, le sam. 09 janv. 2021 15:53:41 -0300, a
ecrit:
> # __FILE__ is a public, well defined API
? My copy of C11 says
“
__FILE__ The presumed name of the current source file (a character string
literal)
”
that's not so well-defined. I would not expect it to nece
Oh, I have sadly forgotten to mention another thing.
On Sat, 9 Jan 2021 at 15:53, Lisandro Damián Nicanor Pérez Meyer
wrote:
> # __FILE__ is a public, well defined API
According to:
Adrian Bunks mentions it in
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=876901#10
Holger Levsen in https://b
Note: in case we do not agree on this topic this will be the text I'll
send to the
tech-ctte.
Let me start by noting that I have nothing against reproducibility. In fact
quite the opposite: I love the idea... as long as it's properly implemented.
The problem here is that __FILE__ is a public, wel
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> In fact most of those packages would not be unreproducible if the
> environment would be the same as the original build. That includes the
> build path.
True, th
On Fri, 8 Jan 2021 at 21:15, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> Hi! Explicitely CCing my bug, since it seems it missed my previous reply.
>
> On Fri, 8 Jan 2021 at 20:49, Guillem Jover wrote:
> >
> > On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer
> > wrote:
Hi! Explicitely CCing my bug, since it seems it missed my previous reply.
On Fri, 8 Jan 2021 at 20:49, Guillem Jover wrote:
>
> On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer
> wrote:
> > [snip]
> > > We did a full archive rebuild testing this change, and I provided
>
On Fri, 2021-01-08 at 19:23:13 -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> [snip]
> > We did a full archive rebuild testing this change, and I provided
> > patches to all known affected packages several months ago. It is a
> > one-line change in debian/rules in most cases:
> >
> >
> > ht
The code that relies on __FILE__ can be found at
https://sources.debian.org/src/qtbase-opensource-src/5.15.2+dfsg-2/src/testlib/qtestcase.h/#L216
So maybe we can try and get a fix there and push this change in the
next stable release, after appropriately tested.
--
Lisandro Damián Nicanor Pérez
Hi!
[snip]
>
> We did a full archive rebuild testing this change, and I provided
> patches to all known affected packages several months ago. It is a
> one-line change in debian/rules in most cases:
>
>
> https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=reproducible-builds%40lists.alioth.de
On 2021-01-08, Lisandro Damián Nicanor Pérez Meyer wrote:
> On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
> wrote:
>>
>> On 2020-11-13, Sune Vuorela wrote:
>> > On 2020-10-27, Vagrant Cascadian wrote:
>> >> Though, of course, identifying the exact reproducibility problem would
>> >> be preferab
On Fri, 8 Jan 2021 at 10:29, Lisandro Damián Nicanor Pérez Meyer
wrote:
>
> Hi! Sorry for this late reply, but it just came into my view.
>
> On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
> wrote:
> >
> > On 2020-11-13, Sune Vuorela wrote:
> > > On 2020-10-27, Vagrant Cascadian wrote:
> > >> T
Hi! Sorry for this late reply, but it just came into my view.
On Fri, 13 Nov 2020 at 17:40, Vagrant Cascadian
wrote:
>
> On 2020-11-13, Sune Vuorela wrote:
> > On 2020-10-27, Vagrant Cascadian wrote:
> >> Though, of course, identifying the exact reproducibility problem would
> >> be preferable.
Guillem Jover wrote:
> > Yes, that's my view too. I had the patch queued in dpkg for my next
> > push, but I've pulled it out for now given the raised concern, but
> > I'm not seeing a very strong case here to not include it again TBH.
>
> Ok, I'm doing this now and will reinstate the patch into t
Hi!
On Mon, 2020-11-16 at 02:33:53 +0100, Guillem Jover wrote:
> On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> > > Adding more hurdles does not help.
> > > I think this is a hurdle we do not need.
> >
> > To me, a one-line change in packaging seems like a quite small hurdle in
On Sat, 2020-11-14 at 11:15:03 -0800, Vagrant Cascadian wrote:
> On 2020-11-14, Sune Vuorela wrote:
> > Unfortunately, only like 10% of the relevant packages have test suites
> > enabled and run, because gettings things to work reliable is sometimes
> > hard.
> So, based on your estimate and the c
On 2020-11-14, Sune Vuorela wrote:
> On 2020-11-13, Vagrant Cascadian wrote:
>> If it could be fixed at the core for QFINDTESTDATA, that would be nicer
>> than fixing 20-30 packages individually, though we're not there right
>> now.
>
> Unfortunately, only like 10% of the relevant packages have te
On 2020-11-13, Sune Vuorela wrote:
> On 2020-10-27, Vagrant Cascadian wrote:
>> Though, of course, identifying the exact reproducibility problem would
>> be preferable. One of the common issues is test suites relying on the
>> behavior of __FILE__ returning a full path to find fixtures or other
>>
Hi
On Mon, 9 Nov 2020 at 22:06, Vagrant Cascadian
wrote:
> Given no objections or concerns of any kind raised in the last two
> weeks, I've submitted a bug against dpkg:
>
> https://bugs.debian.org/974087
There was a query from one of our upstreams in #972294 to which I have
not seen a respons
On 2020-10-27, Vagrant Cascadian wrote:
> The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg
> in 2018.
...
> The result of enabling this feature by default will be to make several
> hundred packages reproducible with varying build-path and reduce the
> diff
The dpkg-buildflags feature reproducible=+fixfilepath was added to dpkg
in 2018.
## What does this feature do exactly?
From the dpkg-buildflags(1) manpage:
fixfilepath
This setting (disabled by default) adds
-ffile-prefix-map=BUILDPATH=. to CFLAGS, CXXFLAGS, OBJCFLAGS
Hi!
On Mon, 2014-08-11 at 10:17:22 +0200, Romain Francoise wrote:
> As of gcc-defaults 1.130 all architectures have moved to GCC 4.9, so we
> can remove the architecture blacklist for stackprotectorstrong.
>
> diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
> index 5223
As of gcc-defaults 1.130 all architectures have moved to GCC 4.9, so we
can remove the architecture blacklist for stackprotectorstrong.
diff --git a/scripts/Dpkg/Vendor/Debian.pm b/scripts/Dpkg/Vendor/Debian.pm
index 5223e0e..f9e8a84 100644
--- a/scripts/Dpkg/Vendor/Debian.pm
+++ b/scripts/Dpkg/Ve
backends,
as each flag is dependent on the specific compiler backend being used.
* It requires not forgetting to pass the compiler variable to the
dpkg-buildflags invocation, or the result will be wrong.
> The following packages build correctly now with this applied:
>
> chromium
Th
On 2014-06-27 17:04, Moritz Mühlenhoff wrote:
> On Tue, Jun 24, 2014 at 09:38:18PM +0200, Niels Thykier wrote:
>>> I think we need a lintian check to gain some traction.
>>
>> Already implemented in 2.5.23 (#711193)[1].
>
> Thanks! Seems I was fooled by outdated lintian results in the PTS.
>
> It
that doesn't get CC/CXX
exported early enough for dpkg-buildflags:
flexc++
gpg-remailer
oxref
Those can be fixed by manually adding CC/CXX in time, e.g.
export CXXFLAGS=$(shell CXX=$(CXX) dpkg-buildflags --get CXXFLAGS)
but that would also require an nmu.
Best wishes,
Mike
diff -Nru dpkg-1.17.10/s
On Wed, Jun 25, 2014 at 07:29:09PM -0400, Michael Gilbert wrote:
> On Tue, Jun 24, 2014 at 10:11 AM, Kees Cook wrote:
> > On Tue, Jun 24, 2014 at 11:29:31AM +0200, Romain Francoise wrote:
> >> Hi,
> >>
> >> GCC 4.9 supports a new stack protector implementation, enabled via the
> >> -fstack-protecto
On Tue, Jun 24, 2014 at 09:38:18PM +0200, Niels Thykier wrote:
> > I think we need a lintian check to gain some traction.
>
> Already implemented in 2.5.23 (#711193)[1].
Thanks! Seems I was fooled by outdated lintian results in the PTS.
It didn't list an error for ploop, while running lintian lo
to be
> fragile and require a lot of maintenance over time.
Version comparison is something computers do incredibly well and
incredibly reliably all the time, so it isn't obvious why it would
suddenly fall apart here. dpkg-buildflags is in perl, but thinking
about it in shell for si
Hi,
On Wed, Jun 25, 2014 at 07:29:09PM -0400, Michael Gilbert wrote:
> Especially when some of them already export either CC=gcc-4.8 or
> CXX=g++-4.8 in debian/rules (like chromium, oxref, and spek), which
> would make it rather convenient to detect the compiler in use.
I've already touched upon
>> I wonder if there is any sensible way for dpkg-buildflags to detect (or
>> maybe just be told) which compile will be used for a build? Perhaps it
>> could take a new argument that would allow it to select flags based on the
>> compiler name and version?
>>
>>
nto the
> archive.
>
>> https://lwn.net/Articles/584225/
>> http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
>> https://fedorahosted.org/fesco/ticket/1128
>>
>> The Security Team has expressed interest in switching dpkg-buildflags
>> over
On Tue, Jun 24, 2014 at 12:21:56PM +0200, Guillem Jover wrote:
> I'd appreciate if you could send a mail to debian-devel for a heads-up
> and to look for input from other people in case there's any possible
> known showstopper.
Done: https://lists.debian.org/debian-devel/2014/06/msg00453.html
--
PTIONS=hardening=+all
eval $(/usr/bin/dpkg-buildflags --export=sh)
fi
exec /usr/bin/cc $CPPFLAGS $CFLAGS "$@"
--
Romain Francoise
http://people.debian.org/~rfrancoise/
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Tr
On 2014-06-24 18:37, Moritz Muehlenhoff wrote:
> On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote:
>> Though really hardening-wrapper should be
>> deprecated for Jessie.
>
> I looked into it, but the number of packages using -wrapper or
> -includes is too large to do this realistically. R
Moritz Muehlenhoff writes:
> On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote:
>> Though really hardening-wrapper should be deprecated for Jessie.
> I looked into it, but the number of packages using -wrapper or
> -includes is too large to do this realistically. Rather for
> jessie+1.
On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote:
> Though really hardening-wrapper should be
> deprecated for Jessie.
I looked into it, but the number of packages using -wrapper or
-includes is too large to do this realistically. Rather for
jessie+1.
I think we need a lintian check to g
On Tue, Jun 24, 2014 at 06:33:33PM +0200, Romain Francoise wrote:
> On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote:
> > I wonder if there is any sensible way for dpkg-buildflags to detect (or
> > maybe just be told) which compile will be used for a build? Perhaps it
>
On Tue, Jun 24, 2014 at 07:11:58AM -0700, Kees Cook wrote:
> I wonder if there is any sensible way for dpkg-buildflags to detect (or
> maybe just be told) which compile will be used for a build? Perhaps it
> could take a new argument that would allow it to select flags based on the
> c
On Tue, Jun 24, 2014 at 12:21:56PM +0200, Guillem Jover wrote:
>> * false positives:
>> - gcc-4.7 4.7.4-1 (checks that dpkg-dev is 'ii')
>
> For what purpose?
By way of getting dpkg-dev's installed version. The changelog suggests
that the dependency cannot be expressed using Build-Depends for re
ives/2014/01/27/fstack-protector-strong/
> https://fedorahosted.org/fesco/ticket/1128
>
> The Security Team has expressed interest in switching dpkg-buildflags
> over to this new flag in Debian for jessie, now that GCC 4.9 is the
> default compiler on all release architectures. In order t
> The Security Team has expressed interest in switching dpkg-buildflags
> over to this new flag in Debian for jessie, now that GCC 4.9 is the
> default compiler on all release architectures. In order to see the
> impact on the archive, David Suárez did a full rebuild on EC2 wit
e the following for more information:
https://lwn.net/Articles/584225/
http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/
https://fedorahosted.org/fesco/ticket/1128
The Security Team has expressed interest in switching dpkg-buildflags
over to this new flag in Debian for j
in the toolchain that these flags need to be passed
at all, and I've not run into any cases where passing them confuses the
native toolchain into doing the wrong thing.
> So, is there a way to make dpkg-buildflags arch-specific, so they are
> picked up for one CC and not another?
There
Hi!
On Wed, 2012-11-21 at 19:09:34 +, Wookey wrote:
> I've been using dpkg-buildflags to nobble the link path and
> rpath-link LDFLAGS setting because the current cross-toolchain for
> arm64 does not get these right by default (and it doesn't have libssp).
As you mention
I've been using dpkg-buildflags to nobble the link path and
rpath-link LDFLAGS setting because the current cross-toolchain for
arm64 does not get these right by default (and it doesn't have libssp).
This works pleasingly well (I've only found a couple of packages that
don't ho
variables
(CFLAGS etc.) does not have the expected value.
A possible solution would be to modify /usr/share/dpkg/buildflags.mk to
use the variables when running the shell command, for ex using something
like:
DEB_BUILD_MAINT_OPTIONS="$(DEB_BUILD_MAINT_OPTIONS)" dpkg-buildflags
This wou
(Are you subscribed to debian-dpkg? Because mail-followup-to drops you
and yet you did not reply to my initial -dpkg mail where I asked for
feedback but only to the one who was copied to -ctte)
On Mon, 01 Aug 2011, Bernhard R. Link wrote:
> > Performance. If the variables are not used, there's no
* Raphael Hertzog [110801 08:58]:
> On Sun, 31 Jul 2011, Bernhard R. Link wrote:
> > While I wholeheartly welcome adding such a script, I am surprised why
> > it is made so complicated and hard to read.
> >
> > Is there a reason for dpkg_late_eval?
>
> Performance. If the variables are not used, t
Hi,
On Sun, 31 Jul 2011, Bernhard R. Link wrote:
> While I wholeheartly welcome adding such a script, I am surprised why
> it is made so complicated and hard to read.
>
> Is there a reason for dpkg_late_eval?
Performance. If the variables are not used, there's no subprocess
executed. And once it
mply
CFLAGS := $(shell dpkg-buildflags --get CFLAGS)
and so on in buildflags.mk and
DEB_HOST_ARCH := $(shell dpkg-architecture -qDEB_HOST_ARCH)
and so on in architecture.mk?
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsu
On Wed, Jul 27, 2011 at 12:55:04AM +0200, Raphael Hertzog wrote:
> On Tue, 26 Jul 2011, Raphael Hertzog wrote:
> > We evaluated how dpkg-buildflags can be used for this. For most
> > autoconf/automake-based build systems there are 2 ways to inject flags:
> > 1/ On the ./c
On Tue, 26 Jul 2011, Raphael Hertzog wrote:
> We evaluated how dpkg-buildflags can be used for this. For most
> autoconf/automake-based build systems there are 2 ways to inject flags:
> 1/ On the ./configure command line:
> ./configure --with-foo CFLAGS="..." LDFLAGS
Hi,
On Mon, 07 Jun 2010, Raphael Hertzog wrote:
> > * If packages should set all the flags, have you considered having a
> > mode where it lists them all (like dpkg-architecture -l), perhaps
> > with export statements?
>
> Would you like this? I have no problem addin
;.
>> >>
>> >>
>> >> How do you get make to honor line breaks in $(eval ...)?
>> >
>> > gah, make is annoying. Well there is always the possibility:
>> >
>> > -include dpkg-buildflags.mk
>> > dpkg-buildflags.mk:
>> &
eaks in $(eval ...)?
> >
> > gah, make is annoying. Well there is always the possibility:
> >
> > -include dpkg-buildflags.mk
> > dpkg-buildflags.mk:
> > $(shell dpkg-buildflags --export=make) > $@
> >
> > Which is probably a hell of a lot simpler
gt; FOO=1 BAR=2
>> BAR=
>> make: Nothing to be done for `all'.
>>
>>
>> How do you get make to honor line breaks in $(eval ...)?
>
> gah, make is annoying. Well there is always the possibility:
>
> -include dpkg-buildflags.mk
> dpkg-buildflags.
e where it lists them all (like dpkg-architecture -l), perhaps
> >> > with export statements?
> >>
> >> Would you like this? I have no problem adding this feature to
> >> dpkg-buildflags.
> >
> > That would be very useful, and you want it to be suitab
ts?
>>
>> Would you like this? I have no problem adding this feature to
>> dpkg-buildflags.
>
> That would be very useful, and you want it to be suitable for $(eval).
>
> It's likely that you will have to support various escapings for it to be
> suitable f
e no problem adding this feature to
> dpkg-buildflags.
That would be very useful, and you want it to be suitable for $(eval).
It's likely that you will have to support various escapings for it to be
suitable for sh eval, make eval, and maybe other languages.
something like:
dpkg-bui
Raphael Hertzog writes:
> Hi Joey,
>
> On Sun, 06 Jun 2010, Joey Hess wrote:
>> Some questions I have..
>>
>> * Do you anticipate adding more flags later? [1]
>
> Possibly yes, although they might not necessarily be among the flags you
> listed.
>
Hi Joey,
On Sun, 06 Jun 2010, Joey Hess wrote:
> Some questions I have..
>
> * Do you anticipate adding more flags later? [1]
Possibly yes, although they might not necessarily be among the flags you
listed.
Ubuntu uses dpkg-buildflags to export supplementary variables related to
their
Some questions I have..
* Do you anticipate adding more flags later? [1]
* Do you think it would be a good idea for packages to set all flags
dpkg-buildflags supports?
* If packages should set all the flags, have you considered having a
mode where it lists them all (like dpkg-architecture
Pass the entire Dpkg::BuildFlags object to update-buildflags, so that
hooks can use its set() method rather than setting hash elements
directly.
---
scripts/Dpkg/BuildFlags.pm |2 +-
scripts/Dpkg/Vendor/Default.pm |8
scripts/Dpkg/Vendor/Ubuntu.pm |3 +--
3 files changed
On Sun, 28 Mar 2010, Raphael Geissert wrote:
> What do you and the other readers think about that use case?
You are reinventing pkg-config I think. It's not really needed.
> > - which can be overriden/expanded by the user with
> > ~/.config/dpkg-buildflags
> > (doe
how to implement what at the moment I'm
>> calling 'dpkg-buildflags' but was not sure how it was decided it should
>> pass the flags to debian/rules.
>>
>> I'm thinking about having a global (/etc/dpkg/buildflags{,.d}) config and
>> a local
On Sat, 20 Mar 2010, Manoj Srivastava wrote:
> > There should be:
> > - the default value provided by dpkg
> > - which can be overriden/expanded system-wide with
> > /etc/dpkg/buildflags (no .d, I don't think it's wise to let random
> > packages modify t
at the moment
>> I'm calling 'dpkg-buildflags' but was not sure how it was decided it
>> should pass the flags to debian/rules.
>>
>> I'm thinking about having a global (/etc/dpkg/buildflags{,.d}) config
>> and a local one (~/.dpkg-buildflags I gu
Hi,
let's have the discussion on the list please. Other people can have useful
feedback on the design too.
On Fri, 19 Mar 2010, Raphael Geissert wrote:
> Yesterday I was writing a plan on how to implement what at the moment I'm
> calling 'dpkg-buildflags' but was not
81 matches
Mail list logo
