Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Automatic dbgsym packages built by default as of today!
617 views
Skip to first unread message
Niels Thykier
Dec 19, 2015, 6:30:02 PM12/19/15
to
Hi,
As of today, dak supports the dbgsym packages built by debhelper and
with debhelper/9.20151219 they are now built by default! With this, a
decade old idea is now implemented and available for general
consumption[1]. :)
* A huge thanks to Ansgar Burchardt for finishing up the remaining
loose ends in dak today. :)
* The debug symbols are available from debug.mirrors.debian.org
- See also [APT-LINE] for installing them via APT
* Currently only experimental and unstable will have dbgsym packages.
- We need changes to Britney to add them to testing.
Quick reminders
===============
* The dbgsym packages are generated by debhelper and will now appear
in (almost) all debhelper based packages.
* You can disable dbgsym generation:
- in your package by passing "--no-debs" to dh_strip
- in your build by setting DEB_BUILD_OPTIONS=noddebs
- in your derivative by patching dh_strip.
* You /can/ migrate your manual "-dbg" package to a "-dbgsym"
- if/when it has no reverse (build-)depends.
- it just requires you to replace "--dbg-package=pkg-dbg" with
"--ddeb-migration='pkg-dbg (<< ${VERSION}~)'
- in a release from now, you can drop --ddeb-migration (and probably
also the "override_dh_strip" if you use the dh-sequencer)
* You are *not* required to migrate your manual "-dbg" packages.
- notably, you should *not* migrate them if they still have reverse
dependencies.
* lintian/2.5.38.1 will complain about an unknown "auto-built-package"
header in dbgsyms. Known issue fixed in the next release of lintian.
Enjoy,
~Niels
[1]
http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/theora-unscaled/2006-05-20/tower/Debian_s_Debugging_Debacle-Erinn_Clark__Anthony_Towns.ogg
I said decade, though the idea is probably older than this video... :)
[2] The apt-sources line (for unstable) should be something like:
deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
Note the use of "unstable-debug" instead of "unstable".
As of today, dak supports the dbgsym packages built by debhelper and
with debhelper/9.20151219 they are now built by default! With this, a
decade old idea is now implemented and available for general
consumption[1]. :)
* A huge thanks to Ansgar Burchardt for finishing up the remaining
loose ends in dak today. :)
* The debug symbols are available from debug.mirrors.debian.org
- See also [APT-LINE] for installing them via APT
* Currently only experimental and unstable will have dbgsym packages.
- We need changes to Britney to add them to testing.
Quick reminders
===============
* The dbgsym packages are generated by debhelper and will now appear
in (almost) all debhelper based packages.
* You can disable dbgsym generation:
- in your package by passing "--no-debs" to dh_strip
- in your build by setting DEB_BUILD_OPTIONS=noddebs
- in your derivative by patching dh_strip.
* You /can/ migrate your manual "-dbg" package to a "-dbgsym"
- if/when it has no reverse (build-)depends.
- it just requires you to replace "--dbg-package=pkg-dbg" with
"--ddeb-migration='pkg-dbg (<< ${VERSION}~)'
- in a release from now, you can drop --ddeb-migration (and probably
also the "override_dh_strip" if you use the dh-sequencer)
* You are *not* required to migrate your manual "-dbg" packages.
- notably, you should *not* migrate them if they still have reverse
dependencies.
* lintian/2.5.38.1 will complain about an unknown "auto-built-package"
header in dbgsyms. Known issue fixed in the next release of lintian.
Enjoy,
~Niels
[1]
http://meetings-archive.debian.net/pub/debian-meetings/2006/debconf6/theora-unscaled/2006-05-20/tower/Debian_s_Debugging_Debacle-Erinn_Clark__Anthony_Towns.ogg
I said decade, though the idea is probably older than this video... :)
[2] The apt-sources line (for unstable) should be something like:
deb http://debug.mirrors.debian.org/debian-debug/ unstable-debug main
Note the use of "unstable-debug" instead of "unstable".
Markus Koschany
Dec 19, 2015, 6:50:03 PM12/19/15
to
Am 20.12.2015 um 00:26 schrieb Niels Thykier:
> Hi,
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
Chapeau to you and everyone who was involved in implementing this
> Hi,
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
feature. Finally the days of manual debug packages are over. :-)
Regards,
Markus
Vincent Bernat
Dec 19, 2015, 8:10:02 PM12/19/15
to
❦ 19 décembre 2015 23:26 GMT, Niels Thykier <ni...@thykier.net> :
> * Currently only experimental and unstable will have dbgsym packages.
> - We need changes to Britney to add them to testing.
For experimental, would it be possible to set "Not-Automatic: yes", so
that debug packages work in the same way than regular packages? Thanks!
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
> * Currently only experimental and unstable will have dbgsym packages.
> - We need changes to Britney to add them to testing.
that debug packages work in the same way than regular packages? Thanks!
--
Make sure comments and code agree.
- The Elements of Programming Style (Kernighan & Plauger)
Vincent Bernat
Dec 19, 2015, 8:10:02 PM12/19/15
to
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
That's great! Many thanks for your work!
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
--
Terminate input by end-of-file or marker, not by count.
Michael Biebl
Dec 19, 2015, 8:20:02 PM12/19/15
to
Am 20.12.2015 um 00:26 schrieb Niels Thykier:
> Hi,
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default!
This is awesome.
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default!
Huge thanks to everyone involved. That's a nice, early christmas present!
Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Zlatan Todoric
Dec 19, 2015, 8:50:02 PM12/19/15
to
On 12/20/2015 02:13 AM, Michael Biebl wrote:
> Am 20.12.2015 um 00:26 schrieb Niels Thykier:
>> Hi,
>>
>> As of today, dak supports the dbgsym packages built by debhelper and
>> with debhelper/9.20151219 they are now built by default!
>
> This is awesome.
> Huge thanks to everyone involved. That's a nice, early christmas present!
>
Julian calendar so..) - yay! (btw, it's my family slava so all are
invited to it ;)
Again, such an awesome news this is and I am joining all the thanks to
everyone involved!
Cheers,
zlatan
Paul Wise
Dec 19, 2015, 10:00:03 PM12/19/15
to
On Sun, Dec 20, 2015 at 10:07 AM, Christoph Anton Mitterer wrote:
> Will this eventually replace all the existing -dbg packages?
That is the plan, yes.
> And will this eventually become part of normal unstable/testing/etc.
> and mirrors, or is it intended that people really always add e.g.
> unstable-debug?
The latter.
> Last but not least, what about security support?
None of the suites available on it (unstable/experimental) recieve
security updates.
The packages on it are ones produced at the same time as the other
packages. So when testing gets added and there is a testing security
update (almost never happens), the security update will also
automatically build -dbgsym packages as long as the relevant debhelper
version is installed. Once stretch is released as stable, the same
applies. jessie/wheezy/etc will of course not get -dbgsym packages.
--
bye,
pabs
https://wiki.debian.org/PaulWise
> Will this eventually replace all the existing -dbg packages?
That is the plan, yes.
> And will this eventually become part of normal unstable/testing/etc.
> and mirrors, or is it intended that people really always add e.g.
> unstable-debug?
The latter.
> Last but not least, what about security support?
None of the suites available on it (unstable/experimental) recieve
security updates.
The packages on it are ones produced at the same time as the other
packages. So when testing gets added and there is a testing security
update (almost never happens), the security update will also
automatically build -dbgsym packages as long as the relevant debhelper
version is installed. Once stretch is released as stable, the same
applies. jessie/wheezy/etc will of course not get -dbgsym packages.
--
bye,
pabs
https://wiki.debian.org/PaulWise
Paul Wise
Dec 19, 2015, 10:30:02 PM12/19/15
to
On Sun, Dec 20, 2015 at 11:10 AM, Christoph Anton Mitterer wrote:
> Hmm when people then have a lot suites, like stable, stable-updates,
> stable-proposed updates, *-backports... that will quit blow up
> sources.lists when in principle they'd need to add according *-debug
> lines for each.
Not if one uses the new Deb822 sources format:
$ cat /etc/apt/sources.list.d/04-debian-debug.sources
Types: deb
URIs: http://debug.mirrors.debian.org/debian-debug/
Suites: unstable-debug experimental-debug
Components: main
> Hmm when people then have a lot suites, like stable, stable-updates,
> stable-proposed updates, *-backports... that will quit blow up
> sources.lists when in principle they'd need to add according *-debug
> lines for each.
Not if one uses the new Deb822 sources format:
$ cat /etc/apt/sources.list.d/04-debian-debug.sources
Types: deb
URIs: http://debug.mirrors.debian.org/debian-debug/
Suites: unstable-debug experimental-debug
Components: main
Niels Thykier
Dec 20, 2015, 5:40:03 AM12/20/15
to
Niels Thykier:
>
Hi,
We have a couple of "known issues" now that this change have been live
for a few hours:
* reprepro rejects upload with automatic debug symbols as it does not
support them yet[1]. (#730572)
- Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
- Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
can trust all uploaders (and their tools) to behave.
* dh_strip(1) incorrectly states that debug symbol package generation
is disabled by default.
- Fixed in debhelper master branch.
* The "experimental-debug" suite does *not* have "Not-Automatic: yes"
like the "experimental" suite have.
Please let me know if you encounter other issues.
Thanks,
~Niels
[1] From dpkg's jenkins build log
"""
[...]
reprepro -b /srv/repository -v --waitforlock 1000
--ignore=wrongdistribution --ignore=uploaders include dpkg
<http://jenkins.grml.org/job/dpkg-binaries/architecture=i386/ws/binaries/dpkg_1.18.4~20151220053048.392_i386.changes>
'/srv/repository/pool/main/d/dpkg/dselect-dbgsym_1.18.4~20151220053048.392_i386.deb'
has packagename 'dselect-dbgsym' not listed in the .changes file!
To ignore use --ignore=surprisingbinary.
[...]
"""
https://lists.debian.org/debian-dpkg/2015/12/msg00010.html
> Hi,
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
>
> [...]
>
> As of today, dak supports the dbgsym packages built by debhelper and
> with debhelper/9.20151219 they are now built by default! With this, a
> decade old idea is now implemented and available for general
> consumption[1]. :)
>
>
Hi,
We have a couple of "known issues" now that this change have been live
for a few hours:
* reprepro rejects upload with automatic debug symbols as it does not
support them yet[1]. (#730572)
- Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
- Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
can trust all uploaders (and their tools) to behave.
* dh_strip(1) incorrectly states that debug symbol package generation
is disabled by default.
- Fixed in debhelper master branch.
* The "experimental-debug" suite does *not* have "Not-Automatic: yes"
like the "experimental" suite have.
Please let me know if you encounter other issues.
Thanks,
~Niels
[1] From dpkg's jenkins build log
"""
[...]
reprepro -b /srv/repository -v --waitforlock 1000
--ignore=wrongdistribution --ignore=uploaders include dpkg
<http://jenkins.grml.org/job/dpkg-binaries/architecture=i386/ws/binaries/dpkg_1.18.4~20151220053048.392_i386.changes>
'/srv/repository/pool/main/d/dpkg/dselect-dbgsym_1.18.4~20151220053048.392_i386.deb'
has packagename 'dselect-dbgsym' not listed in the .changes file!
To ignore use --ignore=surprisingbinary.
[...]
"""
https://lists.debian.org/debian-dpkg/2015/12/msg00010.html
Ansgar Burchardt
Dec 20, 2015, 6:20:03 AM12/20/15
to
Vincent Bernat <ber...@debian.org> writes:
> For experimental, would it be possible to set "Not-Automatic: yes", so
> that debug packages work in the same way than regular packages? Thanks!
This will happen with the next dinstall run.
> For experimental, would it be possible to set "Not-Automatic: yes", so
> that debug packages work in the same way than regular packages? Thanks!
Ansgar
Sebastian Ramacher
Dec 20, 2015, 10:20:02 AM12/20/15
to
Hi
a big thank you for all invovled implementhing this feature!
On 2015-12-19 23:26:09, Niels Thykier wrote:
> * You /can/ migrate your manual "-dbg" package to a "-dbgsym"
> - if/when it has no reverse (build-)depends.
> - it just requires you to replace "--dbg-package=pkg-dbg" with
> "--ddeb-migration='pkg-dbg (<< ${VERSION}~)'
> - in a release from now, you can drop --ddeb-migration (and probably
> also the "override_dh_strip" if you use the dh-sequencer)
So how will we deal with the migration from -dbg to -dbgsym for jessie ->
stretch?
* Should we keep transitional -dbg packages around even if the -dbgsym packages
are in another archive?
* Are we going to tell people in the release notes that we expect
'apt dist-upgrade' to remove plenty of -dbg packages and if they still need
them to reinstall the -dbgsym version?
Does someone else have any other ideas?
Cheers
--
Sebastian Ramacher
a big thank you for all invovled implementhing this feature!
On 2015-12-19 23:26:09, Niels Thykier wrote:
> * You /can/ migrate your manual "-dbg" package to a "-dbgsym"
> - if/when it has no reverse (build-)depends.
> - it just requires you to replace "--dbg-package=pkg-dbg" with
> "--ddeb-migration='pkg-dbg (<< ${VERSION}~)'
> - in a release from now, you can drop --ddeb-migration (and probably
> also the "override_dh_strip" if you use the dh-sequencer)
stretch?
* Should we keep transitional -dbg packages around even if the -dbgsym packages
are in another archive?
* Are we going to tell people in the release notes that we expect
'apt dist-upgrade' to remove plenty of -dbg packages and if they still need
them to reinstall the -dbgsym version?
Does someone else have any other ideas?
Cheers
--
Sebastian Ramacher
Bernd Zeimetz
Dec 20, 2015, 12:20:02 PM12/20/15
to
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi,
> So how will we deal with the migration from -dbg to -dbgsym for
> jessie -> stretch?
>
> * Should we keep transitional -dbg packages around even if the
> -dbgsym packages are in another archive?
>
> * Are we going to tell people in the release notes that we expect
> 'apt dist-upgrade' to remove plenty of -dbg packages and if they
> still need them to reinstall the -dbgsym version?
* And what do with -dbg packages which no not only contain debug
symbols from dh_strip, but also debug information from/for other
languages/interpreters?
Cheers,
Bernd
- --
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Hash: SHA256
Hi,
> So how will we deal with the migration from -dbg to -dbgsym for
> jessie -> stretch?
>
> * Should we keep transitional -dbg packages around even if the
> -dbgsym packages are in another archive?
>
> * Are we going to tell people in the release notes that we expect
> 'apt dist-upgrade' to remove plenty of -dbg packages and if they
> still need them to reinstall the -dbgsym version?
symbols from dh_strip, but also debug information from/for other
languages/interpreters?
Cheers,
Bernd
- --
Bernd Zeimetz Debian GNU/Linux Developer
http://bzed.de http://www.debian.org
GPG Fingerprint: ECA1 E3F2 8E11 2432 D485 DD95 EB36 171A 6FF9 435F
Niels Thykier
Dec 20, 2015, 12:40:03 PM12/20/15
to
Bernd Zeimetz:
> Hi,
at least). Either you end up with:
* an transitional package that will *not* bring in the dbgsym
package, OR
* a transitional package that *cannot* be installed/upgraded without
the user having enabled the debug archive.
Though, it is entirely possible that we need to keep transitional
packages for -dbg packages if apt have issues coping with the upgrade path.
>> * Are we going to tell people in the release notes that we expect
>> 'apt dist-upgrade' to remove plenty of -dbg packages and if they
>> still need them to reinstall the -dbgsym version?
>
Of the two ideas you proposed, this is the one that makes most sense to
me. Though, I have not thought that long about it. :)
> * And what do with -dbg packages which no not only contain debug
> symbols from dh_strip, but also debug information from/for other
> languages/interpreters?
>
> Cheers,
>
> Bernd
>
> [...]
I would be interested in working people on extending the existing debug
symbols packages to be able to include such, when it can be done
completely automatically (in the general case) via build helper tools. :)
Thanks,
~Niels
> Hi,
>
Hi,
>> So how will we deal with the migration from -dbg to -dbgsym for
>> jessie -> stretch?
>>
>> * Should we keep transitional -dbg packages around even if the
>> -dbgsym packages are in another archive?
>>
To be honest, I do not think this will make sense/work (for that purpose
Hi,
>> So how will we deal with the migration from -dbg to -dbgsym for
>> jessie -> stretch?
>>
>> * Should we keep transitional -dbg packages around even if the
>> -dbgsym packages are in another archive?
>>
at least). Either you end up with:
* an transitional package that will *not* bring in the dbgsym
package, OR
* a transitional package that *cannot* be installed/upgraded without
the user having enabled the debug archive.
Though, it is entirely possible that we need to keep transitional
packages for -dbg packages if apt have issues coping with the upgrade path.
>> * Are we going to tell people in the release notes that we expect
>> 'apt dist-upgrade' to remove plenty of -dbg packages and if they
>> still need them to reinstall the -dbgsym version?
>
me. Though, I have not thought that long about it. :)
> * And what do with -dbg packages which no not only contain debug
> symbols from dh_strip, but also debug information from/for other
> languages/interpreters?
>
> Cheers,
>
> Bernd
>
I would be interested in working people on extending the existing debug
symbols packages to be able to include such, when it can be done
completely automatically (in the general case) via build helper tools. :)
Thanks,
~Niels
Robert Edmonds
Dec 21, 2015, 12:40:02 AM12/21/15
to
Paul Wise wrote:
> On Sun, Dec 20, 2015 at 10:07 AM, Christoph Anton Mitterer wrote:
>
> > Will this eventually replace all the existing -dbg packages?
>
> That is the plan, yes.
>
> > And will this eventually become part of normal unstable/testing/etc.
> > and mirrors, or is it intended that people really always add e.g.
> > unstable-debug?
>
> The latter.
Are the *-debug suites going to stay in a separate repository? If so,
> On Sun, Dec 20, 2015 at 10:07 AM, Christoph Anton Mitterer wrote:
>
> > Will this eventually replace all the existing -dbg packages?
>
> That is the plan, yes.
>
> > And will this eventually become part of normal unstable/testing/etc.
> > and mirrors, or is it intended that people really always add e.g.
> > unstable-debug?
>
> The latter.
is a separate mirror network being set up? I help maintain a public
mirror of the 'debian' repository, and if possible I'd like to setup a
mirror of the 'debian-debug' repository as well.
--
Robert Edmonds
edm...@debian.org
Peter Palfrader
Dec 21, 2015, 6:00:02 AM12/21/15
to
On Mon, 21 Dec 2015, Robert Edmonds wrote:
> Are the *-debug suites going to stay in a separate repository? If so,
> is a separate mirror network being set up? I help maintain a public
> mirror of the 'debian' repository, and if possible I'd like to setup a
> mirror of the 'debian-debug' repository as well.
I think the plan is to keep them separate.
> Are the *-debug suites going to stay in a separate repository? If so,
> is a separate mirror network being set up? I help maintain a public
> mirror of the 'debian' repository, and if possible I'd like to setup a
> mirror of the 'debian-debug' repository as well.
We probably don't need it as widely mirrored as the main repository, but
there will be mirrors.
For north america, we are currently still blocking on getting a
dedicated IP addresses for the new sync-proxy...
Cheers,
--
| .''`. ** Debian **
Peter Palfrader | : :' : The universal
https://www.palfrader.org/ | `. `' Operating System
| `- https://www.debian.org/
Anthony DeRobertis
Dec 21, 2015, 12:40:03 PM12/21/15
to
Are there plans to teach httpredir.debian.org about the new debug mirror
network?
http://httpredir.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Release is currently 404.
network?
http://httpredir.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Release is currently 404.
Niels Thykier
Dec 21, 2015, 1:00:03 PM12/21/15
to
Anthony DeRobertis:
I have filed a request for it in [1] - patches are (presumably) welcome. :)
Thanks,
~Niels
[1] https://github.com/rgeissert/http-redirector/issues/70
> Are there plans to teach httpredir.debian.org about the new debug mirror
> network?
>
> http://httpredir.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Release is currently 404.
>
Thanks for the suggestion.
> network?
>
> http://httpredir.debian.org/debian-debug/dists/unstable-debug/main/binary-amd64/Release is currently 404.
>
I have filed a request for it in [1] - patches are (presumably) welcome. :)
Thanks,
~Niels
[1] https://github.com/rgeissert/http-redirector/issues/70
Lars Wirzenius
Dec 22, 2015, 12:50:02 PM12/22/15
to
On Sun, Dec 20, 2015 at 10:35:05AM +0000, Niels Thykier wrote:
> * reprepro rejects upload with automatic debug symbols as it does not
> support them yet[1]. (#730572)
> - Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
> - Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
> can trust all uploaders (and their tools) to behave.
I haven't gotten --ignore=surprisingbinary to actually do what it's
> * reprepro rejects upload with automatic debug symbols as it does not
> support them yet[1]. (#730572)
> - Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
> - Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
> can trust all uploaders (and their tools) to behave.
meant to do, at least with "reprepro processincoming". I get this:
+ reprepro --ignore=surprisingbinary processincoming default
Name 'obnam-dbgsym' of binary 'obnam-dbgsym_1.19.0ci59-1.unstable_amd64.deb' is not listed in Binaries header of 'obnam_1.19.0ci59-1.unstable_amd64.changes'!
Name 'obnam-dbgsym' of binary 'obnam-dbgsym_1.19.0ci59-1.unstable_i386.deb' is not listed in Binaries header of 'obnam_1.19.0ci59-1.unstable_i386.changes'!
Warning: database 'jessie-ci|main|i386' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'jessie-ci|main|amd64' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'jessie-ci|main|source' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'unstable-ci|main|source' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'wheezy-ci|main|i386' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'wheezy-ci|main|amd64' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
Warning: database 'wheezy-ci|main|source' was modified but no index file was exported.
Changes will only be visible after the next 'export'!
There have been errors!
I also don't get this message, which you quoted, though I guess it
might only happen with "reprepro include":
> To ignore use --ignore=surprisingbinary.
This is reprepro 4.16.0-1 from jessie (though it seems sid has the
same version). Am I doing something otterly stupid?
I can get it to work by ignoring that reprepro failed, and then
running "reprepro export" afterwards.
Suggestions, anyone?
--
Schrödinger's backup hypothesis: the condition of any backup is
undefined until a restore is attempted. -- andrewsh
Michael Prokop
Dec 22, 2015, 2:10:02 PM12/22/15
to
* Lars Wirzenius [Tue Dec 22, 2015 at 06:36:55PM +0100]:
> > To ignore use --ignore=surprisingbinary.
> This is reprepro 4.16.0-1 from jessie (though it seems sid has the
> same version). Am I doing something otterly stupid?
> I can get it to work by ignoring that reprepro failed, and then
> running "reprepro export" afterwards.
> Suggestions, anyone?
This is #808558.
regards,
-mika-
> On Sun, Dec 20, 2015 at 10:35:05AM +0000, Niels Thykier wrote:
> > * reprepro rejects upload with automatic debug symbols as it does not
> > support them yet[1]. (#730572)
> > - Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
> > - Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
> > can trust all uploaders (and their tools) to behave.
> I haven't gotten --ignore=surprisingbinary to actually do what it's
> meant to do, at least with "reprepro processincoming". I get this:
[...]
> > * reprepro rejects upload with automatic debug symbols as it does not
> > support them yet[1]. (#730572)
> > - Workaround #1: Build with --no-ddebs / DEB_BUILD_OPTIONS=noddebs
> > - Workaround #2: Pass --ignore=surprisingbinary to reprepro if you
> > can trust all uploaders (and their tools) to behave.
> I haven't gotten --ignore=surprisingbinary to actually do what it's
> meant to do, at least with "reprepro processincoming". I get this:
> > To ignore use --ignore=surprisingbinary.
> This is reprepro 4.16.0-1 from jessie (though it seems sid has the
> same version). Am I doing something otterly stupid?
> I can get it to work by ignoring that reprepro failed, and then
> running "reprepro export" afterwards.
> Suggestions, anyone?
regards,
-mika-
Thomas Goirand
Dec 23, 2015, 6:40:02 AM12/23/15
to
I was very surprised to see it appearing when building my packages. It's
really a super nice feature that we have, thanks for it!
Cheers,
Thomas Goirand (zigo)
0 new messages