Bug#808440: ITP: pkgdiff -- tool for visualizing changes in Linux software packages

[Peter Spiess-Knafl]

Package: wnpp
Severity: wishlist
Owner: "Peter Spiess-Knafl" 

* Package name: pkgdiff
  Version : 1.7.1
  Upstream Author : Andrey Ponomarenko 
* URL : https://github.com/lvc/pkgdiff
* License : GPL-2
  Programming Lang: Perl
  Description : tool for visualizing changes in Linux software packages

Package Changes Analyzer (pkgdiff) - a tool for visualizing changes in Linux
software packages (RPM, DEB, TAR.GZ, etc). The tool is intended for Linux
maintainers who are interested in ensuring compatibility of old and new
versions of packages.

The tool gives a brief overview about new upstream source or binary packages.
It is used inside the abi-tracker, which I plan to bring to Debian [1].

Therefore I first need to package all of abi-tracker's dependencies.

[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808260

Bug#808445: ITP: vim-editorconfig -- EditorConfig Plugin for Vim

[Michael Fladischer]

Package: wnpp
Severity: wishlist
Owner: Michael Fladischer 

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

* Package name: vim-editorconfig
  Version : 0.3.3
  Upstream Author : EditorConfig Team
* URL : https://github.com/editorconfig/editorconfig-vim
* License : BSD_2-clause
  Programming Lang: VimScript
  Description : EditorConfig Plugin for Vim

 EditorConfig helps developers define and maintain consistent coding styles for
 their projects for different editors and IDEs. The EditorConfig project
 consists of a file format for defining coding styles and a collection of text
 editor plugins that enable editors to read the file format and adhere to
 defined styles. EditorConfig files are easily readibly and they work nicely
 with version control systems.
 .
 The EditorConfig Vim plugin supports the following EditorConfig properties:
 * indent_style
 * indent_size
 * tab_width
 * end_of_line
 * charset
 * insert_final_newline
 * trim_trailing_whitespace
 * max_line_length
 * root (only used by EditorConfig core)

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBCgAGBQJWdnSxAAoJEGlMre9Rx7W2Ad8QALYJfmBN7FU35owOOjnI7JAu
poUVEs7VD7JhBUrja7yX8sna/H7Hs00gPngbp3srnKcuqmjMzKDSfcZ6qTn8oVgb
xBWyszX5WRwroVllhgBhv/RygCZfbTHMrnuohtrSPTf54+HreUNk+FNBTMie863h
jQWOmgvh2N8k7HHPP9nvJJs0YCaQ4pyutQJNaYHmTt8UYgakxjv8NS9nteNkg8w+
5pfOHwetSz84Ks+VgPeAepqgh+3E+rMsUeotUBQQXHFfsiHedWcqAEbDVCjRJfpo
/NB+dJ9pKPheF2E0zf4YF0BsmP7C0pbtINhPysHUK2Nme7JLEm1g7A7Fj6Wvs45E
5UfYQcgHFVY2DJjRXO6+Zz20N9WeYJ5+EkBTBT1nYjMfpypHl7WraU4g8yZnZpfP
JHYMj/b82U84wN2JjCvu0KEupSGlqI7rLh+etZ6YpEvgmIELjk1HKYIRwdjVE87Q
FUAHAXE/1Tt5T3kQwbOIZSv3D2lqlzTRf+ed24HylkuZX4aBKu4tKNDhBpxO16oP
ChyZMi7MZOcnkUxuuyLhdHOAgJAyN0v7wHwOtfNFQZMU1Qr7EvCs3l2RLDfcW2yJ
tMjJqjSt9l8SkJqDLq/XNVc17jvcCw0GzsF30lR15GGypN9BGglNgo5Q7I1zP3Jq
bFJaeZ8OnetGmupUb+R3
=YzsB
-END PGP SIGNATURE-

Known issues with automatic dbgsym packages (Was: Automatic dbgsym packages built by default as of today!)

[Niels Thykier]

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]. :)
> 
> [...]
> 

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

'/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






signature.asc
Description: OpenPGP digital signature

Re: Bug#808414: ITP: ms-sys -- Program for writing Microsoft compatible boot records

[Marco d'Itri]

On Dec 20, lucas castro  wrote:

> I'll take a look at ms-sys-free.
Can you clarify which features it provides over the existing mbr 
package?

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Bug#808414: ITP: ms-sys -- Program for writing Microsoft compatible boot records

[Marco d'Itri]

Package: ntfs-3g
Version: 0.0.0+20070920-1
Severity: serious

On Dec 20, Sam Morris  wrote:

> That reminds me... I wonder if anyone has looked into the legal status of
> boot_array from ntfs-3g?
> 
> https://sources.debian.net/src/ntfs-3g/1:2015.3.14AR.1-1/ntfsprogs/boot.c/
There is not much to look at: while it would be hard to argue that this 
Microsoft-originated software cannot be redistributed for this purpose, 
I think that it is quite obvious that it is missing the corresponding 
source code and that until proven otherwise it must be assumed to not 
allow derivate works.
So it is clearly not DFSG free and should eventually be removed.

Unless I am missing something about the NTFS on-disk structure, then the 
first 512 bytes (the boot record proper) can be easily replaced by the 
code from dosfstools and the rest (the first part of NTLDR) can be 
omitted since it is only useful if you need to boot a Windows OS from 
the disk, which would need to be installed from other sources anyway
(Windows PE has a program to install NTLDR, in needed).

-- 
ciao,
Marco


signature.asc
Description: PGP signature

Re: Automatic dbgsym packages built by default as of today!

[Ansgar Burchardt]

Vincent Bernat  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.

Ansgar

Bug#508585: marked as done (Please provide an easy and official way to get debug symbols for all arch)

[Debian Bug Tracking System]

Your message dated Sun, 20 Dec 2015 11:14:13 +
with message-id <56768d85.7020...@thykier.net>
and subject line Re: Please provide an easy and official way to get debug 
symbols for all arch
has caused the Debian Bug report #508585,
regarding Please provide an easy and official way to get debug symbols for all 
arch
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)


-- 
508585: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=508585
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: general
Severity: normal

hello,

In case of bug on rare arch it is quite difficult for the maintener to get 
debug trace. 
A generic stuff like http://debug.debian.net/ will help to solve hard diagnose 
bug like the  #508443 and avoid to create -dbg package like in #508582:
apt-cache search dbg |grep "\-dbg" | wc -l
773
Therefore please find a way to generalize http://debug.debian.net/ and get dbg 
package compiled on the arch, and offer a deb-debug like deb-source deposit.
Using a deb-debug method will allow simple user to download the debug symbol 
without the need to contact the administrator. I even dream of a 
apt-get dbg-depend package that will download all the debug symbols, including 
library linked against my binary.

Keep in mind that maintener time and user time are precious, and a quick 
backstack is often an invaluable information.

Regards

Bastien


--- System information. ---
Architecture: amd64
Kernel:   Linux 2.6.26-1-amd64

Debian Release: lenny/sid
  990 testing security.debian.org 
  990 testing debian.ens-cachan.fr 
   99 unstabledebian.ens-cachan.fr 
  500 lenny   kde4.debian.net 

--- Package information. ---
Depends   (Version) | Installed
===-+-===
| 



-- 

"ROUCARIES Bastien"
   roucaries.bast...@gmail.com
---
DO NOT WRITE TO roucaries.bastien+blackh...@gmail.com OR BE BLACKLISTED


--- End Message ---
--- Begin Message ---
On Fri, 12 Dec 2008 21:34:21 +0100 Bastien ROUCARIES
 wrote:
> Package: general
> Severity: normal
> 
> hello,
> 
> In case of bug on rare arch it is quite difficult for the maintener to get 
> debug trace. 
> A generic stuff like http://debug.debian.net/ will help to solve hard 
> diagnose bug like the  #508443 and avoid to create -dbg package like in 
> #508582:
> apt-cache search dbg |grep "\-dbg" | wc -l
> 773
> Therefore please find a way to generalize http://debug.debian.net/ and get 
> dbg package compiled on the arch, and offer a deb-debug like deb-source 
> deposit.
> Using a deb-debug method will allow simple user to download the debug symbol 
> without the need to contact the administrator. I even dream of a 
> apt-get dbg-depend package that will download all the debug symbols, 
> including library linked against my binary.
> 
> Keep in mind that maintener time and user time are precious, and a quick 
> backstack is often an invaluable information.
> 
> Regards
> 
> Bastien
> 
> 
> [...]

Hi,

We are now building automatic debug symbol packages, which are available
from snapshot.debian.org[1].  I believe we have solved this bug now. :)

Thanks,
~Niels

[1] http://snapshot.debian.org/binary/mscgen-dbgsym/




signature.asc
Description: OpenPGP digital signature
--- End Message ---

Bug#808495: ITP: roary -- high speed stand alone pan genome pipeline

[Sascha Steinbiss]

Package: wnpp
Severity: wishlist
Owner: Sascha Steinbiss 

* Package name: roary
  Version : 3.5.7
  Upstream Author : Andrew J. Page 
* URL : http://sanger-pathogens.github.io/Roary/
* License : GPL-3+
  Programming Lang: Perl
  Description : high speed stand alone pan genome pipeline

Roary is a high speed stand alone pan genome pipeline, which takes annotated
assemblies in GFF3 format (as produced, for instance, by Prokka) and calculates
the pan genome. Using a standard desktop PC, it can analyse datasets with
thousands of samples, something which is computationally infeasible with
existing methods, without compromising the quality of the results. 128 samples
can be analysed in under 1 hour using 1 GB of RAM and a single processor.
To perform this analysis using existing methods would take weeks and hundreds
of GB of RAM. Roary is not intended for meta-genomics or for comparing
extremely diverse sets of genomes.

This package will be maintained under the umbrella of the Debian Med
Packaging Team.

Re: Automatic dbgsym packages built by default as of today!

[Sebastian Ramacher]

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


signature.asc
Description: PGP signature

Re: Automatic dbgsym packages built by default as of today!

[Bernd Zeimetz]

-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 ZeimetzDebian GNU/Linux Developer
 http://bzed.dehttp://www.debian.org
 GPG Fingerprint: ECA1 E3F2 8E11 2432 D485  DD95 EB36 171A 6FF9 435F

Re: Automatic dbgsym packages built by default as of today!

[Niels Thykier]

Bernd Zeimetz:
> 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
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





signature.asc
Description: OpenPGP digital signature

How shall I report a bug in the .deb packaging itself?

[Alberto Salvia Novella]

I want to report a bug that affects the .deb packaging itself, so every 
single package manager is affected too.


https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1528028

How shall I do it?




smime.p7s
Description: S/MIME Cryptographic Signature

Can I suppress automatic creation of -dbgsym packages?

[Dirk Eddelbuettel]

Hi all,

I was just updating one of my several dozen r-cran-* packages. These all use
the same (source) r-cran.mk script shipped with the main R packages.

And now all of sudden it wants to build a -dbgsym package.

That may not be such a good idea for the several hundred r-cran-* packages.
I have been looking around the Deverloper Reference and Wiki (plus Google
searches) but not found a way to suppress this.  What am I missing?

Thanks for any hints.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Can I suppress automatic creation of -dbgsym packages?

[Samuel Thibault]

Dirk Eddelbuettel, on Sun 20 Dec 2015 13:43:38 -0600, wrote:
> That may not be such a good idea for the several hundred r-cran-* packages.

Why not?

Samuel

Re: Can I suppress automatic creation of -dbgsym packages?

[Niels Thykier]

Dirk Eddelbuettel:
> 
> Hi all,
> 
> I was just updating one of my several dozen r-cran-* packages. These all use
> the same (source) r-cran.mk script shipped with the main R packages.
> 
> And now all of sudden it wants to build a -dbgsym package.
> 
> That may not be such a good idea for the several hundred r-cran-* packages.
> I have been looking around the Deverloper Reference and Wiki (plus Google
> searches) but not found a way to suppress this.  What am I missing?
> 
> Thanks for any hints.
> 
> Dirk
> 

Hi Dirk,

Please have a look at [1].  Though if your reason for disabling them are:

 * Upload speed / personal bandwidth costs.
   - Then please consider using "source-only" (or arch:all+source)
 uploads, which is unaffected and keeps the dbgsym.

 * That they take up a lot of mirror space etc.
   - Then please keep in mind that they are off-loaded to a separate
 mirror network and therefore will not burden users / developers
 except those who explicitly enable them.

 * If you have other concerns with them, please let me know. :)

At the same time, the dbgsym packages can be used to assist debugging
your packages or retracing coredumps.  They will also be available from
snapshot.debian.org, so you can retrace coredumps from previous uploads
as long as they had a dbgsym package.

~Niels

[1] https://lists.debian.org/debian-devel/2015/12/msg00262.html





signature.asc
Description: OpenPGP digital signature

Re: How shall I report a bug in the .deb packaging itself?

[Julian Andres Klode]

On Sun, Dec 20, 2015 at 07:44:42PM +0100, Alberto Salvia Novella wrote:
> I want to report a bug that affects the .deb packaging itself, so every
> single package manager is affected too.
> 
> https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1528028
> 
> How shall I do it?

You don't. You fix the bug in your understanding of how package
management works.

-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.

When replying, only quote what is necessary, and write each reply
directly below the part(s) it pertains to (`inline'). Thank you.

Re: Can I suppress automatic creation of -dbgsym packages?

[Dirk Eddelbuettel]

Hi Niels,

Thanks for the prompt and detailed answer!  It addressed all my questions.

On 20 December 2015 at 21:11, Niels Thykier wrote:
| Dirk Eddelbuettel:
| > I was just updating one of my several dozen r-cran-* packages. These all use
| > the same (source) r-cran.mk script shipped with the main R packages.
| > 
| > And now all of sudden it wants to build a -dbgsym package.
| > 
| > That may not be such a good idea for the several hundred r-cran-* packages.
| > I have been looking around the Deverloper Reference and Wiki (plus Google
| > searches) but not found a way to suppress this.  What am I missing?
[...]
| Please have a look at [1].  Though if your reason for disabling them are:
| 
|  * Upload speed / personal bandwidth costs.
|- Then please consider using "source-only" (or arch:all+source)
|  uploads, which is unaffected and keeps the dbgsym.
| 
|  * That they take up a lot of mirror space etc.
|- Then please keep in mind that they are off-loaded to a separate
|  mirror network and therefore will not burden users / developers
|  except those who explicitly enable them.
| 
|  * If you have other concerns with them, please let me know. :)
| 
| At the same time, the dbgsym packages can be used to assist debugging
| your packages or retracing coredumps.  They will also be available from
| snapshot.debian.org, so you can retrace coredumps from previous uploads
| as long as they had a dbgsym package.

Thanks a bunch. The link below did fix it. I had just setup a test
environment in Docker and the env.var will do.

I think will patch the 'debian/rules snippet' we ship with r-base-core to
instruct dh_strip to not create these for now.  _Right now_ we end up with
Lintian errrors hence my first gut instinct to suppress this. The -dbg
packages are a good idea; I provide them as eg r-base-core-dbg and for the
GSL etc.  These may make sense for R packages too, but the r-cran.mk snippet
needs some work to postprocess what dh_gencontrol et al create. Volunteers?

Dirk

| ~Niels
| 
| [1] https://lists.debian.org/debian-devel/2015/12/msg00262.html
| 
| 
| 
| x[DELETED ATTACHMENT signature.asc, application/pgp-signature]

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Can I suppress automatic creation of -dbgsym packages?

[Niels Thykier]

Dirk Eddelbuettel:
> 
> Hi Niels,
> 
> Thanks for the prompt and detailed answer!  It addressed all my questions.
> 
> On 20 December 2015 at 21:11, Niels Thykier wrote:
> | Dirk Eddelbuettel:
> | > I was just updating one of my several dozen r-cran-* packages. These all 
> use
> | > the same (source) r-cran.mk script shipped with the main R packages.
> | > 
> | > And now all of sudden it wants to build a -dbgsym package.
> | > 
> | > That may not be such a good idea for the several hundred r-cran-* 
> packages.
> | > I have been looking around the Deverloper Reference and Wiki (plus Google
> | > searches) but not found a way to suppress this.  What am I missing?
> [...]
> | Please have a look at [1].  Though if your reason for disabling them are:
> | 
> |  * Upload speed / personal bandwidth costs.
> |- Then please consider using "source-only" (or arch:all+source)
> |  uploads, which is unaffected and keeps the dbgsym.
> | 
> |  * That they take up a lot of mirror space etc.
> |- Then please keep in mind that they are off-loaded to a separate
> |  mirror network and therefore will not burden users / developers
> |  except those who explicitly enable them.
> | 
> |  * If you have other concerns with them, please let me know. :)
> | 
> | At the same time, the dbgsym packages can be used to assist debugging
> | your packages or retracing coredumps.  They will also be available from
> | snapshot.debian.org, so you can retrace coredumps from previous uploads
> | as long as they had a dbgsym package.
> 
> Thanks a bunch. The link below did fix it. I had just setup a test
> environment in Docker and the env.var will do.
> 
> I think will patch the 'debian/rules snippet' we ship with r-base-core to
> instruct dh_strip to not create these for now.  _Right now_ we end up with
> Lintian errrors hence my first gut instinct to suppress this.

What error is that (and what version of lintian)?

> The -dbg
> packages are a good idea; I provide them as eg r-base-core-dbg and for the
> GSL etc.  These may make sense for R packages too, but the r-cran.mk snippet
> needs some work to postprocess what dh_gencontrol et al create. Volunteers?
> 
> Dirk
> 
> [...]

Why do you need any postprocessing of the dh_gencontrol output?  The
output of dh_gencontrol for dbgsym packages are synchronized with what
dak expects (and requires) of them.
  Or are you considering to extend the dbgsym packages with R specific
debug information?  That on the other than should be doable, but it
would have to happen before the call to dh_gencontrol.

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: Can I suppress automatic creation of -dbgsym packages?

[Dirk Eddelbuettel]

On 20 December 2015 at 21:52, Niels Thykier wrote:
| Dirk Eddelbuettel:
| > 
| > Hi Niels,
| > 
| > Thanks for the prompt and detailed answer!  It addressed all my questions.
| > 
| > On 20 December 2015 at 21:11, Niels Thykier wrote:
| > | Dirk Eddelbuettel:
| > | > I was just updating one of my several dozen r-cran-* packages. These 
all use
| > | > the same (source) r-cran.mk script shipped with the main R packages.
| > | > 
| > | > And now all of sudden it wants to build a -dbgsym package.
| > | > 
| > | > That may not be such a good idea for the several hundred r-cran-* 
packages.
| > | > I have been looking around the Deverloper Reference and Wiki (plus 
Google
| > | > searches) but not found a way to suppress this.  What am I missing?
| > [...]
| > | Please have a look at [1].  Though if your reason for disabling them are:
| > | 
| > |  * Upload speed / personal bandwidth costs.
| > |- Then please consider using "source-only" (or arch:all+source)
| > |  uploads, which is unaffected and keeps the dbgsym.
| > | 
| > |  * That they take up a lot of mirror space etc.
| > |- Then please keep in mind that they are off-loaded to a separate
| > |  mirror network and therefore will not burden users / developers
| > |  except those who explicitly enable them.
| > | 
| > |  * If you have other concerns with them, please let me know. :)
| > | 
| > | At the same time, the dbgsym packages can be used to assist debugging
| > | your packages or retracing coredumps.  They will also be available from
| > | snapshot.debian.org, so you can retrace coredumps from previous uploads
| > | as long as they had a dbgsym package.
| > 
| > Thanks a bunch. The link below did fix it. I had just setup a test
| > environment in Docker and the env.var will do.
| > 
| > I think will patch the 'debian/rules snippet' we ship with r-base-core to
| > instruct dh_strip to not create these for now.  _Right now_ we end up with
| > Lintian errrors hence my first gut instinct to suppress this.
| 
| What error is that (and what version of lintian)?

E: r-cran-hmisc-dbgsym: extended-description-is-empty
W: r-cran-hmisc-dbgsym: wrong-section-according-to-package-name 
r-cran-hmisc-dbgsym => gnu-r
W: r-cran-hmisc-dbgsym: debug-package-should-be-named-dbg 
usr/lib/debug/.build-id/

| > The -dbg
| > packages are a good idea; I provide them as eg r-base-core-dbg and for the
| > GSL etc.  These may make sense for R packages too, but the r-cran.mk snippet
| > needs some work to postprocess what dh_gencontrol et al create. Volunteers?
| > 
| > Dirk
| > 
| > [...]
| 
| Why do you need any postprocessing of the dh_gencontrol output?  The
| output of dh_gencontrol for dbgsym packages are synchronized with what
| dak expects (and requires) of them.
|   Or are you considering to extend the dbgsym packages with R specific
| debug information?  That on the other than should be doable, but it
| would have to happen before the call to dh_gencontrol.

My analysis may have been premature. This may all be addressable when
creating a new debian/control entry.  If so shouldn't the build abort when
there is no new debian/control entry?
 
Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Can I suppress automatic creation of -dbgsym packages?

[Niels Thykier]

Dirk Eddelbuettel:
> 
> On 20 December 2015 at 21:52, Niels Thykier wrote:
> | Dirk Eddelbuettel:
> | > 
> | > Hi Niels,
> | > 
> | > Thanks for the prompt and detailed answer!  It addressed all my questions.
> | > 
> | > On 20 December 2015 at 21:11, Niels Thykier wrote:
> | > | Dirk Eddelbuettel:
> | > | > I was just updating one of my several dozen r-cran-* packages. These 
> all use
> | > | > the same (source) r-cran.mk script shipped with the main R packages.
> | > | > 
> | > | > And now all of sudden it wants to build a -dbgsym package.
> | > | > 
> | > | > That may not be such a good idea for the several hundred r-cran-* 
> packages.
> | > | > I have been looking around the Deverloper Reference and Wiki (plus 
> Google
> | > | > searches) but not found a way to suppress this.  What am I missing?
> | > [...]
> | > | Please have a look at [1].  Though if your reason for disabling them 
> are:
> | > | 
> | > |  * Upload speed / personal bandwidth costs.
> | > |- Then please consider using "source-only" (or arch:all+source)
> | > |  uploads, which is unaffected and keeps the dbgsym.
> | > | 
> | > |  * That they take up a lot of mirror space etc.
> | > |- Then please keep in mind that they are off-loaded to a separate
> | > |  mirror network and therefore will not burden users / developers
> | > |  except those who explicitly enable them.
> | > | 
> | > |  * If you have other concerns with them, please let me know. :)
> | > | 
> | > | At the same time, the dbgsym packages can be used to assist debugging
> | > | your packages or retracing coredumps.  They will also be available from
> | > | snapshot.debian.org, so you can retrace coredumps from previous uploads
> | > | as long as they had a dbgsym package.
> | > 
> | > Thanks a bunch. The link below did fix it. I had just setup a test
> | > environment in Docker and the env.var will do.
> | > 
> | > I think will patch the 'debian/rules snippet' we ship with r-base-core to
> | > instruct dh_strip to not create these for now.  _Right now_ we end up with
> | > Lintian errrors hence my first gut instinct to suppress this.
> | 
> | What error is that (and what version of lintian)?
> 
> E: r-cran-hmisc-dbgsym: extended-description-is-empty
> W: r-cran-hmisc-dbgsym: wrong-section-according-to-package-name 
> r-cran-hmisc-dbgsym => gnu-r
> W: r-cran-hmisc-dbgsym: debug-package-should-be-named-dbg 
> usr/lib/debug/.build-id/
> 

And what version of lintian is this?  If you are using lintian from
unstable or stable-backports, you shouldn't be seeing these warnings.

> | > The -dbg
> | > packages are a good idea; I provide them as eg r-base-core-dbg and for the
> | > GSL etc.  These may make sense for R packages too, but the r-cran.mk 
> snippet
> | > needs some work to postprocess what dh_gencontrol et al create. 
> Volunteers?
> | > 
> | > Dirk
> | > 
> | > [...]
> | 
> | Why do you need any postprocessing of the dh_gencontrol output?  The
> | output of dh_gencontrol for dbgsym packages are synchronized with what
> | dak expects (and requires) of them.
> |   Or are you considering to extend the dbgsym packages with R specific
> | debug information?  That on the other than should be doable, but it
> | would have to happen before the call to dh_gencontrol.
> 
> My analysis may have been premature. This may all be addressable when
> creating a new debian/control entry.  If so shouldn't the build abort when
> there is no new debian/control entry?
>  
> Dirk
> 

I am sorry, I am not sure what you are asking.  Perhaps you could tell
me in details what you are hoping to achieve?

Thanks,
~Niels





signature.asc
Description: OpenPGP digital signature

Re: How shall I report a bug in the .deb packaging itself?

[Ben Finney]

Alberto Salvia Novella  writes:

> I want to report a bug that affects the .deb packaging itself, so
> every single package manager is affected too.

If you have a general (as in, no specific implementable proposal) issue
with Debian package management, a bug report is inappropriate. You need
to have a discussion first to figure out what the problem even is.

> How shall I do it?

Write a post on your weblog, get a discussion going about your ideas for
how Debian package management can be improved, and be prepared to defend
and refine your ideas.

Eventually you'll know enough to either discard the complaint, or come
up with a *specific* implementable proposal to improve Debian.

-- 
 \   “[On the Internet,] power and control will shift to those who |
  `\   are actually contributing something useful rather than just |
_o__)having lunch.” —Douglas Adams |
Ben Finney 

Bug#808569: ITP: awsshell -- The interactive productivity booster for the AWS CLI

[陳昌倬]

Package: wnpp
Severity: wishlist
Owner: "ChangZhuo Chen (陳昌倬)" 

* Package name: awsshell
  Version : 0.0.1
  Upstream Author : James Saryerwinnie
* URL : https://github.com/awslabs/aws-shell
* License : Apache-2
  Programming Lang: python
  Description : The interactive productivity booster for the AWS CLI

 awsshell provides a interactive environment to control AWS services.
 The following features are supported:
 .
 * Auto completion of commands and options
 * Shorthand auto completion
 * Server side auto completion
 * Fuzzy searching
 * Inline documentation
 * Fish-style auto suggestions
 * Command history
 * Toolbar options
 * Dot commands
 * Executing Shell Commands

-- 
ChangZhuo Chen (陳昌倬) 
Debian Developer (https://nm.debian.org/public/person/czchen)
Key fingerprint = EC9F 905D 866D BE46 A896  C827 BE0C 9242 03F4 552D


signature.asc
Description: PGP signature

Re: Can I suppress automatic creation of -dbgsym packages?

[Paul Wise]

On Mon, Dec 21, 2015 at 6:24 AM, Niels Thykier wrote:
> Dirk Eddelbuettel:
>> My analysis may have been premature. This may all be addressable when
>> creating a new debian/control entry.  If so shouldn't the build abort when
>> there is no new debian/control entry?
>
> I am sorry, I am not sure what you are asking.  Perhaps you could tell
> me in details what you are hoping to achieve?

He appears to be assuming that every -dbgsym package will have an
entry in debian/control from the source package. As I understand it,
since these are *automatic* debug packages, debian/control isn't
involved and debhelper does everything automatically.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Can I suppress automatic creation of -dbgsym packages?

[Dirk Eddelbuettel]

On 20 December 2015 at 22:24, Niels Thykier wrote:
| And what version of lintian is this?  If you are using lintian from
| unstable or stable-backports, you shouldn't be seeing these warnings.

I see.
 
| I am sorry, I am not sure what you are asking.  Perhaps you could tell
| me in details what you are hoping to achieve?

I mostly got lost between not having seen the debian-devel post (might have a
candidate for d-d-announce) and having used the wrong lintian version.

It's all a lot clearer now, so thanks again for your help.

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

Re: Automatic dbgsym packages built by default as of today!

[Robert Edmonds]

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,
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
edmo...@debian.org