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
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp d/rules: wl-asneeded is good if enable, does it introduce some problems? are both autotools-dev and autoreconf needed? usually the latter should superceed the former d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl Il Venerdì 21 Agosto 2015 14:20, Alex Vong alexvong1...@gmail.com ha scritto: Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, Thanks for the quick reply, I have just finished dinner. 2015-08-21 20:46 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: Hi Alex, let's review :) d/changelog please set to unstable, and update the timestamp Okay. d/rules: wl-asneeded is good if enable, does it introduce some problems? Okay I will add it. are both autotools-dev and autoreconf needed? usually the latter should superceed the former Okay I will remove autotools-dev. d/rules: I personally do not like calling bootstrap, specially when the only thing needed there seems to be applying one patch and calling and generating changelogs/manpages. I would generate them with dh_installmanpages or the equivalent dh call. d/patches/*: they seem to come from a git export-patch, are them already upstream? so why don't just ask to release a new tarball? carrying 30 patches might be a maintenance problem. Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development https://gitlab.com/mlucas-ll/mlucas. The 29 patches can be divided into 3 groups. 0001 - 0012, 0027 are patches related to the source, forwarded upstream to be included in the next version. The rest are patches to add the build system and script to generate man page, NEWS, ChangeLog... Any advice on this? debian/repack seems not policy compliant (didn't check) maybe get-orig-source.sh is better as a name Okay changed. also source_package_build.bash but I guess this might be a nitpick, since they are called by uscan so the user/developer never need to call them directly. I do not understand. What should I do with `source_package_build.bash' ? d/watch what is the timestamp there? oh well, seems that upstream in that way doesn't increase the version number when releasing bad numbering is bad :) Upstream uses Mlucas_MM.DD..tbz2 instead of mlucas_14.1.tar.bz2 for backward capability, so we need to update debian/watch version string for every new release... let me know, (I didn't try to build the package, and didn't check the copyrights) cheers, G. d/copyright: expat seems commented (even if not a problem) same for gpl I do it beacuse lintian will complain about empty license if add `License:' in the header paragraph. While lintian will complain about unused license if I seperate the Expat-licnesed files in a seperate file paragraph. What is your recommendation? This email is probably too long... Cheers, Alex
Fwd: paflib uploaded to mentors.debian.net
Dear mentors, I am looking for a sponsor for the package paflib I just uploaded (ITP - #781117) http://bugs.debian.org/781117 paflib debuild passes ok, but lintian -EviIL +pedantic gives the following messages: Do I have to sort them out ? lintian -EviIL +pedantic | grep -v ^N: W: paflib source: changelog-should-mention-nmu W: paflib source: source-nmu-has-incorrect-version-number 0.2.0-1 P: paflib source: no-dep5-copyright P: libpaf-dsc0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL X: libpaf-dsc0: shlib-calls-exit usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 I: libpaf-dsc0: no-symbols-control-file usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 P: libpaf-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: libpaf-ebb0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL X: libpaf-ebb0: shlib-calls-exit usr/lib/powerpc64le-linux-gnu/libpaf-ebb.so.0.0.2 I: libpaf-ebb0: no-symbols-control-file usr/lib/powerpc64le-linux-gnu/libpaf-ebb.so.0.0.2 I: libpaf-ebb0: unused-override no-upstream-changelog Thanks Thierry Forwarded Message Subject:paflib uploaded to mentors.debian.net Date: Fri, 21 Aug 2015 14:27:46 + (UTC) From: mentors.debian.net supp...@mentors.debian.net To: tfa...@free.fr Hi. Your upload of the package 'paflib' to mentors.debian.net was successful. Others can now see it. The URL of your package is: http://mentors.debian.net/package/paflib The respective dsc file can be found at: http://mentors.debian.net/debian/pool/main/p/paflib/paflib_0.2.0-1.dsc If you do not yet have a sponsor for your package you may want to go to http://mentors.debian.net/sponsors/rfs-howto/paflib and set the Seeking a sponsor option to highlight your package on the welcome page. You can also send an RFS (request for sponsorship) to the debian-mentors mailing list. Your package page will give your suggestions on how to send that mail. Good luck in finding a sponsor! Thanks, -- mentors.debian.net
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Gianfranco, 2015-08-21 22:15 GMT+08:00, Gianfranco Costamagna costamagnagianfra...@yahoo.it: so basically the tarball found with uscan has nothing in common with the actual Debian packaging? you grab the tarball, you add a build system and you pack again, right? Actually no. I think this needs clarification. The upstream tarball contains .c .h files and some (non-dfsg-compliant) temporary files. The repack script removes the (non-dfsg-compliant) temporary files and move all the .c .h files into a directory called src/. The build system and friends are added by patches (among those 29 patches). nothing, if it is internal used, and not meant to be called by an user it is fine Exactly, it is called internally by debian/watch. actually the pourpose of the watch file is to notify at each new upstream release, but in that way... not sure if we can make it work I think it is okay, just remember to update the version string before every upload since we cannot *compute* the date string (12.11.2014) from the version string (14.1). The version string actually means 1st release in 2014... maybe I didn't explain myself well lines such as # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # “Software”), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # shouldn't (in my opinion) have the starting # I see! I will remove those `#' then. not a problem for me :) Great! This time is much shorter though. Cheers Alex
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Package: sponsorship-requests Severity: wishlist Hi mentors, I am looking for a sponsor for my package mlucas, I have uploaded a new version of the package to fix issues pointed out by Jakub Wilk, please see previous message in the bug report to see what issues are fixed I will now elaborate more on why this package is suitable for Debian, feel free to skip it __BEGIN_ELABORATION__ Great Internet Mersenne Prime Search (GIMPS) is a collaborative project of volunteers who use freely available software to search for Mersenne prime numbers (quote from Wikipedia). The most popular client `mprime' was available in Debian Potato as the package `prime-net' as shown in this post http://www.mersenneforum.org/showthread.php?t=7181. However, it appears the maintainer had lost interest in it because it was classified as `non-free'. `mlucas' has been developed as an alternative since 1996. While it is not as efficient as `mprime', it is licensed under GPL-2+ and thus suitable to be included in `main'. It has been used in the verification of various Mersenne primes, including the 45th (found in 2008), 46th (found in 2009) and 48th (found in 2013) found Mersenne prime. Therefore, the underlying algorithm is believed to be reliable, thus suitable to be included in Debian. __END_ELABORATION__ * Package name: mlucas Version : 14.1+dfsg-1 Upstream Author : Ernst W. Mayer ewma...@aol.com * URL : http://hogranch.com/mayer/README.html * License: GPL-2+ Section : math It builds those binary packages: mlucas - program to perform Lucas-Lehmer test on a Mersenne number To access further information about this package, please visit the following URL: http://mentors.debian.net/package/mlucas Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/m/mlucas/mlucas_14.1+dfsg-1.dsc Changes since the last upload: mlucas (14.1+dfsg-1) UNRELEASED; urgency=low * Initial release (Closes: #786656) -- Alex Vong alexvong1...@gmail.com Sun, 02 Aug 2015 03:13:37 +0800 Cheers, Alex
Bug#792447: Fwd: Re: Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP]
Forwarded Message Subject: Re: Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP] Date: Fri, 21 Aug 2015 14:25:34 +0200 From: Daniel Stender deb...@danielstender.com To: Gianfranco Costamagna costamagnagianfra...@yahoo.it On 21.08.2015 14:19, Gianfranco Costamagna wrote: Control: tags -1 moreinfo Hi Daniel, I do not remember how we left this one, anyway: now with the llvm stuff being fixed/rebuilt, I asked for a give back of afl, and it is actually building almost everywhere (just arm64 needs investigation, and s390x/kfreebsd-amd64 needs an llvm-toolchain-3.6 rebuild, ongoing right now) How do you feel about updating afl, checking if everything is good and then followup with python-afl? cheers, Gianfranco Hi Gianfranco, ... yes I was thinking about asking you if you would like to make a wrap out of both. AFL build again fine after the latest lvm-toolchain-3.5 update, so that are only the manpages are missing. I'm going to fix the AFL ITA over the weekend and come back then! Thanks! Daniel -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
Bug#792447: RFS: python-afl/0.2.1-1 -- American Fuzzy Lop fuzzy testing for Python code [ITP]
Control: tags -1 moreinfo Hi Daniel, I do not remember how we left this one, anyway: now with the llvm stuff being fixed/rebuilt, I asked for a give back of afl, and it is actually building almost everywhere (just arm64 needs investigation, and s390x/kfreebsd-amd64 needs an llvm-toolchain-3.6 rebuild, ongoing right now) How do you feel about updating afl, checking if everything is good and then followup with python-afl? cheers, Gianfranco Il Lunedì 10 Agosto 2015 11:36, Daniel Stender deb...@danielstender.com ha scritto: On 10.08.2015 11:04, Gianfranco Costamagna wrote: I did a look, and the packaging looks really good (and the upstream maintainer too :) ). However prior to sponsor I would like to see afl working, otherwise it would be not installable on sid. (I'll try to work on llvm side in the next few days) Little (I guess not trivial to fix) nitpick: you might avoid pthread link dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python-afl/usr/lib/python2.7/dist-packages/afl.x86_64-linux-gnu.so was not linked against libpthread.so.0 (it uses none of the library's symbols) dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-afl/usr/lib/python3/dist-packages/afl.cpython-34m-x86_64-linux-gnu.so was not linked against libpthread.so.0 (it uses none of the library's symbols) But I really do not think this is trivial to solve (more a cython problem than a python-afl one IIRC) cheers, Gianfranco Very much welcome! :-) Deal, when you've successfully fuzzed with it we go on with the sponsoring, I'll get into that link issue in the meanwhile. Best, Daniel -- http://www.danielstender.com/blog/ 4096R/DF5182C8 46CB 1CA8 9EA3 B743 7676 1DB9 15E0 9AF4 DF51 82C8
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
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi, Actually no. I think this needs clarification. The upstream tarball contains .c .h files and some (non-dfsg-compliant) temporary files. The repack script removes the (non-dfsg-compliant) temporary files and move all the .c .h files into a directory called src/. The build system and friends are added by patches (among those 29 patches). so can't you ask upstream to integrate the build system and sync with them? it isn't a Debian specific feature, and should be upstreamed IMHO. Exactly, it is called internally by debian/watch. fine I think it is okay, just remember to update the version string before every upload since we cannot *compute* the date string (12.11.2014) from the version string (14.1). The version string actually means 1st release in 2014... the problem is that you don't get notified on new releases, and moreover the versioning that upstream does is simply wrong... can't you ask them to follow the always an higher number versioning? I see! I will remove those `#' then. sorry for that, I'm not a native english speaker :) cheers, G.
Re: Fwd: paflib uploaded to mentors.debian.net
Hi, W: paflib source: changelog-should-mention-nmu if you are nmuing it you need to mention the Non-maintainer upload in changelog. dch --nmu (or similar) does it for you W: paflib source: source-nmu-has-incorrect-version-number 0.2.0-1 same here, 0.2.0-1 is not an NMU number, 0.2.0-1.1 is (nmus adds a .N to Debian revision) https://wiki.debian.org/NonMaintainerUpload P: paflib source: no-dep5-copyright https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/ P: libpaf-dsc0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL GPL means nothing. It might be GPL-1,2,3,1+,2+,3+ or whatever. now GPL symlinks to GPL-3, tomorrow it might refer to GPL-4, and on old systems still on GPL-2. The user should know the correct license, not the license linked on its system. X: libpaf-dsc0: shlib-calls-exit usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 a shared library can't call exit. Simple as it is. I: libpaf-dsc0: no-symbols-control-file usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 e.g. https://wiki.debian.org/UsingSymbolsFiles P: libpaf-dev: copyright-refers-to-symlink-license usr/share/common-licenses/GPL P: libpaf-ebb0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL X: libpaf-ebb0: shlib-calls-exit usr/lib/powerpc64le-linux-gnu/libpaf-ebb.so.0.0.2 I: libpaf-ebb0: no-symbols-control-file usr/lib/powerpc64le-linux-gnu/libpaf-ebb.so.0.0.2 dupes I: libpaf-ebb0: unused-override no-upstream-changelog you have an override that isn't actually used cheers, G.
Bug#795704: RFS: mlucas/14.1+dfsg-1 [ITP] -- program to perform Lucas-Lehmer test on a Mersenne number
Hi Okay. I think this needs further explaination. Upstream does not include a build system, not even a Makefile. Building is done by invoking gcc directly using different flags for different platform. This is however cumbersome, so I add autotools to ease building. I use git for development https://gitlab.com/mlucas-ll/mlucas. The 29 patches can be divided into 3 groups. 0001 - 0012, 0027 are patches related to the source, forwarded upstream to be included in the next version. The rest are patches to add the build system and script to generate man page, NEWS, ChangeLog... Any advice on this? so basically the tarball found with uscan has nothing in common with the actual Debian packaging? you grab the tarball, you add a build system and you pack again, right? I do not understand. What should I do with `source_package_build.bash' ? nothing, if it is internal used, and not meant to be called by an user it is fine Upstream uses Mlucas_MM.DD..tbz2 instead of mlucas_14.1.tar.bz2 for backward capability, so we need to update debian/watch version string for every new release... actually the pourpose of the watch file is to notify at each new upstream release, but in that way... not sure if we can make it work I do it beacuse lintian will complain about empty license if add `License:' in the header paragraph. While lintian will complain about unused license if I seperate the Expat-licnesed files in a seperate file paragraph. What is your recommendation? maybe I didn't explain myself well lines such as # Permission is hereby granted, free of charge, to any person obtaining # a copy of this software and associated documentation files (the # “Software”), to deal in the Software without restriction, including # without limitation the rights to use, copy, modify, merge, publish, # distribute, sublicense, and/or sell copies of the Software, and to # permit persons to whom the Software is furnished to do so, subject to # the following conditions: # shouldn't (in my opinion) have the starting # This email is probably too long... not a problem for me :) cheers! G.
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: paflib uploaded to mentors.debian.net
On Fri, Aug 21, 2015 at 4:37 PM, tfauck tfa...@free.fr wrote: Dear mentors, I am looking for a sponsor for the package paflib I just uploaded (ITP - #781117) http://bugs.debian.org/781117 paflib debuild passes ok, but lintian -EviIL +pedantic gives the following messages: Do I have to sort them out ? lintian -EviIL +pedantic | grep -v ^N: note that if you dont add -I grep should not be needed. -I will help solving the problem if you read the complete text. W: paflib source: changelog-should-mention-nmu W: paflib source: source-nmu-has-incorrect-version-number 0.2.0-1 You should use your name as the maintainer field in debian/control. P: paflib source: no-dep5-copyright Your debian/copyright file almost fits the definitions to be machine readable, so better make some last changes to fix it completely. See https://www.debian.org/doc/packaging-manuals/copyright-format/1.0 P: libpaf-dsc0: copyright-refers-to-symlink-license usr/share/common-licenses/GPL Fist of all, I would advise using the same license for packaging as the package itself. Better link to the exact license: /usr/share/common-licenses/GPL-3 Note that in your text you also write a wrong path (/etc instead of /usr) X: libpaf-dsc0: shlib-calls-exit usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 This is something to report upstream: you probably don't want your program to exit if something goes wrong in a library. I: libpaf-dsc0: no-symbols-control-file usr/lib/powerpc64le-linux-gnu/libpaf-dsc.so.0.0.2 Read about generating symbols: https://wiki.debian.org/UsingSymbolsFiles I: libpaf-ebb0: unused-override no-upstream-changelog You shouldn't override informational lintian tags. Just remove all these overrides. Thanks Thierry
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
Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]
Hugo, I think that makes sense. I will get the dependencies packaged and follow up with the go packaging team. Thanks so much for your time spent on this! Stephen On Fri, Aug 21, 2015 at 2:33 PM, Hugo Lefeuvre hugo6...@fr33tux.org wrote: Hi Stephen, I've had a last look at the source code of the package, and, unfortunately I found something quite annoying: there are lot of external snippets and external libs in the vendors folder. Debian's way of thinking packaging isn't in accordance to it. We should package every piece of code separately; otherwise it may create security and organisational problems. If I upload the package in its current state, it may be rejected by FTP Master. Moreover, it will be hard to maintain this package in the future. The main problem is that packaging these snippets separately will take quite a lot of time and won't be a simple task. I don't have the time to sponsor so many packages. Thus, I'd advise you to get in touch with the Go Packaging Team[0] (#debian-golang on irc.debian.org). They will surely help you to find a solution for your package. They might also decide to upload it. Of course, don't hesitate to ping me if you need some quick review, I'm not far away. :-) Regards, Hugo [0] https://pkg-go.alioth.debian.org/ -- Hugo Lefeuvre (hugo6390)|www.hugo6390.org 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E
Bug#793171: RFS: git-lfs/0.5.2-1 [ITP]
Hi Stephen, I've had a last look at the source code of the package, and, unfortunately I found something quite annoying: there are lot of external snippets and external libs in the vendors folder. Debian's way of thinking packaging isn't in accordance to it. We should package every piece of code separately; otherwise it may create security and organisational problems. If I upload the package in its current state, it may be rejected by FTP Master. Moreover, it will be hard to maintain this package in the future. The main problem is that packaging these snippets separately will take quite a lot of time and won't be a simple task. I don't have the time to sponsor so many packages. Thus, I'd advise you to get in touch with the Go Packaging Team[0] (#debian-golang on irc.debian.org). They will surely help you to find a solution for your package. They might also decide to upload it. Of course, don't hesitate to ping me if you need some quick review, I'm not far away. :-) Regards, Hugo [0] https://pkg-go.alioth.debian.org/ -- Hugo Lefeuvre (hugo6390)|www.hugo6390.org 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: Digital signature
Bug#796395: RFS: rolldice/1.14-1 ITA
Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rolldice * Package name: rolldice Version : 1.14-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : games It builds those binary packages: rolldice - virtual dice roller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rolldice Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rolldice/rolldice_1.14-1.dsc More information about rolldice can be obtained from https://github.com/sstrickl/rolldice Changes since the last upload: rolldice (1.14-1) unstable; urgency=medium * New upstream release (Closes: #74583, #672418) * Removed patch 01_remove_strip.diff - fixed upstream * Removed patch debian-changes-1.10-5 * Don't timestamp the man page * debian/control - Bump standards-version to 3.9.6 - Removed quilt from build-depends - Added libreadline-dev to build-depends - Updated homepage - New maintainer (Closes: #784189)) - Removed article from short description * debian/rules - Remove 'dh_clean -k' in favor of 'dh_prep' - Hardened executables - Add build-arch and build-indep targets -- Thomas Ross th0m4sr...@gmail.com Thu, 20 Aug 2015 20:55:20 -0400 Regards, Thomas Ross signature.asc Description: OpenPGP digital signature
Bug#796395: RFS: rolldice/1.14-1 ITA
I have updated the watch file. The new version is on mentors. Regards, Thomas. signature.asc Description: OpenPGP digital signature
Bug#796030: RFS: tablesnap/0.7.2-1 [ITP] -- Backup utility for the Cassandra database
Ok, I've tested on a clean jessie install and the systemd script works as expected. I also made sure this package will build properly against sid. The python-3to2 packages does not appear to exist in jessie, only stretch and sid. 3to2 is not installed by the python package in sid, only with the python-3to2 package. I can add this as a dependency, but then I won't be able to build for jessie anymore. If I build against sid without the python-3to2 dependency, the resulting deb will install on jessie, but this feels wrong. Is there a simpler way to accomplish this, maybe by just shipping two versions of the scripts upstream? I am also the upstream maintainer, so I can ask myself to make that change :) signature.asc Description: Digital signature
Bug#796030: RFS: tablesnap/0.7.2-1 [ITP] -- Backup utility for the Cassandra database
Hi, Ok, I've tested on a clean jessie install and the systemd script works as expected. I also made sure this package will build properly against sid. wonderful The python-3to2 packages does not appear to exist in jessie, only stretch and sid. 3to2 is not installed by the python package in sid, only with the python-3to2 package. I can add this as a dependency, but then I won't be able to build for jessie anymore. If I build against sid without the python-3to2 dependency, the resulting deb will install on jessie, but this feels wrong. I can backport, but this is wrong. Is there a simpler way to accomplish this, maybe by just shipping two versions of the scripts upstream? I am also the upstream maintainer, so I can ask myself to make that change :) yes, use 2to3 at build time, it is available in python package (I guess) and converts the code to use python3 features/style. I can backport 3to2 if needed, of course :) cheers, G.
Bug#796395: RFS: rolldice/1.14-1 ITA
I have updated the copyright file to conform to dep5. The new version is on mentors. Regards, Thomas.
Bug#796395: RFS: rolldice/1.14-1 ITA
Whoops, forgot to fill in some details: Upstream Author : Stevie Strickland sstri...@cs.brown.edu * URL : https://github.com/sstrickl/rolldice * License : GPL-2 On 21/08/15 01:47 PM, Thomas Ross wrote: Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rolldice * Package name: rolldice Version : 1.14-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : games It builds those binary packages: rolldice - virtual dice roller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rolldice Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rolldice/rolldice_1.14-1.dsc More information about rolldice can be obtained from https://github.com/sstrickl/rolldice Changes since the last upload: rolldice (1.14-1) unstable; urgency=medium * New upstream release (Closes: #74583, #672418) * Removed patch 01_remove_strip.diff - fixed upstream * Removed patch debian-changes-1.10-5 * Don't timestamp the man page * debian/control - Bump standards-version to 3.9.6 - Removed quilt from build-depends - Added libreadline-dev to build-depends - Updated homepage - New maintainer (Closes: #784189)) - Removed article from short description * debian/rules - Remove 'dh_clean -k' in favor of 'dh_prep' - Hardened executables - Add build-arch and build-indep targets -- Thomas Ross th0m4sr...@gmail.com Thu, 20 Aug 2015 20:55:20 -0400 Regards, Thomas Ross signature.asc Description: OpenPGP digital signature
Bug#790125: RFS: dropbear/2015.67-1.1 NMU
Hi Gianfranco,
On Thu, 20 Aug 2015 at 07:23:55 +, Gianfranco Costamagna wrote:
I didn't follow the thread, and seems that other DDs are already caring of
this one, so I would just put my .02$ (and let me know if you need a review
or help).
Thanks! So far only Helmut has given feedback and offered to have
another look when time allows. I'll ping you if there is no follow-up
by the end of the month or so. (That said I wouldn't mind more eyeballs
looking at the package either ;-)
2) what about updating to the latest version and upload on experimental?
I don't see all this need to go for unstable, I might even sponsor an
experimental upload
because if Gerrit is not satisfied he can continue and upload his version to
unstable,
and experimental will disappear automagically.
Isn't this one the experimental suite pourpose?
We are still in the Stretch early stage, we might delay unstable until other
folks tested it.
If by “update to the latest version” you meant my dropbear-{bin,run,initramfs}
packages,
you'll find them there:
dget -x
http://mentors.debian.net/debian/pool/main/d/dropbear/dropbear_2015.68-0.1.dsc
Cheers,
--
Guilhem.
signature.asc
Description: Digital signature
Re: paflib uploaded to mentors.debian.net
On 2015-08-21 17:21, Johan Van de Wauw wrote: On Fri, Aug 21, 2015 at 4:37 PM, tfauck tfa...@free.fr wrote: Dear mentors, I am looking for a sponsor for the package paflib I just uploaded (ITP - #781117) http://bugs.debian.org/781117 paflib debuild passes ok, but lintian -EviIL +pedantic gives the following messages: Do I have to sort them out ? lintian -EviIL +pedantic | grep -v ^N: note that if you dont add -I grep should not be needed. -I will help solving the problem if you read the complete text. Sorry, but you are confusing -I with -i. The -i is the show tag descriptions (vs. -I is --display-info). To avoid the grep, just use: lintian -EIL +pedantic Thanks, ~Niels
Bug#796395: RFS: rolldice/1.14-1 ITA
Oops, it looks like I missed the format header in the copyright file. Unfortunately I will not be able to fix this until Sunday. Regards, Thomas On Friday, 21 August 2015, Thomas Ross th0m4sr...@gmail.com wrote: I have updated the copyright file to conform to dep5. The new version is on mentors. Regards, Thomas.
Bug#796395: RFS: rolldice/1.14-1 ITA
Hi Did you mean to close the bug? About the dep5 copyright issue, yes, I accidentally left out the header. I will fix the use-flag patch as you described. About the man page, the reason I didn't have it be installed by dh_manpages is the man page is edited in the Makefile, adding the version number (see make target 'man'). Should I add the version number myself and have it be installed by dh? Regards, Thomas On Friday, 21 August 2015, Gianfranco Costamagna locutusofb...@debian.org wrote: Control: owner -1 ! Control: tags -1 moreinfo Hi Thomas, the version in mentors has no dep5 copyright. Bonus point for having a dh rules file (seems trivial) another problem regarding the use-flag patch. - $(CC) $(OBJFILES) -g -o rolldice $(LIBS) + $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(OBJFILES) -g -o rolldice $(LIBS) I would move LDFLAGS at the end, near LIBS, because otherwise they might be stripped by the linker (not sure, but I guess the linker might strip libraries if the previous object files in the command line are not using them) BTW do you install the manpage? I guess you might want to install by dh_manpages, the same for installdocs... I guess a dh default call might do everything the rules file does right now after that I guess it is good (note I still need to check the copyright and to build it) BTW License: GPL-2+ License: GPL-2 you need to describe the same license as above, not a different one :) (it might be fixed in the dep5 copyright that hasn't been uploaded, don't know) cheers, G.
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
Bug#796395: marked as done (RFS: rolldice/1.14-1 ITA)
Your message dated Fri, 21 Aug 2015 21:20:34 + (UTC) with message-id 590873325.376112.1440192034567.javamail.ya...@mail.yahoo.com and subject line Re: Bug#796395: RFS: rolldice/1.14-1 ITA has caused the Debian Bug report #796395, regarding RFS: rolldice/1.14-1 ITA to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 796395: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796395 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: normal Dear mentors, I am looking for a sponsor for my package rolldice * Package name: rolldice Version : 1.14-1 Upstream Author : [fill in name and email of upstream] * URL : [fill in URL of upstreams web site] * License : [fill in] Section : games It builds those binary packages: rolldice - virtual dice roller To access further information about this package, please visit the following URL: http://mentors.debian.net/package/rolldice Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/r/rolldice/rolldice_1.14-1.dsc More information about rolldice can be obtained from https://github.com/sstrickl/rolldice Changes since the last upload: rolldice (1.14-1) unstable; urgency=medium * New upstream release (Closes: #74583, #672418) * Removed patch 01_remove_strip.diff - fixed upstream * Removed patch debian-changes-1.10-5 * Don't timestamp the man page * debian/control - Bump standards-version to 3.9.6 - Removed quilt from build-depends - Added libreadline-dev to build-depends - Updated homepage - New maintainer (Closes: #784189)) - Removed article from short description * debian/rules - Remove 'dh_clean -k' in favor of 'dh_prep' - Hardened executables - Add build-arch and build-indep targets -- Thomas Ross th0m4sr...@gmail.com Thu, 20 Aug 2015 20:55:20 -0400 Regards, Thomas Ross signature.asc Description: OpenPGP digital signature ---End Message--- ---BeginMessage--- Control: owner -1 ! Control: tags -1 moreinfo Hi Thomas, the version in mentors has no dep5 copyright. Bonus point for having a dh rules file (seems trivial) another problem regarding the use-flag patch. - $(CC) $(OBJFILES) -g -o rolldice $(LIBS) + $(CC) $(CPPFLAGS) $(CFLAGS) $(LDFLAGS) $(OBJFILES) -g -o rolldice $(LIBS) I would move LDFLAGS at the end, near LIBS, because otherwise they might be stripped by the linker (not sure, but I guess the linker might strip libraries if the previous object files in the command line are not using them) BTW do you install the manpage? I guess you might want to install by dh_manpages, the same for installdocs... I guess a dh default call might do everything the rules file does right now after that I guess it is good (note I still need to check the copyright and to build it) BTW License: GPL-2+ License: GPL-2 you need to describe the same license as above, not a different one :) (it might be fixed in the dep5 copyright that hasn't been uploaded, don't know) cheers, G.---End Message---
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: porter machine: ssh connection: SSH pub keys
Hello Bas: On 20/08/15 09:45, Sebastiaan Couwenberg wrote: On 20-08-15 00:51, Jerome BENOIT wrote: I keep getting the error message: Error: Unable to check the signature or the signature was invalid: == class 'userdir_exceptions.UDFormatError': UDFormatError: Signing key (80BFC3820C4B26E3, Jerome) has expired But my key has not expireed. On the other hand, it was renewed a few month ago. https://pgp.mit.edu/pks/lookup?op=vindexsearch=0x80BFC3820C4B26E3 I suspect you didn't push your updated key to the Debian keyserver. Make sure to send it to keyring.debian.org: gpg --keyserver keyring.debian.org --send-keys your key id See also: https://www.debian.org/events/keysigning It appeared that my subkey was expired: the issue was easily solved once isolated. Thanks a lot for your replies. Cheers, Jerome Kind Regards, Bas
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
Bug#796296: marked as done (RFS: node-os-tmpdir/1.0.1-1 [ITP])
Your message dated Fri, 21 Aug 2015 08:02:50 + (UTC) with message-id 669933142.8662468.1440144170933.javamail.ya...@mail.yahoo.com and subject line Re: Bug#796296: RFS: node-os-tmpdir/1.0.1-1 [ITP] has caused the Debian Bug report #796296, regarding RFS: node-os-tmpdir/1.0.1-1 [ITP] to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 796296: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=796296 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ---BeginMessage--- Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package node-os-tmpdir * Package name: node-os-tmpdir Version : 1.0.1-1 Upstream Author : Sindre Sorhus sindresor...@gmail.com * URL : https://github.com/sindresorhus/os-tmpdir * License : Expat Section : web It builds this binary package: node-os-tmpdir - Node.js os.tmpdir() ponyfill To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-os-tmpdir Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-os-tmpdir/node-os- tmpdir_1.0.1-1.dsc The packaging can also be found here: https://anonscm.debian.org/cgit/pkg-javascript/node-os-tmpdir.git Changes since the last upload: * Initial release (Closes: #785462) Please note that I am now a DM. So after initial sponsorship, you could grant me upload rights once you are happy with my work on the package. Regards, Ross Gammon -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), (100, 'vivid-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-26-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) ---End Message--- ---BeginMessage--- Hi Ross, the packaging looks good, BuiltSignedUploaded, thanks for your contribution to Debian! Please note that I am now a DM. So after initial sponsorship, you could grant me upload rights once you are happy with my work on the package. sure, maybe ask directly to me to see some of your work, and after some uploads the rights will follow. Actually I see you maintain already more than 20 packages in main, and for some of them you already have DM permissions, so you seem to be already doing a good job :) cheers, G.---End Message---
Re: Looking for a mentor for the OpenSIPS project
Hello guys,
Sorry but yestarday I was in the Debconf dinner. Right now I am at
#debian-opensips in irc.debian.org
Kind regards,
--
Julián Moreno Patiño
Debian Developer
.''`. Debian GNU/{Linux,KfreeBSD}
: :' : Free Operating Systems
`. `' http://debian.org/
`- GPG Fingerprint:
C2C8 904E 314C D8FA 041D 9B00 D5FD FC15 6168 BF60
Registered GNU Linux User ID 488513
Bug#793876: RFS: chrony/1.31.1-1
Hi Vincent, [I am merging the e-mails you send yesterday to make the thread easier again.] On 20-08-15 18:12, Vincent Blut wrote: Le jeu. 20 août 2015 à 12:10, Paul Gevers elb...@debian.org a écrit : On 19-08-15 21:29, Vincent Blut wrote: Please add the CVE numbers that were fixed by upstream to your changelog such that the trackers can find it automatically. TIP: if you would have done that and mention that in your RFS you would have probably found a sponsor earlier. I didn’t include them because those fixes have been backported to chrony 1.30-2 in Debian (thanks Joachim btw) and consequently the CVE numbers have already been mentionned in this release’s changelog. Ack. Your priority switch from extra to optional may require a ping to somebody. I am not sure and I would need to search, so please do that yourself. Yes. I’ll have to send a bug report to the ftp.debian.org pseudo-package asking for the modification of the section/priority in the override-file. Will do later today… or tomorrow. Ack. Which file do you have in common with ntp? Please re-read ¹. I guess I’ve been misled by § 7.6.2! The previous section shows the usage of the 'replaces:' field for packages providing *files* already provided by another package. However, the section 7.6.2 seems to be for *packages* that /do conflict/; I interpreted that /do conflict/ by packages providing the same functionality. I even was quite sure my interpretation was correct after seeing the usage example about MTAs. I didn't check if ntp is also doing the conflicts/replaces/provides dance on time-deamon. If so I than you don't need to mention ntp specifically at all¹¹. Anyway, depending on your answer, I’ll revert this commit. Lets not do that until we agree. :) I assume that the change of maintainership has the consent of Joachim? Yes, we’ve discussed about this privately some times ago. Still ok Joachim? Ack on the other mail of Joachim. Wouldn't the hwclockfile stuff in /etc not warrant an debian/NEWS update? Or at the very least some help in the changelog? I don’t think so. Finally, that change have no impact for the user. Previously we had to check (in the postinst script) if the RTC keeps local time or UTC by parsing /etc/adjtime and/or /etc/default/rcS. Depending on the result, we set (or no) the rtconutc directive in /etc/chrony.conf. But now chrony is grown enough to check that by itself. Each time it is started, it will parse the correspondent value in the /etc/adjtime file. So, as you can see, the whole point of using the hwclockfile directive is to have something cleaner than playing the text processing game for the same result. Doesn't this actually require a migration path? What if the /etc/chrony and /etc/adjtime are NOT answering the same? Well, I’m not sure I’m understanding you here. The chronyd daemon will use what /etc/adjtime returns, thanks to the 'hwclockfile /etc/adjtime' directive. Oh, you not understanding me makes sense. It was me who didn't understand what you were doing. I was assuming there now was a new mechanism, but now you explained it is just a better implementation of the same thing. But then again, maybe make that a little clearer in your changelog for others like me? Can you please explain me how commit 1ce86d3 works (the Breaks of util-linux). As the hwclockfile directive can only deal with /etc/adjtime, we need to ensure that we migrated from /etc/default/rcS to /etc/adjtime. To be honest, I’m not sure that break is even needed, because this migration happened prior to Wheezy. I haven't looked it up, is util-linux in essential? Otherwise, shouldn't you depend on it with the higher than dependency? I assume you tested all migrations for admins that already ran chrony as a different users as described in the README.Debian. Are the manual steps even needed? Shouldn't this go into a NEWS file instead of the README file? I tested a lot of use cases, but Jerome Benoit informed me he had an issue possibly related to this change, but as he uses a custom init script etc., I will have to check his atypical configuration. Ack. Line 36 of the README.Debian file ends weird now, you removed a filename but not the and in front. Indeed, will fix. You mean line 27 right? I am talking about The scripts /etc/ppp/ip-up.d/chrony, /etc/ppp/ip-down.d/chrony, and read key 1 from /etc/chrony/chrony.keys and use it as the password to send chronyc commands. In my version that is on line 36. Nice to have, could you think of some autopkgtest test²? And why are the tests disabled. Unless they fail and can't be fixed, it is really recommended to run them. I’m definitely interested in autopkgtest. However I’ll need some times to dive through its meanders. I don’t known why tests have originally been disabled, but I guess it’s because they depend on the clknetsim tool which is not packaged in Debian. Also, if that tool isn’t installed on
Bug#796296: RFS: node-os-tmpdir/1.0.1-1 [ITP]
Package: sponsorship-requests Severity: wishlist Dear mentors, I am looking for a sponsor for my package node-os-tmpdir * Package name: node-os-tmpdir Version : 1.0.1-1 Upstream Author : Sindre Sorhus sindresor...@gmail.com * URL : https://github.com/sindresorhus/os-tmpdir * License : Expat Section : web It builds this binary package: node-os-tmpdir - Node.js os.tmpdir() ponyfill To access further information about this package, please visit the following URL: http://mentors.debian.net/package/node-os-tmpdir Alternatively, one can download the package with dget using this command: dget -x http://mentors.debian.net/debian/pool/main/n/node-os-tmpdir/node-os- tmpdir_1.0.1-1.dsc The packaging can also be found here: https://anonscm.debian.org/cgit/pkg-javascript/node-os-tmpdir.git Changes since the last upload: * Initial release (Closes: #785462) Please note that I am now a DM. So after initial sponsorship, you could grant me upload rights once you are happy with my work on the package. Regards, Ross Gammon -- System Information: Debian Release: jessie/sid APT prefers vivid-updates APT policy: (500, 'vivid-updates'), (500, 'vivid-security'), (500, 'vivid'), (100, 'vivid-backports') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.19.0-26-generic (SMP w/4 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
Bug#793876: RFS: chrony/1.31.1-1
Hi On 20-08-15 22:33, Joachim Wiedorn wrote: Hello Vincent, Vincent Blut wrote on 2015-08-20 18:36: features. By the way, if I want to close these outdated bug reports, what’s the canonical way to do it? I guess I can’t do that from d/changelog? do it in the changelog: e.g. LP: #1313200 I think Vincent means bugs that are closed in a previous upload. Just send a mail to bug-number-d...@bugs.debian.org¹. Paul ¹ https://www.debian.org/Bugs/Developer#closing signature.asc Description: OpenPGP digital signature
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
