ses.php?package=libcbor
> >
> > Issues preventing migration:
> >
> > Not built on buildd: arch amd64 binaries uploaded by bernat
> > Not built on buildd: arch all binaries uploaded by bernat, a new
> > source-only upload is needed to allow migration
>
It would be lovely to get this enabled! It's a pain point for me also, on
occasion.
-Steve
On Fri, Sep 15, 2023 at 11:29:27PM +0200, Vincent Bernat wrote:
> What's the status of throwing away the binaries when doing a non-source-only
> upload?
it's an existing feature of dak waiting to be enabled by ftp-master. I'd guess
that nowish would be a good time to en
on buildd: arch all binaries uploaded by bernat, a new
source-only upload is needed to allow migration
What's the status of throwing away the binaries when doing a
non-source-only upload? This is a major pain point for me. You upload
the package a first time as a source-only upload and g
> > packages that did not migrate to Debian Testing solely because of
> > having a non-source-only upload [1]. This especially applies to
> > arch:all packages since binNMU is still not possible yet.
> >
> > Since we are now months before the projected release freeze, it
Hi Boyuan,
On 21-10-2020 18:45, Boyuan Yang wrote:
> Looking into https://release.debian.org/britney/update_excuses.html and
> searching "source-only", you can find tens of (if not hundreds of)
> packages that did not migrate to Debian Testing solely because of
> having a
Hi all,
Looking into https://release.debian.org/britney/update_excuses.html and
searching "source-only", you can find tens of (if not hundreds of)
packages that did not migrate to Debian Testing solely because of
having a non-source-only upload [1]. This especially applies to
arch:al
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-
gt; be more than enough to do what you say.
https://wiki.debian.org/BuildProfileSpec#The_Built-For-Profiles_field
Built-For-Profiles: nopython
Ideally, a source-only upload would happen, some component would analyze the
build-profiles annotation and figure out in which order to build packages so
that
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
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 in the whole chain gives as much as a warning, let alon
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
Hi,
I tried uploading node-webpack with DEB_BUILD_PROFILES=nocheck sbuild
-s --source-only-changes
https://tracker.debian.org/news/1094664/accepted-node-webpack-4300-2-source-into-experimental/
But it seems the buildd did not consider Built-For-Profiles: nocheck in
the source.changes file. I
On 11/11/19 6:30 PM, Theodore Y. Ts'o wrote:
> Yes, and that's why I use debian/master instead of debian/buster or
> debian/bullseye. :-)
>
> When I do create debian/buster (once it became the stable branch), the
> first thing I did after I branched off debian/buster from
> debian/master was t
On 11/14/19 1:59 AM, Jeremy Bicha wrote:
> Let me try to be more specific. Many packages are maintained by people
> who use gbp. Many packages have pristine-tar branches but do not have
> "pristine-tar = True" set. When I work on one of these packages (and I
> work on many packages with many mainta
On Wed, 13 Nov 2019 at 19:59:07 -0500, Jeremy Bicha wrote:
> Let me try to be more specific. Many packages are maintained by people
> who use gbp. Many packages have pristine-tar branches but do not have
> "pristine-tar = True" set. When I work on one of these packages (and I
> work on many package
On Tue, Nov 12, 2019 at 5:23 AM Thomas Goirand wrote:
> On 11/11/19 12:50 PM, Jeremy Bicha wrote:
> > It is absolutely not possible to set the correct
> > pristine-tar=True/False in ~/.gbp.conf to work with your packages
> > (which avoid pristine-tar) and the vast majority of gbp packages in
> > D
On 11/13/19 1:53 PM, Andreas Tille wrote:
> Except for not agreeing with your opinion about pristine-tar I agree that
> debian/gbp.conf is frequently not very helpful and flooded with unneeded
> options sometimes. It really makes sense to use ~/.gbp.conf instead.
This was the single and only poin
On Tue, Nov 12, 2019 at 11:23:08AM +0100, Thomas Goirand wrote:
>
> If you're rebuilding a package which is already in the archive, you're
> supposed to take the .orig.tar.xz from the archive, and if not, you're
> supposed to generate it with git archive (or with the shortcut for that
> command: .
On 11/11/19 12:50 PM, Jeremy Bicha wrote:
> On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote:
>> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
>>> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
Please, *never* do that. It's generally a very bad idea to write
anyt
On Mon, Nov 11, 2019 at 08:58:42AM +0100, Thomas Goirand wrote:
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were adding your text editor
> >> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
> >
>
On Mon, Nov 11, 2019 at 2:59 AM Thomas Goirand wrote:
> On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
> > On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
> >>
> >> Please, *never* do that. It's generally a very bad idea to write
> >> anything to debian/gbp.conf. It's as if you were
On 11/11/19 1:02 AM, Theodore Y. Ts'o wrote:
> On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
>>
>> Please, *never* do that. It's generally a very bad idea to write
>> anything to debian/gbp.conf. It's as if you were adding your text editor
>> preferences in the package. Instead, p
On Sun, Nov 10, 2019 at 11:20:45PM +0100, Thomas Goirand wrote:
>
> Please, *never* do that. It's generally a very bad idea to write
> anything to debian/gbp.conf. It's as if you were adding your text editor
> preferences in the package. Instead, please prefer writing in ~/.gbp.conf.
I keep most
On 10/5/19 7:48 PM, Attila Szalay wrote:
> I added the "pbuilder-options = --source-only-changes" option to the
> [buildpackage] part of the debian/gbp.conf
Please, *never* do that. It's generally a very bad idea to write
anything to debian/gbp.conf. It's as if you were adding your text editor
pre
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
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 that chan
On 20 September 2019 at 13:27, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
| > -build: build-arch
| > +## edd 19 Sep 2019 for source uploads also build build-indep
| > +build: bui
Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
> -build: build-arch
> +## edd 19 Sep 2019 for source uploads also build build-indep
> +build: build-arch build-indep
>
> build-arch: make-arch
&
On 19 September 2019 at 20:40, Dirk Eddelbuettel wrote:
| On 19 September 2019 at 16:03, Guillem Jover wrote:
| | On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote:
| | > So presumably the dependency graph within debian/rules is wrong. Would
| | > anybody here know
| | >
| | > - e
Dirk Eddelbuettel writes ("Re: Possible doc package side-effect from going
source-only upload [and 1 more messages]"):
> On 19 September 2019 at 14:51, Ian Jackson wrote:
> | This would be a good idea. It is quite some effort but I think you
> | would be rewarded with
Ian, Guillem,
On 19 September 2019 at 14:51, Ian Jackson wrote:
| Dirk Eddelbuettel writes ("Possible doc package side-effect from going
source-only upload"):
| > Maybe someone on the list can help with a sharp insight before I go trying.
| >
| > The r-base source packag
Hi!
On Thu, 2019-09-19 at 07:15:43 -0500, Dirk Eddelbuettel wrote:
> So presumably the dependency graph within debian/rules is wrong. Would
> anybody here know
>
> - either a failsafe idiom forcing the right thing to happen
> - or a more efficient way
>
> to ensure the binary-arch is built
Dirk Eddelbuettel writes ("Possible doc package side-effect from going
source-only upload"):
> Maybe someone on the list can help with a sharp insight before I go trying.
>
> The r-base source package (for the R system and language) has a somewhat
> cobbled together debia
On Thu, Sep 19, 2019 at 07:15:43AM -0500, Dirk Eddelbuettel wrote:
> [1] https://salsa.debian.org/edd/r-base/blob/master/debian/rules
not really that helpful of a comment, but I think the rules file would
be a lot more readable if you'd dropped all the old commented out code
in it.
(and then I t
Hi all,
Maybe someone on the list can help with a sharp insight before I go trying.
The r-base source package (for the R system and language) has a somewhat
cobbled together debian/rules [1], mostly of my making over the last 20+
years since I helped Doug more and more and eventually took it ov
65 matches
Mail list logo
