Re: don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Johannes Schauer]

Hi,

Quoting Jakub Wilk (2015-08-31 16:02:38)
> * Johannes Schauer , 2015-08-31, 15:53:
> >>From now on, "sbuild --dist sid --arch amd64 path/to/my.dsc" works.
> >
> >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.
> >
> >The *right* thing to do is to choose the chroot with the -c or --chroot 
> >option. The -d or --dist option will do the same job, but the side 
> >effect that it changes the distribution field in the .changes file it 
> >creates can be a very dangerous one.
> >
> >So please don't further advertise the -d or --dist option anymore if 
> >you actually want to use the -c or --chroot option instead!
> 
> Um, except that -d/--dist is obligatory. Without it you get:
> 
> No distribution defined

indeed I must've made an error when testing this. This just makes the whole
problem even worse...

So now the advise becomes: never let the argument to -d/--dist be different
from what you want to have in the distribution field in your changes file.

This then also puts some constraints on the naming of schroots - unless of
course the -c option is specified *in addition*.

cheers, josch


signature.asc
Description: signature

Re: don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Jakub Wilk]

* Johannes Schauer , 2015-08-31, 17:06:
So please don't further advertise the -d or --dist option anymore if 
you actually want to use the -c or --chroot option instead!


Um, except that -d/--dist is obligatory. Without it you get:

No distribution defined


indeed I must've made an error when testing this. This just makes the 
whole problem even worse...


So now the advise becomes: never let the argument to -d/--dist be 
different from what you want to have in the distribution field in your 
changes file.


Right. :)

Some relevant bugs:
#529281 (in sbuild),
#542747 (in Lintian).

You may want to use dput-ng, which (by default) doesn't let you upload a 
package when there's discrepancy between Changes and Distribution.


--
Jakub Wilk

don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Johannes Schauer]

Hi,

Quoting Danny Edel (2015-08-21 13:43:41)
> 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.

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.

Furthermore, instead of creating the source package manually before invoking
sbuild on the dsc, you can also execute sbuild directly without any arguments
inside the unpacked source. It will detect this and build the source package
automatically for you.

> logout-relogin or use "newgrp sbuild" in your current shell.

Good suggestion, I added it to the wiki page.

> Now to create the chroots:
> 
> [...]
> 
> 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.

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.

The *right* thing to do is to choose the chroot with the -c or --chroot option.
The -d or --dist option will do the same job, but the side effect that it
changes the distribution field in the .changes file it creates can be a very
dangerous one.

So please don't further advertise the -d or --dist option anymore if you
actually want to use the -c or --chroot option instead!

The -d or --dist option is used for when you want sbuild to even acquire the
source package for you, in which case it otherwise does not know from which
distribution to `apt-get source` it from.

I raised the issue in this thread on buildd-tools-devel@l.a.d.o:

http://lists.alioth.debian.org/pipermail/buildd-tools-devel/2015-July/009671.html

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

> 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?

> 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


signature.asc
Description: signature

Re: don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)

[Jakub Wilk]

* Johannes Schauer , 2015-08-31, 15:53:

From now on, "sbuild --dist sid --arch amd64 path/to/my.dsc" works.


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.


The *right* thing to do is to choose the chroot with the -c or --chroot 
option. The -d or --dist option will do the same job, but the side 
effect that it changes the distribution field in the .changes file it 
creates can be a very dangerous one.


So please don't further advertise the -d or --dist option anymore if 
you actually want to use the -c or --chroot option instead!


Um, except that -d/--dist is obligatory. Without it you get:

No distribution defined

--
Jakub Wilk

Re: Questions before my first upload attempt

[Paul Wise]

On Fri, Aug 28, 2015 at 8:41 PM, Jakub Wilk wrote:

 db.debian.org should be probably fixed show SHA256 fingerprints (in addition
 to MD5 fingerprints).

db.debian.org is planned to be rewritten with python/django.

 You can use the www.debian.org pseudo-pacakge for the wiki, I guess...

The wiki pseudo-package is wiki.debian.org

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Questions before my first upload attempt

[Paul Wise]

On Sat, Aug 29, 2015 at 10:11 AM, Paul Wise wrote:

 db.debian.org is planned to be rewritten with python/django.

... and help is needed for that.

https://github.com/LucaFilipozzi/ud/

-- 
bye,
pabs

https://wiki.debian.org/PaulWise
http://bonedaddy.net/pabs3/
http://wiki.openmoko.org/wiki/User:PaulWise

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

i am trying to follow the instructions for SSH setup with
alioth, after having been accepted as project member of
  https://alioth.debian.org/projects/pkg-libburnia/
and promoted to admin in one sweep.
The project has an SVN and two mailing lists.

A ssh-rsa key has been uploaded via
  https://alioth.debian.org/account/editsshkeys.php


https://wiki.debian.org/Alioth/Svn sends me to
https://wiki.debian.org/Alioth/SSH which tells me to be
mistrusting about the host key fingerprint.
It points to
  https://db.debian.org/machines.cgi?host=moszumanska
which says
  SSH host fingerprint: ssh-rsa d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf

But with my first attempt of logging in, i see:

  $ ssh svn.debian.org
  The authenticity of host 'svn.debian.org (5.153.231.21)' can't be established.
  RSA key fingerprint is SHA256:VbwoMdcyFWByMDQrIOcaUL6c16LV6+80G9+Rs2rtA8E.
  Are you sure you want to continue connecting (yes/no)? 

traceroute (from Sid VM's host, as VM sees * * *) says:

  10  po1.ar1.dc1.yo26.yrk.bytemark.co.uk (91.223.58.29)  50.893 ms  51.077 ms  
51.463 ms
  11  bm-bl1.debian.org (5.153.231.241)  46.995 ms  47.236 ms  47.558 ms
  12  moszumanska.debian.org (5.153.231.21)  48.540 ms * *

Shall i trust it ?

Where to report the mismatch (if it is not my fault ...) ?


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

sorry for the noise.

After learning that it is a feature of Sid's ssh client,
it was not too hard to find

  ssh -o FingerprintHash=md5  svn.debian.org

which displays

  RSA key fingerprint is MD5:d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf.

Jessie's ssh client says by default:
  RSA key fingerprint is d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf.


Is this a bug of the wiki, of db.debian.org/machines.cgi,
or of ssh client ?
Do the wiki and the machine database have bug package names ?


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Jakub Wilk]

* Thomas Schmitt scdbac...@gmx.net, 2015-08-28, 17:06:
After learning that it is a feature of Sid's ssh client, it was not too 
hard to find


 ssh -o FingerprintHash=md5  svn.debian.org

which displays

 RSA key fingerprint is MD5:d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf.

Jessie's ssh client says by default:
 RSA key fingerprint is d7:0b:26:5c:7a:5d:56:40:a9:e0:5d:f4:e1:70:88:bf.


Is this a bug of the wiki, of db.debian.org/machines.cgi, or of ssh 
client ?


db.debian.org should be probably fixed show SHA256 fingerprints (in 
addition to MD5 fingerprints).


In the mean time, it show the public key, which you can manually add to 
your ~/.ssh/known_hosts.



Do the wiki and the machine database have bug package names ?


You can use the www.debian.org pseudo-pacakge for the wiki, I guess...

There's no pseudo-package for db.d.o. You can contact us at 
ad...@db.debian.org.


--
Jakub Wilk

Re: Questions before my first upload attempt

[Gianfranco Costamagna]

Hi Thomas



So this in libburn4.install:

  debian/tmp/usr/lib/*/libburn.so.4*



You can just say usr/lib/*/libburn.so.4*

or even better
usr/lib/*/libburn.so.*

that way at the next soname bump you won't need
to change the install files too.
($somebody might object that having the 4 makes you
sure you don't miss a soname bump)

  debian/tmp/usr/include/libburn/libburn.h
  debian/tmp/usr/lib/*/libburn*.a
  debian/tmp/usr/lib/*/libburn.so
  debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc


not sure why you ship a static library,
we usually do not build/ship them
(shipping a static library is always a security 

nightmare)


(if a static library is really needed you might consider adding another -static 
binary
package, instead of putting in the same binary, but this is up to you)


- Shall i dput -f now ?


sure, mentors allows to dput, dput and dput again the same package.
Only the last version is saved, even if you can see the version logs in the
package view
- What to do about the complaint:
The uploader is not in the package's Maintainer or Uploaders fields
  Add myself to Uploaders ? Am i entitled ?


if you are talking about the package at #679249 you might directly ask this
to the maintainer


I would like to add an argument buildstamped to the make
run of libisoburn.

Where to read about how to achieve this ?


why? :)
I do not get the question, this is the reason why I can't answer
(not that I will have an answer)

cheers,

Gianfranco

Re: Questions before my first upload attempt

[Gianfranco Costamagna]

Hi Thomas,


(please open an RFS if you need a sponsor, otherwise it might be difficult
to track packages reviews and to actually have an upload)

There will be no SONAME change as long as i am the upstream
developer. ABI compatibility is one of the most important
goals of my development.


this is nice to hear!
I see Jakub Wilk and Paul Wise discussing the general
issue. Of course i would obey an instruction to remove
the *.a libraries from *-dev.install, if the discussion
comes to such a conclusion.


As a man who cares about security I avoid as much as possible
the static libraries (some packages might link it static even if
they didn't know that, AFAICS there is no tool in lintian that
spots an accidentally static linked library)

but Jakub is right, the policy allows them, and Paul is also right,
we should change that part :)

so I guess right now it isn't a problem, maybe when and if the
policy will be changed it will be lintian to tell you to strip it.


Other communities put high value on not overwriting
the same version of a tarball or package.
Glad to see that mentors allows it for development work.


also Debian doesn't allow that.
However mentors is not the Debian ftp-master server, so you can play
with versioning as you like, once the package is sponsored you won't be
able anymore, since nobody will be able to upload a new tarball with a different
hash and the same filename (maybe some admins can, but I guess they won't).

He rather orphaned the packages now, to allow me to apply
for sponsorship by others: #796145, #796146, #796147.


nice, this speeds up things


... still waiting for my new dput -f of libburn to show up
on the web site ... it's nearly two hours ago now.

Shall i re-dput ? After what waiting time ?



when the package disappears from here [1] it should be shown on the package
page.

If not, probably your upload wasn't processed correctly, so please
reupload it.

(usually I guess the queue is processed every 10 minutes or so)


[1] ftp://mentors.debian.net/

cheers,

G.

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

Gianfranco Costamagna:
 (please open an RFS if you need a sponsor, otherwise it might be difficult
 to track packages reviews and to actually have an upload)

I will do if my direct approach to already interested
people yields no success.

But currently i seem to have upload problems.


 [1] ftp://mentors.debian.net/

This is empty, 12:59 CEST.

I configured dput for http, as shown in
  http://mentors.debian.net/intro-maintainers

Strangely it said ftp and not http in its messages:

-
$ dput -f libburn_1.4.0-1.1_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854
gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
Good signature on 
/home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes.
Checking signature on .dsc
gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854
gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc.
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading libburn_1.4.0-1.1.dsc: done.
  Uploading libburn_1.4.0.orig.tar.gz: done.
  Uploading libburn_1.4.0-1.1.debian.tar.xz: done.
  Uploading libburn_1.4.0-1.1_source.changes: done.
Successfully uploaded packages.
-

So i now switch ~/.dput.cf to ftp and try again.

-
$ dput -f libburn_1.4.0-1.1_source.changes
Trying to upload package to ftp-master (ftp.upload.debian.org)
Checking signature on .changes
gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854
gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
Good signature on 
/home/thomas/projekte/debian_dir/libburn_1.4.0-1.1_source.changes.
Checking signature on .dsc
gpg: Signature made Mon 24 Aug 2015 08:47:49 AM CEST using DSA key ID ABC0A854
gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc.
Uploading to ftp-master (via ftp to ftp.upload.debian.org):
  Uploading libburn_1.4.0-1.1.dsc: 553 Could not create file.
Leaving existing libburn_1.4.0-1.1.dsc on the server and continuing
NOTE: This existing file may have been previously uploaded partially.
   For official Debian upload queues, the dcut(1) utility can be
   used to remove this file, and after an acknowledgement mail is
   received in response to dcut, the upload can be re-initiated.
  Uploading libburn_1.4.0.orig.tar.gz: 553 Could not create file.
Leaving existing libburn_1.4.0.orig.tar.gz on the server and continuing
NOTE: This existing file may have been previously uploaded partially.
   For official Debian upload queues, the dcut(1) utility can be
   used to remove this file, and after an acknowledgement mail is
   received in response to dcut, the upload can be re-initiated.
  Uploading libburn_1.4.0-1.1.debian.tar.xz: 553 Could not create file.
Leaving existing libburn_1.4.0-1.1.debian.tar.xz on the server and continuing
NOTE: This existing file may have been previously uploaded partially.
   For official Debian upload queues, the dcut(1) utility can be
   used to remove this file, and after an acknowledgement mail is
   received in response to dcut, the upload can be re-initiated.
  Uploading libburn_1.4.0-1.1_source.changes: done.
Successfully uploaded packages.
-

Could not create file and Successfully uploaded packages in
one run ?

Shall i try to create a Debian archive .commands file for dcut(1) ?


Have a nice day :)

Thomas 

Re: Questions before my first upload attempt

[Paul Wise]

On Mon, Aug 24, 2015 at 11:25 AM, Jakub Wilk wrote:

 Um, no. We have literally thousands of packages shipping static libraries
 (in addition to shared libraries). Policy §8.3 says:
 “The static library (‘libraryname.a’) is usually provided in addition to
 the shared version.”

Due to the downsides we should probably change that part of policy and
preventing the addition of new static libs is an essential part of
such a change.

https://wiki.debian.org/StaticLinking

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

i wrote:
Add myself to Uploaders ? Am i entitled ?

Christian Kastner wrote:
 However: it appears that this package is team-maintained. In that case,
 you leave the Maintainer as-is, and add yourself to Uploaders.

Adding myself to uploaders leads to new local warnings:

  W: libburn source: changelog-should-not-mention-nmu
  W: libburn source: maintainer-upload-has-incorrect-version-number 1.4.0-1.1

So for a test, i removed the the surplus .1 and the line
* Non-maintainer upload. from changelog.

Seems to be ok. I can run dpkg-i although the version number
is now lower than the previously installed one.
  Unpacking libburn4 (1.4.0-1) over (1.4.0-1.1) ...


 IMHO, taking over this package correctly would mean to also take over
 the alioth project as admin by
1. Requesting to join the team
2. Having the current admin set your new account as admin
3. Removing the old admin

I was already made aware that there is a repo to be taken
over. (The project page itself is very sparse.)
But currently i am still overwhelmed by packaging.
My plan is to get the three packages presentable, approach
my potential sponsors for adoption, and then try to understand
the rest of the infrastructure.

The current admin is very busy in real life. Else i would have
used him as sponsor and the packages were already in sid.
The task to update the packages to newest upstream was up to now
among the easiest ones.


 Once you have completed the above, add yourself to Uploaders.

Not being there yet, i stay with NMU for now and will put my
three packages on display.

It's time to look for sponsors and to get their opinion
about my packaging.


Gianfranco Costamagna wrote:
 that way at the next soname bump you won't need
 to change the install files too.
 ($somebody might object that having the 4 makes you
 sure you don't miss a soname bump)

There will be no SONAME change as long as i am the upstream
developer. ABI compatibility is one of the most important
goals of my development.
(Last inadverted breaking of ABI was with 0.3.2 in february
 2007, but i got SONAME correct only with version 0.4.2 in
 february 2008.)


 not sure why you ship a static library,

A former maintainer of libburn has put these files into the
libburn-dev.install file.
I am not yet apt to judge whether this should be changed.

One reason might have been that dbg had versions which
did an awful job with dynamic libraries. Did not try yet
with my two month old Jessie. I have my own static
compilation setup for upstream development purposes.

I see Jakub Wilk and Paul Wise discussing the general
issue. Of course i would obey an instruction to remove
the *.a libraries from *-dev.install, if the discussion
comes to such a conclusion.


 sure, mentors allows to dput, dput and dput again the same package.

Other communities put high value on not overwriting
the same version of a tarball or package.
Glad to see that mentors allows it for development work.


 if you are talking about the package at #679249 you might directly ask this
 to the maintainer

As said above, George Danchev has no time to sponsor or
coach me.
He rather orphaned the packages now, to allow me to apply
for sponsorship by others: #796145, #796146, #796147.

I thought they were orphaned since two years, when George
told me he could not longer maintain them. But that
last step was made only a few days ago, when he was
pointed by a bystander to my questions on debian-user.

We do not split in anger or something like that.
It's just that real life prevents him from covering my
upstream releases.

I got an offer of help by Steve McIntyre, who uses xorriso
for debian-cd. But before bothering him with technical
questions, i preferred to bother people who obviously don't
mind noobs and their difficulties.
Thanks a lot to this list and to all who answered.

Dominique Dumont expressed interest, too. He pointed me
to the task of taking care of the repo. (I'm still very
clueless with this topic.)

I will also inform the neighboring team which maintains
dvd+rw-tools.


... still waiting for my new dput -f of libburn to show up
on the web site ... it's nearly two hours ago now.

Shall i re-dput ? After what waiting time ?


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Jakub Wilk]

* Gianfranco Costamagna costamagnagianfra...@yahoo.it, 2015-08-24, 07:00:

 debian/tmp/usr/include/libburn/libburn.h
 debian/tmp/usr/lib/*/libburn*.a
 debian/tmp/usr/lib/*/libburn.so
 debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc



not sure why you ship a static library,
we usually do not build/ship them


Um, no. We have literally thousands of packages shipping static 
libraries (in addition to shared libraries). Policy §8.3 says:
“The static library (‘libraryname.a’) is usually provided in addition 
to the shared version.”


(if a static library is really needed you might consider adding another 
-static binary package, instead of putting in the same binary, but this 
is up to you)


That would be very unusual. Policy §8.3 says static libraries should put 
into the -dev package.


--
Jakub Wilk

Re: Questions before my first upload attempt

[gregor herrmann]

On Mon, 24 Aug 2015 12:50:04 +0200, Thomas Schmitt wrote:

 I configured dput for http, as shown in
   http://mentors.debian.net/intro-maintainers
 
 Strangely it said ftp and not http in its messages:
 
 -
 $ dput -f libburn_1.4.0-1.1_source.changes
 Trying to upload package to ftp-master (ftp.upload.debian.org)

You're uploading to ftp.upload.debian.org and not to mentors.d.n.

Quoting from the page you cited above:

`dput mentors your_sourcepackage_1.0.changes'

(note the 'mentors' which refers to the name in the ~/.dput.cf)


(ftp.upload.debian.org will remove your upload attempts
automatically.)


Cheers,
gregor

-- 
 .''`.  Homepage: http://info.comodo.priv.at/ - OpenPGP key 0xBB3A68018649AA06
 : :' : Debian GNU/Linux user, admin, and developer -  https://www.debian.org/
 `. `'  Member of VIBE!AT  SPI, fellow of the Free Software Foundation Europe
   `-   NP: Tom Waits: Trampled Rose


signature.asc
Description: Digital Signature

Re: Questions before my first upload attempt

[Gianfranco Costamagna]

Hi Thomas,



If you dput $something, you need to wait until $something is processed,
any later upload will fail because you can't overwrite the files
in ftp unprocessed queue.

So wait for the upload, get the email confirmation, and then dput again.

According to the log you posted, seems that dput worked :)
and also the other tool you used ;)



Shall i try to create a Debian archive .commands file for dcut(1) ?

not sure if dcut works on mentors, but I guess not 

(I do not remember honestly).


When I had partial uploads on ftp queue what I did was: retry the upload

this forced dput to upload all the files on mentors.d.o (even if some of them 
was
broken), then after the .changes file was uploaded the $program was checked and 
removed
from the queue.

Then I reuploaded all again.

cheers,

G.

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

gregor herrmann wrote:
 You're uploading to ftp.upload.debian.org and not to mentors.d.n.

Duh (once again). This explains a lot.
Meanwhile i bothered it with a libisofs upload attempt, too.
Need to make me an upload script.

I began to write quite a desparate answer to Gianfranco
and to think about a version bump.

But now it accepts my upload without -f

  $ dput mentors libburn_1.4.0-1.1_source.changes
  ...
  Uploading to mentors (via ftp to mentors.debian.net):
  ...

... patiently waiting for mail now ... oh joy !
Upload shows effect on package/libburn:
All green, except The uploader is not in the package's
Maintainer or Uploaders fields. 


I'm back on tracks, as it seems.

Will upload the other two packages, contact my sponsor
candidates, and ask them whether i shall file an RFS,
additionally.


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

i worked a bit more on my local libburn package.

Shall/can i replace my yesterday upload by help of dput -f ?



Regarding http://mentors.debian.net/package/libburn ,
i have hoepfully solved the complaints under
Package closes bugs in a wrong way 

- Bugs #702621 and #746254 got reassigned to libburn4.

- Closes: #751501 was moved from libburn changelog to libisofs
  changelog.
  (Good catch. Is this check available locally before upload ?)



The failure of debuild -b with compat 9 still riddles me.

With 9 it finally complains

  dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*), 
aborting

It seems to have outsmarted itself by previous

  ./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...

With 8, the configure option --libdir is not used.

After debuild -b with compat 9 i have:

  $ ls debian/tmp/usr/lib
  x86_64-linux-gnu
  $ ls debian/tmp/usr/lib/x86_64-linux-gnu
  libburn.a  libburn.la  libburn.so  libburn.so.4  libburn.so.4.93.0  pkgconfig

The complete ./configure line of 8 is:

  ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libexecdir=\${prefix}/lib/libburn 
--disable-maintainer-mode --disable-dependency-tracking

Of 9:

  ./configure --build=x86_64-linux-gnu --prefix=/usr 
--includedir=\${prefix}/include --mandir=\${prefix}/share/man 
--infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var 
--disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu 
--libexecdir=\${prefix}/lib/x86_64-linux-gnu --disable-maintainer-mode 
--disable-dependency-tracking


Do i have to make a kindof cleanup when switching from
compat 8 to 9 ?




Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

i was able to fix debuild -b with compat 9 by changing the
content of  debian/libburn4.install  from
  debian/tmp/usr/lib/libburn.so.4* usr/lib
to
  debian/tmp/usr/lib/x86_64-linux-gnu/libburn.so.4* usr/lib/x86_64-linux-gnu

Next i wanted to ask: Is this remedy a valid solution ?

But now i see that Niels Thykier wrote:
 If your package is simple, you can use:
  usr/lib/*/file
 instead of
  usr/lib/file

Duh.
Of course there's not only amd64 in the world.
(At least i did find the right files on my own.)

So this in libburn4.install:

  debian/tmp/usr/lib/*/libburn.so.4*

and in libburn-dev.install:

  debian/tmp/usr/include/libburn/libburn.h
  debian/tmp/usr/lib/*/libburn*.a
  debian/tmp/usr/lib/*/libburn.so
  debian/tmp/usr/lib/*/pkgconfig/libburn-1.pc

Works fine on amd64.

=
Remaining questions:

- Shall i dput -f now ?

- What to do about the complaint:
The uploader is not in the package's Maintainer or Uploaders fields
  Add myself to Uploaders ? Am i entitled ?

=
New question:

I would like to add an argument buildstamped to the make
run of libisoburn.

Where to read about how to achieve this ?

-

Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Niels Thykier]

On 2015-08-23 12:48, Thomas Schmitt wrote:
 Hi,
 

Hi Thomas,

 i worked a bit more on my local libburn package.
 
 [...]
 
 The failure of debuild -b with compat 9 still riddles me.
 
 With 9 it finally complains
 
   dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*), 
 aborting
 
 It seems to have outsmarted itself by previous
 
   ./configure ... --libdir=\${prefix}/lib/x86_64-linux-gnu ...
 
 With 8, the configure option --libdir is not used.
 
 After debuild -b with compat 9 i have:
 
   $ ls debian/tmp/usr/lib
   x86_64-linux-gnu
   $ ls debian/tmp/usr/lib/x86_64-linux-gnu
   libburn.a  libburn.la  libburn.so  libburn.so.4  libburn.so.4.93.0  
 pkgconfig
 

Yes, this is caused by bumping to compat 9.  Please have a look at:
  man 7 debhelper

Which (among other things) will list:


COMPATIBILITY LEVELS

[...]

   v9  This is the recommended mode of operation.

   Changes from v8 are:

   -   Multiarch support. In particular, dh_auto_configure
   passes multiarch directories to autoconf in --libdir
   and --libexecdir.


If your package is simple, you can use:


  usr/lib/*/file

instead of

  usr/lib/file

Alternatively, please consider using dh-exec.  This requires three steps:

  Add dh-exec to Build-Depends
  Insert #!/usr/bin/dh-exec in the top of debian/package.install
  chmod a+x debian/package.install


Note this only works in compat 9 and later


Thanks,
~Niels

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-23 16:08, Thomas Schmitt wrote:
 Remaining questions:
 
 - Shall i dput -f now ?

Yes.

I don't know if you have to remove the package first (eg via the web
interface). Can someone more familiar with mentors.debian.net add some
enlightenment here?

 - What to do about the complaint:
 The uploader is not in the package's Maintainer or Uploaders fields
   Add myself to Uploaders ? Am i entitled ?

Orphaning a package means that there is no maintainer anymore;
therefore, you would normally set yourself as Maintainer.

However: it appears that this package is team-maintained. In that case,
you leave the Maintainer as-is, and add yourself to Uploaders.

There's an alioth [1] project, with mailing list and all:

https://alioth.debian.org/projects/pkg-libburnia/

As you can see, there are a number of committers there, and the current
Uploaders field of the package lists one of them.

IMHO, taking over this package correctly would mean to also take over
the alioth project as admin by
1. Requesting to join the team
2. Having the current admin set your new account as admin
3. Removing the old admin

Once you have completed the above, add yourself to Uploaders. Then, add
an entry to debian/changelog, such as:

  * Add myself to Uploaders. Closes: #XX

The XX refers to the bug number with which the package was orphaned,
and which you still need to retitle and of which you still need to claim
ownership :-)

Alternatively, if you no longer wish to team-maintain it, and if the
remaining uploader is OK with this, you could set yourself to
Maintainer, remove the Uploaders, and add the following entry to
debian/changelog:

  * New Maintainer. Closes: #XX

However, you should then get the alioth project removed, to avoid confusion.

[1] https://wiki.debian.org/Alioth

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

i wrote:
$ gpg --verify ../libisoburn_1.4.0-1.1_source.changes
...
gpg: WARNING: This key is not certified with a trusted signature!

Johan Van de Wauw wrote:
 This indicates that you have not set a trust level for that key. If you run
 gpg --edit-key  ABC0A854
 type trust and set to: I trust fully (or whatever you trust yourself :-))

The warning vanished only after i set trust to
5 = I trust ultimately.


W: libburn4: hardening-no-relro usr/lib/libburn.so.4.93.0
 What debhelper version are you using (check debian/compat). 

Was 8.
Inherited from Debian packages libburn_1.3.2-1.1,
libisofs_1.3.2-1.1, libisoburn_1.3.2-1.1.

With 9, the warning changes to

  W: libburn source: package-needs-versioned-debhelper-build-depends 9

I assume because of debian/control line

  Build-Depends: dh-autoreconf, pkg-config, debhelper (= 8), libcam-dev 
[kfreebsd-any]

Changing to (= 9) silences the warning of debuild -S.

But now debuild -b fails until i revert the change in
debian/compat. I.e. back to 8.
With 9, debuild -b ends by:

  dh_install: libburn4 missing files (debian/tmp/usr/lib/libburn.so.4*), 
aborting
  debian/rules:5: recipe for target 'binary' failed
  make: *** [binary] Error 2

Further above i see no problem messages which would deviate
from those of the successful run with compat 8.

We will have to postpone this problem until i succeeded
with uploading.

---
http://mentors.debian.net/intro-maintainers

The proposed line

  dput mentors your_sourcepackage_1.0.changes

does not really match my two candidates

  libburn_1.4.0-1.1_amd64.changes
  libburn_1.4.0-1.1_source.changes

but i guess it's

  $ dput mentors libburn_1.4.0-1.1_source.changes
  ...
  Good signature on /home/thomas/projekte/debian_dir/libburn_1.4.0-1.1.dsc.
  Uploading to mentors (via http to mentors.debian.net):
Uploading libburn_1.4.0-1.1.dsc: done.
Uploading libburn_1.4.0.orig.tar.gz: done.
Uploading libburn_1.4.0-1.1.debian.tar.xz: done.
Uploading libburn_1.4.0-1.1_source.changes: done.
  Successfully uploaded packages.

Confirmation mail arrived:

http://mentors.debian.net/package/libburn
http://mentors.debian.net/debian/pool/main/libb/libburn/libburn_1.4.0-1.1.dsc

I do not yet flag it as seeking a sponsor.
Firstly, because i want to polish it and upload its
two mates libisofs and libisoburn.
Secondly because i already got two offers on debian-user
and will probably approach directly the maintainer team of
dvd+rw-tools, which already accepted one of my patches.

I am not sure whether any of them will have time to be
my mentor, besides the minimum checks needed to authorize
my uploads.

So please help me to thoroughly polish the packages.
I'll apply changes to all three and will upload the other
two when libburn is neatly shining.

---
Glimpse on http://mentors.debian.net/package/libburn :

Looks like i need to re-assign some bugs first.
My changelogs close them where they belong, not where
they have been reported to.

Debhelper compatibility level 9 is not entirely true,
i fear. See above.

vcs-field-not-canonical looks like the tail tip of the
big problem to take care of debian-specific repositories.

The uploader is not in the package's Maintainer or
 Uploaders fields:
I do not feel authorized to add me to any of those fields.


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

somehow i managed to upload the non-working
variant with
  Build-Depends: dh-autoreconf, pkg-config, debhelper (= 9), libcam-dev 
[kfreebsd-any]
and probably debian/compat content 9.

Can i overwrite the upload ?
If i have to make a new version, then i first wait for
some feedback.


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

thanks for the answers. They helped me to achieve progress.


So i really had to pass the can-he-install-sid-? test.

I already began installing yesterday evening.
It is instructive, but i would have preferred to postpone
the qemu adventures until i explore passthrough of DVD drives.

How about publicly available accounts on a sid machine,
where programmers like me can test building of their packages ?

Don't get me wrong. I am not complaining because i have no
other fun in life.
I report this because i believe to see an important reason
why Debian packages of software like mine are outdated.
 

Christian Kastner wrote:
 $ sudo vmdebootstrap \

A link to an example like this should augment the sportive
statement
  [...], built against a current version of sid.
   This simple sentence hides a multitude of sins -- it can be
   a complex process.
in
  https://wiki.debian.org/DebianMentorsFaq#How_do_I_make_my_first_package.3F

I think Debian loses potential packagers after they read it
as it is now. Not every programmer is an enthusiastic sysadmin.

Well, i seem to have achieved it the hard way.
But if i ever have to do it again, i will gladly try your
proposal.

---

I read
  https://wiki.debian.org/InstallFAQ
and experienced:

- Any senseful combination of
{i386 mini.iso, amd64 mini.iso}
x {qemu-system-i386 , qemu-system-x86_64}
x {-cdrom , -hda}
  is broken currently. xorriso is not to blame. El Torito
  boot record and MBR properly lead to isolinux.bin which
  gets stuck after its startup message. Famous last words
  are ETCD or EHDD, depending on -cdrom or -hda.

- debian-8.1.0-amd64-netinst.iso by default installs a
  kind of tablet PC desktop with no visible means to get
  a shell prompt. (I made the mistake to accept the pre-
  selected package collection.)
  I had to boot into rescue mode and zap
  /etc/X11/default-display-manager in order to get at least
  a kernel console after normal boot. (Thx Google.)
  The console goes black after a few minutes so that i cannot
  see the user input prompts, but have to watch the host
  performance meters to know when it is time to press Enter.

  This way i managed to apt-get dist-upgrade to testing.
  One upgrade step more needed to get to sid.
  When the proposal about vmdebootstrap arrived, i decided
  to go on with what i already started.

  But that i did via SSH. (Praise Google for showing all the
  cries for help and the rescue efforts of brave fellow users.)
  Now i have:
# uname -a
Linux ts6-sid 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64 
GNU/Linux
  Cannot really tell whether this is sid. I did my best, at least.
  /etc/apt/sources.list currently has these two active lines

deb http://ftp.de.debian.org/debian/ unstable main
deb-src http://ftp.de.debian.org/debian/ unstable main

  Anything more to add there ?

---


 and inside the VM, adapt to your liking.

(Back to stable ? ~:o))


 You only want to sign the final result of your packaging efforts;
 signing every intermediate result of the development process is
 unnecessary and annoying, hence the -us -uc.

So signing in this context means no -us -uc.
Thanks for clarifying this.


 By the way, in that case, you should retitle the respective bug reports
 from O for orphaned to ITA for intent to adopt.

How to do this ?
(I see few risk that anybody would take care of the packages
 in the next days.)


Back to the work of packaging:

Do i get it right that i should do
  apt-get dist-upgrade
every time before i begin to package something ?


Have a nice day :)

Thomas

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

[Thomas Schmitt]

Hi,

Danny Edel wrote:
 Debian actually has ready-made VM scripts for you.
 https://wiki.debian.org/sbuild

They urgently need advertising at the entry points
of mentors.debian.net and at the upload instructions.


  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.

I was desparately digging the Debian docs for something
like this.


Hm. What shall i do with my brand new sid VM now ?
I copied the development workshop from the host and
installed the needed packages for dpkg-buildpackage.
The first round of packages is built as was done
on the host machine and installed.

Next i plan to test the proposed command debuild.

So many branches to explore ...


https://wiki.debian.org/sbuild#Setup writes:
5  ... *logout* and *re-login*

I'm logged in by my X session and want to keep it running.
Line 2 seems newer than the explanation beneath.
So line 5 would be covered by:
  The fourth line is to update the active user group set
   to include sbuild.


 logout-relogin or use newgrp sbuild in your current shell.

Aha. Enlightenment.
A fruitless google search of active user group set
already brought me to the suspicion that something around
newgroup(1) was meant.


 so make sure to have  10G space there.

2 TB free. My mass storage still produces an echo when i shout.


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.

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

So many branches ...


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

Danny Edel wrote:
 The main advantage of [sbuild] is the ...and throw everything away to get a
 clean starting point, so you have a reproducible and minimal build
 environment.

Yep. Cleaner and thus more sensible to changes in environment.

As said, i deem the source very portable and thus fewly vulnerable
to environmental changes. Other projects would scream first.

But i cannot be so sure with the Debian aspects of the package.
Especially since my understanding is mostly heuristic. (Like
i began to operate the autotools files when i took over libburn.)

A related advantage of the sbuild concept is that the user
is not exposed to the ever changing desktop weirdness.


 Have backups.)

Wanting to have backups caused my mail address and my endeavor
into ISO 9660 and optical burning.


 pbuilder. As an alternative to dput{,-ng}, there is also dupload.

This puts up a nice space of combinations.


 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.

It would be a bit easier for new tools if not the wikis
would only talk about the old ones. Like about mkisofs and
cdrecord, rather than xorriso.

But for new users it is beneficial to have a more narrow guidance.


 Take a look at man devscripts

The offspring of a long evolution, as it looks.


Christian Kastner wrote:
 The reason I posted the qemu-based approach was that it was, at first
 sight, not as complex as the sbuild approach, seeing as it only required
 one command.

Funny thing is that i would have followed your proposals
if each had not come just after i managed to find some
solution myself.

The docs cannot be too bad, after all. Half of my
helpful Google hits were inside Debian.
Its terminology could need some standardization and care
towards offering the right keywords for web search.

---

http://mentors.debian.net/intro-maintainers :
dput wants to be configured.
Tonight.

I hope nobody minds that i did not yet try to solve
any old shortcommings of the ./debian files in the
orphaned packages.
Just give me instructions.

Thanks again for the answers and proposals.


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-21 13:21, Danny Edel wrote:
 On 20/08/15 18:33, Thomas Schmitt wrote:
   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.

I agree that sbuild is ultimately the best way to go. I myself use it,
and keep chroots of various distributions on it.

The reason I posted the qemu-based approach was that it was, at first
sight, not as complex as the sbuild approach, seeing as it only required
one command.

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-21 13:15, Thomas Schmitt wrote:
 I already began installing yesterday evening.
 It is instructive, but i would have preferred to postpone
 the qemu adventures until i explore passthrough of DVD drives.

Yes, that makes sense.

 How about publicly available accounts on a sid machine,
 where programmers like me can test building of their packages ?

Well, we have them. They are called porter boxes, and they exist for
many architectures. However, it is sometimes not easy to get access to
these as a non-DD.

Regardless: if you want to do Debian development, having a sid
environment really is unavoidable, even if it might be a hassle.

   Now i have:
 # uname -a
 Linux ts6-sid 4.1.0-1-amd64 #1 SMP Debian 4.1.3-1 (2015-08-03) x86_64 
 GNU/Linux
   Cannot really tell whether this is sid. I did my best, at least.
   /etc/apt/sources.list currently has these two active lines
 
 deb http://ftp.de.debian.org/debian/ unstable main
 deb-src http://ftp.de.debian.org/debian/ unstable main
 
   Anything more to add there ?

No, looks good!

 By the way, in that case, you should retitle the respective bug reports
 from O for orphaned to ITA for intent to adopt.
 
 How to do this ?
 (I see few risk that anybody would take care of the packages
  in the next days.)

The Debian BTS is manipulated via email. You can see an example for
changing from O to ITA here [1]. I then suggest you read [2] to
understand what exactly is happening, and finally [3] as a general
overview of the BTS.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553654#15
[2] https://www.debian.org/Bugs/server-control
[3] https://www.debian.org/Bugs/Developer

 Do i get it right that i should do
   apt-get dist-upgrade
 every time before i begin to package something ?

Your build environment should be recent. This doesn't mean that you have
 to update before every build, but I'd update it at least daily.

Ideally, your final build should be against an up-to-date sid environment.

Regards,
Christian

Re: Questions before my first upload attempt

[Thomas Schmitt]

Hi,

after some fight with the keyring i am able to produce
signed packages on sid.

Will this warning be a problem ?

  $ gpg --verify ../libisoburn_1.4.0-1.1_source.changes
  gpg: Signature made Fri 21 Aug 2015 10:44:01 PM CEST using DSA key ID ABC0A854
  gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
  gpg: WARNING: This key is not certified with a trusted signature!
  gpg:  There is no indication that the signature belongs to the owner.
  Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854

---

I need a translator from debian-speak to english (or german).

My first runs of debuild showed lintian warnings, which i could
silence, except this class from debuild -b:

  W: libburn4: hardening-no-relro usr/lib/libburn.so.4.93.0
  W: cdrskin: hardening-no-relro usr/bin/cdrskin
  W: libisofs6: hardening-no-relro usr/lib/libisofs.so.6.76.0
  W: libisoburn1: hardening-no-relro usr/lib/libisoburn.so.1.97.0
  W: xorriso: hardening-no-relro usr/bin/xorriso

This package was likely not built with the default
 Debian compiler flags defined by dpkg-buildflags.

What does it want me to do ?
Where ? In debian/rules ? In upstream ? Examples available ?

--
Riddle:

During my work something caused unconditional regeneration
of unpacked
  libisoburn-1.4.0/xorriso/xorrecord.info
The versions of makeinfo differ between release machine
and sid, which causes different .info result.
In subsequent runs of debuild this causes a complaint
about uncommitted changes.

The makeinfo run is indeed in my upstream autotools empire.
But it should only trigger if .info is missing or outdated.
In a build run out of the upstream tarball, the makeinfo
run is not triggered. On the same sid.

Only one of three .info gets regenerated in this way:
  -rw-r--r-- 1 thomas thomas  41768 Aug 21 22:25 xorriso/xorrecord.info
  -rw-r--r-- 1 thomas thomas 291521 Aug 21 14:56 xorriso/xorriso.info
  -rw-r--r-- 1 thomas thomas 108424 Aug 21 14:56 xorriso/xorrisofs.info

I restored xorriso/xorrecord.info from .orig.tar.gz,
but with the next debuild -b it happened again,
despite .info having a new timestamp.
So i stored a copy of the original on disk in order
to restore the victim after each pbuild run.

To my surprise, after i copied this disk file to
xorriso/xorrecord.info for the first time, it does not
get regenerated any more.

What is the magic difference between tar xzf and cp ?
Why does it not happen with ./configure  make
from upstream tarball ?

The time on VM is about one minute behind the host.
Although this is strange, it cannot explain the riddle.

--

dput configuration must wait until tomorrow.
Just a quick backup of my sid workshop and then to bed.


Have a nice day :)

Thomas

Re: Questions before my first upload attempt

[Johan Van de Wauw]

On Fri, Aug 21, 2015 at 11:33 PM, Thomas Schmitt scdbac...@gmx.net wrote:
 Hi,

 after some fight with the keyring i am able to produce
 signed packages on sid.

 Will this warning be a problem ?

   $ gpg --verify ../libisoburn_1.4.0-1.1_source.changes
   gpg: Signature made Fri 21 Aug 2015 10:44:01 PM CEST using DSA key ID 
 ABC0A854
   gpg: Good signature from Thomas Schmitt scdbac...@gmx.net
   gpg: WARNING: This key is not certified with a trusted signature!
   gpg:  There is no indication that the signature belongs to the 
 owner.
   Primary key fingerprint: 44BC 9FD0 D688 EB00 7C4D  D029 E9CB DFC0 ABC0 A854

This indicates that you have not set a trust level for that key. If you run
gpg --edit-key  ABC0A854
type trust and set to: I trust fully (or whatever you trust yourself :-))

 ---

 I need a translator from debian-speak to english (or german).

 My first runs of debuild showed lintian warnings, which i could
 silence, except this class from debuild -b:

   W: libburn4: hardening-no-relro usr/lib/libburn.so.4.93.0
   W: cdrskin: hardening-no-relro usr/bin/cdrskin
   W: libisofs6: hardening-no-relro usr/lib/libisofs.so.6.76.0
   W: libisoburn1: hardening-no-relro usr/lib/libisoburn.so.1.97.0
   W: xorriso: hardening-no-relro usr/bin/xorriso

 This package was likely not built with the default
  Debian compiler flags defined by dpkg-buildflags.

 What does it want me to do ?
 Where ? In debian/rules ? In upstream ? Examples available ?
What debhelper version are you using (check debian/compat). Try going
to 9, if that does not help: share your packaging work, it is hard to
find out without seeing the code.
More explanations here: https://wiki.debian.org/HardeningWalkthrough


 --
 Riddle:

 During my work something caused unconditional regeneration
 of unpacked
   libisoburn-1.4.0/xorriso/xorrecord.info
 The versions of makeinfo differ between release machine
 and sid, which causes different .info result.
 In subsequent runs of debuild this causes a complaint
 about uncommitted changes.

 The makeinfo run is indeed in my upstream autotools empire.
 But it should only trigger if .info is missing or outdated.
 In a build run out of the upstream tarball, the makeinfo
 run is not triggered. On the same sid.

 Only one of three .info gets regenerated in this way:
   -rw-r--r-- 1 thomas thomas  41768 Aug 21 22:25 xorriso/xorrecord.info
   -rw-r--r-- 1 thomas thomas 291521 Aug 21 14:56 xorriso/xorriso.info
   -rw-r--r-- 1 thomas thomas 108424 Aug 21 14:56 xorriso/xorrisofs.info



 What is the magic difference between tar xzf and cp ?
 Why does it not happen with ./configure  make
 from upstream tarball ?
I suppose it is this: copying will set the timestamp at the time of
copying, so make (or another tool) does not detect a changed version:
the generated version is newer than it sources. When extracting you
get the original timestamp.

Kind Regards,
Johan

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: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-20 18:33, Thomas Schmitt wrote:
 i am the upstream developer of freshly orphaned packages libburn4,
 libisofs6, libisoburn1, cdrskin, and xorriso. Now preparing to get
 them in shape for sponsorship and for closing old bug reports.

By the way, in that case, you should retitle the respective bug reports
from O for orphaned to ITA for intent to adopt.

This clearly communicates that you are working on them, and thereby
reduces the chance of redundant work and/or conflicts with other
maintainers.

See 
https://wiki.debian.org/DebianMentorsFaq#How_do_I_adopt_an_existing_package.3F

Re: Questions before my first upload attempt

[Christian Kastner]

On 2015-08-20 18:33, Thomas Schmitt wrote:
 Currently i am stuck at:
 
 - 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 ?

Generally speaking, the advice to build against a current version of
sid is an important one, because that's where the package eventually
gets uploaded to, and your package must work with what's in there, and
not with what's in 8.1.

But yes, there are ways you can do development against sid whilst
remaining mainly in an 8.1 environment. Commonly used solutions are
chroots and VMs, which provide a sid environment more or less isolated
from the host environment.

   (The PackagingTutorial says i shall write 9 into
debian/compat. Is that enough of a sid ?)

As Johan already indicated, the 9 is unrelated to the Debian version.
It refers to the feature set of debhelper, a helper program very
frequently used by packages.

The section COMPATIBILITY LEVELS of debhelper(7) has more details, but
you probably shouldn't care about these yet. Completing a few tutorials
and becoming familiar with the big picture first are probably more
important, so you are non the right track :-)

   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.)

The simplest way I can think of is to create a qemu-based VM with
vmdebootstrap(8). The following should create a useful result, which you
can then further modify:

$ sudo vmdebootstrap \
--distribution sid \
--image mysid.img \
--size=5g \
--mirror http://httpredir.debian.org/debian \
--configure-apt \
--package build-essential \
--package devscripts \
--enable-dhcp \
--hostname mysidvm \
--serial-console \
--owner ${USER}

$ qemu-system-x86_64 -enable-kvm -m 2048 mysid.img

Adapt the QEMU options to your hardware environment and to the features
you need, and inside the VM, adapt to your liking.

 - 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.
 
   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 ?
[...]
   Suspiciously all newbie tutorials for Debian packaging
   propose to use options -us -uc, which i understand prevent
   some kind of signing.

You only want to sign the final result of your packaging efforts;
signing every intermediate result of the development process is
unnecessary and annoying, hence the -us -uc.

As Johan already mentioned, simply omit these, and you will be asked for
a signature.

Alternatively, if you used -us -uc, and you'd like to sign the result
later on, you can use the debsign(1) utility from the devscripts package.

Regards,
Christian

Re: Questions before my first upload attempt

[Johan Van de Wauw]

On Thu, Aug 20, 2015 at 6:33 PM, Thomas Schmitt scdbac...@gmx.net wrote:
 Hi,

 i am the upstream developer of freshly orphaned packages
 libburn4, libisofs6, libisoburn1, cdrskin, and xorriso.
 Now preparing to get them in shape for sponsorship and
 for closing old bug reports.

Thanks for taking time to improve debian!

   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 ?)
No, this is unrelated. debian/compat is about which version of
debhelper to is used. Read about pbuilder.
https://www.debian.org/doc/manuals/maint-guide/build.en.html#pbuilder


   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.)

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

Use debuild -S (for source packages) or debuild -b (for binary
packages). It should ask for your signature when you are finished. In
fact I never use   dpkg-buildpackage, debuild also runs lintian checks
which spot many common errors.

Kind Regards,
Johan