Re: Trying to disable error=format-security for clapack

[Danny Edel]

On 05/16/2016 06:25 PM, Andreas Tille wrote:
> 
> Would you mind commiting to Git what was building for you?
> 

Hi Andreas,

I would love to, but I doubt it's possible.  I tried something along the
lines of "ulimit -s unlimited && dh_auto_test" as an
override_dh_auto_test, but depending on the environment (local vs.
cowbuilder vs. sbuild) this ulimit call would fail with "Operation not
permitted".

In case of cowbuilder or sbuild, it only works if I unlimited from the
shell I started the builder with, so putting any command inside the
debian/ wouldn't do anything.

The important question is if a stack-size-limit is active on the buildds
or maybe they're already unlimited.  I would suggest packing as-is (only
with the const-pointer change) and uploading to a debomatic, since I
think they're very close to the official buildds.

If it actually fails, I'd suggest coordinating with buildd-admins to
figure out the best way to communicate this requirement.  The tests
don't actually need much memory, they just have a very unusual
stack-to-heap ratio.

Cheers,

- Danny



signature.asc
Description: OpenPGP digital signature

Re: Trying to disable error=format-security for clapack

[Danny Edel]

On 05/16/2016 01:50 PM, Danny Edel wrote:
> If you change it to "const char* const", the compiler is assured it's
> never going to point to anything else and does not emit the warning.

Sorry for replying to my own email, but after compiling, the test suite
crashed on the xeigtstz_* with Segmentation Fault errors.

I debugged this a little bit and the reason was these tests use a lot of
local (i.e. stack) variables -- so many in fact that they trigger a
stack overflow on entry.

Disabling stack size limit (mine was 8192 KB) with
  ulimit -s unlimited
before calling dpkg-buildpackage fixed things for me.

I hope this avoids someone the half hour I spent in gdb searching for a
bug that probably isn't there.

- Danny



signature.asc
Description: OpenPGP digital signature

Re: Trying to disable error=format-security for clapack

[Danny Edel]

On 05/16/2016 11:07 AM, Andreas Tille wrote:
> /build/clapack-3.2.1/F2CLIBS/libf2c/arithchk.c:125:2: error: format not a 
> string literal and no format arguments [-Werror=format-security]
>   Cray1 = printf(emptyfmt) < 0 ? 0 : 4617762;

Hi Andreas,

you should have success with changing the type (insted of the value) of
emptyfmt, rather than disabling any warnings.

Right now it's "char *", which is legal C, but problematic, since
character literals are not allowed to be written to anyway and might
even be placed in read-only memory[1].  Just the type "readwrite pointer
to readwrite character" probably triggers the warning.

If you change it to "const char* const", the compiler is assured it's
never going to point to anything else and does not emit the warning.

Cheers,

- Danny

[1]: http://en.cppreference.com/w/c/language/string_literal
--- a/F2CLIBS/libf2c/arithchk.c
+++ b/F2CLIBS/libf2c/arithchk.c
@@ -110,7 +110,7 @@
 	return 0;
 	}
 
-char *emptyfmt = "";	/* avoid possible warning message with printf("") */
+const char * const emptyfmt = "";	/* avoid possible warning message with printf("") */
 
  static Akind *
 ccheck(void)


signature.asc
Description: OpenPGP digital signature

Re: Uniqueness of .deb versions/filenames over distributions

[Danny Edel]

On 02/27/2016 04:05 PM, Tim Landscheidt wrote:
> http://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html#GBP.BRANCH.NAMING
> recommends using different Git branches for jessie, stretch,
> etc., but I fear that such a layout could easily cause them
> to go out of sync as it puts the burden on the committer to
> repeat his changes on another branch.

Hi Tim,

Just to add on that, since I discovered it more by chance myself:  Using
dpkg-mergechangelogs from dpkg-dev package, keeping those branches in
sync becomes really trivial.  Just activate it (see manpage) and feeding
the changes from master into backports becomes as simple as:

git checkout jessie-backports
git merge master
dch --bpo


And to the original question:

>From my understanding, within Debian you can assume that
package_0.1_amd64.deb is the binary created in sid when it was initially
uploaded.  Any new upload (even a binary-only) will add something to the
version number.  So within Debian, same filename means same contents.


Note that Ubuntu will copy the source and if I remember correctly
recompile it into their current development snapshot *without* adding
something to the version number.  So the Debian and Ubuntu binary will
have the same filename, but possibly different contents, depending on
the toolchain.  If the linked binary libs have different ABIs, you're
running into undefined behaviour if you would try to execute a binary
compiled against sid under precise.  Due to the way Ubuntu changes their
GCC version at a different schedule than Debian, this is more likely
than you might think.

It is most likely safe to assume that other Debian-based distributions
do a recompiliation without changing the filename too.


tl,dr:  As soon as we're talking about multiple Distributions (Debian vs
Ubuntu being the most common example), assume same file means different
contents.  *Within* one distribution (Debian jessie vs. stretch, or
Ubuntu precise vs. trusty), same filename will mean same contents.


If you want to avoid yourself some hassle, either only upload to
debian/sid, and ask an Ubuntu dev to auto-sync your package into the
current ubuntu development version, or keep multiple branches for
multiple distributions and treat them all as backports of sid.

Note your sources won't be 100% identical (think of the first line in
d/changelog, it contains the suite name), so keeping the (even small)
diff's in version control is not necessarily a bad thing.

If you treat precise the same as jessie-backports, your workflow will
produce a d/changelog similar to the following:

package (1.0~precise1) precise

* Port to precise
* No source changes

 -- Yourname Timestamp

package (1.0) unstable

* What changed in 1.0

 -- Yourname Timestamp

package (0.9~precise1) precise

* Port to precise
* changed d/rules to be compatible with older dpkg-dev

 -- Yourname Timestamp


Using the above git commands, maintaining them only costs you seconds,
but to the user of your package it's clear that active development
occurs on Debian unstable and is then ported to precise.  And since you
have it all in git, the "changed d/rules" will get correctly merged
and/or trigger a merge conflict, alerting you to the issue.


Hope this helps a little,

- Danny

Is there a "deb bisect" to figure out when exactly a build broke?

[Danny Edel]

Hi Mentors,

I am maintaining the dspdfviewer package in Debian and it now fails to
build (testsuite fails) on big-endian arches on sid, bug #816081.  The
same source compiles against an older release (jessie) just fine, so I
think this is a regression in some™ package in the dependency chain.

In order to figure out which package to file a bug against, I'll
obviously have to try building against sid from various points in time,
using snapshots.debian.org.


So my question is:

Is there any automated tool for the process?  Ideally, I would pass it
my .dsc, seed it with "It worked at date xyz, it does not work now" and
leave it running for a few days, similar to how a "git bisect" works,
and it would output the information
* Last good sid snapshot $gooddate
* First bad sid snapshot $baddate
* Bonus points: Diff of the depchain between $gooddate and $baddate


If there is no such tool available, I'd start my debugging session by
writing one up, but I'd obviously like to avoid duplicate work (Just
because I havn't found one doesn't mean there is none)


Thank you all,

- Danny

Re: Bug#777791: ball: ftbfs with GCC-5

[Danny Edel]

Hello Andreas, hello list(s),

I tried to reproduce this build failure on a current sid and investigate
a bit.  On my machine it outputs the same basic error messages (although
the line numbers in the basic_string template file are a bit different).

I try to quote the error message partially so it becomes a bit clearer
what is really going on:

On 01/07/2016 01:12 PM, Andreas Tille wrote:
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC: In member function 
> 'BALL::String& BALL::String::insert(BALL::String::const_iterator, 
> std::initializer_list)':
> /build/ball-1.4.3~beta1/include/BALL/DATATYPE/string.iC:1379:19: error: no 
> matching function for call to 
> 'std::__cxx11::basic_string::insert(BALL::String::const_iterator&, 
> std::initializer_list&)'
>   str_.insert(p, li);
>^

(...)

Info:
BALL::String::const_iterator is a typedef for std::string::const_iterator


> /usr/include/c++/5/bits/basic_string.h:1308:7: note: candidate: void 
> std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::insert(std::__cxx11::basic_string<_CharT, _Traits, 
> _Alloc>::iterator, std::   initializer_list<_Tp>) [with _CharT = 
> char; _Traits = std::char_traits; _Alloc = std::allocator; 
> std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::iterator = 
> __gnu_cxx::__normal_iterator; 
> typename __gnu_cxx::__alloc_traits __gnu_cxx::__alloc_traits<_Alloc>::rebind<_CharT>::other>::pointer = char*]
>insert(iterator __p, initializer_list<_CharT> __l)
>^
> /usr/include/c++/5/bits/basic_string.h:1308:7: note:   no known conversion 
> for argument 1 from 'BALL::String::const_iterator {aka 
> __gnu_cxx::__normal_iterator 
> >}' to 'std::__cxx11::basic_string::iterator {aka 
> __gnu_cxx::__normal_iterator}'


In essence this says:

(1) No matching function for
string::insert(string::const_iterator, initializer_list),

because (when trying the correct overload),
(2) Cannot convert from string::const_iterator to string::iterator


Which raises the question: Why does the compiler try to convert to a
non-const-iterator in the first place?

According to both cplusplus.com[1] and cppreference.com[2] the insert
function with an initializer_list as second parameter should take a
*const_*iterator directly.

I have condensed this into a simple test case (see attached string.cc)
and for me, this testcase fails in the same way as ball when called with
GCC.

Try it like this:

g++ -std=c++11 string.cc -o string && ./string
(long error message)

Now, with clang++ this fails too:

clang++ -std=c++11 string.cc -o string && ./string
(a bit shorter error message, but essentially the same)

However, if I try the example using clang's STL implementation (from
debian package libc++-dev) it builds *and runs* as expected:

clang++ -std=c++11 -stdlib=libc++ string.cc -o string && ./string
(outputs "Some new string")


I am not sure how to continue from here - this might be a bug in clang's
or gcc's std::string implementation, unportable usage from upstream, or
any number of other things.  If you have access to other compilers, it
may help to test the snippet on them too and report the results.

For reference:

$ g++ -dumpversion
5.3.1

-> Does not compile, cannot convert const_iterator->iterator
-> libstdc++-5-dev 5.3.1-5

$ clang++ -dumpversion
4.2.1

-> Does not compile with default/gcc STL implementation
-> Compiles and runs with libc++-dev 3.7.0-1


I hope this helps in resolving this, or at least in figuring out *where*
the issue actually is located.

- Danny


[1]: http://www.cplusplus.com/reference/string/string/insert/
[2]: http://en.cppreference.com/w/cpp/string/basic_string/insert
#include 
#include 

using namespace std;

int main(){
	string s = "Somestring";
	string::const_iterator ci = s.cbegin()+4;
	initializer_list il = { ' ', 'n', 'e', 'w' , ' ' };
	s.insert(ci, il);
	cout << s << endl;
	return 0;
}

Re: Uploaded package is not showing up in mentors

[Danny Edel]

On 06/10/15 20:48, Petr Vorel wrote:
> Hi there,
> 
> I'm another one who experienced the problem of not being able to upload 
> package to
> mentors.debian.net. I tried several times, wait few days...
> 
> Build and sign package and upload it with
> dput mentors ../freerdp_1.1.0~git20140921.1.440916e+dfsg1-6_amd64.changes
> I'm building with debuild.
> 

Hi Petr,

your package name contains "amd64", suggesting you tried to upload a
binary.  Mentors is source-based, so it may have been silently rejected.
Please try building with

debuild -S

(capital S results in *only* the source package being built) and then
dput the resulting foobar_source.changes file.  If I remember correct,
the confirm/reject email gets sent to whatever mail address is specified
in the gpg key that signed the package, so make sure to use the right
gpg key; debuild will by default pick a key matching $DEBEMAIL
environment variable, see its manpage for more details if you need to
override this.  If you now get a reject mail complaning about the gpg
key, make sure its added at the /my page of the server.

Hope that helps a bit,

  - Danny

Re: don't use sbuild --dist/-d and other sbuild stuff

[Danny Edel]

Hi,

On 31/08/15 15:53, Johannes Schauer wrote:
> for the pure purpose of building a source package, having devscripts installed
> for debuild is not needed. You can instead use dpkg-buildpackage directly.
> Though, if you really just want to build the source package, then even better
> than `dpkg-buildpackage -S` is to run `dpkg-source -b .`. The advantage is,
> that you do not have to have any packages installed which are necessary to run
> the clean target. You probably don't want to install any extra packages like
> that on your host if you are using sbuild later anyways.

Thank you, didn't know that yet. I'll start using that myself and see if
I ever run into any problems.

> It must be mentioned that a common problem with sbuild is, that the .changes
> file it generates will have a *different* distribution from the one you set in
> debian/changelog if you use the --dist or -d option! If sbuild changed the
> value of the distribution field in the .changes file, it will do so in *red*
> but it is still easy to miss this.

Thanks for pointing that one out! I missed that aswell.

For *mentors* this is only a minor issue since only the source package
will get uploaded later on, but in any case the Handbook should teach
how to do it right from the start. Sorry for spreading misinformation.

Something that should also go into the mentors wiki is when to use
codenames and when to use suite names in changelog (for example we write
wheezy-backports rather than stable-backports, but we write unstable
insted of sid). If there's already an official document clarifying this,
I didn't find it.

> Please comment over there if you have a good idea to solve this common 
> mistake.

As soon as I've got something constructive it will be there.

>> I would recommend setting up a local (partial) debian mirror to speed up the
>> package fetching step, but I've gotten weird "500 invalid header" errors when
>> I use apt-cacher-ng, so I'm not recommending this for now.
> 
> I am using apt-cacher-ng as well but I don't think I've encountered HTTP 500
> errors so far. Maybe you can investigate the issue and file a bug?

I am investigating, but so far I get them randomly and have not been
able to reproduce them reliably.

Its either something weird in one of my network components or some kind
of race condition, so I'm unable to send any useful bug reports yet.

>> The only sbuild configuration line I *strongly* suggest is
>>
>> $environment_filter = [ ];
>>
>> This will ensure that no CXXFLAGS= or similar from your working environment
>> contaminate the clean chroot.
> 
> If you think the default should be changed, could you please file a bug 
> against
> sbuild about that?
> 
> Thanks!
> 
> cheers, josch
> 

I should have written that a bit more mentors specific.

I believe the default configuration is absolutely fine for the default
usecase (buildd/sbuild machine). No bug here.

Just for the usecase "Individual developer checking for FTBFS" it may
not be what we want:
We might have $stuff in environment (think -Wall -g) that might make
sense in a programmer's enviroment. But when building a debian package
this shouldn't go over to sbuild.
I wouldn't touch the system-wide or even default file, this was purely a
suggestion for the users' ~/.sbuildrc. Sorry if the wording was ambiguous.

- Danny

Re: Questions before my first upload attempt

[Danny Edel]

On 20/08/15 18:33, Thomas Schmitt wrote:
 
 - https://wiki.debian.org/DebianMentorsFaq#How_do_I_make_my_first_package.3F
   Put a package together, built against a current version of sid.
 
   I'm on Jessie 8.1. The dependencies of the packages in question
   are very basic. The package sources are portable to any X/Open
   compliant system. Tested upstream on very old GNU/Linux, FreeBSD,
   Solaris, and NetBSD.
   I understand i have to submit source packages anyway.
 
   So is there a way to do my packaging work in Debian 8.1 ?
   (The PackagingTutorial says i shall write 9 into
debian/compat. Is that enough of a sid ?)
 
   Else: Is there a shortcut description how to quickly set up
   Debian package development in a virtual machine and how
   to keep it up to date ?
   (Hardware is plenty but my own VM scripts date back to Debian 6.)

Hi Thomas,

Debian actually has ready-made VM scripts for you.

You want to take a look at the sbuild system, it can create a minimal
sid tarball chroot-virtualmachine and use it to build packages for
you. Using sbuild will be as close as it gets to the official buildd
machines, helping you to prevent FTBFS¹. sbuild machines install a bare
minimum of packages plus your specified build-dependencies into a
throwaway directory, build the package and delete everything except the
build log and created .deb, returning to a clean state.

Pointer: https://wiki.debian.org/sbuild

Once sbuild is setup, you can call either sbuild --dist sid from
inside the source directory (quick result, but I wouldn't recommend it)
or call debuild -S on your host machine first:
This will create a .debian.tar.xz and a (signed) .dsc file in .., then
you can call sbuild --dist sid your-package_version.dsc. If that goes
through, you know your dsc is good and you can upload it to mentors with
dupload --to mentors my.changes. (That's why I recommend this two-step
route, since than you have this dsc that built correctly. Btw, the
dupload step will check if you signed correctly)

For bonus points, if you are on a machine that can chroot different
arches (for example amd64 hosts can create a i386 chroot) you can verify
it compiles on both.
Just call another sbuild-createchroot with --arch i386 and then call
sbuild --dist sid --arch i386 my.dsc to build on it.

Be warned that in addition to where you store the sbuild-tarball, the
schroot system will also need enough space to hold the *unpacked*
tarball *plus* all temporary installed packages (build-dependencies) at
/var/lib/schroot, so make sure to have  10G space there.

 
 - I still did not find a hands-on description of fulfilling
   the demand of http://mentors.debian.net/intro-maintainers:
 All packages must be signed with the GnuPG key you configured
  in your control panel.

Set the environment variables DEBNAME=Your Full Name and
DEBEMAIL=your@email.address. Then, when you call debuild -S, gpg will
automatically be called with the right options, all you have to do is
enter your privatekey password : )

 
   http://mentors.debian.net/my has my public key now. I guess
   this does the necessary configuration.
   But how to use gpg or other programs to sign the packages ?
   As GNU maintainer i use on tarballs
 gpg -o ...sig -u ...
   on announcement messages
 gpg --clearsign ...
   Suspiciously all newbie tutorials for Debian packaging
   propose to use options -us -uc, which i understand prevent
   some kind of signing.

This is probably since it prevents the gpg-askpass from starting, and
personally while testing stuff I also use -uc -us (also good for
automated testing, since my privatekey won't be available there). The
tutorials should include a little information that -uc -us is not meant
for production use.

Have fun sbuilding : )

- Danny

¹ Failed To Build From Source. For example, if you don't specify all
build-dependencies. Debian buildd/sbuild will also not install
Recommended: dependencies [after all, they are allowed to be omitted],
but end-user systems will by default.

PS: Just a word of warning: If your sid builds fail with strange linker
messages having to do with std::__cxx11::something, you're out of luck
for now and you've ben hit with the GCC-5/libstdc++6-5 transition. Lets
hope it won't come to that though : )

Re: Questions before my first upload attempt

[Danny Edel]

On 21/08/15 15:42, Thomas Schmitt wrote:
 Well, i need to make some progress with uploading.
 So i'll go on with the VM for now. I need to learn a bit more
 about what sbuild does. On the long run it looks cleaner.

Hi Thomas,

sbuild basically implements what you have started to build in your VM.
The main advantage of it is the ...and throw everything away to get a
clean starting point, so you have a reproducible and minimal build
environment.
Also sbuild's basic set of packages does not include an X server.

However, you now have a VM containing debian's equivalent of a latest
of all open source stuff machine. It can be fun to play around on it,
and if you find any bugs in those (not-yet-in-stable) versions, I'm sure
the maintainers will greatly appreciate reports. (Just don't depend on
sid in the same way as you would on a stable. Have backups.)

 
 Which one to install ?
   dput: /usr/bin/dput
   dput-ng: /usr/bin/dput
 My Jessie obviously has dput installed.

I have non-ng dput aswell, havn't tried the new one yet.

 
 So many branches ...
 

Just to add to the branches: The same thing sbuild does (build in
cleanroom chroot to verify build-depends) is also implemented as
pbuilder. As an alternative to dput{,-ng}, there is also dupload.

I wouldn't say there's a definitive better one, but having more than one
tool for the same problem might turn in handy if one has a bug and/or
breaks. I ultimately chose sbuild over pbuilder because its what
official buildds use.

Take a look at man devscripts (package name also devscripts) as an
overview of even more little helpers.


- Danny

Re: Questions before my first upload attempt

[Danny Edel]

On 21/08/15 13:21, Danny Edel wrote:
 Once sbuild is setup

Just to clarify. In this use case (using sbuild as close to buildd as
possible), the steps labeled for personal use in
https://wiki.debian.org/sbuild#Configuration
are *not* what we want.

The Source package will be created by debuild -S on the host machine,
and sbuild will *only* build the binary.

So the entire (!) series of installation steps is:

* (root) apt-get install sbuild
* (root) mkdir -p /root/.gnupg
* (root) sbuild-update --keygen
* (root) sbuild-adduser $YOURUSERNAME

logout-relogin or use newgrp sbuild in your current shell. Now to
create the chroots:

* (root) sbuild-createchroot --make-sbuild-tarball=/var/lib/sbuild
--arch amd64 /sid-amd64.tar.gz sid $(mktemp -d)
http://httpredir.debian.org/debian

* (root) sbuild-createchroot --make-sbuild-tarball=/var/lib/sbuild
--arch i386 /sid-i386.tar.gz sid $(mktemp -d)
http://httpredir.debian.org/debian

Thats it. Note that you can also use wheezy or jessie if you plan on
testing backporting to those.

From now on, sbuild --dist sid --arch amd64 path/to/my.dsc works.
This will implicitly call dist-upgrade, install build dependencies, copy
files around and work its magic while you're enjoying your coffee. (Yes,
this really can take a while).

I would recommend setting up a local (partial) debian mirror to speed up
the package fetching step, but I've gotten weird 500 invalid header
errors when I use apt-cacher-ng, so I'm not recommending this for now.

The only sbuild configuration line I *strongly* suggest is

$environment_filter = [ ];

This will ensure that no CXXFLAGS= or similar from your working
environment contaminate the clean chroot.

- Danny

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

On 05/08/15 17:10, Danny Edel wrote:
 I won't have it ready today, expect a revised package tomorrow.

While going through the changes, I actually stumbled upon a regression,
forcing me to release a bugfix/maintenance version v1.13.1 upstream.

I used the opportunity to do some cleaning:

* Create an upstream changelog. debhelper found it and auto-compressed
it without any change to debian/rules or similar.

* All the build-system-things in debian/patches that were in
upstream/master have been backported into upstream/release, landing in
v1.13.1. So now the debian/patches directory is empty and other dists
benefit from the cleanups (such as letting the packager decide -g with
-DCMAKE_BUILD_TYPE)

* The .desktop file is included, and it is in upstream/release aswell.

* I could practice importing a new source release and test out the
debian/watch file (it works!). I remembered the Only one changelog
entry rule and re-wrote debian/changelog, so that its still a fresh
package.

* The two remaining comments in debian/rules are from me, no more
boilerplate copies.

* I used the documentation on https://wiki.debian.org/DebugPackage to
create a -dbg package, and corrected the lintian errors.
- Is there any way I can verify that this -dbg package works correctly?
The linked wiki page doesn't list that.

* Both source and binary are completely silent with the EvIL lintian
command you showed me.


So now there's a revised package at

http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13.1-1.dsc

It would be good if you could take a final look at it (Now hopefully
bug-free). Especially the -dbg part I'm not 100% sure if I added that
correctly, or if I messed up $stuff while migrating the debian/
directory to the new version.


If everything is in order, please tell me what I have to do to trigger
the uploading/inclusion process into official Debian.

-- 
Many thanks again for your mentoring,

Danny

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c360b6.6020...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

Hello Gianfranco,

On 06/08/15 16:16, Gianfranco Costamagna wrote:
 Reading symbols from /usr/bin/dspdfviewer...Reading symbols from 
 /usr/lib/debug/.build-id/c2/c35e6f96f063aff4e0d6e3e644855c31b11a0f.debug...done.


Ah yes, it says something like that for me now too, once I install
dspdfviewer-dbg. Success!

 let's wait for unstable/testing to have some people feedbacks
 

While I may be a little bit scared, I'm really looking forward to that
part : )

 thanks to you for the good package and your nice contribution to 
 Debian!

I think the entire open source concept is great - instead of
re-inventing the wheel, I could simply link a couple of libraries (which
were in Debian) together and create the program I needed.

Now I finally managed to give back to that pool, and I hope the program
will help someone on their Bachelor thesis or similar presentation,
saving them from re-inventing the wheel in turn.

 
 I see you did a really good job, and the package was already in a 
 good shape, my suggestions were mostly cosmetic.
 
 I have one more suggestion: please consider having an
 package.install file instead of overriding dh_auto_install, the same
 for the dh_installdocs
 
 (the respective manpages can help you).

Those sections were directly cut-and-paste from the Debian wiki at
https://wiki.debian.org/DebugPackage.

So if there's a better way to handle -dbg packages with debhelper 9,
this documentation site should be updated too.
It also seems that the CDBS software is designed to do the splitting of
main and debug binary package with one command. I will read into
CDBS aswell, maybe I can simplify debian/rules by using that.

I will report back once I find out more.

 
 I guess this will simplify the packaging, but it is a matter of de 
 gustibus.
 
 I hope to see your contributions again, I enjoyed your packaging, I 
 hope to see you as Maintainer or Developer one day :) (let me know
 if you want to work on some packages, I can review them also
 privately or through the list)
 
 cheers!
 
 Gianfranco
 

Thank you very much. I wouldn't mind helping out when I can. I'll go
through the wnpp list, see if anything I am actively using asks for
help, and communicate with you about the details.

PS: You don't have to CC me for on-list-mails either, I have
debian-mentors subscribed aswell.

-- 
Cheers

Danny


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c375c6.9030...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

 both for your input. It improved the quality of my proposed
package by a good amount and I'm getting more confidence in the debian
package already.

-- 
Danny Edel

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1d51c.5090...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

On 05/08/15 11:52, Gianfranco Costamagna wrote:

 Some issues:
 1) please provide a .desktop file if possible

I will.

 2) it seems to work bad with an external monitor.
 
 It splits the pdf half in the main monitor and half in the extended one.
 
 I'm attaching a picture.

This is working exactly as intended : )

Try the -f / --full-page command-line switch for regular PDFs.

The main feature is the double-width thing, since latex-beamer
presentations support a Notes to the presenting person mode, where
they output a double-width PDF with the actual presentation on the left
half, and the notes on the right.

The reason I wrote this viewer was that while this is really useful,
there was no viewer that actually did this splitting on runtime. Hence
dspdfviewer came to life : )



I have created a super basic example at

https://github.com/dannyedel/example-beamer-presentations/releases/tag/v0.1

Of course, the \note{} things will be a lot more sophisticated on real
presentations, but I think you get the idea.



 
 Let me know if you open an RFS bug.

I have sent an email to the submit bug, but from my m...@danny-edel.de
address. I guess it isn't unblocked yet, but I want to wait for a safe
time before I post from deb...@danny-edel.de. I'd rather like to avoid a
doublepost.



 
 (I can eventually sponsor the package BTW)
That would be amazing! Should I even file an RFS bug again then (in case
the email doesn't get through)?

-- 

Cheers,

Danny

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1e408.3060...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

On 05/08/15 12:44, Gianfranco Costamagna wrote:
 This is working exactly as intended : )
 
 Try the -f / --full-page command-line switch for regular PDFs.
 
 
 ok, I thought this was a bug... BTW I have the main monitor to the
 left, and the extended to the right, why does it show the opposite
 order for regular pdfs?
 

If you pass no command-line switch it assumes its a double-width pdf,
which has the presenter side on the right and audience on the left.

It should™ render the presenter view (with the clocks and the notes) to
the primary screen (you can set with xrandr --output XXX --primary),
regardless of whether that primary is left or right.

This assumes that a presenter will carry his or her notebook to the
site, have the internal screen as primary and the external (beamer) as
secondary.

If this auto-detection fails, hit the S (swap-screens) key on the
keyboard.

 
 Usually one hour is enough, the mail are processed I guess each 10
 minutes or so.
 

Allright. I'm assuming m...@danny-edel.de is still blocked, and will
continue to use deb...@danny-edel.de with mailinglists and bugtracker.

 that would be my first sponsored package, so maybe would be nice to
 have some other eye on the package, but I guess as soon as I get more
 confident with the sponsoring and the package is already on
 unstable/Stretch you can ping me directly.

Cool! I have uploaded the changed version (now with .desktop file) and
will re-file the RFS from my deb...@danny-edel.de address, unless you
find another mistake in it.

http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

-- 

Cheers,

Danny

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c1f473.7010...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

On 05/08/15 13:53, Gianfranco Costamagna wrote:
 maybe that s should be put in the manpage somewhere?

Well, it is, under the controls section. But I guess that's not really
well-placed, since you didn't find it straight away : )

If you have a suggestion on where to place and/or how to re-word the
manpage, that would be much appreciated. Since I'm more a developer than
a user (and I know the software inside out anyway) its difficult for me
to think from a user perspective.

 BTW another nitpick is the lack of an icon for the application, 
 gnome-shell shows the default missing icon icon.

I *would* fix that *if* I had any graphical skills. But I have created
an issue in my souce repository, maybe I can find someone™ to imagine
something nice.

 I: dspdfviewer: hyphen-used-as-minus-sign 
 usr/share/man/man1/dspdfviewer.1.gz:118

That's actually quite a cool diagnostic, I will fix that.

How did you make lintian tell you that? I ran --display-experimental
--fail-on-warnings --info --display-info --pedantic on both
source.changes and amd64.changes (from sbuild) and all I got was the
no-upstream-changelog.

 P: dspdfviewer: no-upstream-changelog

v1.14 and up will have an upstream changelog in the tarball.

 The desktop file works correctly, and it lacks of an icon too (not
 an issue, but it might lead to a bad user experience)

Ticket is created, but I can't promise much on the creativity front.

 
 other stuff: why do you add ggdb in the cmake file? it should be 
 handled by Debug and RelWithDebInfo (passed by dh IIRC)

I did add that in the very start (and seems to have forgotten about it).
The reason was that on -CMAKE_BUILD_TYPE=Debug it only added -g (without
-ggdb) and thus working with gdb wasnt super useful.

I have removed it, since I can always inject CXXFLAGS=-ggdb on my devel
machine.

 
 and another issue, why do you handle the Debian revision in such a 
 complicated way?
 
 what about just using 1.13 instead of 1.13-1 passed as variable to 
 cmake?

The reason behind the weird Let the (dist-specific) build system embed
a version number was to encode as much information about the system as
possible, even if a user just posts dspdfviewer --version to a bug
report, a few examples:

* 1.13: User built from release tarball (unchanged)
* v1.13 or v1.13-xx-gDEADBEEF: user built from a git clone
* 1.13-rc0: User built from git (ie. non-release), but deleted .git dir
* 1.13-1: Official debian package
* 1.13-1~bpo80+: Official debian backport
* 1.13+0~20150804124310.32+sid~1.gbpf1ed24: jenkins-debian-glue

(Launchpads auto-builders use similar long and detailed version numbers)

The last line shows the ultimate Idea behind it: The
jenkins-debian-glue, launchpad etc. scripts all modify the
debian/changelog to add a version tag that (a) makes sure more recent
git versions sort higher, and (b) make sure the debian-revision contains
the git version originally built from. My Idea was to clone that magic
into dspdfviewer --version.

OT: With you pointing me to the -rc0 I left in there, I realized that I
actually *added* that (it did say 1.13) before I released 1.13 tarball,
thereby failing to distinguish between 1.13 exact and post-1.13.

Guess I shot my own foot there, but the idea should™ hold up for 1.14.

 BTW instead of the export I would prefer something like 
 dh_auto_configure -- -DYOURVAR=YOURVALUE
 
 but again, if not necessary you can just use the fallback at line
 105 I guess. (maybe after updating it!)

For the above reasoning, I would really like to pass the Debian
version to the build system.

If there is a standard debian way of doing this, I can of course always
change the method, it's really all about easily™ creating meaningful
bug reports. (If its a problem I can of course remove the stance from
the debian/rules entirely)

As long as a debian user uses reportbug, I guess that doesn't matter. It
is more an issue if I get an email directly, or people post to the
github issue tracker.

So ultimately, I leave the decision to you whether I strip the inclusion
logic.


Updated version at
http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

And I will re-send the RFS template from deb...@danny-edel.de, if I read
it correctly they will cross-post to debian-mentors automatically.

-- 
Cheers,

Danny Edel

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c21553@danny-edel.de

Bug#794665: RFS: dspdfviewer/1.13-1 [ITP] -- Dual-screen PDF viewer for latex-beamer presentations

[Danny Edel]

Package: sponsorship-requests
Severity: wishlist

Dear mentors,

I am looking for a sponsor for my package dspdfviewer

* Package name: dspdfviewer
  Version : 1.13-1
  Upstream Author : Danny Edel m...@danny-edel.de
* URL : http://dspdfviewer.danny-edel.de
* License : GPL version 2 or, at your option, any later version
  Section : text

It builds those binary packages:

dspdfviewer - Dual-Screen PDF Viewer for LaTeX-beamer

To access further information about this package, please visit the
following URL:

  http://mentors.debian.net/package/dspdfviewer


Alternatively, one can download the package with dget using this command:

dget -x
http://mentors.debian.net/debian/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

More information about dspdfviewer can be obtained from
  * https://github.com/dannyedel/dspdfviewer
* Sourcecode and issues tracker
  * http://dspdfviewer.danny-edel.de
* Website

Changes since the last upload:

dspdfviewer is not yet in debian, so there are not really changes yet.

However, I initially posted directly to the mailing list and didn't know
to file the bug report. This thread can be found on

https://lists.debian.org/debian-mentors/2015/08/msg5.html

Thanks to the feedback I got in response, the package is much cleaner
now and hopefully can be included in Debian.

-- 

Regards,

Danny Edel

m...@danny-edel.de
deb...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c215a9.8040...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

On 05/08/15 16:15, Gianfranco Costamagna wrote:
 
 nope, the manpage is correct, I tried a --help, and I didn't find it
 (sorry for the confusion)
 
 If you have a suggestion on where to place and/or how to re-word the
 manpage, that would be much appreciated. Since I'm more a developer than
 a user (and I know the software inside out anyway) its difficult for me
 to think from a user perspective.
 
 
 that is something always difficult... Maybe the --help can be more similar to 
 the 
 good manpage? :)

Right now, --help is simply boost_program_options' default output, which
I find pretty nice, especially considering how few option-parsing and
help-outputting lines of code I actually had to generate myself.

I will add a sentence stating that interactive keybinds are stated in
the manpage.

For me it feels natural that a program only tells me
--command-line-switches on --help, and I will find the rest in the
manpage, but an additional pointer can't hurt. The only thing I'd like
to avoid is more duplication between --help, man dspdfviewer and website
(since  one of them always forgets to get updated, and thanks to Murphy,
that's the only one the user did read : )


 lintian -EvIL +pedantic --profile debian/main 
 ../dspdfviewer_1.13-1_amd64.changes
 
The EvIL pedantic lintian. Shell-aliased to lint now : )


 
 
 they are always suggestions, so feel free to leave it if you think users 
 might benefit
 (what about creating a -dbg package? since it is a new package you might 
 benefit from one
 trip only in the NEW queue)
 

I have never created a -dbg package, but if that helps Debian-users to
generate meaningful backtraces -- Who could say no to that : )

I'll revise the source package and work in the -dbg stances.


 
 This is equivalent actually for Debian (it will allow you to remove 6 lines 
 from the CMakeFile),
 but it might be a problem for other Linux based Distro around the globe.

Right now, I'm thinking about renaming the env-variable from
DEBIAN_PACKAGE_VERSION to DISTRIBUTION_PACKAGE_VERSION or something
similar to be cross-distribution, and nicely ask the maintainers of
$dist to add some dist-specific postfix to it (I know gentoo has -r1) if
they changed any source files.

But i guess for now we can use debian/rules to (always) enter if@71.

 
 Having one single way to feed the version might be a benefit for everybody
 

v1.14 will have that most likely (less cruft wins) : )


 BTW the new rules file is what I intended previously, and makes lines 91:96 
 useless now :)
 
 (not asking you to remove, just pointing that to you).
 
 Last thing:
 
 d/rules, lines 2 to 8, I guess you can remove them
 

I will. Just seemed like a boilerplate keep it in there, but since it
says itself without restrictions I guess it's best to delete
boilerplate comments so you only have to read the ones actually from me.

 let me know about the last two things (specially for the dbg package, that is 
 something important)
 and I'll do the upload

I will make the dbg package (didnt know about that), so please don't
upload just yet.

I won't have it ready today, expect a revised package tomorrow.

-- 
Cheers,

Danny


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c22750.4070...@danny-edel.de

Re: RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

Hello Riley,

thank you for listing those things!

I will comment on each of your points inline, I hope that's okay.

On 04/08/15 00:02, Riley Baird wrote:
 
 Hi Danny,
 
 I'm not a DD, so I can't sponsor your package, but I had a look and
 here are some things that I noticed:
 
 d/changelog:
 -Since the package hasn't been uploaded to Debian yet, you should only
 have one changelog entry; you should get rid of version 1.13-2.

Done. Only version is 1.13-1

 
 d/compat:
 -Have you considered upgrading to debhelper 9?

Tried that now, thank you for the suggestion! Reading up on hardening,
requiring recent debhelper allowed me to drop quite a lot of lines from
debian/rules aswell since it includes the cmake workaround.

 
 d/control:
 -Priority should be optional.

Done.

 
 d/docs:
 -You could add INSTALL and README.md to this file

I tried that, but then lintian complained on the binary package
containing an INSTALL file. Only README.md is included now.

 
 d/manpages:
 -You don't need this file.

File deleted.

 
 d/README:
 -You don't need this file.

File also deleted.

 
 General:
 -If m...@danny-edel.de isn't being accepted by the Debian mailing
 lists, you can get whitelisted by subscribing to this list:
 https://lists.debian.org/whitelist/

Thanks! I've written my email inside there. Until I hear from them, I
will mail as deb...@danny-edel.de to the mailinglist (just to be safe).
My email address in the package is now m...@danny-edel.de, as I use
everywhere else.

 -Seeing as you're upstream, you should be able to fix the lintian
 error debian-watch-may-check-gpg-signature

Done, I hope.

I locally created a fresh tar.gz from my signed git tag and
detach-sign'd it, and mirrored the resulting asc to github. So far,
their tarball matches : )

Could you take a look at the debian/watch file? Those opts and regexes
twisted my mind a bit, not sure if I have done that right.

 -Also seeing as you're upstream, in future releases
 you might consider fixing no-upstream-changelog. You don't have to do
 that now, though. :)

I will.

 
 Good luck getting your package into Debian,
 
 Riley Baird
 

Thanks : ) Could you also take a look at the revised version? Its at

http://danny-edel.de/deb/pool/main/d/dspdfviewer/dspdfviewer_1.13-1.dsc

That would be amazing. I also tried to upload this to mentors with

$ dupload --to mentors dspdfviewer_1.13-1_source.changes

and it gave me the following error in an email:
 Hello,
 
 Unfortunately your package dspdfviewer was rejected because of the following
 reason:
 
 Your upload does not contain a valid signature. Output was:
 
 gpg: Signature made Di 04 Aug 2015 11:32:53 UTC using RSA key ID 7183343C
 gpg: Can't check signature: public key not found
 
 
 Please try to fix it and re-upload. Thanks,

Do you know where I have to send my public key, so that mentors finds it?

Thank you again for helping me.

-- 
Danny Edel

m...@danny-edel.de


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c0adc7.6080...@danny-edel.de

RFS: Looking for a mentor for my dspdfviewer package

[Danny Edel]

Dear Debian mentors,

I have created a debian package for my project dspdfviewer, a
dual-screen pdf viewer specifically made for LaTeX-Beamer presentations.
I have been programming and maintaining this since winter 2012/2013, and
I believe it is stable and mature enough now to be included in Debian.


I have filed an Intent To Package (Debian Bug #794319) and in the
meantime I have tried my best to create a proper debian package.

It is available for download at [my server] and now compiles cleanly and
without lintian warnings on sid (I have tested amd64 and i386 in
sbuild'ers, but I don't have access to other architectures)

I can also try to upload the package into the mentors service, if that
is preferred.



This is my first attempt at an official Debian package, so I expect I
will have done quite a bit wrong, so please point me to mistakes and I
will do my best to remedy them.

From https://wiki.debian.org/DebianMentorsFaq#Sponsored_Packages

 Name of the package

dspdfviewer

 The licence the package is provided under

GPL version 2 or, at your option, any later version

 Short and long descriptions of the package

dspdfviewer - Dual-Screen PDF Viewer for latex-beamer presentations

(the following long description is the one I use inside the package)

 This is a specialized PDF Viewing application custom-made for
 the LaTeX class beamer, specifically the
 show notes on second screen=right option.
 .
 To make use of this program, you will need a document created
 by latex-beamer, and you will need two monitors connected to
 your computer.
 They do not need to have the same resolution, not even the same
 aspect ratio.
 .
 This program will split your PDF page in half, and display the
 left half (intended for the audience) on one monitor (think:
 a notebook's VGA output connected to your university's projector)
 and it will display the right half (intended for you) on the
 second screen.
 Also, on the second screen, you get page thumbnails and status
 information, like the time since you started the presentation
 and a wall clock.

 Where the package can be obtained from

Download from [my server] or if that is better I will also post it to
debian mentors server.

[my server]:
http://danny-edel.de/deb/pool/main/d/dspdfviewer/dspdfviewer_1.13-2.dsc



Thank you in advance for your time and help.

---

Danny Edel

m...@danny-edel.de
deb...@danny-edel.de

(Debian's mailing list software rejects mail from m...@danny-edel.de)


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bcd034.5030...@danny-edel.de

Re: Dropping debian/ directory vs Continuous Integration / daily-debs

[Danny Edel]

On 31/07/15 23:16, Jakub Wilk wrote:
 Hi Danny!
 
 * Danny Edel deb...@danny-edel.de, 2015-07-31, 22:51:
 I wanted to ask for an inclusion in debian, but the policy says that 
 even if I'm upstream myself, I'm not supposed to have a debian/ 
 directory at all.
 
 There is no such policy.
 
 debian/ in .orig.tar might be slightly annoying for the Debian 
 maintainer, but that's it.
 

Hello Jakub,

thank you for the clarification! I must have read this wrong. I will
work through the documentation again and (hopefully) end up with a
policy-compilant package with which I can ask for sponsorship.

Thanks again!

-- 

Danny


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bc873f.9090...@danny-edel.de

Dropping debian/ directory vs Continuous Integration / daily-debs

[Danny Edel]

Dear Debian mentors,

I hope this is the right place to ask this kind of question. If it's
not, a pointer in the right direction would be much appreciated.


I have programmed a software called [dspdfviewer], and I feel its
reasonably stable and usable (it is acquiring a growing userbase,
judging from the feedback I get by e-mail and github) now to be included
in distributions.

Since I'm a long-time user of debian myself, i created it as a debian
package pretty much from the start, learning and using tools like
mk-build-deps, debuild and sbuild, and now I have automated builds with
[jenkins-debian-glue] and github, telling me failures on each revision.
 (Jenkins builds the same source against wheezy, jessie and sid). A
similar mechanic hosted by canonical auto-builds from the repository for
all of ubuntu's supported releases.
This allows (a) users that want to try new features to do that without
having to compile themselves, and (b) gives me good feedback that I have
not broken any compatibility.

I wanted to ask for an inclusion in debian, but the policy says that
even if I'm upstream myself, I'm not supposed to have a debian/
directory at all. So I have not filed an official request for inclusion yet.


Since I can't find any documentation on how other people do this, maybe
you can help me:

If I don't have a debian/ directory in my git repository, how do I
verify that each revision builds cleanly in a chroot? And how do people
integrate with CI server like jenkins (the debian-glue specifically
states that it needs a debian/ directory).

Thank you very much in advance for your help,

Danny


[dspdfviewer]: https://github.com/dannyedel/dspdfviewer
[jenkins-debian-glue]: http://jenkins-debian-glue.org/


-- 
To UNSUBSCRIBE, email to debian-mentors-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55bbdfb8.1040...@danny-edel.de