Re: don't use sbuild --dist/-d and other sbuild stuff (was: Re: Questions before my first upload attempt)
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)
* 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)
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)
* 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
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
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
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
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
* 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
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
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
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
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
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
* 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Questions before my first upload attempt
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. Steve McIntyre offered his help (i hope this means sponsorship). But knowing how busy he is, i ask my pre-upload questions here first. Achieved so far: Package upstream sources are updated. Files in ./debian have been adapted. debian/changelog files got new sections 1.4.0. The packages do build by dpkg-buildpackage -us -uc with not more warnings than the current Debian packages of version 1.3.2. The .deb packages do install by dpkg -i. Installed binaries and Xfburn, a user of the libraries, do start up and look ok. Installed xorriso was tested in my afternoon backup script. I dare to trust it. 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 ? (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.) - 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 ? 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. Have a nice day :) Thomas