On Tue, Jul 21, 2020 at 9:28 AM Wouter Verhelst wrote:
> The reason we don't do this is because of bootstrapping: some tools
> require themselves to build, so you need to cross-build them on a
> different architecture, upload the cross-built binary, get an exception
> for that upload, and then re-
Quoting mat...@debian.org (2020-07-21 11:35:30)
> On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote:
> > The reason we don't do this is because of bootstrapping: some tools
> > require themselves to build, so you need to cross-build them on a
> > different architecture, upload the cro
On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote:
> The reason we don't do this is because of bootstrapping: some tools
> require themselves to build, so you need to cross-build them on a
> different architecture, upload the cross-built binary, get an exception
> for that upload, and
On Tue, Jul 21, 2020 at 11:11:13AM +0200, Wouter Verhelst wrote:
> On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote:
> > Personally, I think we should discard binaries from all sourceful
> > uploads and only accept binaries from binary-only uploads such as the
> > uploads done by the build
On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote:
> Personally, I think we should discard binaries from all sourceful
> uploads and only accept binaries from binary-only uploads such as the
> uploads done by the buildds.
The reason we don't do this is because of bootstrapping: some tools
On Wed, Jul 15, 2020 at 01:33:10PM +, Paul Wise wrote:
> > > So we have the buildds installing packages from snapshot.d.o based on
> > > what the maintainer built the package with?
> > no(t yet?)
> I'm confused, Thomas proposed that packages are rejected unless the
> buildd binaries are identic
On Wed, Jul 15, 2020 at 12:45 PM Holger Levsen wrote:
> On Wed, Jul 15, 2020 at 12:41:00PM +, Paul Wise wrote:
> > So we have the buildds installing packages from snapshot.d.o based on
> > what the maintainer built the package with?
>
> no(t yet?)
>
> also: s#what the maintainer built the packa
On Wed, Jul 15, 2020 at 12:41:00PM +, Paul Wise wrote:
> So we have the buildds installing packages from snapshot.d.o based on
> what the maintainer built the package with?
no(t yet?)
also: s#what the maintainer built the package with#what the packages was built
with#
--
cheers,
H
On Wed, Jul 15, 2020 at 11:22 AM Holger Levsen wrote:
> debrebuild from src:devscripts can create an sbuild commandline to install
> exactly the build depends which were installed in the build which is about
> to be rebuild, using the data from the .buildinfo file.
So we have the buildds installi
On Wed, Jul 15, 2020 at 02:37:26AM +, Paul Wise wrote:
> On Tue, Jul 14, 2020 at 4:06 PM Thomas Goirand wrote:
> > Better: we must mandate binary uploads, rebuild them, and make sure they
> > are reproducible. Then get the buildd upload the binary they build (or
> > the one from the uploader, s
On Tue, Jul 14, 2020 at 4:06 PM Thomas Goirand wrote:
> Better: we must mandate binary uploads, rebuild them, and make sure they
> are reproducible. Then get the buildd upload the binary they build (or
> the one from the uploader, since that's the same thing...).
>
> When the package isn't reprodu
Hi Michael,
> I just fell into the trap (again) and uploaded a binary package instead of
> sources only. We don't want the binaries to be uploaded, that much I get, but
> could anyone please explain to me, why we still accept binary uploads and why
> no tool in the whole chain gives as much as a w
On 7/14/20 3:55 PM, Michael Meskes wrote:
> Hi,
>
> I just fell into the trap (again) and uploaded a binary package instead of
> sources only. We don't want the binaries to be uploaded, that much I get, but
> could anyone please explain to me, why we still accept binary uploads and why
> no tool i
On 7/14/20 4:21 PM, Paul Wise wrote:
> On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote:
>
>> I just fell into the trap (again) and uploaded a binary package instead of
>> sources only. We don't want the binaries to be uploaded, that much I get, but
>> could anyone please explain to me, why we
On Tue, Jul 14, 2020 at 2:56 PM Michael Meskes wrote:
>
> Hi,
>
> I just fell into the trap (again) and uploaded a binary package instead of
> sources only. We don't want the binaries to be uploaded, that much I get, but
> could anyone please explain to me, why we still accept binary uploads and w
> Personally, I think we should discard binaries from all sourceful
> uploads and only accept binaries from binary-only uploads such as the
> uploads done by the buildds.
>
> https://lists.debian.org/msgid-search/5ec2e979cd7d7ec9bf386fbf77e3399c7aeeb473.ca...@debian.org
Agreed, that would be the
> You still need to produce binary packages unfortunately if you
> upload
> something to NEW or binary-NEW.
Sure, but that could be checked for as well.
Michael
--
Michael Meskes
Michael at Fam-Meskes dot De, Michael at Meskes dot (De|Com|Net|Org)
Meskes at (Debian|Postgresql) dot Org
Jabber:
On Tue, Jul 14, 2020 at 02:21:30PM +, Paul Wise wrote:
> On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote:
>
> > I just fell into the trap (again) and uploaded a binary package instead of
> > sources only. We don't want the binaries to be uploaded, that much I get,
> > but
> > could anyon
On Tue, Jul 14, 2020 at 15:55, Michael Meskes wrote:
Hi,
I just fell into the trap (again) and uploaded a binary package
instead of
sources only. We don't want the binaries to be uploaded, that much I
get, but
could anyone please explain to me, why we still accept binary uploads
and why
n
On Tue, 14 Jul 2020, Michael Meskes wrote:
I just fell into the trap (again) and uploaded a binary package instead of
sources only. We don't want the binaries to be uploaded, that much I get, but
could anyone please explain to me, why we still accept binary uploads and why
no tool in the whole c
On Tue, Jul 14, 2020 at 1:56 PM Michael Meskes wrote:
> I just fell into the trap (again) and uploaded a binary package instead of
> sources only. We don't want the binaries to be uploaded, that much I get, but
> could anyone please explain to me, why we still accept binary uploads and why
> no to
On Fri, 17 Jan 2020 at 18:08:59 +0530, Pirate Praveen wrote:
> I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild -s
> --source-only-changes
That doesn't mean what you think it does. My understanding is that the
profiles only affect the binaries that *you* built, which were omit
Am Sonntag, den 06.10.2019, 22:09 +0200 schrieb Bernd Zeimetz:
> Hi,
>
> > I'm struggling with it for a while now and I couldn't find the solution.
> > I have a package maintained with git-buildpackage. And now, that I
> > "cannot" upload binary packages I tried to compile the new version with
> >
Am Sonntag, den 06.10.2019, 11:27 +0200 schrieb Alf Gaida:
> On 06.10.19 08:18, Attila Szalay wrote:
> > That option means that the system will create not only the binary
> > .amd.changes but another changes too which contains only the source
> > packages. And I would like to use this method to be
On 10/6/19 11:15 PM, PICCA Frederic-Emmanuel wrote:
> And what about
>
> dgit --gbp push-source ?
not going to touch that. dgit is imho way to over-engineered while
having requirements at the same time, that I don't want to have (like
using dgit.debian.org...).
We have salsa as central reposit
Hi,
> I'm struggling with it for a while now and I couldn't find the solution.
> I have a package maintained with git-buildpackage. And now, that I
> "cannot" upload binary packages I tried to compile the new version with
> the option to create a source-only changes file too. But for some reason
>
On Sun, Oct 6, 2019 at 6:27 PM Alf Gaida wrote:
>
> On 06.10.19 08:18, Attila Szalay wrote:
> > That option means that the system will create not only the binary
> > .amd.changes but another changes too which contains only the source
> > packages. And I would like to use this method to be sure the
On 06.10.19 08:18, Attila Szalay wrote:
> That option means that the system will create not only the binary
> .amd.changes but another changes too which contains only the source
> packages. And I would like to use this method to be sure the package
> compiles, to be able to run the lintian agains
That option means that the system will create not only the binary
.amd.changes but another changes too which contains only the source
packages. And I would like to use this method to be sure the package
compiles, to be able to run the lintian against the package and even be
able to test it before t
On 05.10.19 23:14, Andrey Rahmatullin wrote:
> On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote:
that is miss something - my point is: Why do you invoke pbuilder (read
the same question about sbuild too) to create pure source packages?
>>> To make sure they build correctly.
>>>
On Sat, Oct 05, 2019 at 10:02:54PM +0200, Alf Gaida wrote:
> >> that is miss something - my point is: Why do you invoke pbuilder (read
> >> the same question about sbuild too) to create pure source packages?
> > To make sure they build correctly.
> >
> Ok, checked the calender, it is not April 1. I
On 05.10.19 21:48, Andrey Rahmatullin wrote:
> On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote:
>> that is miss something - my point is: Why do you invoke pbuilder (read
>> the same question about sbuild too) to create pure source packages?
> To make sure they build correctly.
>
Ok, che
On Sat, Oct 05, 2019 at 08:06:56PM +0200, Alf Gaida wrote:
> that is miss something - my point is: Why do you invoke pbuilder (read
> the same question about sbuild too) to create pure source packages?
To make sure they build correctly.
--
WBR, wRAR
signature.asc
Description: PGP signature
On 05.10.19 19:48, Attila Szalay wrote:
> Hi,
>
> I'm struggling with it for a while now and I couldn't find the
> solution. I have a package maintained with git-buildpackage. And now,
> that I "cannot" upload binary packages I tried to compile the new
> version with the option to create a source
34 matches
Mail list logo
