On Monday 20 April 2015 12:46 PM, David Kalnischkies wrote:
That can be very quickly quite a set of packages. apt ~23, apititude
~40, mpv (similar to mplayer) ~159, kate (KDEs notepad) ~465. [0]
That can be tuned by excluding non-libraries, but that has its own
drawbacks (private libraries
On 2015-05-03 18:58, Guillem Jover wrote:
Hi!
On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote:
A) Use .deb (i.e. the regular extension) with a new section.
Is there any problem with using the existing debug section? Or is
the different section used to distinguish that these
On 2015-04-19 19:10, David Kalnischkies wrote:
On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote:
The resulting debs are installable with dpkg -i ( \o/ ). I have not
tried anything fancy like setting up a local APT mirror and tried to
convince APT do install it.
I did and apt
On 2015-05-02 13:46, David Kalnischkies wrote:
On Fri, May 01, 2015 at 11:46:42PM +0200, Niels Thykier wrote:
[…] ddeb support […]
+1. \o/
- apt now properly handles the pkg:arch dependency.
[...]
I would revert the revert as this is potentially causing more trouble
than the
On Sat, May 02, 2015 at 09:07:56AM -0400, James McCoy wrote:
On Sat, May 02, 2015 at 01:46:25PM +0200, David Kalnischkies wrote:
(aka: I don't see why a debug
package has to depend on the package it provides symbols for at all. If
any the relation should be 'Enhances'…).
The intention is
Hi!
On Tue, 2015-04-07 at 22:11:18 +0200, Niels Thykier wrote:
A) Use .deb (i.e. the regular extension) with a new section.
Is there any problem with using the existing debug section? Or is
the different section used to distinguish that these are autogenerated
perhaps?
B) Use .ddeb (i.e.
On Fri, May 01, 2015 at 11:46:42PM +0200, Niels Thykier wrote:
[…] ddeb support […]
+1. \o/
- apt now properly handles the pkg:arch dependency.
For different values of properly – apt isn't the only thing involved
here, you have to consider the reaction of dpkg and dose as well and
these 3
On Sat, May 02, 2015 at 01:46:25PM +0200, David Kalnischkies wrote:
(aka: I don't see why a debug
package has to depend on the package it provides symbols for at all. If
any the relation should be 'Enhances'…).
The intention is to ensure the debug symbols came from the same build as
the binary
On 2015-04-04 10:54, Niels Thykier wrote:
On 2015-04-04 09:54, Josselin Mouette wrote:
Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit :
Hi,
I am particularly interested in automatic debug packages, as the current
situation is pretty messy imho. I found
On Mon, Apr 20, 2015 at 09:50:00AM +0800, Paul Wise wrote:
On Mon, Apr 20, 2015 at 1:10 AM, David Kalnischkies wrote:
I would presume most derivatives aren't using it either
Most derivatives appear to use reprepro but there is one using apt-ftparchive
On Mon, Apr 20, 2015 at 1:10 AM, David Kalnischkies wrote:
I would presume most derivatives aren't using it either
Most derivatives appear to use reprepro but there is one using apt-ftparchive
https://wiki.debian.org/Derivatives/CensusFull
https://wiki.debian.org/Derivatives/Census/Lihuen
On Sat, Apr 04, 2015 at 10:54:09AM +0200, Niels Thykier wrote:
The resulting debs are installable with dpkg -i ( \o/ ). I have not
tried anything fancy like setting up a local APT mirror and tried to
convince APT do install it.
I did and apt works with ddeb just fine, meaning it can happily
On 2015-04-09 09:25, Esokrates wrote:
On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote:
[...]
So mostly that is more a decision making (political) problem, than a
technical
one.
It is not entirely clear to me that we any have (major) political issues
IRT ddebs.
People
On Tuesday, April 07, 2015 10:11:18 PM Niels Thykier wrote:
On 2015-04-07 21:10, Niels Thykier wrote:
On 2015-04-04 12:58, Esokrates wrote:
On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
[...]
I know predictions are hard, but is there a plan to get things done for
On Thursday, April 09, 2015 09:25:44 AM Esokrates wrote:
So mostly that is more a decision making (political) problem, than a
technical one. Stretch is a two year time frame though, which makes me
kinda sad. Thanks for you effort though, keep up the amazing work! If I
understand correctly, if
On 2015-04-04 12:58, Esokrates wrote:
On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
[...]
- Trying to get the reproducible team to try it out to see if it
regresses anything (incl. reproducible builds)
I guess the ddeb's are meant to be reproducible too?
Yes. The
On 2015-04-07 21:10, Niels Thykier wrote:
On 2015-04-04 12:58, Esokrates wrote:
On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
[...]
I know predictions are hard, but is there a plan to get things done for the
next release (Stretch)?
At this point, there is no plan,
Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit :
Hi,
I am particularly interested in automatic debug packages, as the current
situation is pretty messy imho. I found
https://wiki.debian.org/AutomaticDebugPackages.
Does anyone know the status of this? Will this be a goal for
On 2015-04-04 09:54, Josselin Mouette wrote:
Le jeudi 02 avril 2015 à 19:37 +0200, Esokrates a écrit :
Hi,
I am particularly interested in automatic debug packages, as the current
situation is pretty messy imho. I found
https://wiki.debian.org/AutomaticDebugPackages.
Does anyone know the
On Saturday, April 04, 2015 10:54:09 AM Niels Thykier wrote:
Last time I checked, dak was still missing code to handle the
generated .ddeb files.
Cheers,
And it *still* does! But there are a few things that have changed!
* There is an experimental branch for debhelper to generate
Hi,
I am particularly interested in automatic debug packages, as the current
situation is pretty messy imho. I found
https://wiki.debian.org/AutomaticDebugPackages.
Does anyone know the status of this? Will this be a goal for Stretch?
This and reproducible builds would make Debian the perfect
Hi,
Even Microsoft has a service for downloading symbols files for many core
windows components on demand (integrated with the crash dump analysis
tool. (I forget of the chrash dump tool is part of the pre-installed
debugger or it itis seperate)).
They even go a step further and ask for
On Wed, Mar 04, 2009 at 10:19:22PM -0800, Steve Langasek wrote:
On Wed, Mar 04, 2009 at 10:03:28AM +, Tzafrir Cohen wrote:
On Tue, Mar 03, 2009 at 09:17:17PM -0800, Steve Langasek wrote:
Remaining concerns:
- each of these dbg packages requires manual modification to the source
On Thu, Mar 5, 2009 at 5:23 PM, Tzafrir Cohen tzaf...@cohens.org.il wrote:
With rpm there's no such problem, as a separate debug package is
created automatically. I just have to keep it somewhere.
That is exactly the plan for debug.debian.net.
IMO it needs to sidestep dh_strip though, since
On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:
On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't
Aurelien Jarno aurel...@aurel32.net writes:
Compressing -dbg files using dh_builddeb -Zlzma, which uses lzma
compression instead of gzip, gives an average gain of 1.88 in size for
the current -dbg packages we have in sid.
Compressing with bzip2 is already supported by DAK and might help
On Thu, Mar 05, 2009 at 05:35:53PM +0900, Paul Wise wrote:
On Thu, Mar 5, 2009 at 5:23 PM, Tzafrir Cohen tzaf...@cohens.org.il wrote:
With rpm there's no such problem, as a separate debug package is
created automatically. I just have to keep it somewhere.
That is exactly the plan for
On Thu, Mar 05, 2009 at 12:43:43AM -0800, Russ Allbery wrote:
Aurelien Jarno aurel...@aurel32.net writes:
Compressing -dbg files using dh_builddeb -Zlzma, which uses lzma
compression instead of gzip, gives an average gain of 1.88 in size for
the current -dbg packages we have in sid.
Aurelien Jarno aurel...@aurel32.net writes:
AFAIK, allowing LZMA in DAK is just a matter of changing one line in
DAK.
Do you have more details about LZMA being deprecated and replaced by XZ?
See current state of the development at http://tukaani.org/lzma/ and
then http://tukaani.org/xz/ and
Quoting Steve Langasek (vor...@debian.org):
symbols. If there's a will to get that done in Debian now, I will
definitely be happy to ditch the samba-dbg package for one.
I support my co-maintainer on that..:-)
One should note that samba-dbg is sometimes used and already allowed
tracking
Steve McIntyre st...@einval.com writes:
Hey folks,
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick an example
On 2009-03-04, Steve Langasek vor...@debian.org wrote:
[snip]
What I really wish for is the ability to have a relatively centralized
location where the symbols from every single package ended up that was
separate from the normal mirrors.
Yes, absolutely. Doing this right, though, requires
On Wed, Mar 4, 2009 at 7:12 AM, Christian Perrier bubu...@debian.org wrote:
Quoting Steve Langasek (vor...@debian.org):
symbols. If there's a will to get that done in Debian now, I will
definitely be happy to ditch the samba-dbg package for one.
I support my co-maintainer on that..:-)
On Wed, Mar 4, 2009 at 6:17 AM, Steve Langasek vor...@debian.org wrote:
On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I
On Wed, Mar 04, 2009 at 01:45:38PM +0100, Bastien ROUCARIES wrote:
Remaining concerns:
- each of these dbg packages requires manual modification to the source
package (incl. adding the package to debian/control)
- each has to go through the NEW queue
- each takes up space afterwards
Don Armstrong wrote:
On Tue, 03 Mar 2009, Steve McIntyre wrote:
I've got to wondering: are the large -dbg packages actually really
useful to anybody?
Thoughts?
I think they are useful, but probably not for the vast majority of
users. [I've used them on a few dozen occasions.]
What I really
On Wed, Mar 04, 2009 at 10:03:28AM +, Tzafrir Cohen wrote:
On Tue, Mar 03, 2009 at 09:17:17PM -0800, Steve Langasek wrote:
Remaining concerns:
- each of these dbg packages requires manual modification to the source
package (incl. adding the package to debian/control)
- each has to
Hey folks,
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick an example) the amarok-dbg packages, but we have
multiple
Steve McIntyre st...@einval.com writes:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful to
anybody? I can't imagine that more than a handful of users ever install
(to pick an example) the amarok-dbg
On Tue, 03 Mar 2009, Steve McIntyre wrote:
I've got to wondering: are the large -dbg packages actually really
useful to anybody?
Thoughts?
I think they are useful, but probably not for the vast majority of
users. [I've used them on a few dozen occasions.]
What I really wish
On Wed, Mar 4, 2009 at 12:11 AM, Don Armstrong d...@debian.org wrote:
On Tue, 03 Mar 2009, Steve McIntyre wrote:
I've got to wondering: are the large -dbg packages actually really
useful to anybody?
Thoughts?
See #508585 and http://debug.debian.net/
It will be really nice to have
Hi,
Don Armstrong d...@debian.org writes:
What I really wish for is the ability to have a relatively centralized
location where the symbols from every single package ended up that was
separate from the normal mirrors.
The above, coupled with a coredump submission site which would accept
On 2009-03-03, Steve McIntyre st...@einval.com wrote:
Hey folks,
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick
Hi,
On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick
I doubt most users will install them on their own, but I've found
them to be moderately useful in tracking down crashes. It's easier
to convince people to install a -dbg package than to convince them to
recompile the program from source.
Daniel
--
To UNSUBSCRIBE, email to
On Tue, Mar 03, 2009 at 03:11:12PM -0800, Don Armstrong wrote:
On Tue, 03 Mar 2009, Steve McIntyre wrote:
I've got to wondering: are the large -dbg packages actually really
useful to anybody?
Thoughts?
I think they are useful, but probably not for the vast majority of
users. [I've used
On Tue, Mar 03, 2009 at 10:12:22PM +, Steve McIntyre wrote:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick
On Tue, Mar 03, 2009 at 10:25:06PM -0500, Theodore Tso wrote:
I'm looking at my local mirror (slowly) update at the moment, and I've
got to wondering: are the large -dbg packages actually really useful
to anybody? I can't imagine that more than a handful of users ever
install (to pick
On Wed, Mar 4, 2009 at 2:17 PM, Steve Langasek vor...@debian.org wrote:
If the -dbg files were more like these sizes:
...
I doubt there's be too much concern
Remaining concerns:
- each of these dbg packages requires manual modification to the source
package (incl. adding the package
49 matches
Mail list logo
