On Wed, Feb 26, 2014 at 02:24:01PM +0100, Jakub Wilk wrote:
> * Thorsten Glaser , 2014-02-26, 12:54:
> >To add insult to injury, buildd/sbuild currently hardcode both
> >--apt-update --no-apt-dist-upgrade
>
> My sbuild.conf contains this:
>
> # APT_DISTUPGRADE
> # Type: BOOL
> # APT distupgrade.
* Peter Samuelson , 2014-02-26, 09:15:
And if there are any cases even more exotic (you need to restrict the
arch but _not_ because of build-dep availability):
Build-Conflicts-Indep: build-essential [!i386]
To be pedantically correct, one should conflict with a build-essential
package (su
On Thu, Feb 27, 2014 at 7:51 AM, William Grant wrote:
> I'd probably define "Build-Indep-Architecture: armhf armel" to mean
> "build with -A on armhf if you have it, otherwise armel, otherwise
> nowhere". But maybe it would be better for "otherwise nowhere" to be
> "otherwise anywhere"?
You could
On 27/02/14 00:39, Paul Tagliamonte wrote:
> On Wed, Feb 26, 2014 at 01:11:55PM +, Thorsten Glaser wrote:
>> First, we need new syntax to specify the architectures an arch:all
>> package may be built on. (There may be cases where this cannot be
>> deducted from the other binary packages it buil
[Paul Tagliamonte]
> I was going to send a mail about this yesterday. I've decided
> I'm going to start a quest to support this. I settled on
> Build-Indep-Architecture myself.
Sorry for the bikeshedding, but don't we already have ways to express
exactly what we mean?
Build-Depends-Indep: so
Hi,
Le 26/02/2014 15:55, Jakub Wilk a écrit :
> * Paul Tagliamonte , 2014-02-26, 08:39:
>>> First, we need new syntax to specify the architectures an arch:all
>>> package may be built on. (There may be cases where this cannot be
>>> deducted from the other binary packages it builds – if any. Heck,
On Wed, Feb 26, 2014 at 03:55:37PM +0100, Jakub Wilk wrote:
> >BTW; the syntax would define a single arch; you know, in the
> >spirit of reproducability.
>
> I have mixed feeling about this. On one hand, most[0] of arch:all
> packages can be built on more than one architecture, so “single
> arch”
* Paul Tagliamonte , 2014-02-26, 08:39:
First, we need new syntax to specify the architectures an arch:all
package may be built on. (There may be cases where this cannot be
deducted from the other binary packages it builds – if any. Heck,
there may even be cases where a source package has multi
On Wed, Feb 26, 2014 at 01:11:55PM +, Thorsten Glaser wrote:
> First, we need new syntax to specify the architectures an arch:all
> package may be built on. (There may be cases where this cannot be
> deducted from the other binary packages it builds – if any. Heck,
> there may even be cases whe
* Thorsten Glaser , 2014-02-26, 12:54:
To add insult to injury, buildd/sbuild currently hardcode both
--apt-update --no-apt-dist-upgrade
My sbuild.conf contains this:
# APT_DISTUPGRADE
# Type: BOOL
# APT distupgrade. 1 to enable running "apt-get dist-upgrade" at the start
# of each build, or
Carlos Alberto Lopez Perez igalia.com> writes:
> On 13/02/14 22:10, Dimitri John Ledkov wrote:
> > All that's needed, I guess, is for someone to write a patch to dak /
> > wanna-build ... and schedule _all.deb builds on amd64 ?
> > Or if arch-restricted package, on one of the arches it will buil
Paul Tagliamonte debian.org> writes:
>
> On Fri, Feb 14, 2014 at 04:39:25PM +0100, Wouter Verhelst wrote:
> > > Are buildd people happy with humans sending their logs this way?
> >
> > Well, I am, but it's probably not my call.
>
> Which keyring does it use to validate? Can DMs send logs? Does
Sam Hartman debian.org> writes:
[ autotools ]
> I assure you, that even if you get past the being blind bit, it's still
> impossible to figure out what's going on.
And even then, even when you did the unbelievable and, say, ported libtool
to MirBSD and Interix (consuming a whole bottle of wine i
Andrey Rahmatullin wrar.name> writes:
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> Isn't that one of problems fixed by rebuilding everything on buil
On Thu, Feb 13, 2014 at 10:17:46PM +0100, Holger Levsen wrote:
> nope, it's worse than you think: the arch specific package built on the
> developers machine (in a "random"^wnon predicatable environment) will not be
> rebuild, there are also no build logs available.
>
> See https://buildd.debian
On 13/02/14 22:10, Dimitri John Ledkov wrote:
> On 13 February 2014 16:13, Holger Levsen wrote:
>> > Hi,
>> >
>> > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
>>> >> this is just a pledge to you all fellow debian developers to update your
>>> >> build environment before you build a package
I'd like to chime in on this whole build thing.
I've been trying to get pbuilder working for a few days now, on a package
from backports. It should be a simple task, but I need a minor modification
in the form of an extra repository for dependencies.
It's been incredibly difficult to get the packa
On 2014-02-15 15:34, Henrique de Moraes Holschuh wrote:
On Sat, 15 Feb 2014, Philipp Kern wrote:
That's why I was careful to publish the address nowhere. We do some
Unfortunately, that cat is out of the bag, now. Whether it will get
spammed
or attacked, I don't know.
However, it is not lik
* Philipp Kern , 2014-02-15, 15:19:
Are buildd people happy with humans sending their logs this way?
Well, I am, but it's probably not my call.
Which keyring does it use to validate? Can DMs send logs? Does it
validate at all, or can some script kiddies use it as a pastebin
service? :)
That's
On Sat, 15 Feb 2014, Philipp Kern wrote:
> That's why I was careful to publish the address nowhere. We do some
Unfortunately, that cat is out of the bag, now. Whether it will get spammed
or attacked, I don't know.
However, it is not like we ever could trust the logs anyway for any security
purpo
On 2014-02-14 16:42, Paul Tagliamonte wrote:
On Fri, Feb 14, 2014 at 04:39:25PM +0100, Wouter Verhelst wrote:
> Are buildd people happy with humans sending their logs this way?
Well, I am, but it's probably not my call.
Which keyring does it use to validate? Can DMs send logs? Does it
validate
previously on this list Brian May contributed:
> After the damage is done, probably easier to find the malware that did it
Assuming the damage is visible?
> All rants aside, I believe there's a fairly wide agreement that we
> should throw away binaries from builds.
>> I'd encourage something
On Fri, Feb 14, 2014 at 10:42:16AM -0500, Paul Tagliamonte wrote:
> Which keyring does it use to validate? Can DMs send logs? Does it
> validate at all, or can some script kiddies use it as a pastebin
> service? :)
The logs aren't signed, so it only validates the Subject line.
This has been un-abu
On Fri, Feb 14, 2014 at 04:39:25PM +0100, Wouter Verhelst wrote:
> > Are buildd people happy with humans sending their logs this way?
>
> Well, I am, but it's probably not my call.
Which keyring does it use to validate? Can DMs send logs? Does it
validate at all, or can some script kiddies use it
On Fri, Feb 14, 2014 at 02:10:38PM +0100, Jakub Wilk wrote:
> * Wouter Verhelst , 2014-02-14, 14:01:
> >>I'm told there's at least some magic address you can mail the
> >>logs to, but I never remember what it is. (It's all a
> >>workaround anyway.)
> >
> >l...@buildd.debian.org
> >
> >The mail's s
* Wouter Verhelst , 2014-02-14, 14:01:
I'm told there's at least some magic address you can mail the logs to,
but I never remember what it is. (It's all a workaround anyway.)
l...@buildd.debian.org
The mail's subject has to be in the format that buildd uses, though:
Subject: Log for successf
On Thu, Feb 13, 2014 at 11:52:01PM +, Colin Watson wrote:
> On Thu, Feb 13, 2014 at 10:17:46PM +0100, Holger Levsen wrote:
> > See https://buildd.debian.org/status/package.php?p=html2text - you can only
> > hope that I've build it in a clean environment and there aint a logfile for
> > the am
On 2/14/14, Paul Tagliamonte wrote:
> On Fri, Feb 14, 2014 at 04:44:21AM +, Jacob Appelbaum wrote:
>> Heya Sam,
>>
>> On 2/14/14, Sam Hartman wrote:
>> > All rants aside, I believe there's a fairly wide agreement that we
>> > should throw away binaries from builds.
>>
>> I'd encourage somethi
On Fri, Feb 14, 2014 at 04:44:21AM +, Jacob Appelbaum wrote:
> Heya Sam,
>
> On 2/14/14, Sam Hartman wrote:
> > All rants aside, I believe there's a fairly wide agreement that we
> > should throw away binaries from builds.
>
> I'd encourage something slightly different and then I'd expand on
Heya Sam,
On 2/14/14, Sam Hartman wrote:
> All rants aside, I believe there's a fairly wide agreement that we
> should throw away binaries from builds.
I'd encourage something slightly different and then I'd expand on it a bit.
I think it would be useful to have an historical archive of each
bi
All rants aside, I believe there's a fairly wide agreement that we
should throw away binaries from builds.
I seem to recall ftp-master sending out mail to debian-devel-announce
describing the steps along that process a while ago.
I think it's fine to ask where that project is, and to volunteer
re
On 14 February 2014 05:46, Jakub Wilk wrote:
> How many uploaded binaries might include malware?
>>
>
> *shrug* It's not like it's difficult to hide malicious code in source
> packages.
>
After the damage is done, probably easier to find the malware that did it
if you can rely on the source code
On 13 February 2014 21:17, Holger Levsen wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Dimitri John Ledkov wrote:
>> All that's needed, I guess, is for someone to write a patch to dak /
>> wanna-build ... and schedule _all.deb builds on amd64 ?
>> Or if arch-restricted package, on one of the a
On Thu, Feb 13, 2014 at 10:17:46PM +0100, Holger Levsen wrote:
> See https://buildd.debian.org/status/package.php?p=html2text - you can only
> hope that I've build it in a clean environment and there aint a logfile for
> the amd64 build of that arch:any package.
I'm told there's at least some ma
> "Colin" == Colin Watson writes:
Colin> On Thu, Feb 13, 2014 at 07:46:53PM +0100, Jakub Wilk wrote:
>> *shrug* It's not like it's difficult to hide malicious code in
>> source packages.
>>
>> How many configure scripts that we never rebuild from source
>> contains tr
On 2/13/14, Jakub Wilk wrote:
> * Jacob Appelbaum , 2014-02-13, 18:36:
>>How many uploaded binaries might include malware?
>
> *shrug* It's not like it's difficult to hide malicious code in source
> packages.
>
It is much harder for you to hide source code changes as a third party
than binary cha
On 14/02/14 08:13, Paul Tagliamonte wrote:
> On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
>> On 13 February 2014 16:13, Holger Levsen wrote:
>>> Hi,
>>>
>>> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
this is just a pledge to you all fellow debian developers to
On Thu, Feb 13, 2014 at 4:13 PM, Paul Tagliamonte wrote:
> On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
> > On 13 February 2014 16:13, Holger Levsen wrote:
> > > Hi,
> > >
> > > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> > >> this is just a pledge to you all fel
Hi,
On Donnerstag, 13. Februar 2014, Dimitri John Ledkov wrote:
> All that's needed, I guess, is for someone to write a patch to dak /
> wanna-build ... and schedule _all.deb builds on amd64 ?
> Or if arch-restricted package, on one of the arches it will build on?
nope, it's worse than you think:
On Thu, Feb 13, 2014 at 09:10:15PM +, Dimitri John Ledkov wrote:
> On 13 February 2014 16:13, Holger Levsen wrote:
> > Hi,
> >
> > On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> >> this is just a pledge to you all fellow debian developers to update your
> >> build environment before you
On Thu, Feb 13, 2014 at 07:46:53PM +0100, Jakub Wilk wrote:
> *shrug* It's not like it's difficult to hide malicious code in
> source packages.
>
> How many configure scripts that we never rebuild from source
> contains trojans?
Just like my favourite Russ quote:
Basically, people got tired of
On 13 February 2014 16:13, Holger Levsen wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
>> this is just a pledge to you all fellow debian developers to update your
>> build environment before you build a package.
>
> I want all binary packages to be rebuild on *.debian.org ho
(note to myself: you sound really grumpy after reading bikesheds)
On Thu, Feb 13, 2014 at 04:31:36PM +0100, Andreas Beckmann wrote:
> On 2014-02-13 15:37, Ondřej Surý wrote:
> > On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
> >> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wro
* Jacob Appelbaum , 2014-02-13, 18:36:
How many uploaded binaries might include malware?
*shrug* It's not like it's difficult to hide malicious code in source
packages.
How many configure scripts that we never rebuild from source contains
trojans?
--
Jakub Wilk
--
To UNSUBSCRIBE, email
On Thu, Feb 13, 2014 at 06:36:15PM +, Jacob Appelbaum wrote:
> No kidding!
>
> How many uploaded binaries might include malware?
>
> A lack of binary determinism in the build process basically ensures
> that it isn't feasible to discover an answer to this question. :(
>
> All the best,
> Jac
No kidding!
How many uploaded binaries might include malware?
A lack of binary determinism in the build process basically ensures
that it isn't feasible to discover an answer to this question. :(
All the best,
Jacob
On 2/13/14, Holger Levsen wrote:
> Hi,
>
> On Donnerstag, 13. Februar 2014, On
Hi,
On Donnerstag, 13. Februar 2014, Ondřej Surý wrote:
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.
I want all binary packages to be rebuild on *.debian.org hosts. Everything
else is just an ugly workaround.
amen,
On 2014-02-13 15:37, Ondřej Surý wrote:
> On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
>> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
>> Broken libdb5.3-dev:amd64 Conflicts on libdb5.1-dev [ amd64 ] < 5.1.29-7
>>> ( libdevel )
>> Considering libdb5.1-dev:amd64 -1 as
On Thu, Feb 13, 2014, at 15:00, David Kalnischkies wrote:
>
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> >
> > This mostly affects transitions, f.e.:
On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.
>
> This mostly affects transitions, f.e.:
>
> https://release.debian.org/transitions/html/db5.3.html
The probl
On Thu, Feb 13, 2014, at 13:45, Andrey Rahmatullin wrote:
> On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> > Hi,
> >
> > this is just a pledge to you all fellow debian developers to update your
> > build environment before you build a package.
> >
> > This mostly affects transitio
On Thu, Feb 13, 2014 at 01:38:51PM +0100, Ondřej Surý wrote:
> Hi,
>
> this is just a pledge to you all fellow debian developers to update your
> build environment before you build a package.
>
> This mostly affects transitions, f.e.:
>
> https://release.debian.org/transitions/html/db5.3.html
>
Hi,
this is just a pledge to you all fellow debian developers to update your
build environment before you build a package.
This mostly affects transitions, f.e.:
https://release.debian.org/transitions/html/db5.3.html
apt, heimdal, jack-audio-connection-kit, python3.3, python3.4 and
squidguard c
53 matches
Mail list logo
